AttributeName="urn:mace:shibbolethtesting.org:attribute-def:swissEduPersonUniqueID"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> mpowers@hsr.ch AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> 1
14. The user recieves a redirect to the initially requested resource.
24
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Shibboleth interactions
HTTP/1.x 302 Found Date: Mon, 04 Apr 2005 10:30:28 GMT Set-Cookie: _shibsession_default=b03871b42d188af4062e6fbd777550ad; path=/ Location: https://carol.shibbolethtesting.org/secure/
Figure 4.9. The user is forewarded to the initially requested page.
15. The user requests the resource.
GET /secure/ HTTP/1.1 Host: carol.shibbolethtesting.org Cookie: _shibsession_default=b03871b42d188af4062e6fbd777550ad
25
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Shibboleth interactions
Figure 4.10. The user attributes are displayed on the page.
26
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Chapter 5. LDAP backend
The chapter about the LDAP backend gives an introduction in LDAP and where it is used in the Shibboleth demonstrator. Further the configuration, the initialisation of the LDAP and the possible LDAP attributes for the Shibboleth demonstrator are described. 1. Introduction 1.1. What is LDAP?
The Lightweight Directory Access Protocol (LDAP) is a networking protocol for querying and modifying directory services running over TCP/IP. The LDAP directory is a tree of entries with a unique name (distinuished name). As an example an LDAP entry (Node) contains the following data:
dn: cn=Jeff Michaels,dc=foo,dc=bar cn: Jeff Michaels givenName: Jeff sn: Michaels telephoneNumber: 01 555 67 89 mail: j.michaels@foo.bar manager: cn=Sepp Meier,dc=foo,dc=bar objectClass: inetOrgPersons objectClass: organizationalPerson objectClass: person objectClass: top
The objectClasses depend on schemas (schemas define objectClasses) which are used in the LDAP. ObjectClasses are like classes in other Programming languages. In our Shibboleth project we use the schemas swissedu, eduperson and the objectClass "swissEduPerson". 1.2. Usage of LDAP
The Shibboleth identitiy providers moon and sun are based on a OpenLDAP 1 backend. Below a listing of tasks fulfilled by LDAP
• LDAP stores enduser attributes like name, adress, email, ... on moon.shibbolethtesting.org and sun.shibbolethtesting.org.
• LDAP is used as a backed for the CAS server 2 on moon.shibbolethtesting.org
• LDAP is used as a backend for Shibboleth client based authentication on sun.shibboletht- esting.org.
1 Official OpenLDAP website, www.openldap.org [http://www.openldap.org] 2 Official Esup Cas server website, esup-casgeneric.sourceforge.net [http://esup-casgeneric.sourceforge.net/]
27
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
2. LDAP installation
The installation of the OpenLDAP software is simple, because it is already in the Debian distri- bution included. The displayed messages can be ignored, because LDAP will be configured later.
# aptitude install openldap
The OpenLDAP is now installed. The configuration files can be found in /etc/ldap. 3. LDAP configuration
The LDAP configuration on a host will be done in two files.
• slapd.conf - configuration file for the LDAP demon slapd
• ldap.conf - configuration file for access to the ldap
The configuration files are listed below including some notes. Only the Shibboleth relevant parameters are described. 3.1. slapd.conf
The slapd.conf file is the central source of configuration for the OpenLDAP standalone server (slapd), the helper deamon (slurpd), and related tools of LDAP. The slapd.conf file is divided into two sections. The first section contains attributes which affect the overall behavior of the OpenLDAP server. The second section contains parameters which are related to a particular database backend, used by the slapd daemon.
# This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options.
####################################################################### # Global Directives:
# Features to permit #allow bind_v2
# Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/eduperson.schema include /etc/ldap/schema/swissedu.schema
28
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
To use the swissEdu attributes in a LDAP, the related schemas eduperson.schema and swissedu.schema are needed. This schemas are available at Switch 3 . It is important to first include the eduperson.schema because swissedu.schema is based on it.
# Schema check allows for forcing entries to # match schemas for their objectClasses's schemacheck on
# Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server argsfile /var/run/slapd.args
# Read slapd.conf(5) for possible values loglevel 8
# Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb
####################################################################### # Specific Backend Directives for bdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend bdb checkpoint 512 30
####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs #backend
####################################################################### # Specific Directives for database #1, of type bdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database bdb
# The base of your directory in database #1 suffix "dc=shibbolethtesting,dc=org" rootdn cn=root,dc=shibbolethtesting,dc=org rootpw {SSHA}5g5FWSgojECK1C8N2MN+zuEw+rAHAP1a
Each database section has a unique naming context that identifies the root entry in the LDAP tree. For the Shibboleth testing project we defined the context dc=shibbolethtesting,dc=org.
Each LDAP directory can have one root DN (rootdn), which is similar to the superuser account on unix systems.When authenticated, this dn (cn=root,dc=shibbolethtesting,dc=org) is author- ized to do whatever the user likes; access control restrictions do not apply.
The root RN also requires a corresponding root password (rootpw), which can be stored in clear text or encrypted form. The hash password parameters {CRYPT}, {MD5}, {SMD5}, {SSHA} and {SHA} are possible. A password is generated by the following command
3 http://http://www.switch.ch/aai/docs/
29
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
echo "rootpw " `slappasswd -h {SSHA} -s meinpasswort` \ >> /etc/ldap/slapd.conf
Below it is possible to see the end of the file slapd.conf .
# Where the database file are physically stored for database #1 directory "/var/lib/ldap"
# Indexing options for database #1 index objectClass eq
# Save the time that the entry gets modified, for database #1 lastmod on
# Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog
# The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attrs=userPassword by anonymous auth by self write by * none
# Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read
# The admin dn has full write access, everyone else # can read everything. access to * by * read
3.2. ldap.conf
To access LDAP with a client software like CAS server the ldap.conf has to be configured. Only the attributes HOST, BASE and URI with the corresponding values have to be added. For the Shibboleth testing project we only need access on loalhost.
# $OpenLDAP: pkg/ldap/libraries/libldap/ldap.conf,v 1.9 2000/09/04 19:57:01 kurt Exp $ # # LDAP Defaults #
30
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
# See ldap.conf(5) for details # This file should be world readable but not world writable.
#BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12 #TIMELIMIT 15 #DEREF never
HOST 127.0.0.1 BASE dc=shibbolethtesting,dc=org URI ldap://localhost:389
4. Populate the LDAP
Normally after the installation an LDAP will be manually initialized. But the Debian distribution initializes the LDAP itself, because an admin user will be generated and placed in the LDAP directory. An OpenLDAP system normally has a super user (root) with high permissions which raises security risks. For this purpose Debian generates this admin user during the installation. For our testing system this root user is used, because the configuration for the ldap is easier and the expenditure for write access is smaller (no ACL's must be set). 4.1. Attribute overview
The following Table shows the possible LDAP entries for a shibboleth environment based on the siwssedu schema. This attribute overview is based on the list from Switch 4 , which we adapted to our needs.
4 http://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf
31
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Attribute LDAP Person orgPerson inetOrgPer- eduPerson swissEdu Name son Unique ID siwssE- x duPersonU- niqueID Surname sn x Given name givenName x Date of birth swissE- x duPersonD- ateOfBirth Gender swissE- x duPerson- Gender Preferred preferred- x language Language E-mail mail x Home postal homePostalAd- x address dress Business postalAd- x postal ad- dress dress PrivatehomePhone x phone num- ber Business tele- x phone num- phoneNum- ber ber Mobilemobile x phone num- ber Home Or- swissE- x ganization duPerson- HomeOrgan- ization Home Or- swissE- x ganization duPerson- type HomeOrgan- izationType Affiliation eduPerson- x Affiliation StudyswissE- x branch 1 duPerson- Study- Branch1
32
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Attribute LDAP Person orgPerson inetOrgPer- eduPerson swissEdu Name son StudyswissE- x branch 2 duPerson- Study- Branch2 StudyswissE- x branch 3 duPerson- Study- Branch3 Study level swissE- x duPerson- StudyLevel Staff cat- swissE- x egory duPerson- StaffCat- egory Organiza- eduPerson- x tion path OrgDN Organiza- eduPerson- x tional unit OrgUnitDN path Member of eduPerson- x Entitlement System lo- uid gin name Password userPass- word
Table 5.1. Attribute Overview 4.2. Atribute definition
This section shows a detailed description of the attributes.The semantic, the LDAP syntax and an example of how to use an attribute is given. This attribute definition is based on the list from Switch 5 , which we adapted to our needs.
5 http://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf
33
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Description: A unique identifier for a person, mainly for inter- institutional user identification. Semantics: @
The format used is derived from e-mail ad- dresses. LDAP syntax: Directory String - Note: The length of the local part should be minimum 6 and maximum 12 characters. Example: swissEduPersonUniqueID: 845938727494@hsr.ch
Table 5.2. Unique ID (swissEduPersonUniqueID)
Description: Surname or family name (defined in person) Semantics: According to RFC 2256, this is the X.500 sur- name attribute, which contains the family name of a person. LDAP syntax: Directory String Example: sn: Meier-Müller
Table 5.3. Surname (sn)
Description: Given name of a person (defined in inetOrgPer- son) Semantics: RFC 2256 description: "The givenName attrib- ute is used to hold the part of a person's name which is not their surname nor middle name." LDAP syntax: Directory String Example: givenName: Hans-Peter
Table 5.4. Given Name (givenName)
Description: The date of birth of a person. Semantics: Based on RFC 3339 "Date and Time on the Internet: Timestamps". Using the 'full-date' format: full-date = date-fullyear date-month date-mday. LDAP syntax: Numeric String {8} Example: swissEduPersonDateOfBirth: 19871022
Table 5.5. Date of Birth (swissEduPersonDateOfBirth)
34
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Description: The state of being male or female Semantics: "either of the two groups that people, animals and plants are divided into according to their function of producing young" (Oxford Advanced Learner's Dictionary). Permissible values are: not know 0, male 1, female 2 and not specified 9. LDAP syntax: Integer {1} Example: swissEduPersonGender: 1
Table 5.6. Gender (swissEduPersonGender)
Description: Preferred language of a user (defined in inetOr- gPerson) Semantics: Preferred written or spoken language for a user. Form: - LDAP syntax: Directory String Example: preferredLanguage: de-ch
Table 5.7. Preferred Language (preferredLanguage)
Description: Preferred address for the "to:" field of e-mail to be sent to this person (defined in inetOrgPer- son) Semantics: Follow inetOrgPerson definition of RFC 1274: "The [mail] attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822. Note that this attribute should not be used for greybook or other non-Internet or- der mailboxes." LDAP syntax: IA5 string {256} Example: mail: peter.meier@hsr.ch
Table 5.8. E-mail Address (mail)
Description: Home address of the user (defined in inetOrg- Person) Semantics: From RFC 1274 description: "The home postal address attribute type specifies a home postal address for an object. This should be limited to up to 6 lines of 30 characters each." The limitation to up to 6 lines of 30 characters is not relevant within the Shibboleth testing environ- ment. LDAP syntax: Postal Address Example: homePostalAddress: Seestrasse 45 CH-8640 Rapperswil
Table 5.9. Home Postal Address (homePostalAddress)
35
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Description: Campus or office address (defined in orgPer- son) Semantics: Campus or office address, derived from orgPer- son X.520(2000): "The Postal Address attribute type specifies the address information required for the physical postal delivery to an object." The limitation to up to 6 lines of 30 characters as defined in the X.520 standard is not relev- ant. LDAP syntax: Postal Address Example: postalAddress: HSR Oberseestrasse 10 CH-8640 Rapperswil
Table 5.10. Business Postal Address (postalAddress)
Description: Private phone number (defined in inetOrgPer- son) Semantics: Private phone number of the user. Attribute values should follow the agreed format for in- ternational telephone numbers: i.e., "+44 71 123 4567." LDAP syntax: Telephone Number Example: homePhone: +41 1 234 5678
Table 5.11. Private Phone Number (homePhone)
Description: Office/campus phone number (defined in per- son) Semantics: Office/campus phone number of the user. At- tribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567." LDAP syntax: Telephone Number Example: telephoneNumber: +41 1 234 5678
Table 5.12. Business Phone Number (telephoneNumber)
Description: Mobile phone number (defined in inetOrgPer- son) Semantics: Follow inetOrgPerson definition of RFC 1274: "The [mobile] attribute type specifies a mobile telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers: i.e., "+41 79 123 4567." LDAP syntax: Telephone Number Example: mobileTelephoneNumber: +41 79 234 5678
Table 5.13. Mobile Phone Number (mobile)
36
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Description: Name of a Home Organization Semantics: Domain Name of a Home Organization. LDAP syntax: Directory String Example: swissEduPersonHomeOrganization: hsr.ch
Table 5.14. Home Organization (swissEduPersonHomeOrganization)
Description: Type of a Home Organization Semantics: Type of Home Organization according to a controlled vocabulary. University, uas, hospital, library, vho and others are permissible values. LDAP syntax: Directory String Example: swissEduPersonHomeOrganizationType: university
Table 5.15. Home Organization Type (swissEduPersonHomeOrganizationType)
Description: Type of affiliation (defined in eduPerson) Semantics: Specifies the user's relationship(s) to the Home Organization in broad categories: faculty, stu- dent, staff, alum, member, affiliate and employ- ee. LDAP syntax: Directory String Example: eduPersonAffiliation: faculty
Table 5.16. Affiliation (eduPersonAffiliation)
Description: Study branch of a student, first level of classi- fication. Semantics: This attribute follows the catalog of study branches of the SIUS/SHIS. It is classified in branch, domain of branch and group of domain. This attribute is a code corresponding to the group of domain. LDAP syntax: Integer {6} Example: swissEduPersonStudyBranch1: 4
Table 5.17. Study Branch 1 (swissEduPersonStudyBranch1)
SIUS/SHIS 6
6 SIUS/SHIS = swiss university informationsystem
37
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Description: Study branch of a student, intermediate level of classification. Semantics: This attribute follows the catalog of study branches of the SIUS/SHIS. It is classified in branch, domain of branch and group of domain. This attribute is a code corresponding to the domain of branch. LDAP syntax: Integer {6} Example: swissEduPersonStudyBranch2: 42
Table 5.18. Study Branch 2 (swissEduPersonStudyBranch2)
Description: Study branch of a student. Semantics: This attribute follows the catalog of study branches of the SIUS/SHIS. It is classified in branch, domain of branch and group of domain. This attribute is the SIUS/SHIS code of the study branch. LDAP syntax: Integer {6} Example: swissEduPersonStudyBranch3: 7905
Table 5.19. Study Branch 3 (swissEduPersonStudyBranch3)
Description: Study level of a student in a particular study branch. Semantics: This attribute follows the definition of study branch and study level of the SIUS/SHIS. The format is - . For : the permiss- ible values are 0, 10, 15, 20, 25, 26, 31, 32, 39. LDAP syntax: Directory String Example: swissEduPersonStudyLevel: 7905-15
Table 5.20. Study Level (swissEduPersonStudyLevel)
Description: Workbranch of a staff member Semantics: The classification is based on the staff categor- ies of the SIUS/SHIS Documents, suitably ex- panded to include non-school categories (if controlled). There are three main categories: 100 Teachers, 200 Researchers, 300 Others (Support, Admin and technical staff). The last two digits detail the category. LDAP syntax: Integer {3} Example: swissEduPersonStaffCategory: 101
Table 5.21. Staff Category (swissEduPersonStaffCategory)
38
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Description: The distinguished name (DN) of the directory entry representing the organization with which the person is associated (defined in eduPer- son). Semantics: The directory entry pointed to by this dn should be represented in the X.521(2001) "organiza- tion" object class. LDAP syntax: DN Example: o=HSR, c=CH
Table 5.22. Organization Path (eduPersonOrgDN)
Description: The distinguished name (DN) of the directory entries representing the person's Organization- al Unit(s) (defined in eduPerson). Semantics: The directory entry pointed to by this dn should be represented in the X.521(2001) "organiza- tional unit" object class. LDAP syntax: DN Example: ou=ITA, o=HSR, c=CH
Table 5.23. Organizational Unit Path (eduPersonOrgUnitDN)
Description: URI (either URL or URN) that indicates a set of rights to specific resources. (defined in eduPerson) Semantics: With eduPersonEntitlement, a Home Organiz- ation declares that the user whose record contains this attribute is in their opinion entitled to access the SPECIFIC resource described by the URI. I.e. the group membership is restric- ted to authorized users of that resource. LDAP syntax: Directory String Example: eduPersonEntitlement: ht- tp://unil.ch/aai/resources/biblio92
Table 5.24. Group Membership (eduPersonEntitlement)
Description: The uid attribute type specifies a computer system login name. Semantics: n/a LDAP syntax: Directory String Example: uid: franzM
Table 5.25. System login name (uid)
39
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Description: User password for authentication. Semantics: UserPassword values must be represented by following syntax: passwordvalue = schemeprefix encryptedpassword. For the schemaprefix permissible values are: {SHA}, {MD5}, {SMD5}, {CRYPT} and {CLEARTEXT} . LDAP syntax: n/a Example: userPassword: {crypt}3x1231v76T89N
Table 5.26. Password (userPassword)
More detailed informations about the swissEdu person attributes are available at Switch 7 . 4.3. LDIF Files
A main question in the LDAP area is, how to fill it with attributes in a efficient way? For this purpose LDIF files were introduced. For the Shibboleth demonstrator the entries were generated with LDIF files.
The entries can be added to the directory by executing the following command.
# slappadd -l swissEDU.ldif
As you can see the swissEdu.ldif is written in the LDIF syntax:
## Build the eduPeople node dn: ou=eduPeople,dc=shibbolethtesting,dc=org ou: eduPeople objectClass: organizationalUnit
## Add some users dn: cn=Max Powers,ou=eduPeople,dc=shibbolethtesting,dc=org cn: Max Powers uid: mpowers userPassword: {SHA}yDP69XhMj5K37G+c8rBm8B93xQg= sn: Powers givenName: Max swissEduPersonUniqueID: mpowers@hsr.ch eduPersonAffiliation: student swissEduPersonHomeOrganization: hsr.ch mail: mpowers@hsr.ch swissEduPersonDateOfBirth: 19801016 swissEduPersonGender: 1 homePostalAddress: Bachstrasse 15 CH-9000 Zürich homePhone: 044 255 32 45 objectClass: swissEduPerson dn: cn=Dirk Diggler,ou=eduPeople,dc=shibbolethtesting,dc=org cn: Dirk Diggler
7 http://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf
40
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend uid: ddiggler userPassword: {SHA}yDP69XhMj5K37G+c8rBm8B93xQg= sn: Diggler givenName: Dirk swissEduPersonUniqueID: ddiggler@hsr.ch eduPersonAffiliation: faculty swissEduPersonHomeOrganization: hsr.ch mail: ddiggler@hsr.ch swissEduPersonDateOfBirth: 19700712 swissEduPersonGender: 1 homePostalAddress: Waldweg 10 CH-9000 Zürich homePhone: 044 123 43 78 objectClass: swissEduPerson dn: cn=Susi Spitz,ou=eduPeople,dc=shibbolethtesting,dc=org cn: Susi Spitz uid: sspitz userPassword: {SHA}yDP69XhMj5K37G+c8rBm8B93xQg= sn: Spitz givenName: Susi swissEduPersonUniqueID: sspitz@hsr.ch eduPersonAffiliation: student swissEduPersonHomeOrganization: hsr.ch mail: sspitz@hsr.ch swissEduPersonDateOfBirth: 19810423 swissEduPersonGender: 2 homePostalAddress: Hasenweg 34 CH-9000 Zürich homePhone: 044 987 34 87 objectClass: swissEduPerson dn: cn=Sandra Shine,ou=eduPeople,dc=shibbolethtesting,dc=org cn: Sandra Shine uid: sshine userPassword: {SHA}yDP69XhMj5K37G+c8rBm8B93xQg= sn: Shine givenName: Sandra swissEduPersonUniqueID: sshine@hsr.ch eduPersonAffiliation: faculty swissEduPersonHomeOrganization: hsr.ch mail: sshine@hsr.ch swissEduPersonDateOfBirth: 19650214 swissEduPersonGender: 2 homePostalAddress: Melonenstrasse 13 CH-9000 Zürich homePhone: 044 765 34 32 objectClass: swissEduPerson
4.4. Attribute configuration with a LDAP browser
For an easy user management LDIF is not a nice solution. An LDAP browser is more comfort- able, because it is flexible and easy to use. A good, small and platform independent (Java based) browser is "LDAP Browser/Editor V 2.8.1" available at LDAP Browser/Editor 8 .
In the following sections some interactions with the LDAP Browser/Editor are showed with visual addons.
8 http://www-unix.mcs.anl.gov/~gawor/ldap/
41
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
4.4.1. Connect to an LDAP backend
To connect to the LDAP Directory the "Quick connect" function of the LDAP Browser can be used. Only the values for the attributes Host, Base DN, User DN and Password should be changed. The following values are suitable for the Shibboleth environment:
• Host: moon.shibbolethtesting.org or sun.shibbolethtesting.org
• Base DN: dc= shibbolethtesting.org, dc=org
• User DN: cn=root
• Pasword: tuxmux
Figure 5.1. Quick connect window
After connecting the LDAP Browser/Editor basic window shows up the LDAP tree and the corresponding values for the entries.
Figure 5.2. LDAP basic window
42
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
4.4.2. Add/Edit a new node
A new node can be added by the browsers menu "Add entry" function. By selecting person a new node will be added. The object class will be altered later.
Figure 5.3. Adding an new node
Now the node settings are displayed. In this window only the "dn's" and "objectclass's" value are adapted to our needs.The "objectclass" attribute has to contain the value swissEduPerson. Further the "user password" and the surname "sn" have to filled in.
Figure 5.4. Node settings 4.4.3. Add/Edit a new attribute
Now the attributes can be added.This can be done in two ways: adding trough the LDAP menu or the context menu.
43
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ LDAP backend
Figure 5.5. Adding an attribute through contextmenu
Figure 5.6. Adding an attribute through menu
Choosing "Add Attribute" opens an attribute window. Please pay attention to the "Attribute definiton" section where the syntax and form of valid attributes is described.
Figure 5.7. Attribute settings
44
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Chapter 6. Identity Provider (IdP)
To authenticate a user in a Shibboleth environment an identity provider is needed.This chapter gives an introduction into the identity provider and describes the way his components work. Further the installation and configruation of an IdP will be explained. 1. IdP description 1.1. Introduction
After a user made a request to a resource on a service provider, he is been redirected trough the WAYF server to his home organization. On the server of the home organization the user has to authenticate. In case of a successful login, he is been redirected to the original requested page, together with his specific attributes. In our virtual environment we have two identity pro- viders.
• sun (sun.shibbolethtesting.org)
• moon (moon.shibbolethtesting.org 1.2. Tasks
• An identity provider maintains user credentials and attributes. If contacted by any guest he trys to create the handles and foreward them to the service provider. The components are showed in the Figure 6.1 .
The user credentials are used for the authentication and the attributes are needed for the au- thorisation. 1.3. Components
The Identity Provider contains three major components:
• Authentication Authority
The authentication authority provides authentication statements for other components and is integrated in the IdP's authentication service.
• Attribute Authority (AA)
The Attribute Authority brings the user and his priviledges together. Further the attribute authority authenticates and authorizes any requests it receives.
• Single Sign-on Service (SSO)
The Single Sign-on (SSO) Service is the entry point to an LDAP.The SSO service starts the authentication process and forewards the user.
• Artifact Resolution Service
45
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
If the Browser/Artifact profile is used, the IdP sends an artifact to the SP instead of the ac- tual assertion. (An artifact is a reference to an authentication assertion.) The SP then sends the artifact to the artifact resolution service at the IdP via a back-channel exchange. In return, the IdP sends the required authentication assertion to the SP.
Figure 6.1. Illustration identity provider 2. Installation and configuration of an identity provider 2.1. Introduction
This sections describes the Debian specific installation of a Shibboleth identity provider 1.3c and its configuration. It covers installation with Tomcat 5.5 only and the Single Sign On system CAS. More extensive information about the different configuration possibilities is available at Internet2 1 . This installation and configuration guide is based on the Switch tutorial 2 , which we adapted to our needs. 2.2. Overview
The Shibboleth IdP 1.3c is implemented in JAVA and is running as a web application in Tomcat. The IdP consists of two SSO (Single Sign On) servlets and an Attribute Authority (AA). The user access the SSO which requires authentication. The Shibboleth IdP doesn not include authentication, it has to be handled outside by a seperate authentication system. In the Shib- bolethtesting environment the client based authentication in tomcat and the CAS SSO System are used. The AA (Attribute Authority) who is responsible for Attribute releasing is accessed by the Shibboleth service provider and has to be protected with SSL client authentication in Tomcat. So for this purpose in Tomcat two ip addresses/DNS entries and corresponding server certificates are needed. One for the SSO and one for AA with client based authentication. The values for the domain names are:
• http://moon2.shibbolethtesting.org/shibboleth-idp/AA (Attribute Authority on moon) - Tomcat connector needs client based authentication for the service providers.
http://sun2.shibbolethtesting.org/shibboleth-idp/AA (Attribute Authority on sun) - Tomcat connector needs client based authentication for the service providers.
• http://moon.shibbolethtesting.org/shibboleth-idp/SSO (Single Sign On on moon) - enduser authentication through the Esup CAS SSO System
1 http://shibboleth.internet2.edu/guides/idp/ 2 http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/idp/install-idp-1.3-debian.html
46
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
http://sun.shibbolethtesting.org/shibboleth-idp/SSO (Single Sign On on sun) - enduser client based authentication 2.3. Prenotes
This guide applies to Debian etch (testing) and contains some references to Debian specific tools. The following packages should be installed on the system prior to the installation:
• OpenSSL - The OpenSSL tools to handle with server certificates.
# aptitude install openssl
Installed version: 0.9.8a
• ntpdate - Client tool for synchronisation with the NTP server on dave.shibbolethtestin.org. Servers running Shibboleth must have their system synchronized to avoid clock-skews.
# aptitude install ntpdate
Installed version: 4.2.0a
• All packages which are downloaded and not included in the Debian distribution are placed in /opt/Packages and installed in /opt/... . 2.4. JAVA 1.5
In Debian GNU/Linux the official JAVA JDK is not included. This section covers how to install JAVA 1.5 on Debian etch.
1. Download the J2SE Development Kit (JDK) 1.5 for Linux systems from Sun 3 .
The installed version is jdk-1_5_0_05-linux-i586.bin
2. The JDK should be installed in the directory /opt/shibbolethIDP-1.3/ .
# cd /opt/shibbolethIDP-1.3 # ./jdk-1_5_0_04-linux-i586.bin
3. The JAVA binaries are added to the system path.
# export JAVA_HOME=/opt/shibbolethIDP-1.3/jdk1.5.0_05 # /usr/sbin/update-alternatives --install /usr/bin/java java \
3 http://java.sun.com/j2se/1.5.0/download.jsp
47
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
$JAVA_HOME/bin/java 200 # /usr/sbin/update-alternatives --install /usr/bin/javac javac \ $JAVA_HOME/bin/javac 200 # /usr/sbin/update-alternatives --install /usr/bin/jar jar \ $JAVA_HOME/bin/jar 200 # /usr/sbin/update-alternatives --install /usr/bin/keytool keytool \ $JAVA_HOME/bin/keytool 200
4. The export of the JAVA_HOME variable is also in the file /etc/profile included.
# nano -w /etc/profile
JAVA_HOME=/opt/shibbolethIDP-1.3/jdk1.5.0_05 export JAVA_HOME
2.5. Tomcat 5.5
Tomcat 5.5 is the recommend version to use with Shibboleth IdP version 1.3c. For Debian etch an offical Tomcat 5.5 package does not exist (only 5.0 is available). So the package has to be downloaded from Apache.
1. Downloading Tomcat 5.5.12 from apache 4 .
# cd /opt/Packages # wget http://mirror1.zic-network.ch/apache/tomcat/tomcat-5/v5.5.12/\ bin/apache-tomcat-5.5.12.tar.gz
2. Unpacking apache-tomcat-5.5.12.tar.gz in /opt/Packages and copy it to the directory /opt/shibbolethIDP-1.3/
# tar -xzf apache-tomcat-5.5.12.tar.gz # cp -R apache-tomcat-5.5.12 /opt/shibbolethIDP-1.3/
3. Creating some symlinks to simplify the access to configuration and log files.
# ln -s /opt/shibbolethIDP-1.3/apache-tomcat-5.5.12/conf /etc/tomcat # ln -s /opt/shibbolethIDP-1.3/apache-tomcat-5.5.12/logs /var/log/tomcat
4 http://mirror1.zic-network.ch/apache/tomcat/tomcat-5/v5.5.12/bin/apache-tomcat-5.5.12.tar.gz
48
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
4. Unnecessary files can be removed from /opt/shibbolethIDP-1.3/apache-tomcat- 5.5.12/bin
# cd /opt/shibbolethIDP-1.3/apache-tomcat-5.5.12/bin # rm catalina.bat cpappend.bat digest.bat service.bat setclasspath.bat \ shutdown.bat startup.bat tomcat5.exe tomcat5w.exe tool-wrapper.bat version.bat
5. An init.d startup script has to be installed as /etc/init.d/tomcat and has to be set executable. Below is a modified startup script for Tomcat 5.5 on Debian etch.
#! /bin/sh -e # # /etc/init.d/tomcat -- startup script for the Tomcat 5.0 servlet engine # # Written by Miquel van Smoorenburg . # Modified for Debian GNU/Linux by Ian Murdock . # Modified for Tomcat by Stefan Gybas .
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin NAME=tomcat DESC="Tomcat 5.5 servlet engine" DAEMON=/opt/shibbolethIDP-1.3/apache-tomcat-5.5.12/bin/catalina.sh CATALINA_HOME=/opt/shibbolethIDP-1.3/apache-tomcat-5.5.12/
# The following variables can be overwritten in /etc/default/tomcat5
# Run Tomcat 5.5 as this user ID (default: tomcat5) # Set this to an empty string to prevent Tomcat from starting automatically TOMCAT5_USER=root
# The first existing directory is used for JAVA_HOME (if JAVA_HOME is not # defined in /etc/default/tomcat5) JDK_DIRS="/opt/shibbolethIDP-1.3/jdk1.5.0_05"
# Arguments to pass to the Java virtual machine (JVM) CATALINA_OPTS="-Djavax.net.ssl.trustStore=/etc/tomcat/truststore.jks"
# Use the Java security manager? (yes/no) TOMCAT5_SECURITY="no"
# End of variables that can be overwritten in /etc/default/tomcat5
# overwrite settings from default file if [ -f /etc/default/tomcat5 ]; then . /etc/default/tomcat5 fi
test -f $DAEMON || exit 0
# Look for the right JVM to use for jdir in $JDK_DIRS; do if [ -d "$jdir" -a -z "${JAVA_HOME}" ]; then JAVA_HOME="$jdir" fi done export JAVA_HOME export CATALINA_OPTS
49
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
# Define other required variables PIDFILE="/var/run/$NAME.pid" LOGDIR="$CATALINA_HOME/logs" WEBAPPDIR="$CATALINA_HOME/webapps" STARTUP_OPTS="" if [ "$TOMCAT5_SECURITY" = "yes" ]; then STARTUP_OPTS="-security" fi
# CATALINA_PID for catalina.sh export CATALINA_PID="$PIDFILE" case "$1" in start) if [ -z "$TOMCAT5_USER" ]; then echo "Not starting $DESC as configured (TOMCAT5_USER is empty in" echo "/etc/default/tomcat5)." exit 0 fi if [ -z "$JAVA_HOME" ]; then echo "Could not start $DESC because no Java Development Kit" echo "(JDK) was found. Please download and install JDK 1.3 or higher and set"
echo "JAVA_HOME in /etc/default/tomcat5 to the JDK's installation directory."
exit 0 fi
echo -n "Starting $DESC using Java from $JAVA_HOME: "
# Remove dangling webapp symlinks for webapp in "$WEBAPPDIR"/*; do if [ "$webapp" != "$WEBAPPDIR/*" -a ! -e "$webapp" ]; then echo "Removing obsolete webapp $webapp" >>"$LOGDIR/catalina.out" rm "$webapp" >> "$LOGDIR/catalina.out" 2>&1 || true fi done
# Symlink new webapps from /usr/share/java/webapps for webapp in /usr/share/java/webapps/*; do if [ -e "$webapp" -a ! -e "$WEBAPPDIR/`basename $webapp`" \ -a ! -e "$WEBAPPDIR/`basename $webapp .war`" ]; then echo "Symlinking new webapp $webapp" >>"$LOGDIR/catalina.out" ln -s "$webapp" "$WEBAPPDIR" || true fi done
# Create catalina.policy (for the security manager) # rm -f /var/lib/tomcat/catalina.policy # cat /etc/tomcat/policy.d/*.policy >/var/lib/tomcat/catalina.policy
mkdir -p "$CATALINA_HOME/work/_temp" touch "$PIDFILE" "$LOGDIR/catalina.out" || true chown --dereference "$TOMCAT5_USER" "$PIDFILE" "$LOGDIR" \ "$LOGDIR/catalina.out" "$CATALINA_HOME/work" \ "$CATALINA_HOME/temp" || true if start-stop-daemon --test --start --pidfile "$PIDFILE" \ --user $TOMCAT5_USER --startas "$DAEMON" >/dev/null; then # -p preserves the environment (for $JAVA_HOME etc.) # -s is required because tomcat5's login shell is /bin/false su -p -s /bin/sh $TOMCAT5_USER \ -c "\"$DAEMON\" start $STARTUP_OPTS" \ >>"$LOGDIR/catalina.out" 2>&1 echo "$NAME." else
50
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
echo "(already running)." fi ;; stop) echo -n "Stopping $DESC: " if start-stop-daemon --test --start --pidfile "$PIDFILE" \ --user $TOMCAT5_USER --startas "$DAEMON" >/dev/null; then echo "(not running)." else su -p $TOMCAT5_USER -c "\"$DAEMON\" stop" >/dev/null 2>&1 || true # Fallback to kill the JVM process in case stopping did not work sleep 1 start-stop-daemon --stop --oknodo --quiet --pidfile "$PIDFILE" \ --user "$TOMCAT5_USER" rm -f "$PIDFILE" echo "$NAME." fi ;; restart|force-reload) $0 stop sleep 1 $0 start ;; *) echo "Usage: /etc/init.d/tomcat {start|stop|restart|force-reload}" >&2 exit 1 ;; esac
exit 0
6. To start Tomcat automatically with the default runlevels, the different rc.d should be up- dated .
# update-rc.d tomcat defaults
2.6. Shibboleth IdP 1.3c
1. To install the IdP, the Shibboleth IdP sources from Internet2 5 can be downloaded directly.
# cd /opt/Packages # wget https://wayf.internet2.edu/shibboleth/shibboleth-idp-1.3c.tar.gz
2. The shibboleth-idp-1.3c.tar.gz should be extracted in the directory /opt/Packages/ .
# tar -xzf shibboleth-idp-1.3c.tar.gz
5 https://wayf.internet2.edu/shibboleth/shibboleth-idp-1.3c.tar.gz
51
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
3. The support contact E-Mail address in /opt/Packages/shibboleth-idp-1.3c- install/webApplication/idPError.jsp could be modified.
4. The installation of the LDAP is started through an Ant script (Ant is released together with the IdP in the IdP package).
# cd /opt/shibbolethIDP-1.3/shibboleth-idp-1.3c-install # ./ant Do you want to install the Shibboleth Identity Provider? [Y,n] Y What name do you want to use for the Identity Provider web application? [default: shibboleth-idp] shibboleth-idp Deploying the java web application. Do you want to install it directly onto the filesystem or use the tomcat manager application? 1) filesystem (default) 2) manager 1 Select a home directory for the Shibboleth Identity Provider [default: /usr/local/shibboleth-idp] /opt/shibbolethIDP-1.3/shibboleth-idp Enter the tomcat home directory [default: /usr/local/tomcat] /opt/shibbolethIDP-1.3/apache-tomcat-5.5.12
5. The implementation of Sun's JAXP parser has been identified as containing a memory leak.Therefore, both JDK 1.4.x and 1.5.x should endorse the new XML libraries in Tomcat. The Shibboleth jar files are copied to the Tomcat directory.
# cp /opt/shibbolethIDP-1.3/shibboleth-idp/endorsed/*.jar /opt/shibbolethIDP-1.3/apache-tomcat-5.5.12/common/endorsed/
Other existing .jar files in /opt/shibbolethIDP-1.3/apache-tomcat- 5.5.12/common/endorsed/ may conflict with Xalan and should be removed.
6. For a simpler access to the Shibboleth configuration and log files symbolic links should be set.
# ln -s /opt/shibbolethIDP-1.3/shibboleth-idp/etc /etc/shibbolethIDP # ln -s /opt/shibbolethIDP-1.3/shibboleth-idp/logs /var/log/shibbolethIDP
7. The IDP_HOME environment variable should be set.
# export IDP_HOME=/opt/shibbolethIDP-1.3/shibboleth-idp
52
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
8. Including the export IDP_HOME into the /etc/profile file.
# nano -w /etc/profile IDP_HOME=/opt/shibbolethIDP-1.3/shibboleth-idp export IDP_HOME
2.7. Central Authentication System (CAS) Single Sign On (SSO) - moon.shibbolethtesting.org
The Central Authentication System generic handler (ESUP CAS) handles user authentication with username and password against an LDAP backend on moon.shibbolethtesting.org. To use CAS on Shibboleth, the CAS client and the CAS server have to be configured. 2.7.1. CAS generic handler (server)
1. Downloading the esup-cas-server package from esup-casgeneric.sourceforge.net 6 .The version of CAS server included in this package is cas-server-2.0.12
# cd /opt/Packages # wget http://switch.dl.sourceforge.net/sourceforge/esup-casgeneric/\ esup-cas-server-2.0.5-2.zip
2. Extracting the downloaded file esup-cas-server-2.0.5-2.zip .
# unzip esup-cas-server-2.0.5-2.zip
3. Configuring our CAS server to fit in the LDAP backend in /opt/Packages/esup-cas- server-2.0.5-2/properties/build.properties .
# nano -w /opt/Packages/esup-cas-server-2.0.5-2/properties/build.properties
esup-casgeneric.auth=ldap-search esup-casgeneric.auth.ldap-search.filter=uid=%u esup-casgeneric.auth.ldap-search.search-base=dc=shibbolethtesting,dc=org esup-casgeneric.auth.ldap-search.scope=sub esup-casgeneric.auth.ldap-search.bind-dn=cn=root,dc=shibbolethtesting,dc=org esup-casgeneric.auth.ldap-search.bind-password=tuxmux esup-casgeneric.auth.ldap-search.url=ldap://moon.shibbolethtesting.org
6 http://esup-casgeneric.sourceforge.net
53
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
# [...] esup-casgeneric.log.path=/var/log/esup-casgeneric.log # [...] cas-server.deploy.home=/opt/shibbolethIDP-1.3/apache-tomcat-5.5.12/webapps/cas
4. After the configuration, the CAS server can be deployed with Ant. For this purpose Ant in the folder /opt/Packages/shibboleth-idp-1.3c-install is used. To run Ant successfully the path to the Ant jar files in the Ant script has to be modified. The CAS server will be installed in /opt/shibbolethIDP-1.3/apache-tomcat- 5.5.12/webapps/cas , and can be tested via the URL http://moon.shibboletht- esting.org:8080/cas/login
# cd /opt/Packages/esup-cas-server-2.0.5-2 # /opt/Packages/shibboleth-idp-1.3c-install/ant deploy
2.7.2. CAS generic handler (client)
1. To use the CAS server with Shibboleth, the CAS client must be installed and configured.
Downloading the CAS client Verison 2.1.1 for JAVA from www.ja-sig.org 7
# cd /opt/Packages/ # wget http://jasigch.princeton.edu:9000/display/CAS/Java+CAS+Client+2.1.1
2. Unpacking the cas-client-java-2.1.1.tar.gz file and build it with Ant. Ant from the folder /opt/Packages/shibboleth-idp-1.3c-install is used.
# tar -xzf ./cas-client-java-2.1.1.tar.gz # cd cas-client-java-2.1.1 # ant jar
3. Enabling the Shibboleth web application to use CAS SSO.
# cp /opt/Packages/cas-client-java-2.1.1/dist/casclient.jar \ /opt/Packages/shibboleth-idp-1.3c-install/webApplication/WEB-INF/lib/
7 http://www.ja-sig.org
54
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
4. After enabling the Shibboleth web application to use CAS, the file /opt/Packages/shib- boleth-idp-1.3c-install/webAppConfig/dist.idp.xml has to be modified. After a new deployment this file is the web.xml of Shibboleth. Modifications on the file dist.idp.xml will only be effective after a new deployment of Shibboleth.
IdPConfigFile file:///etc/shibbolethIDP/idp.xml
CASFilter edu.yale.its.tp.cas.client.filter.CASFilter edu.yale.its.tp.cas.client.filter.loginUrl https://moon.shibbolethtesting.org/cas/login edu.yale.its.tp.cas.client.filter.validateUrl https://moon.shibbolethtesting.org/cas/proxyValidate
edu.yale.its.tp.cas.client.filter.serverName moon.shibbolethtesting.org edu.yale.its.tp.cas.client.filter.wrapRequest true
CASFilter /SSO/*
IdP Shibboleth Identity Provider
edu.internet2.middleware.shibboleth.idp.IdPResponder
1
IdP /SSO
55
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
IdP /AA IdP /Artifact IdP /Status
css text/css
5. To get the modifications of Shibboleth effective the Shibboleth IdP web application has to be redeployed.
# cd /opt/Packages/shibboleth-idp-1.3c-install # ./ant
2.8. Client certificate based (PKI) Single Sign On (SSO) - sun.shibbolethtesting.org
1. Shibboleth supports client certificate authentication by utilization of a filter.This filter ensures that the certificate is valid and appropriate for the application. To use the filter properly, Tomcat must be configured to use client certificate based authentication on the SSO (please see below at the Tomcat connector configuration). The following /opt/Pack- ages/shibboleth-idp-1.3c-install/webAppConfig/dist.idp.xml is used:
IdPConfigFile file:///etc/shibbolethIDP/idp.xml
Client Cert AuthN Filter
56
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
edu.internet2.middleware.shibboleth.utils.ClientCertTrustFilter
Client Cert AuthN Filter /SSO
IdP Shibboleth Identity Provider
edu.internet2.middleware.shibboleth.idp.IdPResponder
IdP /SSO IdP /AA IdP /Artifact IdP /Status
css text/css
2. To get the modifications effective, the Shibboleth IdP must be redeployed. Please pay at- tention to use a fresh /opt/Packages/shibboleth-idp-1.3c-install directory which was not patched with CAS.
# cd /opt/Packages/shibboleth-idp-1.3c-install # ./ant
57
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
2.9. Server certificates and keystores
The server certificates and keystores for the Shibboleth environment were generated with TinyCA version 0.7.0 8 and portecle version 1.1 9 . More information about certificates is available in the chapter "Certificates" of this documentation. 2.10. Tomcat 5.5 configuration
1. The keystores (contains server certificates) and truststores (contains accepted root CA's for PKI) are copied to the Tomcat directory /etc/tomcat . The permissions to the files must be set correctly. Only the user runnning Tomcat needs read permission for the key- and truststores.
• moon.shibbolethtesting.org
# cp moon.shibbolethtesting.org.jks /etc/tomcat # cp truststore.jks /etc/tomcat
• sun.shibbolethtesting.org
# cp sun.shibbolethtesting.org.jks /etc/tomcat # cp truststore.jks /etc/tomcat # cp truststore2.jks /etc/tomcat
2. Configuring the connectors for the Shibboleth environment in the file /etc/tomcat/serv- er.xml .
• moon.shibbolethtesting.org:
8 Official TinyCA website, tinyca.sm-zone.net/ [http://tinyca.sm-zone.net/] 9 Official Portecle website, portecle.sourceforge.net [http://portecle.sourceforge.net/]
58
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="yes" sslProtocol="TLS" keystoreFile="/etc/tomcat/moon2.shibbolethtesting.org.jks" keystorePass="tuxmux" truststoreFile="/etc/tomcat/truststore.jks" truststorePassword="tuxmux" />
• sun.shibbolethtesting.org:
Other connectors (like the AJP 1.3 connector on port 8009) are not needed for a Tomcat-only installation and can be unmarked or deleted from server.xml . 2.11. Shibboleth IdP 1.3c configuration
To run the Shibboleth IdP, four configuration files must be modified.
The file samples in this section refer to moon.shibbolethtesting.org. The configuration on sun.shibbolethtesting.org is similar, except the names.
• idp.xml - basic configuration file
• resolver.xml - configuration for the attribute source (LDAP access from Shibboleth)
59
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
• arp.site.xml - Attribute Release Policy (which attributes will be released to which service provider)
• shibboleth-metadata.xml - contains SP's and IdP's in a federation
1. The /etc/shibbolethIDP/idp.xml is the basic configuration file for the Shibboleth IdP server. Below the idp.xml of moon.shibbolethtesting.org is listed. Important attributes are described more detailed.
• AAUrl : is provided for backward compatibility with Shibboleth 1.1. It directly specifies the URL used to access the attribute query handler (the AA) for older versions of Shibboleth. Versions 1.2 and higher retrieve this information from metadata.
• defaultRelyingParty : This specifies the relying party to use for a request when no RelyingParty element's name attribute matches the policy URI of an incoming request (an incoming request will be authenticated against the metadata file). Typically, this will be populated with the URI of a federation.
• providerId : This URN is the unique identifier of our resource within the federation. It's value should be "stable". It should not change, even a resource has to be moved from one host to another one. So choosing a "service name" is preferred over a host name.
To use the idp.xml for sun.shibbolethtesting.org only the attributes providerId and AAUrl should be changed to correct values.
60
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
file:///etc/shibbolethIDP/arps/
file:///etc/tomcat/moon.shibbolethtesting.org.jks moon.shibbolethtesting.org moon.shibbolethtesting.org tuxmux tuxmux
61
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
implementation="edu.internet2.middleware.shibboleth.idp.provider.ShibbolethV1SSOHandler">
.+/shibboleth-idp/SSO
.+/shibboleth-idp/AA
.+/shibboleth-idp/Artifact
https://[^:/]+(:443)?/shibboleth-idp/Status
2. To release attributes from the LDAP of an identity provider to a service provider the con- nection from Shibboleth to the LDAP server has to be configured and the Shibboleth attrib- ute names have to be defined. The configuration of the attribute source could be done in the file /etc/shibbolethIDP/resolver.xml . This file does not define which at- tributes should released to which service provider.
To use the file for sun.shibbolethtesting.org only the values for the LDAP connector at the end of the configuration file should be changed.
62
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
63
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
3. To allow the release of attributes to the service providers carol.shibbolethtesting.org and winnetou.shibbolethtesting.org the Attribute Realease Policy must be defined. The ARP will specify which attribute will be released to which service provider.The following Attribute Release Policy should be placed in /etc/shibbolethIDP/arps with the name arp.site.xml . This Attribute Realease Policy is valid for moon.shibbolethtesting.org and sun.shibbolethtesting.org.
General ARP:
64
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
This file contains the custom Attribute Release Policies for the HomeOrg urn:mace:shibbolethtesting.org:moon.
urn:mace:shibbolethtesting.org:carol
urn:mace:shibbolethtesting.org:winnetou
65
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
4. The file shibbolethtesting-metadata.xml contains data about the IdP's and SP's in a federation. Federations are collections of IdP's and SP's that agree to exchange information according to a set of rules with a list of acceptible root certificate authorities, often utilizing a common set of attributes. E.g. if a service provider needs some attributes he must be authenticated sucessfully against the root certificate in the metadata file. If the authentication isn't sucessfully the default relaying party with the coresponding attributes will be taken.This means when the SP gets authenticated sucessfully against the certificate in the metadata file he will get the attributes which are defined in arp.site.xml for this specific service provider. When the SP does not get succesfully authenticated against the metadata file he will get the attributes from the default relying party. (Currently, attributes for a default relying party are not defined).
The following shibbolethtesting-metadata.xml is valid for all SP's and IdP's in the shibbolethtesting federation and must be placed on all SP's and IdP's.
66
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
MIIG9DCCBNygAwIBAgIJAMYEdJ2B3EYqMA0GCSqGSIb3DQEBBAUAMIGIMQswCQYD VQQGEwJDSDESMBAGA1UECBMJU3QuR2FsbGVuMRMwEQYDVQQHEwpSYXBwZXJzd2ls MQwwCgYDVQQKEwNIU1IxDDAKBgNVBAsTA0lUQTEiMCAGA1UEAxMZU2hpYmJvbGV0 aHRlc3RpbmcgUm9vdCBDQTEQMA4GCSqGSIb3DQEJARYBLTAeFw0wNTExMjMxNTE5 MDNaFw0xNTExMjExNTE5MDNaMIGIMQswCQYDVQQGEwJDSDESMBAGA1UECBMJU3Qu R2FsbGVuMRMwEQYDVQQHEwpSYXBwZXJzd2lsMQwwCgYDVQQKEwNIU1IxDDAKBgNV BAsTA0lUQTEiMCAGA1UEAxMZU2hpYmJvbGV0aHRlc3RpbmcgUm9vdCBDQTEQMA4G CSqGSIb3DQEJARYBLTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMGs G3fzHVwhQhuHYVDTMWRVUc3jYpu7C1h9dY2ub1jqGbCzx2a25JaTx9qKMJBAK6WJ qu2/9b6tvX2DrHVPhaFofNxyvtT8YMEjhJ8jA9irYXdfa4dw3N6mN+Vt+/52LZri xLVu9oRjozafr8OUgdQV1ko9dEi8LMZrTQblZc4gGZtQjq8oqqF8RwYaQyV82K8d Wb3lXzh+p7pvTMRQHhdIl7x3o6D+OA/yLsc5dYv04+tip3FQZ338eQSZqhZ/MVGZ 8YwDfejrANnjR6et+UpgF8/bXf1FCbUX5yJKqSEzxX4dfDq/Mk3r9aGBXYWTS12H qS5+lAEmcxXjPTLYXAtNVr6UTSX8OJJg69hdzbqT3d2sTMuCrsFz+T/Lx6jvwAqN ZNGdUigjwMgc4j/TzTGWAODincRBn7a08nCt0wUIWmRjzUYSr9GLmPAU6EKzR7MG KhUth3joAGyKGPX/QiX57wg6rA1m5LqozQm7LllHJ7681GdMNLDyMwUso3hDakMn TAVLwQ/bqdGiicgStzwf8dQjJgiJSm+VQYyJLasIj6sL8yp/+Ou4AKmAZd3+DA3Q 0U759CbHEvG8bUfXaEkhwlv2wQAmf0FuPz8l/SuxGEBY0qYxsaS9rk3BVapyKmMP N/8EY1CKdWQQBs8TpmYMn9cRr74SJ2PC9velHhJdAgMBAAGjggFdMIIBWTAdBgNV HQ4EFgQUHVBI5HqkzSavVNU6jvyqoZyFRH0wgb0GA1UdIwSBtTCBsoAUHVBI5Hqk zSavVNU6jvyqoZyFRH2hgY6kgYswgYgxCzAJBgNVBAYTAkNIMRIwEAYDVQQIEwlT dC5HYWxsZW4xEzARBgNVBAcTClJhcHBlcnN3aWwxDDAKBgNVBAoTA0hTUjEMMAoG A1UECxMDSVRBMSIwIAYDVQQDExlTaGliYm9sZXRodGVzdGluZyBSb290IENBMRAw DgYJKoZIhvcNAQkBFgEtggkAxgR0nYHcRiowDwYDVR0TAQH/BAUwAwEB/zARBglg hkgBhvhCAQEEBAMCAQYwCQYDVR0SBAIwADArBglghkgBhvhCAQ0EHhYcVGlueUNB IEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAMBgNVHREEBTADgQEtMA4GA1UdDwEB/wQE AwIBBjANBgkqhkiG9w0BAQQFAAOCAgEAIJQ2T83P669NULeNOZWBQzeMDh8aVxXA xTWAhmU4f26QMbaW3z8RsqBQ13noKDab27mAXfK5byDHmHPDxp0n5HMn8z8KkLmb 0pGq8ewRFwjZsVWO/29LrDR2FmErhpNPVHWTupwHmvHPg40gAO7QKr1H7/PB8kVy FmeOyG1fLdezcZmex9C39ubNsxGvyEpF36T2AZJRxe53K1ltbo7Ych7BK8pNYw8B 0TH2UcWz762Qe/ROfexTbufojuRBlbsDGkevF9bnjKe9ue+1XcYHCiTQwxz76uXu 6eUmD1CU2TOCz9UrBaTjki9POVAxrgyjcfvzgtHBKlij9mkSmVFmf3IKY1YVjueM GotOPbcck4MYeu2oifKXQI2sUf37O2ti9CFQHUnv8CqscNBrvFn7yqf3nBd51Rl5 N10yiC5McpKisaMq3DAJzCF9FG/oVPS1+M+zch5zm39XeBRG7Rg6ZPDv+zJO+3ds Q6ZcL0GHIuiqVlSCvUpgAgf94WJWhlJFrBEFvDJzwpD/n5LjO3zKmCM/tLMTZqF9 Y9ekxVo+Gyp4ldaCFKejPcwc1l6D/4pDdPMtFiFKld4uTxYCZ/NqGm8UlcDS4+dr xGuvnr9UDoZg+t/cU8mwqGmUsD0+78r03EFUuMdWGfem2lamQx9QX2Oee0OF7g+n GypQXlvfvFk=
moon
67
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
moon.shibbolethtesting.org
urn:mace:shibboleth:1.0:nameIdentifier
shibbolethtesting.org
moon.shibbolethtesting.org
urn:mace:shibboleth:1.0:nameIdentifier
Identity Provider Moon Identities 'R' Us https://moon.shibbolethtesting.org/ Technical Support idp@moon.shibbolethtesting.org
68
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
sun
sun.shibbolethtesting.org
Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="https://sun.shibbolethtesting.org/shibboleth-idp/Artifact"/>
urn:mace:shibboleth:1.0:nameIdentifier
Location="https://sun.shibbolethtesting.org/shibboleth-idp/SSO"/>
shibbolethtesting.org
sun.shibbolethtesting.org
69
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
Location="https://sun2.shibbolethtesting.org/shibboleth-idp/AA"/>
urn:mace:shibboleth:1.0:nameIdentifier
Identity Provider Sun Identities 'R' Us https://sun.shibbolethtesting.org/ Technical Support idp@sun.shibbolethtesting.org
carol.shibbolethtesting.org
urn:mace:shibboleth:1.0:nameIdentifier
70
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Location="https://carol.shibbolethtesting.org/Shibboleth.sso/SAML/Artifact"/>
Service Provider Carol Services 'R' Us
https://carol.shibbolethtesting.org Technical Support sp@carol.shibbolethtesting.org
winnetou.shibbolethtesting.org
urn:mace:shibboleth:1.0:nameIdentifier
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://winnetou.shibbolethtesting.org/Shibboleth.sso/SAML/POST"/> Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
71
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Identity Provider (IdP)
Location="https://winnetou.shibbolethtesting.org/Shibboleth.sso/SAML/Artifact"/> Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://winnetou.shibbolethtesting.org/Shibboleth.sso/SAML/POST"/> Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Location="https://winnetou.shibbolethtesting.org/Shibboleth.sso/SAML/Artifact"/> Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://winnetou.shibbolethtesting.org/Shibboleth.sso/SAML/POST"/> Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Location="https://winnetou.shibbolethtesting.org/Shibboleth.sso/SAML/Artifact"/>
Service Provider Carol Services 'R' Us https://winnetou.shibbolethtesting.org Technical Support sp@winnetou.shibbolethtesting.org
72
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Chapter 7. Service Provider(SP)
A service provider protects a web resource in a Shibboleth environment.This chapter describes how the components of an SP work and how a SP will be installed and configured. 1. SP description 1.1. Introduction
On the webserver of the service provider, protected content is stored. In our case this are simple PHP scripts, which print out the submitted attributes. On real servers this could be an E-Learning service or an access restricted file server. In our virtual environment we have two Service Providers:
• Winnetou (winnetou.shibbolethtesting.org)
• Carol (carol.shibbolethtesting.org 1.2. Tasks of a SP
• Protection of the resources.
• Establish connection to the IdP (trough the WAYF)
• Validation of the certificates
• Validation of the attributes
• Enabling access to the desired resource 1.3. Components
The Service Provider contains three major components:
• Assertion consumer services (ACS's)
• Shibboleth daemon (shibd)
• Resource manager (RM)
73
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
Figure 7.1. Illustration service provider 1.3.1. Assertion Consumer Services (ACS's)
Supporting the SAML authentication protocol requires one or more URLs hosted on the server be designated as special locations called "assertion consumer services"(in older releases also called "SHIRE" URLs). Shibboleth is then handling the requests, made to these URL's. 1.3.2. Shibboleth deamon (shibd)
Shibd is a C++ Apache2 module which implements the Shibboleth SP components. 1.3.3. Attribute requester or Resource Manager (RM)
Accepts attributes from the attribute authority and makes authorization decisions based on local rules and the user's Attributes. 1.4. Process flow
1. Request the resource
• ACS redirects to the WAYF Server
2. Authentication acknowledgement of Idp
• Forewarding the SAML attributes from the Apache modul (ACS) to the shibboleth deamon (shibd).
• The deamon requests the attribute authority for the attributes.
3. Attributes of the attribute authority
• Verification of the attributes (AAP.xml)
• Access permission (or denegation) for the resource.
74
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
Figure 7.2. Illustration of the Shibboleth process flow 2. Installation and configuration of a ser- vice provider 2.1. Introduction
This sections describes the Debian specific installation of a Shibboleth service provider 1.3 and its configuration . It covers installation with Apache 2. More extensive information about the different configuration possibilities is available at Internet2 1 . This installation and config- uration guide is based on the Switch 2 manual, which we adapted to our needs. 2.2. Overview
The following service providers exist in the Shibboleth testing environment:
• http://carol.shibbolethtesting.org
• http://winnetou.shibbolethtesting.org
For a more detailed view into the Shibboleth run circle please see the chapter interactions. 2.3. Prenotes
This guide applies to Debian etch (testing) and contains some references to Debian specific tools. The following packages should be installed on the system prior to the installation:
• Apache 2 with SSL + mod_php - The Open Source web server is available at www.apache.org 3 .
# aptitude install apache2 libapache2-mod-php4
1 http://shibboleth.internet2.edu/guides/sp/ 2 http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/sp/install-sp-1.3-debian.html 3 http://www.apache.org
75
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
Installed version of Apache 2: 2.0.55
Installed version of php4: 4.4.0-4
• OpenSSL - The OpenSSL tools and libraries to handle with server certificates.
# aptitude install openssl libssl0.9.8 libssl-dev
Installed version of OpenSSL: 0.9.8a
• ntpdate - Client tool for synchronisation with the NTP server on dave.shibbolethtestin.org. Servers running Shibboleth must have their system synchronized to avoid clock-skews.
# aptitude install ntpdate
Installed version of ntpdate: 4.2.0a
• All packages which are downloaded and not included in the Debian distribution are placed in /opt/Packages and installed in /opt/... . 2.4. Pretasks
As previous mentioned the Shibboleth SP is a C/C++ Apache 2 module. So the installation requires to compile the sources. To compile the Shibboleth sources the necessary libraries and tools, gcc, g++ and make are needed. The installation of the building tools will be done later.
1.
# export SHIB_HOME=/opt/shibbolethSP-1.3
2. Including the export of the SHIB_HOME variable in the file /etc/profile
# nano -w /etc/profile
SHIB_HOME=/opt/shibbolethSP-1.3 export SHIB_HOME
76
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
2.5. C/C++ compilers and building tools
To compile C/C++ code in Debian etch the building tool gcc , g++ and make are needed. The official Debian etch default building tools from the package system were installed. The install- ation of these packages will also install other dependent packages.
# aptitude install gcc g++ make
The installed versions are:
• gcc: 4.0.2
• g++: 4.0.2
• make: 3.80 2.6. Install libcurl library cURL is a command line tool for transferring files with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, Gopher, Telnet, DICT, FILE and LDAP. cURL supports HTTPS certificates, HTTP POST, HTTP PUT, FTP uploading, Kerberos, HTTP form based upload, proxies, cookies, user + password authentication, file transfer resume, http proxy tunneling and many other features. For Shibboleth SP 1.3 the supported versions are 7.11.0 or higher. As the default Debian etch libcurl is version 7.15.0-4, this library meets the requirements of Shibboleth.
# aptitude install libcurl3 libcurl3-dev
2.7. Log4cpp
Log4cpp is a library of C++ classes for flexible logging to files, syslog, IDSA and other destin- ations. It is modeled after the Log4j Java library, staying as close to their API as reasonable. The project homepage is log4cpp.sourceforge.net 4 They do not supply binaries yet, because of the numerous incompatible ABIs (e.g. g++ 2.95 vs 2.96 vs 3.0 vs 3.2) and different package formats. Internet2's Shibboleth project is using a snapshot which has been fixed on the supported Shibboleth platform and have been added with bug fixes. Shibboleth SP 1.3 requires this special log4cpp version which is available at Internet2 5
1.
# cd /opt/Packages # wget http://wayf.internet2.edu/shibboleth/log4cpp-0.3.5rc1.tar.gz
2. Building and installing the log4cpp library:
4 http://log4cpp.sourceforge.net 5 http://wayf.internet2.edu/shibboleth/log4cpp-0.3.5rc1.tar.gz
77
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
# tar xvzf log4cpp-0.3.5rc1.tar.gz # cd log4cpp-0.3.5rc1 # ./configure --prefix=$SHIB_HOME --disable-static --disable-doxygen # make # make install
2.8. Xerces-C++ library
Xerces-C++ is an validating XML Parser for C++. Xerces-C++ makes it easy to give your ap- plication the ability to read and write XML data. A shared library is provided for parsing, gener- ating, manipulating, and validating XML documents. The project homepage is: xml.apache.org/xerces-c/ 6 . For Shibboleth a special 2.6.1 release of Xerces-C++ with fixes applied is needed because the official release is incompatible with Shibboleth SP 1.3. This special version of Xerces-C++ is available at Internet2 7 .
1.
# cd /opt/Packages # wget http://wayf.internet2.edu/shibboleth/xerces-c-src_2_6_1.tar.gz
2. Installing Xerces into the Shibboleth SP directory:
# tar xvzf xerces-c-src_2_6_1.tar.gz # cd xerces-c-src_2_6_1 # export XERCESCROOT=`pwd` # cd src/xercesc # ./runConfigure -p linux -c gcc -x g++ -r pthread -P $SHIB_HOME # make # make install
2.9. XML-Security C++ library
The C++ library is an implementation of the XML Digital Signature specification. The Project homepage is: xml.apache.org/security/c/index.html 8 . Shibboleth requires the version 1.2.1 of the XML Security library.
1.
# cd /opt/Pacakges # export XERCESCROOT=`pwd`/xerces-c-src_2_6_1 # wget http://xml.apache.org/dist/security/c-library/xml-security-c-1.2.1.tar.gz
6 http://xml.apache.org/xerces-c/ 7 http://wayf.internet2.edu/shibboleth/xerces-c-src_2_6_1.tar.gz 8 http://xml.apache.org/security/c/index.html
78
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
2. Building and installing the XML-Security-C++ library in the Shibboleth directory:
# tar xvzf xml-security-c-1.2.1.tar.gz # cd xml-security-c-1.2.1/src # ./configure --prefix=$SHIB_HOME --without-xalan # make # make install
2.10. OpenSAML library
Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between security domains. In Shibboleth these are the identity provider and a service provider. OpenSAML is a Library which can be used to build, transport, and parse SAML 1.0 and 1.1 messages. OpenSAML supports the SOAP binding for the exchange of SAML requests and response object. The project homepage is: www.opensaml.org 9 . For Shibboleth SP 1.3 the OpenSAML 1.1a Library from Internet2 is required.
1.
# cd /opt/Packages # wget http://wayf.internet2.edu/shibboleth/opensaml-1.1a.tar.gz
2. Building and installing the OpenSAML library in the Shibboleth SP directory:
# tar xvzf opensaml-1.1a.tar.gz # cd opensaml-1.1 # ./configure --prefix=$SHIB_HOME --with-log4cpp=$SHIB_HOME -C # make # make install
2.11. Install Shibboleth SP 1.3
The Shibboleth SP 1.3 is an Apache dynamic loadable module. Therefore, it has to be linked with the Apache webserver. It requires the apxs2 tools as well as the Apache header files.
1. The Apache development packages containing the apxs2 and the Apache2 header files can be installed with the Debian package system.
# aptitude install apache2-threaded-dev
9 http://www.opensaml.org
79
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
2. The Shibboleth SP sources can be downloaded from the Internet2 homepage 10 .
# cd /opt/Packages # wget http://wayf.internet2.edu/shibboleth/shibboleth-sp-1.3b.tar.gz
3. Building and installing the Shibboleth service provider ( Shibboleth Daemon, Apache 2 module, libraries, ..) for Apache 2 into the Shibboleth directory.
# tar xvzf shibboleth-sp-1.3b.tar.gz # cd shibboleth-1.3 # ./configure --prefix=$SHIB_HOME \ --with-log4cpp=$SHIB_HOME \ --enable-apache-20 --with-apxs2=/usr/bin/apxs2 \ --disable-mysql # make # make install
4. For a simpler access to the Shibboleth configuration files, symbolic links can be defined.
# ln -s /opt/shibbolethSP-1.3/etc/shibboleth /etc/shibbolethSP
5. The /var/log/shibbolethSP logging directory does not exist. Creating and granting write access to the user running Apache (normally it should be www-data ).
# mkdir /var/log/shibbolethSP # chown www-data:www-data /var/log/shibbolethSP # chmod 755 /var/log/shibbolethSP
2.12. Server certificates
The server certificates and keystores for the Shibboleth environment were generated with TinyCA version 0.7.0 11 . More information about this topic is available in the chapter "Certificates" of this documentation. Warning
It is important to create in tinyca a client certificate not a server certificate for the SAML service on the service providers. If you choose a server certificate in tinyca, the client authentication of the service provider at the identity provider will fail.
10 http://wayf.internet2.edu/shibboleth/shibboleth-sp-1.3b.tar.gz 11 Official TinyCA website, tinyca.sm-zone.net/ [http://tinyca.sm-zone.net/]
80
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
2.13. Apache 2 configuration
To load the Shibboleth SP 1.3 module and get access to the secured web application Apache 2 has to be configured.
1. First, the Shibboleth module has to be configured and the Shibboleth protected location has to be defined. For this purpose the file /etc/apache2/mods-avail- able/mod_shib.conf is created. The mod_shib.conf file:
## # Shibbolethtesting # # Shibboleth SP 1.3 ## # Shibboleth SP 1.3 config ShibConfig /etc/shibbolethSP/shibboleth.xml ShibSchemaDir /opt/shibbolethSP-1.3/share/xml/shibboleth
SetHandler shib-handler
## # example: /secure location is protected by shibboleth AuthType shibboleth ShibRequireSession On require valid-user
2. After the module is configured it should be possible to load it. A module loader which should be placed in /etc/apache2/mods-available/mod_shib.load is created. The content of this file:
# # Load Shibboleth module for Apache2 # LoadModule mod_shib /opt/shibbolethSP-1.3/libexec/mod_shib_20.so
3. To enable the Shibboleth module for Apache 2, the Debian a2enmod tool is used.
# a2enmod mod_shib
4. On Debian, the Apache 2 webserver is started with the /etc/init.d/apache2 script. The script must be modified and the environment variable LD_LIBRARY_PATH set to be able to load the Shibboleth module. The following listing shows the beginning of the file /etc/init.d/apache2 :
81
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
#!/bin/sh -e # # apache2 This init.d script is used to start apache2. # It basically just calls apache2ctl. ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin"
SHIB_HOME=/opt/shibbolethSP-1.3 LD_LIBRARY_PATH=${SHIB_HOME}/libexec:${SHIB_HOME}/lib export LD_LIBRARY_PATH
5. Finally the Apache 2 server has to be restarted.
# /etc/init.d/apache2 restart
2.14. Shibboleth SP 1.3 configuration
To run the Shibboleth SP, three configuration files must be modified. The file samples of this section refers to carol.shibbolethtesting.org. The configuration on winnetou is similar, except the names hast to be renamed.
• shibboleth.xml - main configuration file
• AAP.xml - Attribute Acceptance Policy (which attributes are accepted from which idp)
• shibboleth-metadata.xml - contains SP's and IDP's in a federation
1. The /etc/shibbolethSP/shibboleth.xml is the main configuration file for the Shibboleth SP. Below the shibboleth.xml from carol.shibbolethtesting.org. Important attributes are explained beneath.
82
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
83
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
• providerId : This URN is the unique identifier of our resource within the federation. This value should not be changed, even you have to move your resource from one host to another one. So choosing a "service name" is preferred over a host name.
On winnetou.shibbolethtesting.org we changed the attribute providerId and homeURL to the appropriate values.
84
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
idpHistory="true" idpHistoryDays="7">
85
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
uri="/etc/shibbolethSP/AAP.xml"/>
• AAPProvider : Defines the path to the Attribute Acceptancy Policy. The AAP defines which attributes are accepted from which provider. Currently attributes from all IdP's are accepted.
urn:mace:shibbolethtesting.org
/etc/certificates/carolClient.key /etc/certificates/carolClient.crt
• CredentialsProvider : Defines where the private key and corresponding certificate for signing the SOAP requests are located.
86
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
On winnetou.shibbolethtesting.org the key and certificate attributes must be changed to appropriate values.
2. To accept attributes from the identity providers moon.shibbolethtesting.org and sun.shib- bolethtesting.org the Attribute Acceptancy Policy must be defined. The AAP will specify which attribute will be accepted from which service provider. Currently attributes from all service IdP's will be accepted. This file implements the attribute specifications from the LDAP Chapter and maps the attributes to Apache 2 environment variables. Below the At- tribute Acceptance Policy which is valid for carol.shibbolethtesting.org and moon.shib- bolethtesting.org.
87
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
Header="SHIB_SWISSEP_DATEOFBIRTH" Alias="dateOfBirth">
88
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
^[M|m][E|e][M|m][B|b][E|e][R|r]$ ^[F|f][A|a][C|c][U|u][L|l][T|t][Y|y]$ ^[S|s][T|t][U|u][D|d][E|e][N|n][T|t]$ ^[S|s][T|t][A|a][F|f][F|f]$ ^[A|a][L|l][U|u][M|m]$ ^[A|a][F|f][F|f][I|i][L|l][I|i][A|a][T|t][E|e]$ ^[E|e][M|m][P|p][L|l][O|o][Y|y][E|e][E|e]$
89
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
3. The metadata file is the same on every host (IdP, SP) in the federation, it would be ex- plained in the chapter about the IdP.
Information about shibbolethtesting-metadata.xml is available in the chapter about the IdP.
4. The logging information of the Shibboleth SP will be written in three files.
• shibboleth.logger
• native.logger
• shibd.logger Files with a good logger configuration are available at Switch 12 . The Shibboleth SP will log into the /var/log/shibbolethSP directory.
5. The Shibboleth package from internet2 does not come with a Debian startup script for the shibd daemon, but there is one available at Switch.
The content of the file /etc/init.d/shibboleth :
#! /bin/sh # # /etc/init.d/shibboleth for Debian # # start/stop script for Shibboleth ServiceProvider 1.3 daemon # # Created: 20050602 - Valery Tschopp - SWITCH
12 http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/sp/
90
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
# # HOWTO INSTALL: # root:/etc/init.d# update-rc.d shibboleth defaults 95 15
PATH=/bin:/usr/bin:/sbin:/usr/sbin
# # Shibboleth 1.3 # SHIB_HOME=/opt/shibbolethSP-1.3 SHIB_ETC=/etc/shibbolethSP
SHIB_CONFIG=$SHIB_ETC/shibboleth.xml
LD_LIBRARY_PATH=$SHIB_HOME/lib
DAEMON=$SHIB_HOME/sbin/shibd NAME=shibd DESC="Shibboleth 1.3 Daemon" test -x $DAEMON || exit 0 set -e case "$1" in start) echo -n "Starting $DESC: $NAME" start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \ --background --make-pidfile \ --exec $DAEMON -- -fc $SHIB_CONFIG echo "." ;; stop) echo -n "Stopping $DESC: $NAME" start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \ --exec $DAEMON echo "." ;; restart) # Restart $0 stop sleep 1 $0 start ;; configtest) echo "Check config for $DESC: $NAME" start-stop-daemon --start \ --exec $DAEMON -- -tc $SHIB_CONFIG echo "Done." ;; *) N=/etc/init.d/$NAME # echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2 echo "Usage: $N {start|stop|restart|configtest}" >&2 exit 1 ;; esac exit 0
The script must be set executable.
91
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Service Provider(SP)
6. At the end only the Shibboleth script must be registered with the update-rc.d tool as a startup script. Updating and starting:
# update-rc.d shibboleth defaults # /etc/init.d/shibboleth start
92
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Chapter 8. WAYF server
On a WAYF server it is possible to choose the home organisation for authentication. This chapter gives an overview about the WAYF server and how it will be installed and configured. 1. What is a WAYF server
The WAYF service can be either outsourced and operated by a federation or deployed as a part of the identity provider. In our case, we outsourced the WAYF Server. It is called moon.shibbolethtesting.org.The WAYF is responsible for allowing a user to associate themself with an specific home organisation. On the WAYF server dave.shibbolethtesting.org of the Shibboleth demonstrator, it is possible to choose between moon.shibbolethtesting.org and sun.shibbolethtesting.org. After the choice, the WAYF server redirects the user to the known address of the identity provider of the institution. 2. Installation of the WAYF server
The Installation of the WAYF server is easy. For this purpose a running Tomcat installation and the Shibboleth identity provider sources are needed. The installation and configuration of the Tomcat is explained in the identity provider chapter.
To setup the WAYF server, the sources from the identity provider installation (see section identity provider) can be taken. To build the WAYF war file, it is necessary to change into the Shibboleth IdP sources directory and run the Ant skript with the correct parameter.
# cd /opt/Packagaes/shibboleth-idp-1.3c-install # ./ant shibboleth-wayf
The war file for the WAY server is now builded and located in the directory: /opt/Pack- ages/shibboleth-idp-install .The war file should be copied into the webapps directory of Tomcat, where it will be deployed.
# cd /opt/Packagaes/shibboleth-idp-1.3c-install/dist # cp shibboleth-wayf.war /opt/shibbolethIDP-1.3/apache-tomcat-5.5.12/webapps/
After a sucessfull installation of the war archive, the WAYF server has to be configured. 3. Configuration of the WAYF server
The configuration of the WAYF server has to be done in two files. These two files are:
• wayfconfig.xml - located in /opt/shibbolethIDP/apache-tomcat- 5.5.12/webapps/shibboleth-wayf/WEB-INF/classes/conf
93
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ WAYF server
• sites.xml - located in /opt/shibbolethIDP/apache-tomcat- 5.5.12/webapps/shibboleth-wayf/WEB-INF/classes/conf
The code listing below shows the file wayfconfig.xml . Only minimal configuration like cacheType and cacheExpiration can be done. For our purpose it was not necessary to change any value.
In order to fulfill the request for a web resource you have just attempted to access, information must be obtained from your identify provider. Please select the provider with which you are affiliated. No provider was found that matches your search criteria, please try again.
Institution University State School
The second code listing for configuration of the WAYF server is the important one. There, the different service providers will be defined.
For each service provider a OriginSite tag is needed. As name, the providerId from the specific service provider has to be taken.The handle service (the place where the authentication happens) and the attribute authority (releases attributes of an authenticated person) should contain the corresponding urn's (the urn's are available in the idp.xml file of the identity pro- viders).
Identity Provider Moon shibbolethtesting.org Identity Provider Sun 94
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ WAYF server
Name="sun.shibbolethtesting.org">
shibbolethtesting.org
95
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Chapter 9. Certificates
The communication to the web ressources and the Shibboleth servers are protected through SSL. For this purpose keys and certificates are created. This chapter describes and explaines this process. 1. Keys and certificates 1.1. Identity Provider
• XML signing keypair for SAML services - /etc/tomcat/moon.shibbolethtest- ing.org.jks , /etc/tomcat/sun.shibbolethtesting.org.jks
This key is defined in the credential section of the "idp.xml" file and has to be trusted by the Service Provider. The key is used to sign the XML handles which are exchanged between the Identity Provider and the Service Provider.
• SSL server keypair for SAML services - /etc/tomcat/moon2.shibbolethtest- ing.org.jks , /etc/tomcat/sun2.shibbolethtesting.org.jks , /etc/tomcat/truststore.jks
This is used to authenticate the SAML "listener" that handles HTTP connections and SOAP messages from service providers. The key is used to authenticate the Attribute Authority and also has to be trusted by the Service Provider.
• SSL server keypair for browser facing services - /etc/tomcat/moon.shibboletht- esting.org.jks , /etc/tomcat/sun.shibbolethtesting.org.jks , /etc/tomcat/truststore2.jks
Shibboleth expects users to login in a way before issuing assertions to service providers. Normally this is done with SSL. This use of SSL is not part of Shibboleth and you are free to use any keypair you wish. Often a commercial certificate is used to prevent browser warnings. Since this keypair may not be trusted by ServiceProviders, the HandleService and the Attribute Authority are often running with different keypairs using a different address or port. 1.2. Service Provider
• SSL client keypair for SAML services - /etc/tomcat/carolClient.crt , /etc/tomcat/carolClient.key , /etc/tomcat/winnetouClient.crt , /etc/tomcat/winnetouClient.key
This key is defined in the credential section of the "shibboleth.xml" file and has to be trusted by the Attribute Authority. The key is used to sign the SOAP messages which are exchanged between the Attribue Authority and the Service Provider. Warning
For the SAML service on the service providers it is important to create in TinyCA a client certificate, not a server certificate. If you choose a server certificate in TinyCA the client authentication of the Service Provider at the Identity Provider will fail.
96
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Certificates
• XML signing keypair for SAML requests
This is an untested and unused feature of the Shibboleth application, which could sign the SAML messages. This feature is less used because SSL is much faster than signing due to the session caching provided by most SSL libraries.
• SSL server keypair for browser facing services - /etc/tomcat/carol.crt , /etc/tomcat/carol.key , /etc/tomcat/winnetou.crt , /etc/tomcat/win- netou.key
The SAML profiles that Shibboleth is based on assumes that service providers use SSL. It is strongly recommend use SSL across all web sites because Shibboleth sessions are ultimately based on HTTP cookies. Stealing cookies is much easier if they travel over an unsecure con- nection. The strongest authentication technology in the world is reduced to a simple cookie. 2. Creating certificates and keystore 2.1. Creating Java keystore
Create an empty Java keystore:
$ keytool -genkey -alias a -keystore www.example.edu.jks Enter keystore password: KEYSTOREPASS What is your first and last name? [Unknown]: What is the name of your organizational unit? [Unknown]: What is the name of your organization? [Unknown]: What is the name of your City or Locality? [Unknown]: What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct? [no]: yes Enter key password for (RETURN if same as keystore password):
$ keytool -delete -alias a -keystore www.example.edu.jks Enter keystore password: KEYSTOREPASS
2.2. Java keystore with trusted CA certificates (Truststore)
Import CA root certificates into keystore (truststore):
$ keytool -import -trustcacerts -alias shibbolethtestingrootca \ -file shibbolethtestingrootca.crt -keystore truststore.jks
97
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Certificates
Omitting the -keystore option adds the CA certificates to Java's default certificate store (/opt/java/jre/lib/security/cacerts). 2.3. Creating certificates with TinyCA
TinyCA 1 is a simple graphical userinterface written in Perl/Gtk to manage a small CA (Certific- ation Authority). TinyCA works as a frontend for openssl. We where using the actual version 0.7.0.
1. First a new CA (Certificate Authority) has to be created:
Figure 9.1. Creating a Root CA
2. The individual certificates for each host have to be created. For the Shibboleth certificate based authentication on sun.shibbolethtesting.org, the common name of the browser certificate has to be equal with the uid in the LDAP directory.
1 TinyCA http://tinyca.sm-zone.net/ [http://tinyca.sm-zone.net/]
98
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Certificates
Figure 9.2. Creating a host certificate
3. The host certificates have to be signed by the root CA.
Figure 9.3. Requests for signing the certificates.
4. Exporting the certificates in the PKCS#12 format.
99
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Certificates
Figure 9.4. Exporting the certificates.
2.4. Create keystores
The created certificates must be filled in the keystore. We were using "Portecle" 2 because on the commandline java keystore, no PKCS12 import was allowed. Portecle is a GUI application for creating and managing keystores, keys and certificates. The recent version we were using was 1.1.
1. First the key pair is imported.
2 Portecle http://portecle.sourceforge.net/ [http://portecle.sourceforge.net/]
100
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Certificates
Figure 9.5. Importing the key pair
2. Then saving as a keystore.
Figure 9.6. Exporting the keystore.
101
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Appendix A. Timetable
Beneath the timetable for the Shibboleth demonstrator project. Some notes will follow at the end of the timetable.
Week Date Tasks Comments 1 24.10 - 30.10 Understand the prob- Completed lem domain 2 31.10 - 06.11 Setting up the host ae military service, system completed 3 07.11 - 13.11 Setting up the virtual ae military service, hosts completed 4 14.11 - 20.11 Shibboleth installation ae military service 5 21.11 - 27.11 sp(carol) configuration 6 28.11 - 04.12 sp(carol), wayf(dave) configuration 7 05.12 - 11.12 idp(moon), ldap config- uration 8 12.12 - 18.12 idp(moon) configura- tion 9 19.12 - 25.12 idp(sun), sp(winnetou) configuration 10 09.01 - 15.01 uml startup scripts, fine tuning 11 16.01 - 22.01 Tomcat problem, docu- mentation 12 23.01 - 29.01 Tomcat problem, docu- mentation 13 30.01 - 05.02 documentation, lab preparation 14 06.02 - 10.02 design documentation
Table A.1. Timetable
For the periode of 24.10 - 18.12 their were no severe problems, the work was according done to the timetable. After this a problem with the client authenticatin for the SP on Tomcat arised. At the beginning of this problem we had no idea what the proper solution was. So we fixed the problem with a hack, whereby the whole Shibboleth demonstrator was running succesfully.
In the following week we gave our concentration to the fine tuning of the uml startup scripts.
After a meeting with our tutor it turned out, we should fix the Tomcat problem properly. So we gave our concentration again to this topic, which we fixed after two weeks of posting in mailinglists and searching in the internet.
Because we planned a reserve in the timetable we had not strive, through the Tomcat problem, to finish our work in time.
102
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Appendix B. Empiric report 1. Joël Stillhart
At the beginning, I didn't know what Shibboleth was and how it works. My goal was to realize a project which covers linux. But because I have experience with linux, apache, tomcat etc. the focus of my interesting referred on Shibboleth. Shibboleth is a sophisticated and complex software. For me the most difficult thing was to keep the overview and to know how the different components work. So after this studie I think I have learned a lot about Shibboleth and it's components.
Another challenge was to write the documentation with docbook, for me docbook was a new and extensive topic with many application possibilities. I think in the team we fulfilled this challenge to our satisfaction.
At the end, I want to thank the other group members Andreas and Armin for their work. For me it was always joyfully to work with them. At this time I also thank our professor and his as- sistant for their great support and sacrificed time. 2. Andreas Eigenmann
It was my desire to make a research paper based on Linux, and Shibboleth looked to be a very promising software, which is used in the practice. Since Shibboleth is a quite complex software and I never heard something about it before, I had to get deeper in quite a lot of topics. We could, however, go back to a very good documentation from switch and Internet2. Many prob- lems could be solved with the support of the great and big Shibboleth community, which support us on the mailing list with tips and tricks. This is a very big advantage of Open Source projects.
I think I have studied a lot from this subject and I am capable of carrying out such a project in the practice now.
We decided to use the professional Docbook for the documentation which was adopted by the open source community, where it has become a de facto standard. We noticed very fast, that it is a very fueature rich but flexible markup language. The biggest problem was to find a good editor, which meets our requirements. In future, I intend to document my work with it too.
Our team harmonized very well since we have already solved some smaller projects together. I would like to thank Joël and Armin for their great work here. I would also like to thank our professor and his assitant for their continuous support. 3. Armin Thommen
The Shibboleth installation was a complete different work, compared to the other projects we had at the HSR. For me it was quite more exciting because we had to go deeper in quite a lot of topics, like User Mode Linux, certificates and so on. Because Shibboleth is a sophisticated and complex software it was not always easy to keep the overview. Also the documentation with "Docbook" was a great challenge. After finishing the biggest part of the documentation I also learned, that until now there exists no perfect documentation solution! To decison to write the documentation in English was a big challenge, which I personally underestimated.
103
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Empiric report
In our team we always had fun and for me it was a pleasure to work with Joël and Andreas. At this time I would like also thank our tutor and his assitant. The collaboration with them was always respectful and constructiv.
Locking back at the past three month I woukd like to say that I learned a lot and I improved my Linux skills very much... So much that I use now Linux on a regular base for my daily work.
104
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Bibliography Websites
[1] Official Guide of Shibboleth IDP. http://shibboleth.internet2.edu/guides/idp/ .
[2] Official guide of Shibboleth SP. http://shibboleth.internet2.edu/guides/sp/ .
[3] Internet2 Shibboleth technical overview. http://shibboleth.internet2.edu/docs/draft-mace- shibboleth-tech-overview-latest.pdf .
[4] SWITCHaai. http://www.switch.ch/de/aai/ .
[5] SWITCHaai attribute specification. http://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf .
[6] Shibboleth IdP installation documentation of Switch . http://www.switch.ch/aai/docs/shib- boleth/SWITCH/1.3/idp/install-idp-1.3-debian.html .
[7] Shibboleth SP installation documentation of Switch . http://www.switch.ch/aai/docs/shib- boleth/SWITCH/1.3/sp/install-sp-1.3-debian.html .
[8] ESUP CAS server installation documentation of Switch . http://www.switch.ch/aai/docs/shib- boleth/SWITCH/1.3/idp/install-esupcas.html .
[9] Shibboleth Attribute Authority documentation. http://www.switch.ch/aai/docs/shib- boleth/SWITCH/1.3/ .
[10] Manual about Debian Linux Distribution. http://www.debiananwenderhandbuch.de .
[11] Tomcat Documentation. http://tomcat.apache.org/tomcat-5.5-doc/index.html .
[12] ESUP CAS server documentation. http://esup-casgeneric.sourceforge.net/install.html .
[13] Wikipedia LDAP article. http://en.wikipedia.org/wiki/LDAP .
[14] Wikipedia SOAP article. http://en.wikipedia.org/wiki/SOAP .
[15] Wikipedia SAML article. http://en.wikipedia.org/wiki/SAML .
[16] Wikipedia CAS article. http://en.wikipedia.org/wiki/Central_Authentication_Service .
[17] Wikipedia SSO article. http://en.wikipedia.org/wiki/Single_sign-on . Books
[18] LDAP. System Administration. Gerald Carter. 1-56592-491-6. March 2003. O'Reilly.
[19] DocBook-XML. Einführung und Anwendung. Lars Trieloff. 3-8266-1519-0. 1. Auflage. Copyright © 2005 mitp-Verlag.
105
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Glossary
Where are you from On the WAYF server a user can decide on which identity provider (WAYF) he/she would like to authenticate him/herself.
Service Provider (SP) The component of Shibboleth which is responsible to protect the web application and requests the user attributes. A service pro- vider consits of the following components: attribute requester, assertion consumer service and shibd.
Identity Provider (IdP) The component of Shibboleth which is responsible for the authen- tication of users and the release of user attributes. A identity provider consists of the following components: SSO service, ar- tifact reolution service, attribute authority and authentication au- thority.
Single Sign On (SSO) Single Sign On means a authentication method, where a user can authenticate himself once, and get access to several sys- tems. At an identity provider the SSO is the first point of contact.
Attribute Authority (AA) The attribute authority is a component in an IdP which handles attribute requests from the attribute requester.
Attribute Resolver On attribute request, the attribute resolver gets information from a different source and prepare it for transport with SAML.
Artifact Resolution Service Service on a IdP which sends and receives artifacts instead of an authentication assertion and authentication assertions to a SP's assertion consumer service (ACS).
Artifact An artifact is a reference to an authentication assertion.
Authentication authority The authentication authority is an integrated component of an IdP. It distributes statements of authentication to other compon- ents.
Attribute Requester or Exchanges user attributes with the attribute authority at an Ressource Manager (RM) identity provider.
Assertion consumer ser- The assertion consumer service (on a SP) handles the authen- vices (ACS) tication assertion from the artifact resolution service, initates to get user attributes over the attribute requester from the identity provider and redirects a user to the secured web application.
Shibboleth Daemon Software which implements the Shibboleth SP components. (shibd)
Attribute Acceptance Specifies on a service provider which attributes are accepted Policy (AAP) from which identity providers.
Attribute Release Policy Specifies on a identity provider which attributes are released to (ARP) which service providers.
106
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Glossary
Federation A federation is a group of identity provders and service providers in a network.
Relying Party The relying party would be selected per request. Normally it means the service provider receiving information from the idenity provider.
Lightweight Directory Ac- Network protocol, which permits the inquiry and the modification cess Protocol (LDAP) of information from a directory service.
Central Authentication Single Sign On (SSO) protocol to allow a user through a CAS Service (CAS) client to authenticate himself against a CAS server. A CAS server could handle authentication against different backends like LDAP, SQL Database or Kerberos.
Security Assertion Markup Through SAML, an XML standard, authentication and authoriza- Language (SAML) tion data could be exchanged between a service provider and a identity provider.
Extensible Markup Lan- XML is a markup language which can describe a different sort guage (XML) of data.
SOAP SOAP is a protocol which allows to transport xml messages over a network with https.
User mode Linux (UML) A Software for Linux which makes possible to run several virtual Linux systems on one host Linux System.
Public Key Infrastructure In the Shibbolethdemonstrator context it means client authentic- (PKI) ation on a SSO of a identity provider through browser certificates. swissEduPerson Class for the LDAP which describes attributes in a university field.
107
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/ Colophon
This documentation is written with DocBook 1 version 4.4.The HTML files were generated with Xalan 2 and the FO files with xep from RenderX 3 version 4.5. The PDF's were generated through x4u from RenderX.
Shibboleth the key word in our project has an interesting meaning.Wikipedia explains Shibboleth as follows: ".. Shibboleth refers to words and phrases that can be used in a similar way—to distinguish members of a group from outsiders. The word is also sometimes used in a broader sense to mean specialized jargon, the proper use of which reveals speakers as members of a particular group or subculture." (e.g. Chuchichäschtli)
1 Official Docbook website, www.docbook.org [http://www.docbook.org] 2 Official Xalan website, xml.apache.org/xalan-j/ [http://xml.apache.org/xalan-j/] 3 Official RenderX website, www.renderx.com [http://www.renderx.com/]
108
XML to PDF by RenderX XEP XSL-FO Formatter, visit us at http://www.renderx.com/
