Configuring IdP for SLCS certificates

From BeSTGRID

Jump to: navigation, search

This page lists the configuration steps that must be done to let an already configured IdP join the ARCS SLCS operation and let the users start using SLCS certificates.

The steps are:

  • Configure the SharedToken and Organization attributes
    • The other required attributes needed are Common Name and Email address - these are likely to be already configured.
  • Include the SLCS server metadata on the IdP.
  • Ask the SLCS server administrator (Sam Morrison) to trust your IdP on the SLCS server.
    • Give him also the statically configured Organization attribute and ask him to configure this Organization for the New Zealand DN namespace.
  • Download the SLCS client application.
    • If your IdP has Autograph installed, configure the application to use the /shibboleth/IdP SSO URL instead of /shibboleth/SSO
  • Install the SLCS CA root certificate on your grid gateway (including the GUMS server).

Contents

[edit] Shared Token attribute

There are two approaches to providing the SharedToken attribute - either Federation Managed (FAST) or Institution Managed (IMAST). Both are documented at http://www.aaf.edu.au/documentation.

The advantages of FAST are:

  • Reliable central storage.
  • Easier transfer of SharedToken among institutions (when a researcher moves to a different site).
  • A central mechanism for avoiding hash collisions (keep tokens unique).

The advantages of IMAST would be:

  • Not dependent on a single point of failure.

This page documents how to configure the SharedToken attributes based on the FAST approach - but IMAST would work the same well (if the new encoding avoiding problematic characters is implemented). 


wget http://www.mams.org.au/downloads/FAST-idp.zip
  • Copy all jars into /var/lib/tomcat5/webapps/shibboleth-idp/WEB-INF/lib/
    • Note: commons-codec-1.3.jar already exists
    • A few other jars exist in different versions:
    • commons-logging-1.03.jar (old) vs. commons-logging-1.1.jar (new)
    • xmlsec-20050514.jar (old) vs. xmlsec-1.3.0.jar (new)
    • Keeping so far both.
  • Add the attribute definition to resolver.ldap.xml
    • If no <AttributeDependency> is provided, FAST will use just the IdP and user identification - but that is perfectly sufficient. 
<CustomAttributeDefinition id="urn:mace:federation.org.au:attribute:auEduPersonSharedToken"
                   class="au.edu.mq.melcoe.mams.fst.wsservice.SharedTokenAttrDef">
</CustomAttributeDefinition>
  • Testing shared token:
    • With resolvertest, I need to include all jars from /var/lib/tomcat5/webapps/shibboleth-idp/WEB-INF/lib/ in classpath - and then Yes, I do have a shared token attribute!
    • With Autograph: define the attribute first in/usr/local/shibboleth-autograph/connectorConfigs/AttributeInfoPointData.xml 
               <Attribute id="urn:mace:federation.org.au:attribute:auEduPersonSharedToken"  type="string">
                       <FriendlyName lang="en">shared token</FriendlyName>
                       <Description lang="en">no description</Description>
               </Attribute>
    • Testing on a SP: define the attribute in AAP.xml: 
       <AttributeRule Name="urn:mace:federation.org.au:attribute:auEduPersonSharedToken" Header="Shib-AuEduPerson-SharedToken">
               <AnySite>
           <AnyValue/>
       </AnySite>
       </AttributeRule>
    • Restart shibd
  • Testing in Autograph:
    • Installing JARS the same as for IdP itself (similar case, commons-codec-1.3.jar and xalan-2.7.0.jar already exist, and xmlsec-20050514.jar already existed vs. new version xmlsec-1.3.0.jar)
    • Works OK - except that I get a different value then inside the IdP (problem being investigated).

[edit] Organization attribute

To use the SLCS service, it is necessary to configure the Organization attribute to be defined for each user with a static value (like "University of Canterbury"). It might also be desirable to configure the Country attribute with the value of "NZ". Following the StaticDataConnector documentation, add the following into resolver.ldap.xml: 

   <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:o">
       <DataConnectorDependency requires="staticAttributesConnector"/>
   </SimpleAttributeDefinition>

   <SimpleAttributeDefinition id="urn:mace:terena.org:schacCountryOfResidence">
       <DataConnectorDependency requires="staticAttributesConnector"/>
   </SimpleAttributeDefinition>

   <StaticDataConnector id="staticAttributesConnector">
       <Attribute name="o">
           <Value>University of Canterbury</Value>
       </Attribute>
       <Attribute name="schacCountryOfResidence">
           <Value>NZ</Value>
       </Attribute>
   </StaticDataConnector>

If you are using Autograph, add the following into /usr/local/shibboleth-autograph/connectorConfigs/AttributeInfoPointData.xml: 

               <Attribute id="urn:mace:dir:attribute-def:o"  type="string">
                       <FriendlyName lang="en">organization</FriendlyName>
                       <Description lang="en">no description</Description>
               </Attribute>
               <Attribute id="urn:mace:terena.org:schacCountryOfResidence"  type="string">
                       <FriendlyName lang="en">country</FriendlyName>
                       <Description lang="en">no description</Description>
               </Attribute>

Please note that earlier versions of Autograph could not handle a StaticDataConnector. You may need an updated shib-java.jar, or better a newer version of Autograph. You may get these either from Stuart Allen (MELCOE), or from the author of this documentation (Vladimir Mencl).

If you are not using Autograph, configure the release of these attributes for the target SP in the site's Attribute Release Policies (ARPs).

[edit] SLCS server metadata

Because slcs1.arcs.org.au is only registered at Level 1, I had to manually add a mini-federation with the SLCS SP metadata:

  • Create extra-metadata.xml - take level-1-metadata.xml and keep only
    • Testbed Federation Level 1 CA's <ds:KeyInfo>
    • <EntityDescriptor entityID="urn:mace:federation.org.au:testfed:slcs1.arcs.org.au">
    • Change OrganizationDisplayName from "VPAC" to "ARCS SLCS server" to distinguish it in Autograph from other VPAC's entries.
  • Include the file in idp.xml: 
     <MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata"
             uri="file:/usr/local/shibboleth-idp/etc/extra-metadata.xml"/>
  • For new version Autograph, also embed the Service Provider Description (SPD) inside the metadata

You may download the attached file extra-metadata.xml.

[edit] Registration with SLCS server administrator

  • Ask Sam Morrison to allow your IdP to access the SLCS server.
  • Give him the value configured for the Organization static attribute and ask him to configure that for the NZ BeSTGRID namespace.

[edit] Testing the SLCS service

[edit] SLCS client application

  • Follow the ARCS instructions for installing the SLCS command-line client.
  • After the build, untar the file glite-slcs-ui-1.3.2-jdk1.6.tar.gz somewhere.
  • Within the extracted directory, edit the metadata in etc/glite-slcs-ui/slcs-metadata.aaf.xml
    • Enter https://slcs1.arcs.org.au/SLCS/login as the Service Provider.
    • Create a configuration entry for your IdP
      • If you have Autograph installed, configure your IdP with the location /shibboleth-idp/IdP instead of /shibboleth-idp/SSO
        • Because the new version Autograph redirection servlet always redirects /Autograph/ConfigurationDecision and automated tools may not be able to handle the sequence of redirects, it is necessary to point them to /shibboleth-idp/IdP (instead of /shibboleth-idp/SSO) - which goes straight to the IdP SSO login, bypassing Autograph-related redirects.
  • Edit etc/glite-slcs-ui/slcs-init.xml and change the path to etc/glite-slcs-ui/truststore.aaf.jks - by default, it assumes you untarred the distribution in /opt/glite

Finally, in the bin directory, run 

./slcs-init -i canterbury.ac.nz -u YOUR-USER-ID -p YOUR-SHIB-PASSWORD -k PASSPHRASE
  • replace the -i parameter with your IdP id as defined in the metadata.

[edit] SLCS-enabled Grix and Grisu

  • These are both preliminary versions under development - use with care. As of now, they only list Level 1 IdPs - stay tuned for updates.

[edit] SLCS CA root certificate

[edit] Pending issues

  • The SLCS server occasionally fails and the SLCS client tool prints 
Shibboleth Authentication Failed.
  • The shibd logs on the SLCS server contain the following message (after successfully going through one Artifact resolution query): 
2008-09-12 14:45:19 ERROR SAML.SAMLSOAPHTTPBinding [511] sessionNew: failed while contacting SAML responder: error:1408F06B:SSL routines:SSL3_GET_RECORD:bad decompression
2008-09-12 14:45:19 ERROR shibd.Listener [511] sessionNew: caught exception while creating session: SOAPHTTPBindingProvider::send() failed while contacting SAML responder: error:1408F06B:SSL routines:SSL3_GET_RECORD:bad decompression
  • This problem occurred so far twice:
    • Once it went away after moving the IdP to a new system (RHEL based, with openssl-0.9.8b-10.el5, just slightly newer then the old CentOS-based IdP)
    • It reoccurred once, and was solved by restarting shibd on the SLCS server.
    • The problem is likely to occur again: however, no permanent solution has been found yet. It might help to configure Apache on the IdP to only accept SSLv2 ciphers, where no compression is available.
Retrieved from "http://www.bestgrid.org/index.php/Configuring_IdP_for_SLCS_certificates"