I would like to restrict LDAP bind users so that have access to only what is absolutely necessary.
For example, I have an LDAP user that is used to bind for a specific application.
cn=app1,ou=bind-accounts,dc=example,dc=net"
The LDAP bind user should only be able to read specific attributes for the users that need to access the application, even if they are in different OUs.
The following user specific access rules achieve my desired outcome.
access to dn.exact="cn=bob,ou=users,dc=example,dc=net" attrs=uid,objectClass,entry
by dn="cn=app1,ou=bind-accounts,dc=example,dc=net" read
access to dn.exact="cn=alice,ou=users,ou=client1,ou=clients,dc=example,dc=net" attrs=uid,objectClass,entry
by dn="cn=app1,ou=bind-accounts,dc=example,dc=net" read
I have the following group that includes both users that need access to the app
dn: cn=app1-access,ou=groups,dc=example,dc=net
cn: app1-access
objectClass: groupOfNames
description: Users permitted to access app1
member: cn=alice,ou=users,ou=client1,ou=clients,dc=example,dc=net
member: cn=bob,ou=users,dc=example,dc=net
What access rule would filter on members of the group, so I don't have to have the user specific rules?
Related
net core application and trying to implement authentication and authorization. I have set of users and these users belong to different regions. For example I have region APAC and I have some users in it. Then I have roles like global admin or regional admin. Now these users are type of regional admin global admin etc. Now I want to return role claim in my token. To return role claim in my JWT token I should add app roles in manifest. So how should I return app roles now. If I select as group then all users belong to that group emits this role details. I am little bit confused here. I have grouped users according to regions. Inside each region users are of type regional admin, global admin etc and they have different permissions inside app. Segregation of these groups vs roles I am finding lot of challenge and no use full document also I found. Can some one help me to segregate these groups vs roles.
As I understand you have users with different roles under the groups segregated by the regions. When you are trying to authorize by group all the users with different roles of the group emit the group role details.
Assuming regional admin you mentioned as a custom role for your application(as there is no such role in AAD) following is a suggestable approach.
A user can be assigned to multiple groups and Roles can be assigned to individual users/groups.
Create groups separately for regional admin, global admin users and assign roles to these groups accordingly.
If you are using the role claim in the token for role-based access control, authorize applications based on the role permissions granted by the administrator to groups. Please refer this link for the detailed documentation on how to create/manage roles for an application in Azure AD.
In setting up User Federation from an LDAP provider, there are three LDAP attributes:
Username LDAP attribute
RDN LDAP attribute
UUID LDAP attribute
How does the value of each of these impact Keycloak or the sync process?
For instance, if the directory ensures unique email addresses, are there any negatives to using mail as the UUID LDAP attribute?
Where can I find details on each of these attributes--specific to Keycloak?
In Keycloak admin console, you may hover over the tooltip - a tiny question mark - next to the LDAP attribute label if you want as much info as possible about it. I checked this on Keycloak v6.0.1 but I assume it applies to most recent versions. Such tooltip will often give more info than you can find on the Keycloak documentation website. More details about these attributes:
Username LDAP attribute: Name of LDAP attribute which is mapped as Keycloak username. For many LDAP server vendors it can be 'uid'. For Active Directory it can be 'sAMAccountName' or 'cn'. The attribute should be filled for all LDAP user records you want to import from LDAP to Keycloak. So there you could use the mail attribute if you want this as username in Keycloak. Then users would log on to Keycloak with their email address. If you enable LDAP synchronization to Keycloak local database (switch on Import Users), this will be recorded there as username.
RDN LDAP attribute: Name of LDAP attribute which is used as RDN (top attribute) of typical user DN. Usually it's the same as Username LDAP attribute, however it's not required. For example for Active directory it's common to use 'cn' as RDN attribute when username attribute might be 'sAMAccountName'. For example with a conventional LDAP directory (not Active Directory) where user DNs are typically uid=XXX,ou=people,dc=example,dc=com, you would use 'uid' there.
[EDIT 2019-05-31] The RDN attribute is actually used for instance when you create a new user in Keycloak. If you have the Edit Mode option set to WRITABLE in the settings, Keycloak synchronizes it back to the LDAP directory, i.e. creates the new user entry in LDAP. For that, it needs (among other things) the RDN and the Users DN (another option below the RDN) to make the full DN of the new user LDAP entry.
UUID LDAP attribute: Name of LDAP attribute which is used as unique object identifier (UUID) for objects in LDAP. For many LDAP server vendors, it's 'entryUUID' however some are different. For example for Active Directory it should be 'objectGUID'. If your LDAP server really doesn't support the notion of UUID, you can use any other attribute, which is supposed to be unique among LDAP users in tree. For example 'uid' or 'entryDN'. Any standard LDAP v3 directory should use entryUUID (OpenLDAP, OpenDJ...).
Regarding best practices on UUID in LDAP directories, you may look at the RFC 4530 standard.
In general, I would advise against using 'mail' as UUID, because a user's 'mail' may change (see reasons down below), whereas an entry UUID - whether it is a user entry or not - is meant to be a globally uniquely generated number (or at least contain such a number), usually generated on server side, and fixed once and for all for the entry. (Furthermore, it shall not be reused ever, even after the entry is deleted, as UUIDs should be unique in time and space.) In particular, it should be independent from any of the user's variable attributes, like email address.
Indeed, a user's email address may change during his/her lifetime in the organization for various reasons, just to name a few:
Users - women typically - may get married or divorced, and therefore may change their last name.
Top management decides to rebrand the company and therefore change the mail domain.
The company is going through a merger or an acquisition with/by another company and therefore the mail domain changes again.
...
We have integrated Websphere commerce with LDAP and the proper login flow is working fine.
We have a requirement that user can have an option to login using his phone number and also his membership card.
Currently we are storing the ph.no and membership card in LDAP database also.
We are unable to use these fields for login as well. Can someone give some pointers on the same?
WAS has Standalone and Federated LDAP authentication.
Standalone LDAP configs in WebSphere allow you to construct your own LDAP search that's used to map a web username to a DN. You can list multiple attributes using LDAP filter syntax (|(phone=%v)(membershipcard=%v)...
https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/tsec_ldapfilter.html
Modify the user filter, if necessary. The user filter is used for
searching the registry for users and is typically used for the
security role-to-user assignment. The filter is also used to
authenticate a user with the attribute that is specified in the
filter. The filter specifies the property that is used to look up
users in the directory service. In the following example, the property
that is assigned to %v, which is the short name of the user, must be a
unique key. Two LDAP entries with the same object class cannot have
the same short name. To look up users based on their user IDs (uid)
and to use the inetOrgPerson object class, specify the following
syntax: (&(uid=%v)(objectclass=inetOrgPerson)
Federated registries take a semi-colon separated list of LDAP attribute names used for the same purpose.
https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twim_ldap_settings.html :
All login properties are searched during login. If multiple entries or
no entries are found, an exception is thrown. For example, if you
specify the login properties as uid;mail and the login ID as Bob, the
search filter searches for uid=Bob or mail=Bob. When the search
returns a single entry, then authentication can proceed. Otherwise, an
exception is thrown.
Both are covered in gory detail in the manual.
I have defined security properties of a login
I have 200 users .
How can I apply dynamically the same security properties of a login for all users login ?
Create a Role (through the GUI or T-SQL) with the required permissions, then add all 200 users as members of that role. Not sure if you can force the role to 'copy' permissions from a particular user, but from an auditing and maintenance perspective, it's far simpler to make required changes to a Role once and have them instantly inherited by all members.
Adding permissions to a role enables the given permission to all users in that role by default; this is something I want to avoid.
I want to be able to set permissions like "Booking: View own Bookings" at user level and not the role level.
Is there a module that already does this, or can someone give me some possible approaches or pseudo code of some kind?
Yes, there's the User Permissions module.
User Permissions provides an interface for giving additional permissions to individual users without the need to assign them to a special role. When this module is enabled, users with the 'administer permissions' permission can access the 'User Permissions' tab on each user's account.