With a User Driven Federation (UDF) configuration it is possible to allow users to link their external identities to Ubisecure CustomerID internal identities (accounts). For example, the user could favor to only carry one set of one-time passwords and link a TUPAS account with the Ubisecure CustomerID account and effectively login to the web service in question using TUPAS instead.
Also see SSO User Driven Federation - SSO page for Ubisecure SSO configurations. There Agent configuration that needs to be done, (Agent).
...
- This procedure is not possible with Ubisecure SSO versions predating 7.1.0.
- If making the LDIF file for Open LDAP on Linux, make sure that the LDIF content only contains Unix-style line breaks, i.e. only linefeed character but not carriage return character.
- All LDIF blocks below can be concatenated to the same file and imported at once.
- If using a graphical LDAP client to make the modifications, it is required to have root privileges to Ubisecure Directory.
Register the CIDFederationManagerFactory as an ubiloginService Instance.
Code Block |
---|
language | text |
---|
title | Listing 1. LDIF block creating the CustomerID Federation Service |
---|
|
dn: cn=CustomerID Federation,cn=Services,ou=System,cn=Ubilogin,dc=example,dc=com
changetype: add
objectClass: ubiloginService
objectClass: top
cn: CustomerID Federation
ubiloginClassname: com.ubisecure.customerid.federation.CIDFederationManagerFactory
ubiloginServiceInputParameter: subject
ubiloginTitle: CustomerID Federation |
Code Block |
---|
language | text |
---|
title | Listing 2. LDIF block creating a User Mapping Table for Ubisecure CustomerID |
---|
|
dn: cn=CustomerID User Mapping,cn=Server,ou=System,cn=Ubilogin,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ubiloginLDAPURLUserMappingTable
cn: CustomerID User Mapping |
...
Code Block |
---|
language | text |
---|
title | Listing 4. LDIF block defining a Federation Manager Template |
---|
|
dn: cn=eidm.policy,ou=eIDM Services,cn=Ubilogin,dc=example,dc=com
changeType: modify
replace: ubiloginConfString
ubiloginConfString: FederationManager.TemplateName federation
- |
Modify Authentication Method(s) with Federation Capabilities
Code Block |
---|
language | text |
---|
title | Listing 5. Modifying tupas.test.1 method to offer federation |
---|
|
dn: cn=tupas.test.1,cn=Server,ou=System,cn=Ubilogin,dc=example,dc=com
changetype: modify
replace: ubiloginLDAPURLUserMappingTableDN
ubiloginLDAPURLUserMappingTableDN: cn=CustomerID User Mapping,cn=Server,ou=System,cn=Ubilogin,dc=example,dc=com
-
changetype: modify
replace: ubiloginDirectoryServiceDN
ubiloginDirectoryServiceDN: cn=CustomerID Directory,cn=Services,ou=System,cn=Ubilogin,dc=example,dc=com
- |
In the example above there is a precondition that there is already a configured authentication method called tupas.test.1, which is now equipped with the ubiloginLDAPURLMappingTableDN
and ubiloginDirectoryServiceDN
attributes, which enable the user driven federation functionality.
Configuring User Driven Federation with Authentication Method Grouping
When a set of authentication methods are operating in, what could be considered, the same domain such as TUPAS, it may be feasible to configure the system in such a way that it allows the user to form a federation link from one authentication method and have this link be recognized when signing on from another authentication method of the same conceptual domain. This is only possible when authentication methods return an exactly matching user identifier, like a personal identity number, a social security number or something similar.
...
Code Block |
---|
language | text |
---|
title | Listing 6. LDIF block creating a specialized Ubilogin Service User Mapping Entry |
---|
|
dn: cn=44a5a6c3-706e-419f-adf8-d31f182bcffa,cn=CustomerID User Mapping,cn=Server,ou=System,cn=Ubilogin,dc=example,dc=com
changetype: add
objectClass: ubiloginServiceUserMappingEntry
objectClass: ubiloginServiceReference
objectClass: top
ubiloginServiceDN: cn=CustomerID Federation,cn=Services,ou=System,cn=Ubilogin,dc=example,dc=com
ubiloginServiceInputParameter: subject ${nameID.format('hetu').nameQualifier('tupas.group').spNameQualifier('tupas.group').spProvidedID(method.CUSTID).value(method.CUSTID)} |
Authorization Policy Requirements for Authentication Method Grouping
It is possible to configure CustomerID to create federation links during registration. In case authentication method grouping configuration should be in effect, it is necessary to configure the SAML Assertion's NameID element to be produced with compatible attributes. This can be done by extending the workflow.policy Authorization Policy definitions.
For example, if the serviceInputParameter in Listing 6 were to be used, the authorization policy should be modified as follows:
...
Code Block |
---|
language | text |
---|
title | Listing 8. Authorization policy setNameID() with references to original NameID, read from the username object |
---|
|
${nameID.format('hetu').value(method.CUSTID).spProvidedID(username.spProvidedID).spNameQualifier(username.spNameQualifier).nameQualifier(username.nameQualifier)} |
This use case may arise from various business requirements. For example, two authentication methods are required to work in a common domain and a third one in a separate or maybe some common domain authentication methods supply the same identifying attribute with different names. In these cases it is required to register specialized User Mapping Tables for each authentication method.
In the example below, the previously defined specialized Ubilogin Service Mapping Entry has been registered to the method tupas.test.1 using an LDIF like below:
...
Code Block |
---|
language | text |
---|
title | Listing 12. Modifying myidp.test.1 method to offer federation |
---|
|
dn: cn=myidp.test.1,cn=Server,ou=System,cn=Ubilogin,dc=example,dc=com
changetype: modify
replace: ubiloginLDAPURLUserMappingTableDN
ubiloginLDAPURLUserMappingTableDN: cn=MyIDP User Mapping,cn=Server,ou=System,cn=Ubilogin,dc=example,dc=com
- |
Importing LDIF to Ubisecure Directory
Code Block |
---|
language | text |
---|
title | Listing 13. Importing LDIF file to Ubisecure Directory (linux) |
---|
|
cd /usr/local/ubisecure/ubilogin-sso/ubilogin/ldap/openldap
./import.sh /path/to/file.ldif |
...
Code Block |
---|
language | text |
---|
title | Listing 14. Importing LDIF file to Ubisecure Directory (Windows) |
---|
|
cd /D "C:\Program Files\Ubisecure\ubilogin-sso\ubilogin\ldap\adam"
import.cmd C:\path\to\file.ldif |
Language keys for User Driven Federation
Code Block |
---|
language | text |
---|
title | Listing 15. UDF language keys in i18n/uas.properties |
---|
|
CONFIRM_INTRO_TITLE = Create Account Link
CONFIRM_INTRO_TEXT = Before entering the requested service you can link your external identity with your existing user permanently.
CONFIRM_HELP_TITLE = Help
CONFIRM_HELP_TEXT = The account you used has not been linked to your existing account. Please save the link and continue to the service.
CONFIRM_HELP_LINKS =
CONFIRM_LOGIN_TITLE = Account Settings
CONFIRM_LOGIN_TEXT = Please select to remember the account link.
CONFIRM_LOGIN_PERSISTENT_TEXT = Remember this next time |
...
Code Block |
---|
language | text |
---|
title | Listing 21. UDF configuration keys in protection.properties |
---|
|
protection.1.methods = password.2, tupas.test.1
protection.1.sso.template = udf
protection.1.continue = https://cid.example.com/eidm2/wf/register/udf
protection.1.customeriduseronly = false |
Preventing Disabled Users From Logging In Using User Driven Federation
If a user has an existing authentication method linkage that has been created using user driven federation that user can by default still use that method to access applications even though the user is later disabled. To prevent this you can modify the authorization policy for the application in Ubisecure SSO Management. Here is an example for an authorization policy attribute value definition:
...