(Shibboleth SP v1.3)
You usually don't want to release all attributes to every application that's running on a particular webserver. Though this is of less importance if one person manages all applications on that server, it becomes extremely important on a shared webserver! To control the release of attributes at the IdP side, you need the SP to identify every application with a separate providerId. This can all be configured in shibboleth.xml (and appropriate adjustments at the IdP) as explained on this page.
However, each application SHOULD live on a separate virtual host from the others. Failing to do this will not provide any real separation of applications because any resource in one application can generally trick the client into supplying the cookie issued by another.
<RequestMap> element contains mappings from request-URLs to
applicationIds. Take a look at this piece of configuration in the default
<RequestMapProvider type="edu.internet2.middleware.shibboleth.sp.provider.NativeRequestMapProvider"> <RequestMap applicationId="default"> <!-- This requires a session for documents in /secure on the containing host with http and https on the default ports. Note that the name and port in the <Host> elements MUST match Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element below. --> <Host name="sp.example.org"> <Path name="secure" authType="shibboleth" requireSession="true" exportAssertion="true"/> </Host> <!-- this line below: --> <Host name="admin.example.org" applicationId="foo-admin" /> </RequestMap> </RequestMapProvider>
<RequestMap> element always has an
applicationId attribute with a fixed value of default that matches another configuration block a bit lower in shibboleth.xml.
Note the line that contains
applicationId="foo-admin". This is a mapping of the request-URL to a separate
applicationId. This is absolutely necessary to create a separate application since applications are defined by
applicationIds. You can define a separate applicationId for any
Important Note: for this security-contraint that is defined in the Shibboleth configuration to work, the request needs to pass through the Shibboleth module/filter. For IIS this means that the ISAPI filter should be enabled on this location (that's usually ok). For Apache httpd this means that you need to enable the module on this location in the webserver configuration or a .htaccess file (this is usually not the case). For Apache httpd, you can use these directives to enable the modules in "lazy session" mode so it processes each request:
<Location /> AuthType shibboleth require shibboleth </Location>
Adjust this configuration to fit your needs.
The next step is to map the new, separate
applicationId to a new, separate
providerId. This is also done in
shibboleth.xml. Take a look at this piece of configuration:
<Applications id="default" providerId="https://sp.example.org/shibboleth" homeURL="https://sp.example.org/" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <!-- ... --> <Application id="foo-admin" providerId="https://admin.example.org"> <!-- ### this is *necessary* if you are subsetting a <host>, use the default /Shibboleth.sso when configuring for vhosts --> <!-- <Sessions lifetime="7200" timeout="3600" checkAddress="false" handlerURL="/secure/admin/Shibboleth.sso" handlerSSL="true" cookieProps="; path=/secure/admin; secure"> </Sessions> --> </Application> <!-- ... --> </Applications>
Each separate application also needs a separate Shibboleth handler. That's what the
<Sessions> elements takes care of. (When using a version prior to 1.3b you MUST specify an
AssertionConsumerService Location. Forgetting this will result to the following error: "Shibboleth handler invoked at an unconfigured location".) When using vhosts, you will notice that
Shibboleth.sso is already listening on all vhosts so there's no need for another
Sessions element if the default's properties are OK.
Also take a look at the
cookieProps, they make sure that THIS Shibboleth session stays within THIS application (
path to restrict access to the cookie within this path;
secure option to restrict transport of the cookie only when using https aka ssl-secured).
Note that this separate application can be configured to only see the
EduPersonPrincipalName attribute of the user. If you use this configuration where you specify certain attributes to be realeased, then you will have to specify EVERY attribute that you want to release to this application. If you don't specify any attributes, Shibboleth queries for all attributes as defined in the parent element.
The SP is ready now.
It is obvious that the new application will also identify itself to the IdP with its new,separate
providerId. That was actually the point of this entire howto. So the modifications will require some changes at the IdP too.
Using Shib v1.3, you will have to create separate metadata for each application since the Shibboleth handler. Copy the the entire <EntityDescriptor> element of the providerId of the "default"
applicationId . The only changes necessary are the
entityID and the
AssertionConsumerService Location values. This can be done because you are using the same credentials as the default application.
The whole point was to create separate rules at the IdP to release attributes. So you should now adjust your
arp.sites.xml to match your needs.
You have now separated an application from the default application in a simple way.