You've got an IdP or an SP that can interoperate with TestShib, and now you'd like to do something useful with your provider. We have a few suggestions on how to proceed, depending on your goals.


You could:


If you'd like to do something different, or have questions, the shibboleth-users@internet2.edu mailing list and its archives are excellent resources.





Use a different IdP in TestShib with your SP

There are two simple steps needed to change the IdP that your SP uses. Follow them both, and you should be able to accept users and attributes from the new IdP.

  1. Download a new copy of the TestShib Metadata from http://www.testshib.org/metadata/testshib-metadata.xml and place it in your SP's configuration directory.
  2. Modify the wayfURL attribute of shibboleth.xml's <SessionInitiator/> element to point to the URL of the SSO handler of the IdP.

That should work. Try it out by accessing your SP as you did when you used TestShib's IdP.

Discovering which IdP to use in a transaction is the biggest problem in federated identity management. The traditional solution is the WAYF service, but this forces users through another click. A separate <SessionInitiator/> element can be declared for each provider and lazy sessions or multiple URL's can be used to differentiate the IdP's, but this scales poorly. InfoCard or a similar technology that includes some client intelligence looks like the most promising solution at this time.



Use a different SP in TestShib with your IdP

Using a new TestShib SP with your IdP requires no configuration of the IdP in most cases as long as you have the SP's metadata. The new SP will receive the default attributes unless you write a special ARP.

  1. Download a new copy of the TestShib Metadata from http://www.testshib.org/metadata/testshib-metadata.xml and place it in your SP's configuration directory.
  2. Remember that that SP needs to be configured with a <SessionInitiator/> of some sort(direct pointer, or a WAYF) for your IdP.

Access a resource protected by this SP. From there, the standard flows should happen.

If this or other SP's will require special treatment, we've got just the Wiki topic for you.



Send Attributes from LDAP

The default TestShib installation uses attributes that are generated by a dummy responder. They're always the same for everyone. Attributes in production should come from an LDAP directory, SQL database, or other source of your choice.

TestShib has a public LDAP directory included in the configuration you downloaded that you can use if you don't have your own data source handy. These instructions cover how to use an LDAP directory.

  1. Modify the resolverConfig attribute of idp.xml's <IdPConfig/> element at the very top to point to resolver.ldap.xml instead of resolver.xml.
  2. If you'd like, modify the TestShib <JNDIDataConnector> element to point to your directory instead of TestShib's. The fields should be self-explanatory.

Remember that your authentication source needs to have the same principal names as will be searched for in the directory. With TestShib, this means either you simply match the names in your user.db to those in the directory or use LDAP authentication to protect your SSO. The TestShib LDAP has entries for myself, alterego, and superego.



Write a custom ARP

Attribute Release Policies(ARP's) restrict the information released about specific users to specific providerId's. We'll write one using basic XML to reduce the information made available to TestShib.

ShARPE is a powerful web-based tool developed by MAMS of Macquarie University to help administrators manage ARP's. Service descriptions and group policies are some of its unique capabilities. The Autograph companion utility gives your users a simple interface to manage their own attribute release. It'd be well worth your time to check these out.

  1. Read through the following policy. For the providerid https://sp.testshib.org/shibboleth/testshib/sp, which corresponds to the TestShib SP, we're going to deny the release of eduPersonPrincipalName because myself considers that sensitive information. Your installation releases that data to everyone by default.

    2. <?xml version="1.0" encoding="UTF-8"?>

<AttributeReleasePolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns="urn:mace:shibboleth:arp:1.0" 
xsi:schemaLocation="urn:mace:shibboleth:arp:1.0 shibboleth-arp-1.0.xsd">
   <Description>Myself wants to protect its identity.</Description>
   <Rule>

      <Target>
         <Requester>https://sp.testshib.org/shibboleth/testshib/sp</Requester>
      </Target>
      <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName">
         <AnyValue release="deny"/>

      </Attribute>
   </Rule>
</AttributeReleasePolicy>
  2. Make a new file in your IdP's /etc/arps/ directory where arp.site.xml is located named arp.user.myself.xml. Open it in a text editor of your choice and paste in the entire above policy.

Try accessing the TestShib SP again. You should notice that the attribute eduPersonPrincipalName is no longer released if you're myself, but it's still released if you authenticate as alterego.



Use Attributes in Webpages and Webapps

Attributes carried by Shibboleth can be used by webapps to provide customized content as well as for access control. We'll show you how to display these passed attributes as a first step. The code used to do that should provide a good example for more sophisticated content customization.

SAML attribute assertions include URI names for the attributes they carry. These names are mapped, filtered, and renamed by the SP using rules in AAP.xml to be made available to applications. Unfortunately, the naming of header variables is to some degree influenced by the web server, which means the same name in AAP.xml can appear differently in different environments.

K.U. Leuven has created demonstration scripts.

  1. Download the script of your choice and install it at /secure as you would deploy any other webapp in that hosting environment.

Try accessing https://yourhostin.testshib.org. With any luck, instead of a 404 error, you'll see attributes.



Restrict Access to a Webpage

Access control for a page can be enforced by the Shibboleth module with XML or .htaccess, by another module using the Shibboleth attributes, or by the webapp. We'll just briefly show how to do it using mod_shib's standard access controls.

Let's pretend your resource at /secure is a TestShib faculty portal which should only be available to people with an eduPersonAffiliation of Faculty@testshib.org. This means that of the TestShib IdP users, only superego should be given access.

  1. Find the <Location /secure> directive which protects your test resource. This is located at /opt/shibboleth-sp/etc/apache*.config (depends on your version) for most installations and /etc/httpd/conf.d/shib.conf for RPM installations.
  2. Change the require valid-user directive to be require affiliation Faculty@testshib.org instead.

Try accessing the page using different users from the TestShib IdP. See what happens.


© Copyright 2006 Internet2.