Shibboleth 2.0 IdP slides - Installfest (Edited)

Slide 1: Installation to SSO Chad La Joie chad.lajoie@switch.ch

Slide 3: Terms: Entity ID A unique identifier for a identity provider (IdP) or service provider (SP) In shibboleth 2 the recommended format is a URL idp: https://HOSTNAME/idp/shibboleth sp: http://HOSTNAME/shibboleth © 2008 SWITCH 3

Slide 4: 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. © 2008 SWITCH 4

Slide 5: 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. © 2008 SWITCH 5

Slide 6: 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. © 2008 SWITCH 6

Slide 7: 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. © 2008 SWITCH 7

Slide 9: Installation • Unpack the Shibboleth distribution unzip -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 © 2008 SWITCH 9

Slide 10: 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 © 2008 SWITCH 10

Slide 11: 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 © 2008 SWITCH 11

Slide 12: 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. © 2008 SWITCH 12

Slide 13: 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. © 2008 SWITCH 13

Slide 15: 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 © 2008 SWITCH 15

Slide 16: 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. © 2008 SWITCH 16

Slide 17: 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. © 2008 SWITCH 17

Slide 18: 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. © 2008 SWITCH 18

Slide 19: 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> © 2008 SWITCH 19

Slide 20: 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 © 2008 SWITCH 20

Slide 21: 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! © 2008 SWITCH 21

Slide 22: 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. © 2008 SWITCH 22

Slide 23: 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> © 2008 SWITCH 23

Slide 24: Metadata: UK Configuration • Download UK Federation Certificate curl 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> © 2008 SWITCH 24

Slide 25: 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). © 2008 SWITCH 25

Slide 26: 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. © 2008 SWITCH 26

Slide 27: 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. © 2008 SWITCH 27

Slide 28: 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 © 2008 SWITCH 28

Slide 29: 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 © 2008 SWITCH 29

Slide 30: Login Handler: UsernamePassword 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"; © 2008 SWITCH 30

Slide 31: Login Handler: UsernamePassword 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> © 2008 SWITCH 31

Slide 32: 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. © 2008 SWITCH 32

Slide 33: 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 © 2008 SWITCH 33

Slide 34: 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. © 2008 SWITCH 34

Slide 35: Attribute Resolution

Slide 36: 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. © 2008 SWITCH 36

Slide 38: 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. © 2008 SWITCH 38

Slide 39: 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. © 2008 SWITCH 39

Slide 40: 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. © 2008 SWITCH 40

Slide 41: 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" /> © 2008 SWITCH 41

Slide 42: 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. © 2008 SWITCH 42

Slide 43: 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. • Each type has its own set of configuration options. © 2008 SWITCH 43

Slide 44: 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. © 2008 SWITCH 44

Slide 45: 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. © 2008 SWITCH 45

Slide 46: 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. © 2008 SWITCH 46

Slide 48: 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. © 2008 SWITCH 48

Slide 49: 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). © 2008 SWITCH 49

Slide 50: 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> © 2008 SWITCH 50

Slide 51: 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> © 2008 SWITCH 51

Slide 52: Example – Simple Directory Lookup of epe <resolver:AttributeDefinition id="eduPersonEntitlement" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="shibentitlement"> <resolver:Dependency ref="myLDAP" />  </resolver:AttributeDefinition> © 2008 SWITCH 52

Slide 53: 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" /> © 2008 SWITCH 53

Slide 54: Some examples – Static entitlements <resolver:AttributeDefinition id="eduPersonEntitlement" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="shibentitlement"> <resolver:Dependency ref="staticEntitlements" />  </resolver:AttributeDefinition> © 2008 SWITCH 54

Slide 55: 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> </resolver:AttributeDefinition> © 2008 SWITCH 55

Slide 56: Example – Continued <![CDATA[ importPackage(Packages.edu.internet2.middleware.shibb oleth.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"); } } ]]> © 2008 SWITCH 56

Slide 57: 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:AttributeDefinition> <resolver:DataConnector xsi:type="ComputedId" xmlns="urn:mace:shibboleth:2.0:resolver:dc" id="computedIDConnector" generatedAttributeID="computedID" sourceAttributeID="uid" salt="your random string here"> <resolver:Dependency ref="myLDAP" /> </resolver:DataConnector> © 2008 SWITCH 57

Slide 58: 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" /> </resolver:AttributeDefinition> © 2008 SWITCH 58

Slide 59: 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" />  </resolver:DataConnector> © 2008 SWITCH 59

Slide 60: 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 ) © 2008 SWITCH 60

Slide 61: Example – adding scope <resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="example.org" sourceAttributeID="uid"> <resolver:Dependency ref="myLDAP" /> </resolver:AttributeDefinition> © 2008 SWITCH 61

Slide 62: Example - prescoped <resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Precoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="example.org" sourceAttributeID="shibeppn"> <resolver:Dependency ref="myLDAP" /> </resolver:AttributeDefinition> © 2008 SWITCH 62

Slide 63: Attribute Filtering

Slide 65: 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. © 2008 SWITCH 65

Slide 66: 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. © 2008 SWITCH 66

Slide 67: Policy Requirement Rule Configuration •<PolicyRequirementRule> defines a requirement rule. • Every rule has a xsi:type attribute that defines its type. • Each type has its own set of configuration options. • Every attribute filter policy must have one, and only one, policy requirement rule © 2008 SWITCH 67

Slide 68: 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. © 2008 SWITCH 68

Slide 69: 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 © 2008 SWITCH 69

Slide 71: 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. • Each type has its own set of configuration options. © 2008 SWITCH 71

Slide 72: 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. © 2008 SWITCH 72

Slide 73: 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"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy> © 2008 SWITCH 73

Slide 74: 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"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy> © 2008 SWITCH 74

Slide 75: 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> </AttributeFilterPolicy> © 2008 SWITCH 75

Slide 76: 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" /> </PolicyRequirementRule> <AttributeRule attributeID="eduPer...cipalName"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy> © 2008 SWITCH 76

Slide 77: 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> </PolicyRequirementRule> <AttributeRule attributeID="eduPersonPrincipalName"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy> © 2008 SWITCH 77

Slide 78: 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> </PolicyRequirementRule> © 2008 SWITCH 78

Slideshare.net (beta)