The Federal E-Authentication profile specifies the SAML 1.0 artifact profile in conjunction with some restrictions on assertion content. ShibOnedotThree supports this profile.
Configure an IdP for E-Authentication Use
The set-up process assumes that a complete InQueue installation and testing has been performed and you have a functional Shibboleth IdP. If not, complete that section first.
- Add a virtual host in apache that uses the proper eAuth cert/key for SSL (in ssl.conf).
- Create SAML2 metadata for each AA (sample below).
- Add a metadata provider element (in idp.xml) that points to eAuth metadata. (<MetadataProvider/> in the sample below)
- Add a protocol handler for the eAuth SSO handler (in idp.xml) (<ProtocolHandler/> in the sample below).
- Add an extra location for the artifact lookup handler that maps to eAuth SSL endpoint (in idp.xml) (<ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.SAMLv1_1ArtifactQueryHandler"/> in the sample below).
- Add servlet mappings for the eAuth SSO handler and the eAuth location for the artifact lookup handler (in web.xml).
- Add a name mapping that uses Subject DNs (in idp.xml) (<NameMapping/> in the sample below).
- Add a relying party element w/defaultTarget (this should be equal to the "TARGET" query parameter used in the artifact redirect) for each AA (in idp.xml) (<RelyingParty/> in the sample below)
- Adjust the attribute resolver configuration to include a commonName attribute. (in resolver.xml) (don't forget the eAuth namespace).
- Adjust the attribute release polices to release the commonName attribute (in arp.site.xml).
- Configure the SAML 1->1.1 filter (in web.xml).
The Sun AA implementation does not seem to work with the
SSLVerifyClient optional_no_ca Apache directive. To get around this, you must configure client-auth and create an appropriate trust bundle.
Example SAML 2.0 metadata for E-Authentication use: eAuth-sites.xml
idp.xml file for E-Authentication use: idp.xml
Configure an SP for E-Authentication Use
The set-up process assumes that a complete InQueue installation and testing has been performed and you have a functional Shibboleth SP. If not, complete that section first.
The ShibbolethApplication being configured for EAuthenticationDeployment must have an AssertionConsumerService element inside its Sessions element set up as below:
The index value can be anything as long as it's unique within the set of elements. The distinction with a normal artifact profile endpoint is the additional namespace-qualified MinorVersion attribute. This attribute defaults to 1, indicating support for SAML 1.1 in most Shibboleth configurations. Set it to 0 to enable SAML 1.0 support. This works for POST or artifact, but EAuthenticationDeployment requires the use of artifact.
Additional settings that may be helpful...
- strictValidity and propagateErrors in your MemorySessionCache or MySQLSessionCache element may need to be "false" to prevent premature expiration of the attributes included in the short-lived EAuthnAssertion, and in some cases the lack of an AttributeAuthority offered by the IdentityProvider to refresh them
A starting policy file is attached: eauth-AAP.xml
CredentialServiceProvider MetaData Configuration
Supplying MetaData for an EAuth CredentialServiceProvider is essentially the same as for any other Shibboleth IdentityProvider, except that:
- The EntityDescriptor element's entityID attribute is set to the CSP's approved value for Assertion Issuer
- The IDPSSODescriptor element's protocolSupportEnumeration attribute must contain "urn:oasis:names:tc:SAML:1.0:protocol" to indicate support for SAML 1.0
- The SingleSignOnService element's Binding attribute can be set to urn:mace:shibboleth:1.0:profiles:EAuth (currently not used, but identifies the redirection protocol that might be used to invoke the CSP)
- There may not be an AttributeAuthorityDescriptor included