I have a Catalyst application that I recently created. I based the original authentication model on the example given in the Catalyst example using "SimpleDB". I am also using the Authorization::Roles module to permission users in specific application roles.
Now I need to move to LDAP authentication. I need to use LDAP to authenticate the user, but the user should still have a row in the User table to validate that the user is allowed to use the application. Also, the application should still lookup the User Roles from the Role table to determine what roles the user is allowed.
My question is: I have read that dropping in the Catalyst LDAP authentication module is pretty much Plug-N-Play, but will the application still use the User/Role tables that are already defined in the application?
Related
We want to integrate Keycloak 18 in our platform to replace a self-implemented solution in the future. The first step was to implement an own user provider to keep our existing tables where users, roles and permissions are stored. This was pretty easy. So the old and new way can co-exist for a step-by-step replacement.
Now we also want to provide integrations for other user providers, like LDAP, Kerberos etc.
Is there a way to load the roles from our external db table after a user was authenticated by a random user provider?
e.g.:
User sends auth request to keycloak
User has been successfully authenticated by the ldap user provider
lookup external db to get the roles for the username and add them to the user model
thank you for your help
We have an existing web application which works with its own users, stored in a local SQL server database and each user has specific rights to access specific content.
A new customer is interested in using this application, but their requirement was that it should have SAML 2.0 integrated.
Now, I'm new to SSO, but I assume they want this so all user management is done at their place and that their users can log on at any of their services, using the same credentials.
The user rights defined at our web application however, are application specific; they have no meaning outside our application. So I assume these fields should remain stored and managed at our end, instead of managed at the identity provider?
But what would be the best way initiate this? I could create an empty user record locally whenever the user logons for first time, but he would literally not be able to do anything without proper rights. I could give him default right settings, but there should be at least 1 administrator to distribute the rights of the remaining users. Is it common to ask additional fields at the identity provider to initiate users for a specific service?
This can be done using entitlements sent in a SAML2 attribute. e.g. if you have a normal user profile for your application, you can ask the IdP to release an attribute such as eduPersonEntitlement or urn:oid:1.3.6.1.4.1.5923.1.1.1.7 as it's known in SAML2. If the IdP owner agrees to release this attribute you can agree a controlled vocabulary with them for the value of the attribute.
So when a normal user logs in to your application using SAML2 and their attributes arrive in an AttributeStatement with a collection of SAML2 Attribute instances you can look for urn:oid:1.3.6.1.4.1.5923.1.1.1.7. If it has a value of, perhaps, https://yourapp.com/entitlement/user you can set them up with a normal user account. If they have a value of, perhaps, https://yourapp.com/entitlement/admin, you can set them up with admin rights.
Just be careful to compare what they already have (if anything) with their incoming SAML2 entitlement, in case they longer are an admin. The IdP decides who is a normal user and who is an admin but that's up to them to work that out. All you care about is the value of urn:oid:1.3.6.1.4.1.5923.1.1.1.7
The full set of eduPerson attributes is here
I have a web application that I would like to use authenticate using MembershipReboot for a subset of users but internally I would also like to use Active Directory.
What's the best practice of authenticating a single web application with two different authentication models? Any code samples would be great.
For this scenario you'll need a UserService for Membership Reboot. This will mean when users log in to Identity Server using the local username & password fields they will use Membership Reebot. You can find this UserService here.
To also use Active Directory you need to configure it as an external identity provider. This will then provide users with the option to log in using their AD credentials.
If you want to specify in your requests which provider to log the user into, check out the acr_values parameter of the Authorization endpoint or the IdentityProviderRestrictions property of the Client class.
What are best practices for maintaining roles (e.g., a user-provisioning role) in a Web application that uses OAuth 2.0 authentication against a Google App domain? These are roles that are tied to a specific Web application, rather than to the domain as a whole.
Is role management at the application level typically done using the application's backend database, once the OAuth Web flow authorization has been completed? I was thinking of using a Google App group to stand in for each role and then verify membership in the group using the Directory API before allowing an action to be carried out. Is this a suitable approach? This requires either a service account with a group-membership privilege or the assigning of such a privilege to each user in the domain with that role, which are steps that would be nice to avoid.
Is there an API to read information about Google App's native domain-level roles for this? Should custom properties on the user's profile be used? If the latter, is there a straightforward way for a domain admin to set these up when provisioning a new user in the domain, or will a separate UI need to be built out? I've noticed that in the user profile information there is a isDelegatedAdmin field, but that field is a boolean, and I have not found anything with more granular information on the roles delegated to the user account.
We are a service provider. Suppose in our application, we originally have our own user/role management. Different users with different roles are allowed to use different features. So that when a user login we need to know which roles this user has, and prepare appropriate UI. We have administrator role, users with this role can assign roles to other users.
We are thinking of enabling SAML SSO for our application, now the problem is how do we setup roles for each user.
Solution 1, we relies on IdP to provide role information for each login user, the role information may come along with Assertion, but this may not work for all the IdPs.
Solution 2, we only retrieve user from the IdP, and manage the roles in our own application. For example, when we get an Assertion, we retrieve the username(or email address), and match with a record in our DB, if it doesn't exist we automatically create one for this new user. Then we rely on users with administrator role to assign correct role for this new user.
Now the questions is where is the first administrator coming from? Our customer gets our application, and turns on SAML SSO, now there is no users in the DB yet, then how can we resolve such bootstrapping issue? Is there any kinds of standard way? We have come up with different options but not sure which is better and what are the concerns for each options.
Option 1, have a default built-in administrator user. There is a regular native login page that built-in users can login without going through IdP(there is an option to turn it on/off if SAML SSO is enabled)
Option 2, during SAML SSO setup, ask for the administrator user name, so that we automatically create this user in our DB with administrator role. Then when this user login through IdP we could match him in our DB.
What are the other options?
For your first question about who should handle the roles. As I understand every customer has your One of your service provider software. And it connects to a central IDP that you own. If this is the case, it feels like its to complex letting the administrators handle roles on your IDP. I would go for number two.
About question number two. I have been in the same situation I can not remember that I have seen a obvious standard solution for this.
What we did was option 2. It works fine but it adds some complexity to the install procedure. We choose it because we would not have a native login page.
I thing maybe I would be better to go with option 1.
You can get the roles from the different directories of your IDP using your authorization layer. It removes the constraints on SAML and gives the same results as your solution 1.