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.
Related
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.
...
I'm using OpenAM 13 to provide single-sign-on capabilities to a suite of applications. The authentication itself is provided by LDAP, as there is an existing LDAP store used by other applications outside the scope of this single-sign-on.
A custom attribute called userattrib1 has been added to each users LDAP record. When this attribute is set to 999, the user is not allowed to log onto the single-sign-on, for all other values they are allowed to log on. I realise this is an unusual setup, however this is part of a pre-existing application.
How would I go about configuring OpenAM 13 to support this check? I'd like to avoid performing this check in the end-user applications, as there are several applications I'd have to add the check to.
If LDAP auth module is used you can specify a user search-filter to leverage the custom attribute.
However NOT searchfilters like
userattrib1 != 999
will typically lead to unindex searches and can not really be used, instead you should check how many distinct 'passing' values you have and then use that in a compound filter like
(|(userattrib1=123)(userattrib1=124)(userattrib1=125)(userattrib1=126))
potentially you can even 'group' the values to use a substring filter like
userattrib1=12*
depending on the filter used you need an equality index or/and a substring index configured for attribute userattrib1
I have specified the LDAP filter option as uid=${username} to get the username. I also need to get other attributes such as organization, telephone no, email etc.. I have only one LDAP store configured in my system. I know all the configuration steps to acheive it. I am struck with the LDAP filter to get those attributes. That's where I am getting error.
for eg, in order to get organization, I should give something like o=${SOMETHING}
How to provide the filter?
Please let me know.
Thanks,
Aswini J
I'm assuming you have already specified in the Assertion Mapping screen that you wish to "Retrieve Additional Attributes" and that you then added your existing LDAP Data Store.
The filter is simply used to locate a single user's record that you wish to return the associated attributes from. In the previous Admin screen (LDAP Directory Search) is where you specify the user attributes you wish to return. You simply specify your LDAP Base DN and then select the attributes from the drop-down list. You can find more information in the Admin Guide -
http://documentation.pingidentity.com/display/PF73/Configuring+an+LDAP+Directory+Search#ConfiguringanLDAPDirectorySearch-2232188
After choosing the attributes, you then get to setup your LDAP Filter where something as simple as "uid=${username}" will usually suffice. It really depends on what user identifier is coming in from your IDP Adapter and how specify that lookup needs to be. If you're using the HTMLForm Adapter, then chances are your users are entering their LDAP userID values.
We are currently looking into implementing our own STS (Microsoft WIF) for authenticating our users, and in that process we have come up with a few questions that we haven’t been able to answer.
We have different kinds of users, using different kinds of applications. Each kind of user needs some special types of claims only relevant for that kind of users and the application belonging.
Note that we do not control all the clients.
Let’s say that all users are authorized using simple https using username and password (.NET MVC3). A user is uniquely identified by its type, username and password (not username and password alone). So I will need to create an endpoint for each user type, to be able to differentiate between them. When a user authorize, I’ll issue a token containing a claim representing the user type. Is there an easier way for doing this? Can I avoid an endpoint for each user type (currently there are three)?
My token service can then examine the authorized users’ token and transform the claims, issuing a token containing all the users’ type specific claims. So far so good, except for the multiple endpoints I think?
If I need to have multiple endpoints, should I expose different metadata documents as well, one for each endpoint? Having one big metadata document containing a description of all claims, doesn’t make any sense since there is no application that needs all claims.
Update
Some clarifications.
Certain applications are only used by certain types of users. Not one application can be used by multiple user types.
Depending on what type of application the request is coming from, username and passwords needs to be compared for that user type. There are user stores for each type of application. That is why I need to know what application type the request is coming from. I can't resolve the type by the username and password alone.
Based on your problem description, it sounds like you have three indepent user "repositories" (one for each user type).
So imho this would be a valid scenario for three STS or a STS with multiple endpoints.
Another way to solve this could be to distinguish the user type by the indentifier of the replying party redirecting the user to the sts. This identifier is submitted in the wtrealm parameter.
The processing sequence could look like the following:
Get configuration for relying party (wtrealm) from configuration store (I'd suggest a database for your rather complex case)
Validate user with username, password and user type (from relying party configuration)
Add claims depending on user type or relying party specific configuration.
The datasbase/class structure for this could look similiar to this:
Need some more information to answer:
Are certain applications only used by certain types of users? Or can any user type access any application? If the former, you can configure the STS for that application to pass that user type as a claim. Each application can be configured to have its own subset of claims.
Where is the user type derived from? If from a repository, could you not simply construct a claim for it?
Update:
#Peter's solution should work.
Wrt. the 3 STS vs. 3 endpoints,
Many STS - can use same standard endpoint with different "code-behind". Would still work if you migrated to an out-the box solution . Extra work for certificate renewals.
One STS - custom endpoints won't be able to be migrated. Only one STS to update for certificate renewals.
Metadata - given that it can be generated dynamically, doesn't really matter. Refer Generating Federation Metadata Dynamically.
I'm interested in how other people code this because I'm either not understanding it properly or I'm missing something or perhaps even I'm doing it right!
First of all, this is NOT an Active Directory instance of LDAP its OpenDS which other than some syntactical differences shouldn't much matter.
So assume I have my tree structure setup something like this:
-dc=somedomain,dc=com
-uid=rootuser
-ou=Group1
-uid=username1
-uid=username2
-ou=Group2
-uid=username3
-uid=username4
In order to authenticate as the 'rootuser' I would need to pass the fully qualified Username when I create my System.DirectoryServices.DirectoryEntry object, in this case:
uid=rootuser,dc=somedomain,dc=com
but for any other user in the tree I have to know in advance what LDAP path to append to the username to have them authenticate thru. So for example this will fail:
uid=username1,dc=somedomain,dc=com
but this will work:
uid=username1,dc=somedomain,dc=com,ou=Group1
So my question is how do you handle this when you don't know at login time what specific group a user belongs to to build that path? The only way I can figure to do it is to make the initial call as 'rootuser' so I have access to the entire tree then use System.DirectoryServices.DirectorySearcher to scan it for that particular user (i.e. username1)
using (DirectorySearcher searcher = GetDirectorySearcher()) {
searcher.Filter = "(&(objectClass=person)(uid=" + userName+ "))";
SearchResult result = searcher.FindOne();
return result.GetDirectoryEntry().Path;
}
at that point I have the path for the user I want to login and I can proceed with the actual auth. Am I way off base here or is this generally how it is done?
thanks!
You build a search filter on attributes that are unique to the user, e.g. screen-name, e-mail. Make sure LDAP is configured to ensure they are unique. Then you find the corresponding entry if any, get the DN, and rebind as that user with the appropriate password. If there was no such entry you react accordingly.
You don't say what language you are using, but in JNDI that means setting the DN as the security principal, the password as the credentials, and calling LdapContext.reconnect().
SASL supports the notion of using a username to authenticate. Your directory server administrator may be able to configure the directory server to map distinguished names to identities. Given the correct mapping it is possible for a client to authenticate without knowing the distinguished name. Professional-quality directory servers support a number of different mapping mechanisms such as direct mapping, exact match, regular expression, or a custom identity mapper.