Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

For a given IdP, Portal SP, and WSP SP, the entityIds and public keys need to be used and shared consistently across them all. Use this are space to record their values for a particular set of entities. The section following this will refer to them by the "shell variables" defined on the left hand side below.

$IdPEntityId

...

                                                                                                                                                                                                                   

$PortalEntityID

 

$WSPEntityId

 

Configuration guidance

Each component - IdP, the Portal's SP, the Portlet, and the WSP

$PortalEntityID=  _______________________________________________________________

$WSPEntityId=  __________________________________________________________________

Configuration guidance

Each component - IdP, the Portal's SP, the Portlet, and the WSP's SP - has ordinary configuration needs unrelated to enabling delegation. A general prerequisite of the following guidance is that these are working in non-delegation scenarios.

...

The RelyingParty element for each WSP must have a ProfileConfiguration element to enable its delegation delegation support . To prevent it from further delegation set allowTokenDelegation to "false".

...

Step 5(g) of the delegation plug-in installation instructions require requires a that a suitable IdP key be identified as IdPValidationOnlyCredential. It's important that this not be a new key. Use a single key for all of the IdP's purposes.

...

Portal's SP configuration

Configuration objectives The sole configuration objective for this SP are:

...

is to enable it to integrate with the Delegated SAML Authentication Library used by portlets acting as delegates.

...

Note that there There is no delegation-specific configuration required beyond that necessary to properly integrate with uPortal so that uPortal together with its portlets can act as a delegateother delegation-specific configuration required.

Integrating uPortal with shibboleth to support delegation centers on enabling the SP to provide the portal's Delegated SAML Authentication Library with the SAML response token from the user login sequence and with the IdP's public signing keys from the metadata.

...

Code Block
xml
xml
<RequestMapper type="Native">
  <RequestMap applicationId="default">
    <Host name="$PortalHostName"authType="shibboleth" requireSession="true" exportAssertion="true"/>
  </RequestMap>
</RequestMapper>
...
<ApplicationDefaults id="default" policyId="default"
  entityID="$PortalEntityId"
  homeURL=" "
  REMOTE_USER="uid eppn persistent-id targeted-id"
  signing="false" encryption="false id="default" policyId="default"
  ...
  metadataAttributePrefix="Meta-">
  ...
  <Sessions ...
    exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
    exportACL="127.0.0.1" ... >
    ...
  </Sessions>
  ...
  <AttributeExtractor type="Chaining">
    <AttributeExtractor type="XML" path="attribute-map.xml"/>
    <AttributeExtractor type="KeyDescriptor" signingId="Signing-Keys"/>
  </AttributeExtractor>
  ...
</ApplicationDefaults>

...

Code Block
xml
xml
<bean id="HttpManagerBean" class="edu.wisc.my.webproxy.beans.http.ShibbolethEnabledHttpManagerImpl" scope="prototype">
<property name="spPrivateKey" value="/etc/shibboleth/sp-key.pemsome path"/> <!-- This property and the one below are optional to provide client-side TLS authentication to the IdP -->
<property name="spCertificate" value="/etc/shibboleth/sp-cert.pemsome path"/>
<property name="portalEntityID" value="https://canadaspis.uchicago.edu/shibboleth$PortalEntityId"/> <!-- This property is required -->
</bean>

WSP's SP configuration

Configuration objectives for this SP are:

...

The sole configuration objective for this SPis to enable it to accept proxied SAML tokens, but only those presented by the Portal.

The SessionInitiator of type "SAML2" must have its ECP attribute set to "true" to enable it to produce the appropriate SAML authenticationRequest to be forwarded by the SAML Delegated Authentication Library to the IdP. The PolicyRule of type "Conditions" must have a new child PolicyRule of type Delegation to enable this SP to process delegated tokens that it receives. The Delegation PolicyRule uses a del:delegate element and a match attribute so that only delegated tokens received from the Portal will be accepted

...

.

The example configuration below assumes that the default Application is the Portal. It is also possible to associate these declarations with specific Applications by using ApplicationOverride elements.

Code Block
xml
xml
<ApplicationDefaults id="default" policyId="default"
  entityID="$WSPEntityId"
  homeURL="&nbsp;&nbsp; "
  REMOTE_USER="uid eppn persistent-id targeted-id"
  signing="false" encryption="false" some URL " ... >
  ...
  <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet" relayState="cookie" entityID="$IdPEntityId">
    <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html" ECP="true"/>
    <SessionInitiator type="Shib1" defaultACSIndex="5"/>
  </SessionInitiator>
  ...
</ApplicationDefaults>
...
<SecurityPolicies>
  <Policy id="default" validate="false">
    <PolicyRule type="MessageFlow" checkReplay="true" expires="60"/>
    <PolicyRule type="Conditions">
      <PolicyRule type="Audience"/>
      <!-- Enable Delegation rule to permit delegated access. -->
      <PolicyRule type="Delegation" match="oldest"
        xmlns:del="urn:oasis:names:tc:SAML:2.0:conditions:delegation"
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" >
        <del:Delegate>
          <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">$PortalEntityId</saml:NameID>
        </del:Delegate>
      </PolicyRule>
    </PolicyRule>
    <PolicyRule type="ClientCertAuth" errorFatal="true"/>
    <PolicyRule type="XMLSigning" errorFatal="true"/>
    <PolicyRule type="SimpleSigning" errorFatal="true"/>
  </Policy>
</SecurityPolicies>

...

In order to reduce the number of sources of potential errors as we begin to configure all of this, we can start with a configuration that is simplest and workable but not production ready, and then add in further configuration. Capabilities that can be peeled off and applied after everything else is working are: --- - MAYBE! - ---

  • TLS client authentication of  SOAP messages
  • Delegation restrictions

...