Attributes are controlled by the JA-SIG Person Directory project and returned to scoped services via the SAML 1.1 protocol. The Person Directory dependency is automatically bundled with the CAS server. Therefor, declaring an additional dependency will not be required. This Person Directory project supports both LDAP and JDBC attribute release, caching, attribute aggregation from multiple attribute sources, etc.
An example configuration of Person Directory is provided here, which is used by the uPortal project and demonstrates a range of feature the library provides. You may be able to use this as a starting point when configuring your attribute policy with CAS.
A PersonDirectory IPersonAttributeDao attribute source is defined and configured to describe the global set of attributes to be fetched for each authenticated principal. That global set of attributes is then filtered by the service manager according to service-specific attribute release rules. More about the Person Directory and its configurable sources can be found here.
Specify the username attribute for a registered service (optional)
Starting in CAS 3.5.x, the service registry component of CAS has the ability to allow for configuration of a usernameAttribute to be returned for the given registered service. When this property is set for a service, CAS will return the value of the configured attribute as part of its validation process.
The configuration of this behavior is as follows:
Populate Principal's attributes with LDAP repository
CredentialsToLDAPAttributePrincipalResolver lets you create and populate the principal with attributes extracted by JA-SIG Person Directory. Person Directory can rely on different types of context source (Database, LDAP, etc).
We'll describe the LDAP way:
The mapping between LDAP attributes and their names in principal's attributes map are defined in ldapAttributesToPortalAttributes of attributeRepository. You'll define here that the "name" attribute of the principal must be set by the "cn" attribute of the LDAP entry.
Accessing attributes using the CAS client for java
Using the org.jasig.cas.client.validation.Saml11TicketValidator class for ticket validation will populate attributes that can be retrieved from the HttpServletRequest.
See this Java CAS Client page for some basic example code.
Accessing attributes using phpCAS
phpCAS attempts to extract attributes from the CAS server's XML response for authentication success. However, even if you have configured the metadata populators, by default, Jasig CAS does not include attributes as a part of its response. For phpCAS to access them we must configure the XML response to include these attributes. To do this, open casServiceValidationSuccess.jsp (located at WEB-INF/view/jsp/protocol/2.0) and insert the following after you see the line <cas:user> ... </cas:user>
phpCAS should automatically pick up these attributes via the internal method readExtraAttributesCas20(). Individual attributes can be accessed by calling phpCAS::getAttribute('key').
Configuring multi-valued key support for attributes
Say you have an ldap user attribute called myPersonId and you need to expose it to apps via different names. For example, app1's service configuration will specify that it should receive this attribute as "myPersonId" and app2 should receive it as "personUid". Here are the things you'd do in deployerConfigContext.xml:
Specify an attribute filter for a registered service (optional)
As of CAS 4, the service registry component of CAS has the ability to allow for configuration of an attribute filter. Filters have the ability to do execute additional processes on the set of attributes that are allocated to the final principal for a given user id. For instance, you might want to decide that certain attribute need to be removed from the final resultset based on a user role, etc.
Currently, there's support for a RegisteredServiceRegexAttributeFilter that is regex filter responsible to make sure only attributes that match a certain regex pattern are released for a given service. If you of course wish to write your own filter, you need to design a Java class that implements the RegisteredServiceAttributeFilter interface and as such, plug that custom instance into the specific service registry entry you intend to use.
A sample configuration of RegisteredServiceRegexAttributeFilter follows below. You may use the below template to configure your custom attribute filters as well. This example also demonstrates the configuration of an attribute filter that only allows for attributes whose length is 3.