I have a login page on my symfony2 application.
That only users in an remote active directory can connect.
And I would like to create a user on my oracle database for every new user who connect on my app.
How can I handle that ?
Im using FOSUserBundle and the LDAP Component
I can't find a way to hook the login success to implement an user creation or orverride the symfony ldap core component.
Thanks for your helps
Related
So i have Symfony 4 app which should allow login via LDAP and based on your groups modify some of the values in this ldap directory.
The Login itselfs, and mapping from Ldap Groups to ROLE_ works perfectly.
The idea was that only the currently logedin user does a modification. Not a hidden Directory Admin.
For this i would need to $ldap->bind() with the user credentials each time a loged in user wants to modify the directory.
But for this i would need the password. The only way i could think of, would be to save the password in the session - but form a security standpoint this would be a very very bad idea.
Is there any other way? Like store the already binded connection somehow?
As far as I see in the Symfony security component - the UserProvider only refreshes the user from sesison - without calling ldap again.
The LdapBindAuthenticationProvider only uses the ->bind() call with the given credentials and catches an exception if password doesnt match.
But the connection itself is a simple fire & forget.
I have a Wordpress/WooCommerce installation using Wordpress itself for authentication. I want to switch to LDAP-based authentication (e.g. OpenLDAP). How can I migrate existing users with minimal intervention on their part?
Ideally they would simply continue using their pre-existing credentials for Wordpress and for any other resources using the same LDAP database.
In addition, new users created via WooCommerce purchases should be created as LDAP users.
(Existing plugins like Simple LDAP Login seem to handle creating Wordpress users for pre-existing LDAP credentials just fine. I'm looking for support in the other direction.)
I think you'll have to develop this task yourself. You could check tools like : https://lsc-project.org/start which will allow you to configure mapping and synchronising SQL database to LDAP directory and schedule the task regularly (or trigger it on new row in the DB)
Only point where you could have some problem would be the "keep their credentials". I don't know wordpress, but if the hashing and/or crypting mechanism of the passwords are not natively supported by OpenLDAP, you will have to hash the clear password of the user to store it with a mechanism compatible.
One way would be to tell every user that the password will be reset and that they will have to retype it (some custom landing page where you authenticate the user with his credentials on the wordpress DB and if successful write the password on the LDAP)
Another way would be to deploy some self service password with all account reset and a need to re-set them with a link send to their email (from the LDAP). There are tools like that, for example : https://ltb-project.org/documentation/self-service-password
Follow Esteban's advice I developed a solution as follows:
Wordpress interface
Install Simple LDAP Login
Install JWT Authentication for WP REST API
Users authenticate against LDAP, fall back on Wordpress
"Change password" sends them to new interface
New interface
User logs in via new interface
Users authenticate against LDAP, fall back on:
Authenticate against Wordpress via JWT. On success:
Create LDAP user (we have the password)
Delete Wordpress password hash (no longer needed, forces LDAP-based authentication in future)
Workflow
Existing users can sign in via Wordpress or the new interface. Once they use the new interface (to sign in or change their password), they are migrated to LDAP-based authentication.
New users are registered in LDAP. They can sign in via Wordpress or the new interface, both backed by LDAP.
I have successfully set up the FOSUserBundle and the FR3D LDAP bundle to allow my company users to login to the web app with their own login.
From now, if someone logins, they will have the default role, which is ROLE_USER.
However, I only want a specific role to be allowed (in this case it's ROLE_CONSULT, which I created).
What I am doing to allow users at this moment is:
Ask the user to login to the web app
They get the "You have no right to access this web page"
They tell me he connected
I change the user's role to "ROLE_CONSULT" with a form I created within the admin panel.
What I want to do is:
I select the user from the LDAP list
Change the user role (which is not on the database yet, but will be as soon as I change the role)
The user logins successfully
I already developed the 1 and 2 points, but as the "salt" is empty on the database, it doesn't allow the user to connect as it must believe the password isn't correct.
Any idea how I can make it work by telling Symfony2 it is the first login, it will automatically ONLY check the entered password at my LDAP configuration ?
Thanks.
Alright, that was easy.
I just forgot to put the "DN" to the database.
Now it's working.
I'm developing an ASP.NET MVC application. I need to support multiple authentication mechanisms (this app is used by multiple customers, each with their own preferred authn provider). One auth provider will be Active Directory. The AD integration for authentication is straightforward and I have no problems with that.
For authorization, roles will be stored in a local database (NOTE: we cannot use Active Directory groups for doing authorization - roles need to be local application roles because we support multiple authn providers and AD admins won't want to create custom groups in AD just for our app). My expectation is that we will need to create "stub" user accounts in our local database in order to do the User-is-assigned-which-Roles mapping. These stub user accounts will also be used to indicate which users are authorized to access the application (not everyone in the AD database should have access).
The anticipated flow of control will be:
User accesses login page > enters credentials > posts credentials to app server.
The app validates the credentials against AD. At this point, we know if the user is authenticated.
The app checks the user's SID to see if a "stub" user account with that SID exists in the local database. If not, the app displays an "not authorized" error message to the user.
The app will look up roles for the user in the local database user-is-assigned-which-roles table.
User identity info including roles will be stored as claims and the app will use typical claims based authorization (i.e. ClaimsAuthorizationManager).
My question is what is the best way to create "stub" user accounts into my local database? My guess is that we should use some sort of AD export script to export AD accounts for those users that should be granted access to the ASP.NET app and then import those users into the local database (NOTE: I expect that the stub account will contain minimal info - perhaps just the user's SID from AD and maybe the username).
A batch export/import is probably OK as an initial deployment process. After the app is up-and-running and new users join the organization, I expect a more user-friendly mechanism will be desired for granting a new user access to our app (other than exporting/importing the new user's account from AD to our local database). My guess is that we'll need some sort of user browser screen so that an admin in our app can browse the AD directory, select a user, click a button and then have that user's "stub" account created automatically in our app.
Has anyone implemented an application with similar requirements? If so, how did you bootstrap the creation of "stub" accounts in your local database? Is there a better way to address these requirements?
Please feel free if this can Help You Custom Annotation Authorization
It's only a workaround, or just an idea, not a solution...
To use it you only need to use Annotation in the controller
e.g.
[ARQAuthorize]
public class BlaBlaController : Controller .....
I am currently implementing a similar solution. Here is how the application works. I'm using ASP.NET MVC 5, ASP.NET Identity 2.2.1.
I am using the Identity framework to manage users and roles within the application. The user goes to a login page, enters their credentials. The application checks against the application DB to see if the user exists. If not it throws an error that the user doesn't exist in the database. If the user exists, it authenticates against AD. If authentication fails they get an error message, if it doesn't fail I create a ClaimIdentity from the user out of the database (not the user in AD) and pass that to my SignIn method.
My user in the application DB has the same username as the AD username and I use that as my stub. I also include the domain of the user in the DB as well in the case that I might have multiple domains I need to support. With Identity, don't forget to also populate the SecurityStamp field with a guid.
The plan is to bulk import the users and permissions from a spreadsheet and I have some standard CRUD actions created to allow creation of individual users and assigning of roles after that.
Background: I'm using Open ID authentication in my asp.net website. Here is how it works currently - User would pick an Open ID provider from dropdown (google/yahoo/myopenid/etc..) and then click on Login button. The application would then pass the user to the provider authentication page. On successful authentication and authorization on the open ID provider site, user is directed to my application. So far, so good.
Problem: On the Open ID provider authentication page, if the user chooses/clicks Sign Up, then the provider is following its own workflow and the control never returns to my application.
Question: Is there a way where I can disable the dynamic registration on provider (i.e., the Sign Up)?, so that, the user would then be required to register with the provider and then use my application? Or
Is there a way that I can get the control back once the dynamic registration is done?
No. The OpenID protocol has no such provision and while it would be courteous of a Provider to remember to ultimately redirect their new user back to your site, not all do.