This guide is deprecated because Service Provider should use the Interfederation deployment guide instead.
The following page describes the technical steps that are required when a Service Provider (SP) shall be configured to allow access for users from a non-SWITCHaai Identity Provider (IdP). This allows bilateral (inter-federation) cooperations with non-SWITCHaai federation members even before European or global solutions like eduGAIN are used in production. Any legal or policy-related issues are up to the administrator of the service to deal with and are subsequently not covered here.
It is assumed that the SP is a Shibboleth Service Provider 2.x which is fully configured and working according to our deployment guides. For the sake of simplicity it is assumed that one single foreign IdP is to be added to the SP's configuration.
The Service Provider (SP) as well as the Identity Provider (IdP) need to know each other in order to communicate. Knowing each other means having the other component's metadata. Therefore, the SP must be configured to load the IdP's metadata. There are two ways of loading the IdP's metadata
In the following the bold values surrounded by ## stand for:
In order to configure an SP to load additonal metadata, proceed with the following steps:
<MetadataProvider type="XML" uri="##METADATA-URL##" backingFilePath="##METADATA-BACKUP-FILE##" reloadInterval="3600"> <MetadataFilter type="Signature" verifyName="false"> <TrustEngine type="StaticPKIX" verifyDepth="5"> <CredentialResolver type="File"> <Certificate format="PEM"> <Path>##METADATA-SIGNING-CERT-FILE##</Path> </Certificate> </CredentialResolver> </TrustEngine> </MetadataFilter> <MetadataFilter type="Whitelist"> <Include>##IDP-ENTITYID##</Include> </MetadataFilter> </MetadataProvider>
The following listing contains links to federation metadata and other relevant files of some federations that SWITCHaai Federation Members may cooperate with. Fingerprints of signing certificates can be compared with the command:
openssl x509 -fingerprint -sha1 ##METADATA-SIGNING-CERT-FILE##
Identity Providers in non-SWITCHaai federations sometimes use and release different attribute names and values than the ones defined in the AAI attribute specification. Therefore, it may be necessary to make the SP accept these attributes and map them onto attributes that are required by the application protected by the SP. In order to do so, it may be necessary to edit the two files attribute-map.xml and attribute-policy.xml.
The attribute map defines how attributes from a SAML assertion are mapped to the web server environment. It is possible to map multiple SAML attributes onto the same attribut that is made available to the application. This allows for example to compensate for the fact that other federations don't use the attribute swissEduPersonUniqueID to identifiy users. Rather they use the eduPersonPrincipalName, which looks almost the same as the swissEduPersonUniqueID but generally is not opaque. In this case, it may be convenient to map the eduPersonPrincipalName onto the same header as the swissEduPersonUniqueID so that the application doesn't have to care what unique attribute it shall use for identifying users. This could be accomplished for example with an entry in the attribute-map.xml like the following, which maps the eduPersonPrincipalName onto the same header as the swissEduPersonUniqueID:
<!-- eduPersonPrincipalName--> <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName" id="Shib-SwissEP-UniqueID" aliases="principalName uniqueID"/> <Attribute name="urn:oid:220.127.116.11.4.1.5918.104.22.168.6" id="Shib-SwissEP-UniqueID" aliases="principalName uniqueID"/>The attribute mapping also is thye first place where filtering occurs. All attributes in SAML assertions with no definition in the attribute map are filtered out. Therefore, one must make sure that a definition in the attribute map for all attributes that the application requires exists.
The attribute policy on the other hand defines which attributes and values are accepted by the SP. One could for instance create a rule that will make the SP accept a certain attribute or value only from specific Identity Providers. Or it can be enforced that attributes can only have certain values or that the values must match a regular expression. The default behaviour is to pass all attributes which are not referenced specifically by a rule in this file.
In order to find out whether the attribute map and policy must be adapted, one has to find out which attributes the in question service requires. Since most federations use attributes based on the eduPerson attribute schema or the SCHAC schema, they mostly use the same attribute names and value definitions. For a list of available eduPerson attributes, have a look at the file /etc/shibboleth/attribute-map.xml.dist that should contain a complete listing of (commented out) attribute mappings.
In order to test whether a user from the bilaterally configured IdP can access the service, it's best to try the following procedure:
Once access from the Non-SWITCHaai IdP was successfully tested and all attributes that the service requires are available, one can adapt the access control rules. This is done like one would do it for any SWITCHaai IdP because it is purely based on attributes. For details how to define access rules, please have a look at the page that explains access control. Just keep in mind that all attributes that are used for access control rules must be available and contain one or more values. Otherwise the rule won't match and access will be denied.
In order for users of non-SWITCHaai IdPs to being sent to the login page of the Non-SWITCHaai IdP to log in, it is necessary to either provide a special login link for them or to extend the Embedded WAYF with entries for the other IdPs.
Please feel free to contact us for assistance and recommendations in case of difficulties or problems.