Shibboleth 2.0 IdP slides - Installfest (Edited)

Installation to SSO

Chad La [email protected]

2© 2008 SWITCH

Tour of What We Learned

SWITCH AAI Demo Page: http://aai-demo.switch.ch

http://aai-demo.switch.ch/

3© 2008 SWITCH

Terms: Entity ID

A unique identifier for a identity provider (IdP) or service provider (SP)

In shibboleth 2 the recommended format is a URLidp: https://HOSTNAME/idp/shibboleth

sp: http://HOSTNAME/shibboleth

4© 2008 SWITCH

Terms: Relying Party

The SAML peer to which the IdP is communicating.

In all existing cases, the relying party of the IdP is always an SP. Some very advanced cases allow one IdP to be a relying party to another IdP.

5© 2008 SWITCH

Terms: Binding

A description of how a SAML message is attached to an underlying transport protocol, such as http or smtp.

For example: If the message is sent over HTTP what HTTP headers need to be set, what are the URL or form parameter names, etc.

6© 2008 SWITCH

Terms: Profile

A description of how to use SAML, over a specific binding, to accomplish a specific task (e.g. Single Signon) in an interoperable manner.

Profiles are the finest grained unit of interoperability within SAML.

7© 2008 SWITCH

Terms: Metadata

A description of the SAML features supported by a SAML entity. Most importantly this includes the URLs for communicating with an entity.

Shibboleth also uses this information to build technical trust between entities.

8© 2008 SWITCH

Lets take a Closer Look

http://www.switch.ch/aai/demo/2/medium.html

http://www.switch.ch/aai/demo/2/medium.html

9© 2008 SWITCH

Installation

• Unpack the Shibboleth distributionunzip -d /usr/local/src /opt/installfest/shibboleth-idp-2.0.0-bin.zip

• Change to /usr/local/src/identityprovider

• chmod +x ant.sh

• Run the installation script; ./ant.sh• answer yes, this is a new install• use /opt/shibboleth-idp as your shib home

directory• enter your hostname: idp#.example.com• enter password for your password

10© 2008 SWITCH

SHIB_HOME

• /opt/shibboleth-idp should now contain:–bin–conf–credentials–lib–logs–metadata–war

•The Shibboleth documentation refers to this directory as SHIB_HOME

11© 2008 SWITCH

SHIB_HOME/bin

Contains command line tools

aacli: Attribute authority command line interface allows you to simulate an attribute query/release

version: Provides the version of the IdP

12© 2008 SWITCH

SHIB_HOME/conf

The IdP’s configuration files.

We’ll cover most as we go through the course. We will not cover service.xml or internal.xml as these control advanced features.

13© 2008 SWITCH

SHIB_HOME/credentials

Credentials used by the IdP.

By default the IdP’s generated key (idp.key), cert (idp.crt) and a keystore (idp.jks) containing both are put here.

Good location to place things like trust anchor X.509 certs, cached CRLs, etc.

14© 2008 SWITCH

SHIB_HOME/lib

The libraries (jars) that make up the IdP.

These are copies of those that occur in the IdP WAR file and are only used by the command line tools.

15© 2008 SWITCH

SHIB_HOME/logs

Location of the Shibboleth log files.

process log: detailed description the IdP processing requests

access log: record of all the clients that connect to the idP

audit log: record of all information sent out from the IdP

16© 2008 SWITCH

SHIB_HOME/metadata

Default location where various metadata files are stored.

The IdP does not automatically load any metadata. Metadata read from a file, or stored backup copies of remote metadata are usually put in this directory.

17© 2008 SWITCH

SHIB_HOME/war

The location of the IdP WAR file created by the installer.

We point Tomcat to this file, instead of copying it to Tomcat, so that we don’t forget to copy new WARs if we rebuild the IdP (to add an extension, for example) or run into problems with Tomcat’s file caching mechanisms.

18© 2008 SWITCH

Metadata: Configuration

• Metadata is loaded in to the IdP by metadata providers.

• Metadata providers are configured in the relying-party.xml file

• This file may only contain one top-level provider. By default the top level provider is a chaining provider that contains other metadata providers and uses them in the order defined.

19© 2008 SWITCH

Metadata: Provider Config

•Metadata providers are configured using <MetadataProvider> element

•Every metadata provider has a:–unique ID given by the id attribute–type given by the xsi:type attribute

•Each type of metadata provider has its own set of configuration options

•Metadata provider may have a single filter defined by <MetadataFilter>

20© 2008 SWITCH

Metadata: Filesystem Provider

•The filesystem metadata provider reads a metadata file from the local filesystem.

•Type attribute value:–FilesystemMetadataProvider

•Configuration attribute:–metadataFile gives the path to the metadata file

21© 2008 SWITCH

Metadata: File-backed HTTP Provider

• Loads metadata via HTTP and backs it up to a local file

• Type attribute value:–FileBackedHTTPMetadataProvider

• Configuration Attributes:–metadataURL: HTTP URL of metadata file–backingFile: location of the backup file–cacheDuration: max time between refreshes

• Refreshes metadata automatically, no more cron jobs!

22© 2008 SWITCH

Metadata: Watchout

The chaining metadata provider looks up relying party information in its children in the order they are defined. If two child providers load different metadata for the same entity only the first description will ever be used by the IdP. No attempt to merge the data is made.

23© 2008 SWITCH

Metadata: UK Configuration

• Define the provider

<MetadataProvider id=“ukfederation”

xsi:type="FileBackedHTTPMetadataProvider”

xmlns="urn:mace:shibboleth:2.0:metadata”

metadataURL=“http://metadata.ukfederation.org.uk/ukfederation-metadata.xml”

backingFile=”/opt/shibboleth-idp/metadata/ukfed.xml”>



<MetadataFilter xsi:type="SignatureValidation”

xmlns="urn:mace:shibboleth:2.0:metadata"

trustEngineRef="shibboleth.SignatureTrustEngine"

requireSignedMetadata="true" />

</MetadataProvider>

24© 2008 SWITCH

Metadata: UK Configuration

• Download UK Federation Certificatecurl http://metadata.ukfederation.org.uk/ukfederation.pem > /opt/shibboleth-idp/credentials/ukfederation.pem

• Add Certificate to shibboleth.SignatureTrustEngine trust engine

<security:TrustEngine xsi:type="security:StaticExplicitKeySignature" id="shibboleth.SignatureTrustEngine">

<Credential xsi:type="X509Filesystem” xmlns="urn:mace:shibboleth:2.0:security" id=”UKFederationTrustAnchor"> <Certificate> /opt/shibboleth-idp/credentials/ukfederation.pem </Certificate> </Credential>

</security:TrustEngine>

25© 2008 SWITCH

Terms: Authentication Method

An identifier that a relying party may use to stipulate how authentication should be performed.

Authentication method identifiers correspond to a prescription of how authentication is done (even if the details are only in someone’s head).

26© 2008 SWITCH

Terms: Login Handler

An IdP component that correlates all supported authentication methods with currently configured authentication mechanisms.

A login handler may map more than one authentication method to the same authentication mechanism.

27© 2008 SWITCH

Terms: Session

State information about the user, currently active authentication methods, and services to which they are signed into.

A user’s IdP session is created the first time they authenticate but may outlive the lifetime of all authentication methods.

28© 2008 SWITCH

Login Handler: Configuration

• Login handlers are configured in handler.xml•<LoginHandler> defines a login handler• Every login handler definition has a xsi:type attribute that defines the type of the handler.

• Each type has its own set of configuration options.• Each <LoginHandler> must contain at least one <AuthenticationMethod> indicating what authentication method it provides

29© 2008 SWITCH

Login Handler: UsernamePassword

•Login handler that prompts for a username/password and validates against a JAAS module (LDAP & Kerberos 5 currently supported)

•Type attribute value:UsernamePassword

•Configuration attributes:–jaasConfigurationLocation path to the JAAS configuration file

30© 2008 SWITCH


Edit the login.config• Uncomment the LDAP login modules• Configure it like this:

edu.vt.middleware.ldap.jaas.LdapLoginModule required

host=”ldap.example.org”

base="ou=people,dc=example,dc=org"

userField="uid";

31© 2008 SWITCH


Edit handler.xml

• Comment out RemoteUser handler

• Uncomment UsernamePassword handler• Add unspecified authentication method

<AuthenticationMethod> urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</AuthenticationMethod>

32© 2008 SWITCH

Login Handler: Authentication Duration

• Each authentication mechanism supports an activity timeout

• After this timeout expires the mechanism is considered inactive for that user.

• If the user attempts to access a new service provider that requires that authentication mechanism they must re-authenticate.

• It is configured by the authenticationDuration attribute on the <LoginHandler>

• Its value is the number of minutes of inactivity and its default value is 30.

33© 2008 SWITCH

Forced Authentication

•Only works with mechanisms that can re-authenticate a user.

•RemoteUser does not support forced authentication.

•The service provider will receive an error if the IdP can not support forced authentication

34© 2008 SWITCH

Terms: Authentication Mechanism

A concrete mechanism used to authenticate a user.

Shibboleth 2 currently supports REMOTE_USER, user/pass against LDAP & Kerberos, and IP address based mechanisms.

Attribute Resolution

36© 2008 SWITCH

Terms: Attribute

A piece of information about a user. Each attribute has a unique ID and has zero of more values.

Shibboleth attributes are protocol-agnostic data structures.

37© 2008 SWITCH

Terms: SAML Attribute

An attribute that is represented in SAML notation.

Shibboleth transforms attributes into SAML attributes by a process known as encoding.

38© 2008 SWITCH

Terms: Data Connector

A plugin that creates multiple attributes from information in data sources like LDAP and databases.

Shibboleth currently supports static, LDAP, relational database, computed, and stored ID data connectors.

39© 2008 SWITCH

Data Connection Configuration

•Data connectors are configured in attribute-resolver.xml•<DataConnector> defines a data connector

•Every data connector has a id attribute that uniquely identifies it.

•Every data connector has a xsi:type attribute that defines the type of the handler.

•Each type has its own set of configuration options.

40© 2008 SWITCH

Data Connector Configuration

•Some connectors will need information collected by another plugin in order to work. This is represented by a <resolver:Dependency ref=“NAME” />

•The dependency is declared before any other configuration elements.

•The value of the ref attribute is the ID of the plugin upon which the connector depends.

41© 2008 SWITCH

Data Connector Failover

•Data connectors may define failover connectors such that if the data connector fails the failover connector is invoked.

• If more than one failover connector is defined they are tried in order until one succeeds.

•They are defined using:<resolver:FailoverDataConnector ref="CONNECTOR_ID_1" />

42© 2008 SWITCH

Terms: Attribute Definition

A plugin that creates a single attribute by transforming other attributes and state information.

Shibboleth currently supports simple, scoping, regex, mapping, template, scripting, principal name, and principal authentication method attribute definitions.

43© 2008 SWITCH

Attribute Definition Configuration

•Attribute definitions are configured in attribute-resolver.xml•<AttributeDefinition> defines a definition

•Every definition has a id attribute that uniquely identifies it.

•Every definition has a xsi:type attribute that defines the type of the handler.


44© 2008 SWITCH

Attribute Definition Configuration

•Most definitions will need information collected by another plugin in order to work. This is represented by a <resolver:Dependency ref=“NAME” />

•The dependency is declared before any other configuration elements.

•The value of the ref attribute is the ID of the plugin upon which the definition depends.

45© 2008 SWITCH

Terms: Attribute Encoder

A plugin that converts an attribute into a protocol specific form, like a SAML attribute.

Attribute encoders are associated with an attribute through the attribute’s attribute definition.

46© 2008 SWITCH

Attribute Encoder Configuration

• Attribute encoders are configured as children of an attribute definition.

•<AttributteEncoder> defines an encoder• Every definition has a xsi:type attribute that defines the

type of the handler. • Each type has its own set of configuration options.

47© 2008 SWITCH

Terms: Principal Connector

A plugin that converts a name identifier, provided by a relying party, into the internally used userid.

48© 2008 SWITCH

Terms: Attribute Resolver

A subsystem in Shibboleth responsible for fetching, transforming, and associating encoders with attributes.

Only attributes produced by attribute definitions leave the resolver and are available to other parts of the system.

49© 2008 SWITCH

More About Attribute Dependencies

•Any resolver plugin may have any number of dependencies.

• If more than one dependency provides the same attribute the dependant plugin operates on the effective union of values

•Attribute definitions may be marked with a dependencyOnly=“true” attribute. This ensures the value is never released outside the resolver (and speeds up filtering a bit).

50© 2008 SWITCH

Some Examples – LDAP Connector

<resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc" id="MyLDAP" ldapURL="LDAP_URL" baseDN="BASE_DN" principal="PRINCIPAL_NAME" principalCredential="PRINCIPAL_CREDENTIAL">

<FilterTemplate>

<![CDATA[

(uid=${requestContext.principalName})

]]>

</FilterTemplate>

<ReturnAttributes>x y z</ReturnAttributes>

51© 2008 SWITCH

Some examples – Static Connector

<resolver:DataConnector id="staticEntitlements" xsi:type="dc:Static"xmlns="urn:mace:shibboleth:2.0:resolver:dc">

<Attribute id="eduPersonEntitlement">

<Value>urn:mace:dir:entitlement:common-lib-terms</Value>

</Attribute>

</resolver:DataConnector>

52© 2008 SWITCH

Example – Simple Directory Lookup of epe

<resolver:AttributeDefinitionid="eduPersonEntitlement"xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"sourceAttributeID="shibentitlement">

<resolver:Dependency ref="myLDAP" />



</resolver:AttributeDefinition>

53© 2008 SWITCH

Example – Attribute Encoders

<resolver:AttributeEncoder xsi:type="SAML1String"xmlns="urn:mace:shibboleth:2.0:attribute:encoder"name="urn:mace:dir:attribute -def:eduPersonEntitlement" />

<resolver:AttributeEncoder xsi:type="SAML2String"xmlns="urn:mace:shibboleth:2.0:attribute:encoder"name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7"friendlyName="eduPersonEntitlement" />

54© 2008 SWITCH

Some examples – Static entitlements

<resolver:AttributeDefinitionid="eduPersonEntitlement"xsi:type="Simple"xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="shibentitlement">

<resolver:Dependency ref="staticEntitlements" />




55© 2008 SWITCH

Example – Computing epe from group membership

<resolver:AttributeDefinition xsi:type="Script"xmlns="urn:mace:shibboleth:2.0:resolver:ad"id="eduPersonEntitlement">

<Dependency ref="MyLDAP" />

<Script>

<![CDATA[ // Script here

]]>

</Script>


56© 2008 SWITCH

Example – Continued

<![CDATA[importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);

epe = new BasicAttribute("eduPersonEntitlement");

for (i = 0; i<isMemberOf.getValues().size(); i++ { if (isMemberOf.getValues().get(i)).equals("STF"){ epe.getValues().add("member"); epe.getValues().add("staff");

}

}

]]>

57© 2008 SWITCH

Example – eptid computed

<resolver:AttributeDefinition xsi:type="Scoped" id="eduPersonTargetedID" xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="example.org" sourceAttributeID="computedID">

<resolver:Dependency ref="computedIDConnector" />


<resolver:DataConnector xsi:type="ComputedId" xmlns="urn:mace:shibboleth:2.0:resolver:dc" id="computedIDConnector" generatedAttributeID="computedID" sourceAttributeID="uid" salt="your random string here">



58© 2008 SWITCH

Example – eptid stored

<resolver:AttributeDefinition xsi:type="Scoped" id="eduPersonTargetedID" xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="example.org" sourceAttributeID="storedID">

<resolver:Dependency ref="storedIDConnector" />


59© 2008 SWITCH

Example - Continued

<resolver:DataConnector xsi:type="StoredId"xmlns="urn:mace:shibboleth:2.0:resolver:dc"id="storedIDConnector"generatedAttributeID="storedID"sourceAttributeID="uid"salt="ThisIsRandomText">

<resolver:Dependency ref="MyLDAP" />

<ApplicationManagedConnection jdbcDriver="DRIVER_CLASS"

jdbcURL="DATABASE_URL" jdbcUserName="DATABASE_USER" jdbcPassword="DATABASE_USER_PASSWORD" />




60© 2008 SWITCH

Example – Continued

• Database created with:CREATE TABLE shibpid (

localEntity VARCHAR NOT NULL,

peerEntity VARCHAR NOT NULL,

principalName VARCHAR NOT NULL,

localId VARCHAR NOT NULL,

persistentId VARCHAR NOT NULL,

peerProvidedId VARCHAR NULL,

creationDate TIMESTAMP NOT NULL,

deactivationDate TIMESTAMP NULL

)

61© 2008 SWITCH

Example – adding scope

<resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="example.org" sourceAttributeID="uid">



62© 2008 SWITCH

Example - prescoped

<resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Precoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="example.org" sourceAttributeID="shibeppn">



Attribute Filtering

64© 2008 SWITCH

Terms: Attribute Filter Policy

A policy containing a trigger, that indicates if the policy is active, and a set of attribute value filters.

65© 2008 SWITCH

Attribute Filter Policy Configuration

•Attribute filters are defined in attribute-filter.xml

•Attribute filter policies are declared with <AttributeFilterPolicy>

•Every filter policy has a single id attribute that provides a unique name for the policy.

66© 2008 SWITCH

Terms: Policy Requirement Rule

A specific requirement that must be met in order for an attribute filter policy to in effect.

An attribute filter policy may only have one requirement rule but some rules allow child rules to be declared and combined.

67© 2008 SWITCH

Policy Requirement Rule Configuration

•<PolicyRequirementRule> defines a requirement rule.

•Every rule has a xsi:type attribute that defines its type.


•Every attribute filter policy must have one, and only one, policy requirement rule

68© 2008 SWITCH

Terms: Attribute Rule

A rule, specific to an attribute, that determines which values are released to a relying party.

An attribute filter policy may have any number of attribute rules.

69© 2008 SWITCH

Attribute Rule Configuration

•A rule representing the set of values released to a relying party.•<AttributeRule> defines a rule.

•Every rule has an attributeID attribute that identifies the attribute, by ID, to which the rule applies

70© 2008 SWITCH

Terms: Permit Value Rule

A rule that determines if an attribute value is permitted to be released to a relying party.

71© 2008 SWITCH

Permit Value Rule Configuration

•A rule that signifies a value should be released to the requester.•<PermitValueRule> defines a rule.

•Every rule has a xsi:type attribute that defines its type.


72© 2008 SWITCH

Attribute Filtering Gotchyas

•Only those values explicitly permitted are ever released

•There is no way to expressly deny the release of an attributes so be careful how your attribute filter policies overlap (deny value rules will be in 2.1)

•Rules that operate on an attributes’ values will not take into consideration value scopes.

73© 2008 SWITCH

Example – Release eptid & eppn to anyone

<AttributeFilterPolicy id="releaseToAnyone">

<PolicyRequirementRule xsi:type="basic:ANY" />

<AttributeRule attributeID="eduPersonTargetedID">

<PermitValueRule xsi:type="basic:ANY" />

</AttributeRule>

<AttributeRule attributeID="eduPe...cipalName">


</AttributeRule>

</AttributeFilterPolicy>

74© 2008 SWITCH

Example – Release eppn to specific SPs

<AttributeFilterPolicy id="releaseEPPN"> <PolicyRequirementRule xsi:type="basic:OR"> <basic:Rule xsi:type="saml:AttributeRequesterString" value="https://sdauth.sciencedirect.com/sp" />

<basic:Rule xsi:type="saml:AttributeRequesterString" value="urn:mace:athens:somesp" />

</PolicyRequirementRule>

<AttributeRule attributeID="eduPer...cipalName">


</AttributeRule>


75© 2008 SWITCH

Example – Release only allowed epa values

<AttributeFilterPolicy>

<PolicyRequirementRule xsi:type="basic:ANY" /> <AttributeRule attributeID="eduPersonAffiliation">

<PermitValueRule xsi:type="basic:OR">

<basic:Rule xsi:type="basic:AttributeValueString"

value="member" ignoreCase="true" />

<basic:Rule xsi:type="basic:AttributeValueString"

value="staff" ignoreCase="true" />



</PermitValueRule>

</AttributeRule>


76© 2008 SWITCH

Example – Release eppn to specific entitygroups

<AttributeFilterPolicy id="releaseEPPN"> <PolicyRequirementRule xsi:type="basic:OR"> <basic:Rule xsi:type="saml:AttributeRequesterInEntityGroup" value="https://ukfederation.org.uk" />

<basic:Rule xsi:type="saml:AttributeRequesterInEntityGroup" value="urn:mace:athens" />


<AttributeRule attributeID="eduPer...cipalName">


</AttributeRule>


77© 2008 SWITCH

Example – Release eppn to all Sps except...

<AttributeFilterPolicy id="releaseEPPN">

<PolicyRequirementRule xsi:type="basic:NOT">

<basic:Rule xsi:type="basic:OR">

<basic:Rule xsi:type="saml:AttributeRequesterString" value="http://sdauth.sciencedirect.com/sp" />

<basic:Rule xsi:type="saml:AttributeRequesterString" value="urn:mace:athens:somesp" />

</basic:Rule>


<AttributeRule attributeID="eduPersonPrincipalName">


</AttributeRule>


78© 2008 SWITCH

Example – Release epe if AuthN method is x or y & SP is z...

<PolicyRequirementRule xsi:type="basic:AND">

<basic:Rule xsi:type="basic:OR">

<basic:Rule xsi:type="...AuthenticationMethodString" value="some-string-for-iris-scan" />

<basic:Rule xsi:type="...AuthenticationMethodString" value="some-string-for-fingerprint-reader" />

</basic:Rule>

<basic:Rule xsi:type="..AttributeRequesterString" value="https://myfinanceapp.example.org/sp" />

</basic:Rule>

Technology

Shibboleth 2.0 IdP slides - Installfest (Edited)