Shibboleth IdP Pre-requisite Training

1. Shibboleth IdP Pre-requisite Training www.vlemiddleware.com Kidderminster College vlem@kidderminster.ac.uk

2. Course overview • Understanding Federated Access Management and Shibboleth • Overview of prerequisites and installation • Hands on: Configuring Shibboleth Pre-requisites • NTP • Firewall • Certificates • Authentication • Attributes & Directories

3. Understanding Federated Access Management and Shibboleth

4. Federated Access Management Based on a set of defined values and expectations: • Trust - a protected resource must be able to trust the information provided by the AIMS • Security - only authorised parties should be able to read the information and only approved administrators should be able to amend the information. • Privacy - an access and identity management system holds a variety of account information about individuals such as user name, email address and password and this data may not be divulged to third parties

5. FAM Benefits • Users; • Single sign-on using institutional ID and password to resources • Assurance that their personal data will not be disclosed to third parties. • Librarians; • Freed from the burden of user name and password administration, • New tools for managing licenses and service subscriptions. • IT managers; • More control of the access management process although it will require additional institutional effort in the short term. • Institutions; • Single service to meet the requirements of e-learning, e-research and library-managed resources.  • Simplification of the authentication process has also proven to lead to increased use of subscribed services. • Service providers • No longer need to maintain records of very user

6. Typical Process

7. Anyone within an authenticating organisation. Student Staff member User

8. Two phases Responsible for user authentication – makes use of existing mechanisms Obtaining the authorisation to access specific to access materials Identity Provider

9. Role; Establish a security process for authenticating the user Receive and accept attributes Handle resource management Service Provider

10. SP – Assertion Consumer Service • Role to create a new security context for the user. • It does this by contacting the Identity Provider’s Authentication Authority. • Once the user has been authenticated via the Identity Provider’s Authentication Authority, a handle will be sent back to the Assertion Consumer Service. • When the Assertion Consumer Service has the handle, it will send it to the Attribute Resolver.

11. WAYF • The WAYF (‘Where Are You From’) provides a mechanism for allowing users to be forwarded to the correct home organisation. • This is normally presented in the form of a web page with a drop-down list. • Once the correct organisation is selected, the user will be forwarded to their Identity Provider server ready for authentication. • The service makes use of a national WAYF service that works as an intermediary between the Identify Provider and the Service Provider.

12. IdP – Authentication Authority • Allows Service Providers to query the users’ authentication information. • Allows a user to authenticate against their local authentication store and issue authentication assertions about the user to relying parties • Gives the end user a handle to be used later to request attributes from the Attribute Authority. • This includes determining whether the user has already logged on by consulting the Single Sign On (SSO). If they have not then they will be authenticated. • The Handle will be produced and passed to the Service Providers Assertion Consumer Service.

13. IdP – Single Sign-on Service • A method of access control that enables a user to authenticate once and gain access to computers and systems they have permission to access. • Removes the need to authenticate for individual services. • Should be seen as a framework in which to implement solutions and not a complete solution. • For it to work in practice all the services used by users need to be covered by the framework.

14. SP – Attribute Requester/Resolver • Uses the handle given to it by the Assertion Consumer Service along with the address of the Attribute Authority to request attributes about the user. • These attributes have been passed to the Attribute Resolver. • Attribute Acceptance Policies will be used to provide validation and analysis before passing the attributes to the Resource Manager.

15. IdP – Attribute Authority • Responds to requests from a Service Provider’s Attribute Resolver • Contains Attributes of users affiliated to that organisation. • Requires privileged access to the campus directory or directories. • Operates using a set of rules, known as Attribute Release Policies • Define what user information can be released to which Service Providers and under what circumstances.

16. Directories • Directories are critical in the management of information held by organisations on people, processes, resources and groups. • Storage of this information in a common area allows diverse applications from varied locations access a consistent and comprehensive source for current values. • Directories need ways to describe: • the sequence of fields in the database (a schema) • the names of the fields (a namespace) • the contents of the fields (attribute values). • Directories also need indices into the database (identifiers).

17. SP – Resource & Resource Manager • Resource access can be managed by using logic within applications or web server authorisation rules. • These decisions are usually based on the attributes that have been retrieved for the user.

18. Federation • A group that sign up to an agreed set of policies for exchanging information about users and resources to enable access and use of on-line resources and services. • Establishes authorisation through the secure exchange of information (known as attributes) between the two parties. • Devolves the responsibility for authentication to a user’s home organisation

19. How it all fits together

20. Attributes Release Policies • Service Providers may require different attributes in order to provide service to users. • Resources licensed to all members of the organisation the Service Provider may only need to know only the eduPersonScopedAffiliation and possibly an eduPersonTargetedID to allow the user to store preferences. • More fine grained authentication or logging requirements may require more attributes. • Identity Provider should maintain an Attribute Release Policy (ARP) which lists attributes and values that can be released and block release of all others. • Attributes should only be released if this is permitted by a rule in the ARP. • Service Providers are recommended to publish which attributes they require so Identity Providers can quickly identify the correct ARP configuration. • However Identity Providers should be cautious about releasing attributes and challenge Service Provider requirements that don’t seem necessary.

21. Metadata • The federation publish metadata describing participating entities. • Provides information required for entities to know how to communicate with each other • Establishes a trust fabric permitting entities to verify each other’s identities. • The presence of federation metadata should not be taken as a guarantee of behaviour. • It is the responsibility of Identity Provider to establish appropriate policies for attribute release based on their knowledge of individual Service Providers. • It is the responsibility of the Service Provider to decide how much trust to place in the attributes presented by the Identity Provider based on their knowledge of the Identity Provider. • Federation metadata is available in two formats: • standard metadata using SAML 2.0 with extensions • Shibboleth 1.2 metadata.

22. Metadata Refresh • The metadata published by the federation is regularly updated to: • include new entities • describe changes to existing entities • remove old entities, because they have left the federation or the entity has been reported as compromised. • Sites working with old copies of the federation metadata may; • be unable to communicate with new federation members or members whose details have changed. • vulnerable to attacks based on compromised entities. • Members are strongly recommended to refresh the metadata used by their entities at least once a day.

23. Overview of prerequisites and installation

24. Software • Apache • Tomcat • mod_proxy_ajp • Shibboleth 1.3

25. Digital Certificates

26. Authentication Services • Basic Authentication • LDAP Authentication • Java-based authentication • Web ISO systems • Kerberos or Windows Integrated Authentication

27. Attribute & Directories • Setup the necessary attributes in one of the following directories: • Active Directory • Novell e-directory • OpenLDAP • Databases

28. UK federation attributes

29. Schema update or mapping? • The LDAP schema can be updated with the eduPerson class • Alternatively they can be mapped to existing attributes:

30. Getting Shibboleth to do the work • It is also possible to let Shibboleth use logic to set attributes, e.g.

31. Hands on: Configuring Shibboleth NTP Firewall Certificates Authentication Attributes & Directories

32. Exercise: Set NTP • Use NTP to ensure time is synched • Windows • If on domain then time is already synced to DC • net time /setsntp:ntp2.ja.net (or point to your DC) • Linux • Yum install ntp • vi /etc/ntp.conf

33. Firewall • Need port 443 open • In some cases 8443 as well • Open networks perimeter firewall • Open system firewall: • Linux: iptables/lokkit • Windows: Built-in or third party

34. Exercise: Create Certificates • OpenSSL is native on Linux • Download from http://www.slproweb.com for Windows • openssl genrsa -out mytest.test.local.key 2048 • openssl req -new -key mytest.test.local.key -out mytest.test.local.csr • openssl x509 -req -days 365 -in mytest.test.local.csr -signkey mytest.test.local.key -out mytest.test.local.crt

35. Exercise: Update certificate references • Update Apache front facing certificate /etc/httpd/conf.d/ssl.conf • SSLCertificateFile /etc/pki/tls/idpx.test.local.crt • SSLCertificateKeyFile /etc/pki/tls/idpx.test.local.key • Update Shibboleth signing certificates • Set in “Credentials” section of $SHIB_HOME/etc/idp.xml

36. Exercise: Setup Apache authentication • Edit /etc/httpd/conf/shibboleth.conf • Uncomment “LDAP Auth” (non ssl) and update these details to point to your ldap server

37. Exercise: Modify user attributes • Use ADModify.net to modify users “url” attribute to use for eduPersonEntitlement • Download from http://epet.kidderminster.ac.uk/vlemiddleware/shibboleth/ADModify_2.1.zip

38. Exercise: Modify Shibboleth to use AD • Edit $SHIB_HOME/etc/resolver.ldap.xml • Uncomment LDAP (non ssl) and update these values to point to your ldap server

39. Exercise: Attribute Release Policies • Edit $SHIB_HOME/etc/arps/arp.site.xml

40. Exercise: Test the resolver • Resolvertest allows you to see what attributes will be released

41. Exercise: Discuss your next move • Discuss in a small group what you plan to do when you get back to your institution • Feedback this information to the class

42. Thank You For further information: www.vlemiddleware.com Kidderminster College vlem@kidderminster.ac.uk