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.
Related
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.
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.
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.
We use Jenkins with LDAP authentication. My question: is it possible to implement this rights scenario?
if not logged-in (anonymous) ==> read all
if logged in (via LDAP) but not a "special" user ==> full access to specified jobs only
if logged in (via LDAP) and also a "special" user ==> full admin access
My goal is to avoid having to manage large numbers of users explicitly.
There's a plugin "Role Strategy Plugin" that supports permissions for specified jobs, but it doesn't distinguish between anonymous and logged-in (via LDAP) users. It seems that the only way to grant access to specified jobs is to grant it user by user...which I want to avoid.
Can you use Active Directory? If so:
you can use groups for authentication, and therefore assign rights to the entire group.
you can use a project-based matrix, so specified jobs will only be visible to specific groups
If you cannot (only LDAP):
I think you can still do the above, but I think your LDAP configuration will require more work for groups. I am not sure of group support in the Jenkins LDAP API.
I would like to create a user similar to admin, but with restricted privs. The user would be able to create/read/delete objects under a certain DN in the directory, but not others.
Typically, the native server providing the LDAP service has an ACL model.
Within that system, you can create users with appropriate trustee rights/ACLs.
For example, in eDirectory, you would grant this new user object BCRDI rights to the container of interest, then have your LDAP app authenticate as that user.
In Active Directory you can do the same thing.
In Open LDAP you can do the same thing.
The specific details depend on the server providing the LDAP service. (I like others, hate saying LDAP server, since really they are not LDAP servers. They are offering an LDAP service on top of whatever database they store objects in.)