Acceptance of SAML assertions and authentication of incoming users is all handed by the SAML extension service. The back-end Web server developer does not need to do anything different in order to support incoming SAML users. However, there are some issues to consider if OLAC is being used.
OLAC allows back-end Web servers to receive user attribute information pulled from various data sources as HTTP header or query string parameters. As mentioned in Sending User Attributes to Partner Sites, user attribute information can be shared between SAML affiliate sites. It is possible to make the SAML attribute information available to back-end Web servers using OLAC. This is done by creating an entry in the OLAC table for a given protected resource with the DataSource = SAML. The value name should be the SAML Attribute name of the incoming SAML attribute. The Name value can be the same as that of other OLAC attributes. If other OLAC attributes exist with the same name, they are overridden if SAML OLAC data is available. This allows you to define protected resources that contain customized content that behave in the same way if the user authenticated directly to the system or was authenticated via a SAML assertion. See Accessing SAML Attributes in OLAC for more information.
Based upon the value of the partnership between two SAML partners, various levels of security might be required. The Trusted Affiliate configuration allows the administrator to determine what types of security constraints must exist in order for the system to accept SAML data from a specified Trusted Affiliate. The available options are:
Require Signatures on Browser/POST: This setting allows the administrator to require that SAML assertions sent in the Browser/POST profile contain a verifiable digital signature. This gives the receiving site the ability to verify that the provided assertion was indeed issued by the proper referring site. The SAML specification requires that SAML data sent in the Browser/POST profile contain a digital signature.
Require Signatures on Browser/Artifact: This setting allows the administrator to require that SAML assertions sent in the Browser/Artifact profile contain a verifiable digital signature. This gives the receiving site the ability to verify that the provided assertion was issued by the proper referring site. This is in addition to the security provided by the SAML back-channel communications layer associated with the SAML Browser/Artifact profile. The SAML specification does not require that Browser/Artifact assertions be signed; however, some partner sites might require it.
Require Mutual SSL: This setting requires that communication from this Trusted Affiliate be made over mutually authenticated SSL. According to the SAML specification, communication over the HTTPS back-channel must be mutually authenticated.
For more information on these settings, see Configuring the SAML Extension.