This section contains the following topics:
Assertion Attribute Configuration Examples
How To Add Session Attributes to an Assertion
How to Configure Claims Transformation at the Asserting Party
The Assertion Configuration step of the partnership wizard defines the configuration of the following settings:
The Name ID attribute, a required assertion attribute, identifies a user in a unique way. The Name ID format indicates the identifier type that the federated partners support. The Name ID type specifies the user profile attribute that is associated with the name ID format. The user profile attributes come from a user store or the session store.
Servlets, web applications, or other custom applications can use attributes to display customized content or enable other custom features. When used with web applications, attributes can limit the activities of a user at the relying party. For example, an attribute variable named Authorized Amount is set it to a maximum dollar amount that the user can spend at the relying party.
Attributes are designated in an <AttributeStatement> element or an <EncryptedAttribute> element. Attributes take the form of name/value pairs. Attributes can also be made available as HTTP headers or HTTP cookies.
Note: Attributes statements are not required in an assertion.
You can configure different types of attributes for an attribute statement. The types of attributes include:
Session attributes are available for assertions only if they are persisted in the session store.
You can also configure an expression to transform assertion attributes. This capability is called claims transformation.
When the relying party receives the assertion, it makes the attribute values available to applications.
Typically, attributes come from user directory records, but an assertion can contain attributes from other sources, such as an external database or application content. You can write an assertion generator plug-in that pulls in attributes from various sources. The assertion generator plug-in is a piece of custom code that you write according to the Assertion Generator Plug-in interface.
For information about writing a plug-in, see the Programming Guide for the Federation Java SDK.
Configure assertion options at the asserting party.
Follow these steps:
The relying party uses these values to interpret the Name ID value in the assertion.
Depending on the selected NameID Type option, complete the entry with a proper value.
Enter any constant string in the Value field.
Enter a valid user store attribute in the Value field. For example, mail.
Enter a valid session store attribute in the Value field.
Enter a valid LDAP user directory attribute in the Value field. Also, enter a valid DN in the DN specification fields. For example, the DN attribute is cn=JaneDoe and the specification is ou=Engineering,o=ca.com.
Note: Click Help for a description of fields, controls, and their respective requirements.
Note: If you select this option, the value of the Name ID Format value must be Persistent Identifier.
For help filling out the table, view some assertion attribute examples. Click Help for detailed information about each column in the attribute table.
Note: For the LDAP user store attributes, you can add multivalued user attributes to an assertion. The Help describes how to specify multivalued user attributes.
To write a plug-in, see the Programming Guide for the Federation Java SDK.
The following graphic shows some examples of assertion attribute entries. This screen is for a SAML 2.0 partnership. The SAML 1.1 screen is similar, but the Retrieval Method and Format columns are missing. A Namespace column exists instead.
Note: The DN Attribute example includes a DN Specification column, with the entry ou=Engineering,o=ca.com. This column is not visible in this graphic.
|
Copyright © 2013 CA.
All rights reserved.
|
|