Shibboleth 2.0 IdP slides - Installfest (Edited)

Installation to SSO Chad La Joie [email_address]

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 URL idp: 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 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

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

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

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

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>

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.

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. Each type has its own set of configuration options.

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 "> <FilterTemplate> <![CDATA[ ( uid =${requestContext.principalName})‏ ]]> </FilterTemplate> <ReturnAttributes> x y z </ReturnAttributes>

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>

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>

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:AttributeDefinition id=" eduPersonEntitlement " xsi:type=" Simple " xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID=" shibentitlement "> <resolver:Dependency ref=" staticEntitlements " />  </resolver:AttributeDefinition>

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>

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

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>

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>

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 "> <resolver:Dependency ref="myLDAP" /> </resolver:AttributeDefinition>

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>

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. Each type has its own set of configuration options. 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. Each type has its own set of configuration options.

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

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>

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>

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>

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>

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=" ..AttributeRequesterStrin g" value=" https://myfinanceapp.example.org/sp " /> </basic:Rule> </PolicyRequirementRule>

Shibboleth 2.0 IdP slides - Installfest (Edited)

More Related Content

What's hot (17)

Viewers also liked (20)

Similar to Shibboleth 2.0 IdP slides - Installfest (Edited) (20)

More from JISC.AM (20)

Recently uploaded (20)

Shibboleth 2.0 IdP slides - Installfest (Edited)