Shibboleth 2.0 IdP slides - Installfest (Edited)

Installation to SSO

Chad La Joiechad.lajoie@switch.ch

Tour of What We Learned

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

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

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.

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.

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.

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.

Lets take a Closer Look

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

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

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

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

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.

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.

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.

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

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.

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.

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.

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>

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

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!

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.

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>

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>

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).

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.

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.

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

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

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";

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>

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.

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

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

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.

Terms: SAML Attribute

An attribute that is represented in SAML notation.

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

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.

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.

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.

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" />

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.

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.

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.

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.

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.

Terms: Principal Connector

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

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.

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).

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">

<![CDATA[

(uid=${requestContext.principalName})

</FilterTemplate>

Some examples – Static Connector

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

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

</Attribute>

</resolver:DataConnector>

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>

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" />

Some examples – Static entitlements

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

<resolver:Dependency ref="staticEntitlements" />

Example – Computing epe from group membership

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

<![CDATA[ // Script here

</Script>

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");

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">

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" />

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" />

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

Example – adding scope

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

Example - prescoped

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

Attribute Filtering

Terms: Attribute Filter Policy

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

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.

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.

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

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.

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

Terms: Permit Value Rule

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

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.

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.

Example – Release eptid & eppn to anyone

</AttributeRule>

</AttributeRule>

</AttributeFilterPolicy>

Example – Release eppn to specific SPs

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

</PolicyRequirementRule>

</AttributeRule>

Example – Release only allowed epa values

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

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

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

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

</PermitValueRule>

</AttributeRule>

Example – Release eppn to specific entitygroups

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

</AttributeRule>

Example – Release eppn to all Sps except...

<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>

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

<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>

Shibboleth 2.0 IdP slides - Installfest (Edited)

Technology

Shibboleth and CU

Shibboleth at Newcastle

· idp idp idp IELTS . idp idp idp IELTS . idp idp idp IELTS

Shibboleth Identity Provider (IdP) - CLARIN · Shibboleth Identity Provider (IdP) Sebastian Rieger sebastian.rieger@gwdg.de. CLARIN AAI Shibboleth Workshop 2 Integrating your local

2 - Shibboleth IdP Installation

IdP Login Form Customization - SWITCH...Shibboleth IdPv3 Login Form Customization - Shibboleth Training 2015 Author SWITCHaai Subject Templates and Customization Created Date 20151015072549Z

Holly Eggleston, UCSD Shibboleth and Library Resources InCommon Library/Shibboleth Project

Shibboleth SSO & Drupal

Shibboleth at Cardiff University Lindsay Roberts Project Manager – Shibboleth Implementation Phase 2

David Kennedy, UMD Shibboleth and Library Resources Internet2 Library/Shibboleth Project

Lenya and Shibboleth

Configure the Captive Portal to Authenticate Users Against an IdP SAML 20 Using Shibboleth

Integrating a Shibboleth IdP with Microsoft Active Directory · Integrating a Shibboleth IdP with Microsoft Active Directory - 3 - purposes and are not intended to be definitive or

Shibboleth: EBSCOhost implementation

3 Sample Security Configuration for a Shibboleth IdP V2 BJ ... · DNS is configured so that the Shibboleth IdP Server resolves names from an external DNS server. The external DNS

7 October 2015 Shibboleth. Agenda Shibboleth Background and Status Why is Shibboleth Important (to Higher Ed)? Current Pilots Course Management

Belnet R&E Federation Workshop Shibboleth IdP Deployment Belnet – Mario Vandaele Brussels – 15 March 2012

Introduction to Shibboleth - SWITCH...• •SAML 2.0 • SSO ... Introduction to Shibboleth - Shibboleth Training 2015 Author: SWITCHaai Created Date: 20151015071708Z

Shibboleth Tutorial

Shibboleth SP Logout Support - Shibboleth Training …...Current state of SLO in Shibboleth Shibboleth Service Provider 2.5.x • Supports local and global logout Shibboleth Identity