...
An ACS does most of the work of SSO for the SP and is the "receiving" half of the SSO message exchange started by a SessionInitiator. As a multi-protocol system, the SP itself is oblivious to specific SSO protocols; each ACS provides the implementation of a particular protocol. The "assertion" terminology is SAML-specific but is an abstraction at this level.
Common Attributes
Location
(relative path)- The location of the ACS (when combined with the base handlerURL). This is the location to which an IdP sends assertions using whatever protocol and binding it shares with the SP. Each combination of SSO protocol and binding is usually installed at a unique location to improve efficiency.
...
policyId
(namespace-qualified byurn:mace:shibboleth:2.0:native:sp:config
) (string)- References the
id
of a<Policy>
element in the configuration and causes that security policy to be applied to messages sent to this endpoint. Not generally used because attackers can bypass special policies by choosing the most advantageous endpoint, but allows for more advanced extension features in the future.
- References the
signing
(namespace-qualified byurn:mace:shibboleth:2.0:native:sp:config
) (see NativeSPSigningEncryption) (Version 2.6 and Above)- Controls outbound signing of XML messages subject to applicability to the protocol involved. This has no effect with any existing supported protocols.
encryption
(namespace-qualified byurn:mace:shibboleth:2.0:native:sp:config
) (see NativeSPSigningEncryption) (Version 2.6 and Above)- Controls outbound encryption of XML messages and content subject to applicability to the protocol involved. This has no effect with any existing supported protocols.
...
SAML 1.x AssertionConsumerService
...
Example usage with the default namespace from the distributed shibboleth2.xml:
Code Block | ||
---|---|---|
| ||
<md:AssertionConsumerService Location="/SAML2/POST" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
conf:ignoreNoPassive="true" />
|
...