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.
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 a keycloak deployment where I am federating users from a legacy DB. So far this is working good. Now I'm trying to add some clients that will be our API users. Creating, adding roles, and creating a service account seems to be all good as well.
But I need these service accounts to be in table where my federated users are. My app uses ACLs which based on my user table.
I don't see anything in the develop guide. Is this possible?
since anypoint platform url anypoint.mulesoft.com is publicly accessible anyone can access the resources. Is there anyway i can restrict access to my org users apart from creating access roles.
Can i create org specific url with org secific access so that others cant access?
Can put some network related restrictions?
I think you confusing two different things:
Accessing a public URL (ie https://anypoint.mulesoft.com)
Authorization inside your organization's account
You can not restrict access to a site that you don't own, it is publicly accessible and needs to be accessed by other users. It doesn't even make sense really. Would you attempt to restrict access by others to google.com or twitter.com (or their API URLs)? It is not the right approach and it is just not possible.
What makes sense however is to manage permissions inside your organization in Anypoint Platform. It means when an user belonging to your organization logs in you can manage what of the available roles are permissions that user will have. You can do that in the Access Management page. You can also create custom roles with specific permissions and teams to better organize your users.
As mentioned you are not able to change MuleSoft's main URL (ie https://anypoint.mulesoft.com), one option being to control from Access Management page, both mentioned by #aled
There are two main ways you can get what you need:
If your organization already has some MFA tool that requires you to be in your corporate VPN, you could use that MFA as the MFA for the Anypoint Platform e.g. Users will need Username/Password, connect to the VPN to be able to get access to the MFA generator/auth and then use that code to finish logging into the platform. As Admin in Anypoint Platform you can enforce EVERYONE to have MFA set up (keep in mind ClientApps authorization for your automation users)
If your company already has an Identity Provider you can configure identity management in Anypoint Platform to set up users for single sign-on (SSO). The fragments below extracted from the official docs external-identity:
After configuring identity management, you must add new SSO users using your external identity management solution and internal provisioning process. If you use the Invite User feature to add users to your organization after you have configured an identity provider, the credentials for these users are stored locally in your organization rather than with the identity provider.
Users that log in with SSO are new users to the system. If the new user has the same username as a user that already exists in your Anypoint Platform organization, the new user co-exists with the original user with the same username. Users with the same username are managed independently from one another.
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 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.