Using SAML Assertions for Single
Sign-On
Use
The AS Java supports the use of the Security Assertion Markup Language (SAML) for Single Sign-On. You can use SAML for Single Sign-On in a scenario where a user is authenticated on an external authentication system that acts as an SAML authority. Based on this authentication, the user receives an SAML assertion (upon request) that he or she can use to access the AS Java.
The AS Java accepts SAML assertions for Single Sign-On. However, it cannot act as an SAML authority that issues such assertions.
Constraints
There are some limitations of the SAML implementation on the AS Java. The following constraints apply:
· The condition element AudienceRestrictionCondition is accepted by the AS Java, however it is not evaluated. Any other child elements of the Conditions element result in processing errors.
· Assertions must have exactly one AuthenticationStatement element. The authentication statement must have a NameIdentifier element.
· If they are present, the elements AuthorizationDecisionStatement and AttributeStatement are ignored.
· Creating digital signatures for outgoing documents is not supported. Digital signatures present with incoming documents are not verified.
Prerequisites
To protect the data
exchange, SSL is required for the connection between the source and
destination sites. For more information, see
Using SSL and SNC for
Transport Layer Security.
Because SSL is required by the SAML specification, per default, its use is activated in the SAML configuration. However, for testing purposes, you can disable the enforcement of SSL for the SAML-based document exchanges. In this case, you receive warnings in the log files, but you can still process the communication requests.
Integration
There are several components involved in the SAML Single Sign-On scenario:
· The site that authenticates the user establishes a source site server that initiates the SAML communication. This source site provides the destination site with an assertion artifact, which is an identifier for the user’s assertions.
· The source site also provides a responder, which acts as the SAML authority that actually provides the user’s assertions.
· In addition to the desired resource, the destination site provides an artifact receiver, which receives the initial assertion artifact and passes it on to be evaluated by the SAML login module.
The artifact receiver is a component defined by the SAML specification. However, because the AS Java uses a login module to evaluate the SAML assertions, any of its applications can be used as the artifact receiver.
· If the user’s ID as provided by the SAML authority is not identical to the user ID at the destination site, then the destination site must also provide a user mapping mechanism.
The figure below shows this server landscape in detail:
Activities
The figure above also shows how this process occurs when the user accesses the destination site.
...
1. The user authenticates him or herself at the source site, for example, using user ID and password.
2. He or she requests a resource at the destination site (via the source site), for example, the resource www.dest.com/resource.
3. The source site then contacts the destination site’s artifact receiver. Thereby, it sends the target URL for the requested resource and an assertion artifact, which will identify the user’s assertions in the next steps.
4. The artifact receiver redirects the user client to the desired destination.
The requested resource may also be the assertion receiver. In this case, the user is allowed access directly and no redirect is necessary. This is the case for applications on the AS Java. See (3’) in the graphic above.
5. The SAML login module, which is used by the resource at the destination site, evaluates the artifact, which includes determining the source site based on the source ID information provided with the artifact.
6. The login module requests the user’s authentication assertions from the source site’s responder. This request occurs using the SOAP protocol.
7. The source site’s responder sends the user’s assertions.
8. The login module analyzes the assertions and authenticates the user. If necessary, a user mapping module can be applied after the login module to obtain the user’s correct ID for the AS Java. See Step (8’) in the figure.
9. The resource is sent to the user.
We do not provide a user mapping module with the AS Java. However, you can easily insert your own module in the login stack for the corresponding applications or templates. This mapping module can use any desired technology, for example, entries in a directory server, hard-coded mappings, or a mapping table in a database. For a sample mapping module, see the Example SAML Mapping Module Used by the SAML Test Application.
For more information about creating login module stacks, see Managing Authentication Modules.
Monitoring
The SAML authentication service writes log data to the category /System/Security/SAML. You can view the data using the LogView in the server’s log system_security_log.
When configuring the AS Java to support SAML, messages will appear in the log due to the incomplete configuration. However, such messages should not appear once you have finished the configuration.
Per default, the log file used is <instance_dir>\j2ee\cluster\server<n>\log\system\security.log.<x>.
Configuration
See:
● Mapping SAML Principals to AS Java User IDs
● Accessing an Application that Accepts SAML Assertions