Keycloak 20.0.0
Problem: I have 2 types of Groups in my Keycloak setup.
Locally created Groups (from Keycloak)
LDAP imported Groups
Issue: How do I differentiate between both types of groups in my application? I need to store the source of the LDAP server configurations against LDAP groups in my application database.
Things tried:
I tried adding attributes to "Mapped Group Attributes" in Keycloak assuming it will add those specified attributes against Imported LDAP Groups but that is not working.
Other than this I have tried going through several posts/discourse/JBoss docs but a similar problem is not reported earlier. I am wondering how it works if Keycloak has more than one LDAP configured and the application needs to know the source of the Group.
In the case of Users, I can see additional LDAP-specific Attributes but nothing in the case of Groups.
I don't want to have to fetch a user of a given LDAP imported group, find the LDAP mapping there and store it against Group. Feels like overkill and it seems that I am missing some configuration and this should be an obvious feature.
Please assist.
Related
I have connected Wso2 ti an external LDAP. Through the admin panel i can see the users and roles that are fetched from LDAP.
However when requesting groups using Scim Api like
https://10.4.0.17:9443/wso2/scim/Groups
only groups that belong to the internal PRIMARY UserStore are fetched.The problem is that i use the external LDAP UserStore as my main UserStore.So i should not get any groups from that UserStore.
How do i configure Scim to fetch from the external LDAP instead of the internal PRIMARY ?
I had a similar question. At the moment at least for Readonly LDAP, groups are not added to the internal DB. You can add it manually to the DB.This is of course not a solution and I filled an issue on github. If you are still interested in a fix, you can upvote the issue.
Via Passport's plugins I am able to connect my LDAP databases to LoopBack for authentication purposes.
In my current setup, I have a set of groups in LDAP that creates authorization for other services. For example, I have a chat group, which define which user can use our internal chat server.
My goal here is to reduce the redefinition of groups. I would like to only have one place where every group/role are defined, so for that I would like to match all my LDAP's group as Roles in LoopBack.
Is there a way to map those groups as Roles for LoopBack? And if so, is there an example of such behaviour/configuration somewhere online?
Ideally, I would be able to do the same for ACLs, as I can also store those in the LDAP databases.
I'm a newbie in the LDAP + Liferay + OpenAM world, so I wonder if someone could point me in the right direction in a problem I have. In a real life environment, there are 2 LDAP servers, a OpenAM server and a Liferay application. What the customer needs is to authenticate users in Liferay against OpenAM, and OpenAM should use the LDAP servers. Problem is, the user exists only in one of the LDAP servers (it will be moved from one to the other in one point of the future). What the customer wants is:
Users must be able to authenticate independently of what LDAP contains the user.
The obtained token must be valid for both LDAP servers, as it will be used in a different service (I have no control over it) against only one of them to validate authentication.
As I said, I'm new to this world so, if the answer is too complex (I'm afraid it will be for me), maybe you could point me to books or docs that could resolve this scenario.
Thanks
You should configure LifeRay to use OpenAM for all authentications and you can configure OpenAM to use both LDAP servers (use different realms).
Details for OpenAM configuration will be in the OpenAM documentation.
As the previous answer states you should route all your authentication requests to the OpenAM server and let it validate the credentials against the right LDAP server. Using two different realms (one for each LDAP server) won't work in your case since that will require LifeRay to know where to find the user before hand. Also, sessions are linked to a specific realm.
There are multiple solutions to your problem. Here are just a couple:
Option 1
If you have control over the authentication flow. That is, if your application uses a custom UI and communicates with OpenAM via REST, you could create two different authentication module instances under a single realm (let's say two instances of the DataStore authentication module) each one pointing to a different LDAP server.
Let's call this module instances DataStore1 and DataStore2. Your application can collect the user credentials (username and password) and submit them to DataStore1. If authentication succeeds the user is already logged in. If it fails, the application can try with DataStore2.
Of course this is not ideal since you'll be making two authentication requests per login instead of just one.
Option 2
A better option (though more complicated to implement) would be creating a custom authentication module. This module can try authenticating the user against LDAP Server 1 and then try with LDAP Server 2 if the first authentication failed. Notice that with this option you don't need custom logic on the application side since it will only send a single authentication request to the OpenAM server. In fact, you can protect your application with an OpenAM Policy Agent.
Another advantage of this approach over Option 1 is that you can migrate your users behind the scenes assuming that the end goal is to migrate users from LDAP Server 1 to LDAP Server 2. If the first authentication succeeds your custom code could read the user entry from LDAP Server 1 and copy it over to LDAP Server 2.
Hope this helps you solve the problem.
I am trying to protect a Java servlet with OpenAM + J2EE tomcat agent. I got this part working by using embedded OpenDJ of OpenAM.
Now I am trying to authenticate against a LDAP server, so I added a LDAP module instance for OpenAM, but I get "User has no profile in this organization" when I am trying use uid/password of an user from that LDAP store.
I checked OpenAM administration guide on this the description is rather brief. I am wondering if it is even possible to do this without using the data store configured for OpenAM?
The login process in OpenAM is made of two stages:
Verifying credentials based on the authentication chain and individual authentication module configurations
User profile lookup
By configuring the LDAP authentication module you took care of the authentication part, however the profile lookup fails as you haven't configured the user data store (see data stores tab). Having a configured data store allows you to potentially expose additional user details across your deployment (e.g. include user attributes in SAML assertions or map them to HTTP headers with the agent), so in most of the scenarios having a data store configured is necessary.
In case you still don't want to configure a data store, then you can prevent the user profile lookup failure by going to Access Control -> <realm> -> Authentication -> All Core Settings -> User Profile Mode and set it to Ignore.
This is unrelated to authentication but it's related to authorization ... you have to configure appropriate policies ... see OpenAM docs.
Agents will enforce authorization, OpenAM determines if the user has the permission to access a protected resource.
As Bernhard has indicated authentication is only part of the process of granting access to a user. He is referring to using a Policy to control access.
Another method is to check if the authenticated user is a member of the desired group programmatically. This can be useful when you want access control over resources that OpenAM doesn't know about (e.g. specific data).
For example, lets say that you want different groups to have access to different rows in a table in a database. You can retrieve the group information associated with the user and add that to your database query, thus restricting the data returned.
I'm sure that you could do this with OpenAM as well using custom modules to allow the policy to use information in the database as resource, but I've found it is much simpler to perform this fine grained access control in your code, and is in all likelihood significantly faster.
Context
A company that uses Active Directory for a long time. Previously, admins added Domain Users Group to many resources with read access. It is not realistic to change all this.
A service, in this case a GitHub:Enterprise instance, that uses LDAP for authentication was introduced for a cooperation project with another company.
Problem
Creating AD accounts for the external users gives them access to many resources which they should not have access to. If we don't create AD accounts for them, they cannot access the new service.
Is there a way to create a kind of 'decorated' proxy for AD that has some local users (the external guys) and refers to the original AD db for other users (the employees)?
What other ways are there that could solve the access permission problem?
It is possible to set up an additional VM with either Windows or Linux to solve the problem; however, it would be preferable if that was not required.
Typically this would be done with SAML federation.
Or you could use your openLDAP and add all the users into it as this would not allow permissions for AD.