Protocol limitations prevent large quantities of roles being sent over some bindings. Ubilogin Ticket Protocol is limited by data restrictions imposed when using the HTTP GET binding. Authentication may fail or loop if the number of roles or attributes is very large.
- Use SAML SP products where possible
The default configured SAML POST binding is not subject to the restrictions imposed when using the HTTP GET binding.
- Use backend approaches
Consider sending only the user identifier and retrieving roles via the CustomerID REST API after authentication is complete. The target application will need to be modified to query the REST API after login.
- Limit roles sent to applications
By default, the eidm:roles macro specified in an Authentication Policy sends all roles to an application. Limit sending of roles to applicable sets of roles using Blacklists and Whitelists as specified in Chapter 7.1 of the CustomerID Configuration guide.
Shorten role namespace
Avoid unnecessary long role and organization names during system installation and configuration. Long role names can be converted to compact role names using the role mapping mapping functionality of the Authorizer component as described in Chapter 7.1 of the CustomerID Configuration guide.
CustomerID Authorizer policy configuration example with whitelist and role naming conversion
Consider the following example eidm2-authorizer.properties which only sends the nominated whitelist of 8 roles as two character role names. Any additional roles are ignored.
policy.3.name = compact
policy.3.include = whitelist
policy.3.roles.1 = eIDMUser
policy.3.roles.2 = OrganizationMainUser
policy.3.roles.3 = OrganizationUser
policy.3.roles.4 = PendingTupasUser
policy.3.roles.5 = PendingSMSUser
policy.3.roles.6 = eIDMMainUser
policy.3.roles.7 = OrganizationOwner
policy.3.roles.8 = OrganizationAdmin
policy.3.mapping.1 = mapping1
policy.3.mapping.2 = mapping2
policy.3.mapping.3 = mapping3
policy.3.mapping.4 = mapping4
policy.3.mapping.5 = mapping5
policy.3.mapping.6 = mapping6
policy.3.mapping.7 = mapping7
policy.3.mapping.8 = mapping8
mapping1 = eIDMUser
mapping1.name = eu
mapping2 = OrganizationMainUser
mapping2.name = om
mapping3 = OrganizationUser
mapping3.name = ou
mapping4 = PendingTupasUser
mapping4.name = pt
mapping5 = PendingSMSUser
mapping5.name = ps
mapping6 = eIDMMainUser
mapping6.name = em
mapping7 = OrganizationOwner
mapping7.name = oo
mapping8 = OrganizationAdmin
mapping8.name = oa
To use this policy, refer to policy name after
eidm:roles:macro as shown below
In this example, if a user has a role OrganizationMainUser, it will be sent as om. If a user has a role called HRMainUser, it will not be sent as it is not on the whitelist. Blacklist functionality is available to send all roles excluding a list of given roles.
Use multiple applications sending only application specific roles
In a proxy configuration using Web Agent for Apache, create multiple agents and use multiple activator files for each specific application.
For each specific application, configure a different authentication policy which references a different policy in the eid-authorizer.properties file. Specify a policy that contains only application specific roles. Thus large numbers of roles are never sent.
Modify Apache httpd settings to permit large volumes of data in GET requests
By default, Apache httpd is configured to restrict the maximum length of a GET request.
The Apache httpd setting LimitRequestLine controls this value
Carefully consider mentioned security risks involved in increasing this value. All network hardware between the end user browser and the target application must be modified to allow larger values.