Shibboleth Identity Provider (IdP) Sebastian Rieger

Transcription

1 Shibboleth Identity Provider (IdP) Sebastian Rieger Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen, Germany CLARIN AAI Hands On Workshop, , Oxford eresearch Center

2 Integrating your local identities in federations setting up your own IdP allows your users to access services (SPs) in federations and to cooperate with other institutions the IdP reflects the home organization of your users in the federation, it ensures proper authentication (username, password) and authorization, credentials and sensitive data are stored in the institute (not at the SPs) on successfull authentication the IdP issues a digitally signed assertion (token, ticket), that authenticates the user a reference to the assertion is stored as a Cookie (HTTP session) in the user s web browser by redirecting the client to the IdP (using HTTP redirect or POST), while accessing another SP, assertion (Cookie) is used to authenticate the user without further logins Single Sign-On is achieved as long as assertion is valid CLARIN AAI Shibboleth Workshop 2

3 Architecture of a Shib IdP Shibboleth IdP is a Java Web Application, Download JDK 1.6 preferred, installation script (install.sh) Java Security Provider and Tomcat configuration platform independent Linux, Windows Documentation: Basic Components: Web Server (Apache e.g. 2.2) Application Server (Tomcat e.g. 5.5) IdP is deployed in idp.war (current version 2.1.2) AuthN: SSOHandler used for authentication: HTTP, form-based or existing session / assertion (Cookie), certificates in development, using AuthN DB or LDAP, custom implementations possible (JAAS) AuthZ:Attribute Authority allowing AuthZ using attributes, using Attribute DB, LDAP,... Source: CLARIN AAI Shibboleth Workshop 3

4 Configuring Apache and Tomcat setting up a virtual host in Apache, passing access to local Tomcat using certificate and keyfile of the IdP /etc/apache2/conf.d/idp.conf: <VirtualHost :443> ServerName my-new-idp.example.com:443 SSLEngine on SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key <Proxy ajp://localhost:8009/idp/*> Allow from all </Proxy> ProxyPass /idp/ ajp://localhost:8009/idp/ </VirtualHost> Listen 8443 <VirtualHost :8443> ServerName my-new-idp.example.com:8443 SSLEngine on SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key <Location /idp>allow from all SSLOptions +StdEnvVars +ExportCertData SSLVerifyClient optional_no_ca SSLVerifyDepth 10 </Location> <Proxy ajp://localhost:8009/idp/*> Allow from all </Proxy> ProxyPass /idp/ ajp://localhost:8009/idp/ </VirtualHost> CLARIN AAI Shibboleth Workshop 4

5 Configuring Apache and Tomcat setting up the Tomcat to deploy the idp.war remember to reserve enough Java heap (using Xmx, -Xms) (e.g. /etc/default/tomcat5.5) server.xml <Server port="8005" shutdown="shutdown"> <!-- Define the Tomcat Stand-Alone Service --> <Service name="catalina"> <!-- Define an AJP 1.3 Connector on port > <Connector port="8009" address=" " request.tomcatauthentication="false" enablelookups="false" redirectport="8443" protocol="ajp/1.3" /> </Service> </Server> /etc/tomcat5.5/catalina/localhost/idp.xml <Context docbase="/opt/shibboleth-idp/war/idp.war" privileged="true" antiresourcelocking="false" antijarlocking="false" unpackwar="false" /> CLARIN AAI Shibboleth Workshop 5

6 a Shib 2.0 session initialization in detail Demo showing each HTTP request / response Source: CLARIN AAI Shibboleth Workshop 6

7 Connecting the IdP to Identity Management IdP can use a directory service (LDAP, AD, ), database, custom connectors Attribute Resolver and AuthN engine can use separate configurations two integration types for AuthN: external (web server, or tomcat realm) and internal (formbased auth using Shibboleth) Example: internal Shib-based AuthN via LDAP (login.config) ShibUserPassAuth { edu.vt.middleware.ldap.jaas.ldaploginmodule sufficient host= ldap.gwdg.de" port="636" base= dc=gwdg,dc=de" ssl="true" userfield="uid" subtreesearch="true"; }; // alternate Kerberos config ShibUserPassAuth { com.sun.security.auth.module.krb5loginmodule sufficient; }; failover config possible by inserting more sufficient configurations (fall-through) CLARIN AAI Shibboleth Workshop 7

8 Connecting the IdP to Identity Management Configuring AuthN handler in handler.xml <!-- Shib internal Username/password login handler --> <LoginHandler xsi:type="usernamepassword jaasconfigurationlocation= file:///opt/shibidp/conf/login.config > <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </AuthenticationMethod> </LoginHandler> <! alternate handler for external AuthN e.g. Tomcat using HTTP REMOTE_USER header --> <LoginHandler xsi:type="remoteuser"> <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified </AuthenticationMethod> </LoginHandler> failover for IdP possible by using Load Balancing (Layer 3), Cost: no SSO after failover Session-aware Load Balancing (Layer 7) supported since IdP 2.1 using terracotta ( network attached memory to provide persistent clustered heap, see tc-config.xml) other services (besides SAML-based profiles) defined in the handler.xml: Status (display the status of the IdP) e.g. Metdata (retrieve metadata from IdP) e.g. Login Handler PreviousSession to allow SSO CLARIN AAI Shibboleth Workshop 8

9 Joining federations with your IdP Federations / trusts can be assigned in relying-party.xml multiple federations can be assigned definition of the IdP entity and certificate & private key used for digital signatures <DefaultRelyingParty provider=" defaultsigningcredentialref="idpcredential"> Publish service URLs (profiles) of the IdP - SSO (AuthN) - AttributeQuery (handling requests for attributes to do AuthZ) - ArtifactResolution (requesting an assertion using an Artifact e.g. POST profile) - all handlers are offered for SAML 2.0 and SAML 1.1 to ensure interoperability with Shibboleth 1.1 (by the way end of life 6/30/2010!) automatic download and caching of the metadata of the assigned federations CLARIN AAI Shibboleth Workshop 9

10 Joining federations with your IdP cont. Configuring integration of metadata in relying-party.xml (e.g. trusted SPs) // get metadata.xml from URL, cache it localy, check signature // and ignore parties not being SPs <MetadataProvider id="urlmd" xsi:type="filebackedhttpmetadataprovider" xmlns="urn:mace:shibboleth:2.0:metadata" metadataurl=" backingfile="/opt/shibboleth-idp/metadata/dfn-aai-test-metadata-backingfile.xml"> <MetadataFilter xsi:type="chainingfilter" xmlns="urn:mace:shibboleth:2.0:metadata"> <MetadataFilter xsi:type="signaturevalidation" xmlns="urn:mace:shibboleth:2.0:metadata" trustengineref="shibboleth.metadatatrustengine" requiresignedmetadata="true" /> <MetadataFilter xsi:type="entityrolewhitelist" xmlns="urn:mace:shibboleth:2.0:metadata"> <RetainedRole>samlmd:SPSSODescriptor</RetainedRole> </MetadataFilter> </MetadataFilter> </MetadataProvider> // security trust engine to check metadata signature as configured in the filter <security:trustengine id="shibboleth.metadatatrustengine" xsi:type="security:staticexplicitkeysignature"> <security:credential id="myfederation1credentials" xsi:type="security:x509filesystem"> <security:certificate>/opt/shibboleth-idp/credentials/dfnaai.pem</security:certificate> </security:credential> </security:trustengine> CLARIN AAI Shibboleth Workshop 10

11 Multiple Federations joining multiple federations can be accomplished in several ways registering the IdP in multiple federations and configure them in relying-party.xml usage of bridging protocols (e.g. edugain) building a confederation for MPG-AAI we developed an IdP Proxy that is placed in multiple federations and allows different authentication mechanisms Implementation as custom JAAS module (external Tomcat AuthN), custom data connector users select the single IdP Proxy in the Discovery Service and use their local identities (and IdPs), to log in using their mail address, IdP is derived from the domain / realm attributes going to external federations can be filtered only one IdP for the entire MPG in the external DS Institut A IdP Institut C Institut A IdP MPG-AAI Option b) LDAP Option a) Shibboleth Max-Planck-Gesellschaft IdP Proxy DFN-AAI CLARIN AAI LDAP Shibboleth Workshop bei der GWDG11 Ovid SP Option c) GWDG Elsevier SP EBSCO SP IDM Out-Sourcing

12 X.509 certificates & Java The Basics the installation script of the IdP creates a keypair, this can be used for further requests root@idp:/opt/shibboleth-idp/credentials# openssl req -new -key idp.key -out idp.csr resulting CSR can be sent to your NREN CA, issued certificate is copied to idp.crt path to files is configured in relying-party.xml and the virtual host, containing your IdP e.g.: Listen 8443 <VirtualHost :8443> ServerName idp.example.com:8443 SSLEngine on SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key <Location /idp> Allow from all </Location> <Proxy ajp://localhost:8009/idp/*> Allow from all </Proxy> ProxyPass /idp/ ajp://localhost:8009/idp/ </VirtualHost> Java keystore IdP.jks can be deleted, or you can import cert and key using keytool CLARIN AAI Shibboleth Workshop 12

13 Interaction with SPs IdP delivers assertions and attributes to SPs, Shibboleth allows a finegrained filtering of the outgoing attributes attributes are based on standards: inetorgperson, eduperson, dfneduperson e.g. edupersonaffiliation, edupersontargetedid, edupersonentitlement Attribute management at the IdP is split into two instances: Resolver and Filter Resolver gets attributes from directory services, databases etc. (attribute-resolver.xml) attributes are converted and mapped e.g. to URN (e.g. urn:geant:dfn.de:mpg: ) combining multiple attribute (sources), and complex formatting are possible Filter defines Attribute Release Policy (ARP) for consuming SPs / federations (attribute-filter.xml) filtering can be configured individually for every SP / federation the IdP knows complex filter scenarios are possible (filtering specific values, defining filter rules) CLARIN AAI Shibboleth Workshop 13

14 Attribute Resolver first data connectors are defined as sources for the attributes in attribute-resolver.xml <!-- Example Static Connector --> <resolver:dataconnector id="staticattributes" xsi:type="static" xmlns="urn:mace:shibboleth:2.0:resolver:dc"> <Attribute id="edupersonaffiliation"><value>member</value></attribute> <Attribute id="edupersonentitlement"> <Value>urn:mace:dir:entitlement:common-lib-terms</Value> </Attribute> </resolver:dataconnector> <!-- Example LDAP Connector --> <resolver:dataconnector id="myldap" xsi:type="ldapdirectory xmlns="urn:mace:shibboleth:2.0:resolver:dc" ldapurl="ldaps://ldap.gwdg.de" basedn="o=goestern" principal="cn=roadmin,o=gwdg principalcredential="secret"> <FilterTemplate> <![CDATA[ ]]> (uid=$requestcontext.principalname) </FilterTemplate> </resolver:dataconnector> failover LDAP servers possible by separating different URLs with a blank CLARIN AAI Shibboleth Workshop 14

15 Attribute Resolver cont. <!-- Example Relational Database Connector --> <resolver:dataconnector id="mydb" xsi:type="relationaldatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"> <ApplicationManagedConnection jdbcdriver="oracle.jdbc.driver.oracledriver" jdbcusername="myid" jdbcpassword="mypassword" /> <QueryTemplate> <![CDATA[ ]]> </QueryTemplate> SELECT * FROM student WHERE gzbtpid = $requestcontext.principalname <Column columnname="gzbtpid" attributeid="uid" /> <Column columnname="fqlft" attributeid="gpa" type="float" /> </resolver:dataconnector> <!-- StoredID (persistentid) Connector e.g. to generate edupersontargetedid --> <resolver:dataconnector id="mystoredid" xsi:type="storedid" xmlns="urn:mace:shibboleth:2.0:resolver:dc" generatedattributeid="persistentid" sourceattributeid="uniqueid" salt="some/secret"> <resolver:dependency ref="uniqueid" /> <ApplicationManagedConnection jdbcdriver="com.mysql.jdbc.driver" jdbcurl="jdbc:mysql://localhost:3306/shibboleth?autoreconnect=true" jdbcusername= user" jdbcpassword= secret" /> </resolver:dataconnector> CLARIN AAI Shibboleth Workshop 15

16 Attribute Resolver cont. the attributes from the data connectors have to be mapped to SAML attributes <resolver:attributedefinition id="edupersonaffiliation" xsi:type="simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceattributeid="edupersonaffiliation"> <resolver:dependency ref="staticattributes" /> <resolver:dependency ref="myldap" /> <resolver:attributeencoder xsi:type="saml1string xmlns="urn:mace:shibboleth:2.0:attribute:encoder name="urn:mace:dir:attribute-def:edupersonaffiliation" /> <resolver:attributeencoder xsi:type="saml2string" xmlns="urn:mace:shibboleth:2.0:attribute:encoder name="urn:oid: " friendlyname="edupersonaffiliation" /> </resolver:attributedefinition> <resolver:attributedefinition id="edupersonentitlementovid" xsi:type="template" xmlns="urn:mace:shibboleth:2.0:resolver:ad"> <resolver:dependency ref="idpproxydataconnector" /> <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: " friendlyname="edupersonentitlement" /> <Template><![CDATA[urn:wkhmr:ovid.institutional.login:${uid}]]></Template> <SourceAttribute>uid</SourceAttribute> </resolver:attributedefinition> other complex attribute types are possible, several depencies can be defined (e.g. for failover) CLARIN AAI Shibboleth Workshop 16

17 Attribute Filter filters defined in attribute-filter.xml - deny attributes and values for federations / SPs <AttributeFilterPolicy> <PolicyRequirementRule xsi:type="basic:or"> <basic:rule xsi:type="saml:attributerequesterinentitygroup" groupid="urn:mace:incommon" /> <basic:rule xsi:type="saml:attributerequesterinentitygroup groupid=" /> </PolicyRequirementRule> <AttributeRule attributeid="edupersonscopedaffiliation"> <PermitValueRule xsi:type="basic:any" /> </AttributeRule> <AttributeRule attributeid="edupersonaffiliation"> <PermitValueRule xsi:type="basic:or"> <basic:rule xsi:type="basic:attributevaluestring" value="faculty"/> <basic:rule xsi:type="basic:attributevaluestring" value="student"/> </PermitValueRule></AttributeRule> </AttributeFilterPolicy> <AttributeFilterPolicy> <PolicyRequirementRule xsi:type="basic:attributerequesterstring value=" /> <AttributeRule attributeid="edupersonentitlementovid"> <PermitValueRule xsi:type="basic:any" /></AttributeRule> </AttributeFilterPolicy> CLARIN AAI Shibboleth Workshop 17

18 Ensuring privacy You can use aacli.sh to check which attributes are delivered by the IdP Filtering attributes and their values is not enough to ensure privacy, personal data belonging to the user is maybe not be allowed to leak from the institute but SPs need at least an attribute to differentiate between users solution is to deliver anonymized id for the user edupersontargetedid persistent id being a hash over username + idp secret + sp name, irreversible, users get different ids for different SPs (service publishers can not track the users) for other attributes containing personal data, users can get the possibility to explicitly approve attributes being sent: SWITCHaai uapprove Users will need to accept terms of use and confirm the sending of attributes to every SP they use, reconfirmation is needed if policy, or the set of delivered attributes changes Demo: using Ovid service in the MPG-AAI CLARIN AAI Shibboleth Workshop 18

19 Customizing idp login etc. login page can be customized in the IdP sources see src/main/webapp/login.jsp also login-error.jsp (e.g. for failed authentication) can be customized error.jsp, error404.jsp (failures during usage of the profiles and handlers) changes can be deployed by using install.sh again (builds the WAR and deploys it) CLARIN AAI Shibboleth Workshop 19

20 Logging Shibboleth IdP logging is configured in logging.xml accesses are logged to /opt/shibboleth-idp-2.0.0/logs/idp-access.log and /opt/shibboleth-idp-2.0.0/logs/idp-audit.log debugging information can be taken from /opt/shibboleth-idp-2.0.0/logs/idp-process.log <!-- Logs IdP, but not OpenSAML, messages --> <logger name="edu.internet2.middleware.shibboleth"> <level value="debug" /> </logger> <!-- Logs OpenSAML, but not IdP, messages --> <logger name="org.opensaml"> <level value="debug" /> </logger> <!-- Logs LDAP related messages --> <logger name="edu.vt.middleware.ldap"> <level value="debug"/> </logger> consider privacy of logged information! Demo CLARIN AAI Shibboleth Workshop 20

21 Outlook: IdP in Shibboleth 2.x Shib IdP 2.2 Single Logout functionality (SAML-conform SLO, partly already implemented) ECP profile of SAML 2.0 (Enhanced Client or Proxy / Delegation e.g. SOAP, ) X.509 and other authentication mechanisms (Kerberos, SPNEGO, ADFS etc. currently available using plug-ins) native support for privacy enhancements like uapprove integration of user-centric Identity Management (CardSpace, OpenID)? maybe support for desktop applications? e.g. using ECP? Thanks for your attention! any questions? CLARIN AAI Shibboleth Workshop 21