Investigation and Implementation of Shibboleth SSO Authentication Mechanism Through A Specific Scenario'

C
O V E
N T R
U N I V E R S I T Y
Faculty of Engineering and Computing
Investigation and implementation of Shibboleth SSO authentication mechanism through a specific scenario
Author: Gilles Rubens Badouet MSc Network Computing

SID: 3940347
Email:gilles.badouet@gmail.com
Supervisor: Dr. Rahat Iqbal

Submitted in partial fulfilment of the requirements for the Degree of Master of Science Network Computing
Academic Year: 2012/13
2012/2013
Declaration of Originality This project is all my own work and has not been copied in part or in whole from any other source except where duly acknowledged. As such, all use of previously published work (from books, journals, magazines, internet, etc) has been acknowledged within the main report to an entry in the References list.
I agree that an electronic copy of this report may be stored and used for the purposes of plagiarism prevention and detection.
I understand that cheating and plagiarism constitute a breach of University Regulations and will be dealt with accordingly.
Signed: Gilles Rubens Badouet
Date: 26/08/2013
Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013
Page 1 of 125
2012/2013
Page 2 of 125
2012/2013
Abstract
This work titled Investigation and implementation of Shibboleth SSO mechanism through a case scenario presents, discusses, describes and explains the major aspects and concepts of Shibboleth protocol and provides two related prototypes
implementations of the protocol within a set of chosen tools and environments. The implementation relies on the project client specifications and recommendations and therefore follows some imposed deployment infrastructures. The work report first focuses on the research investigation in Shibboleth concepts, its relationship with similar mechanisms and its particularities in the Single Sign On mechanism alongside with its federation principles. It also emphasizes on the SAML (Security Assertion Markup Language), the protocol that Shibboleth implements and on which it relies. The second major part of this report describes step by step the installation, deployment and configurations of Shibboleth in working prototypes within Windows based Operating Systems.
The primary prototype implementation is a sort of initial deployment carried out within a self-defined ad-hoc environment helping to implement the second prototype. Considered in this project as the real time prototype as it has been conducted within the client premises, the second prototype has some similar steps of the primary implementation and is much more complete in terms of applications integrations and the Shibboleth log out mechanism. It also focuses more on the client specifications. The end of this real time prototype provides the integration strategy of 247lib.com/247libDE application. A testing approach is then provided to demonstrate how successful sample of simple applications have been integrated into the implementation. The test illustrates with details description the main use case scenario of authentication through the Shibboleth based single sign on mechanism. The appendix part of this report and the CD bound to the report include the configuration files of the project implementation, the testing data and other project details.
The project report finally discusses the encountered risks and issues faced throughout the project progress alongside with a critical appraisal and recommendations for future works.
Page 3 of 125
2012/2013
Document map and summary view
Page 4 of 125
2012/2013
Table of Contents
Abstract ..................................................................................................................... 3 Document map and summary view ......................................................................... 4 Table of Contents ..................................................................................................... 5 Figures list ................................................................................................................ 8 Acronyms and abbreviations list ............................................................................ 9 Additional Materials on the Accompanying CD ................................................... 10 Acknowledgements ................................................................................................ 11 Chapter 1: Introduction .......................................................................................... 13 1.1 Project definition and context ......................................................................... 13 1.2 Background to the Project ............................................................................... 14 1.3 Project Scope and Objectives ......................................................................... 15
1.3.1 Scope .................................................................................................................15 1.3.2 Objectives ..........................................................................................................17
1.4 Report overview ................................................................................................ 17 Chapter 2: Methodology......................................................................................... 19 2.1 Problem Identification ...................................................................................... 19 2.2 Methodology approach and justification ........................................................ 19 2.3 Overview of the Web SSO mechanism ........................................................... 21
2.3.1 Overview ............................................................................................................21 2.3.2 Web SSO architecture ........................................................................................21 2.3.3 SSO protocols ....................................................................................................22 2.3.4 SSO assets ........................................................................................................23
2.4 Major aspects of SAML protocol and SSO use case ..................................... 24
2.4.1 Definition and overview ......................................................................................24 2.4.2 SAML basic use case .........................................................................................25 2.4.3 SAML other use case scenarios .........................................................................26 2.4.4 SAML architecture ..............................................................................................26 2.4.5 SAML Components structures ...........................................................................29 2.4.6 SAML Security and Privacy aspect .....................................................................31 2.4.7 SAML benefits ....................................................................................................33
2.5 Shibboleth as an implementation framework of SAML ................................. 33

2.5.1 Shibboleth architecture and components ............................................................34 2.5.2 Overview of the web SSO steps with Shibboleth ................................................36
2.6 Web application 247lib.com/247libDE............................................................. 40 Chapter 3: Literature Review and related works.................................................. 42 3.1 Introduction....................................................................................................... 42 3.2 Web SSO protocols .......................................................................................... 42
Page 5 of 125
2012/2013
3.3 The use of SAML .............................................................................................. 43 3.4 Application of Shibboleth ................................................................................ 45 3.5 Gap and contribution ....................................................................................... 47 Chapter 4: Implementation requirements ............................................................. 48 4.1 Requirements gathering procedure ................................................................ 48 4.2 Requirements table .......................................................................................... 50 Chapter 5: System analysis and design ............................................................... 52 5.1 System overview .............................................................................................. 52 5.2 Use case modelling diagram ........................................................................... 53 5.3 System architecture ......................................................................................... 54
5.3.1 Primary prototype architecture ............................................................................54 5.3.2 Real time prototype architecture .........................................................................57
5.4 Human- Computer Interface ............................................................................ 59 Chapter 6: Implementation .................................................................................... 60 6.1 Primary implementation ................................................................................... 61
6.1.1 Installation and deployment of Shibboleth Service Provider................................61 6.1.2 Installation and deployment of Shibboleth Identity Provider ................................64 6.1.3 Network access, FQDN and addresses binding ..................................................70 6.1.4 Further configuration of the Service Provider ......................................................74 6.1.5 Further configuration of the Identity Provider ......................................................76 6.1.6 Integration of a simple html resource to Shibboleth and sign on test ..................82
6.2 Real time implementation ................................................................................ 84

6.2.1 Installation and deployment of Shibboleth Service Provider................................85 6.2.2 Installation and deployment of Shibboleth Identity Provider ................................86 6.2.3 Specification of the used domain, IP addresses and hostnames ........................86 6.2.4 Configuration of the Service Provider .................................................................87 6.2.5 Configuration of the Identity Provider ..................................................................88 6.2.6 Integration of many protected resources to Shibboleth, SSO & logout tests .......91
Chapter 7: Testing .................................................................................................. 96 7.1 Testing strategy ................................................................................................ 96 7.2 Testing area, stakeholders and environment................................................. 97 Chapter 8: Project Management .......................................................................... 103 8.1 Project Schedule and adjustment ................................................................. 103 8.2 Risk Management and issues........................................................................ 104
8.2.1 Risk analysis techniques ..................................................................................105 8.2.2 Risks list, assessment and mitigation strategy ..................................................105
8.3 Other management issues and countermeasures ....................................... 107

8.3.1 Primary implementation issues faced and solutions..........................................107 8.3.2 Real time implementation issues faced and solutions .......................................110
8.4 Quality Management....................................................................................... 111
Page 6 of 125
2012/2013
Chapter 9: Critical Appraisal ............................................................................... 113 9.1 Experience and knowledge gained ............................................................... 113 9.2 Interesting and difficult aspects of the project ............................................ 115 9.3 Project outcomes ........................................................................................... 116 9.4 Conclusion from the experiences ................................................................. 116 9.5 Case study relation to my course ................................................................. 117 Chapter 10: Conclusions ..................................................................................... 118 10.1 Achievements ............................................................................................... 118 10.2 Future Work .................................................................................................. 119 Chapter 11: Student Reflections ......................................................................... 120 Bibliography and References .............................................................................. 121 Appendix A Project proposal and Specifications ...... AErreur ! Signet non dfini. Appendix B Configuration files of the primary prototype implementation .... A1 Appendix C Configuration files of the real time prototype implementation ... A1 Appendix D Latest Implementation testing data and logs ............................. A27 Appendix E Interim Progress Report and Meeting Record .. AErreur ! Signet non dfini. Appendix F Progress and discussions notes with the project client ... AErreur ! Signet non dfini.
Page 7 of 125
2012/2013
Figures list
Figure 1: Methodology approach.20 Figure 2: Simplified Web SSO architecture...22 Figure 3: SAML Basic use case...25 Figure 4: SAML structure..27 Figure 5: Simplified example of a Subject, Assertion and Statement Structure...30 Figure 6: Simplified structure of an attribute..31 Figure 7: IdP components structure34 Figure 8: SSO sequence diagram38 Figure 9: Shibboleth profile...40 Figure 10: 247lib.com/247libDE existing interface41 Figure 11: requirements table..51 Figure 12: System High-level context diagram..53 Figure 13: System Use Case diagram54 Figure 14: Physical structure of the primary prototype.55 Figure 15: Logical structure of the primary. ..57 Figure 16: Logical structure of the real time prototype.58 Figure 17: IIS 7 required services setting...62 Figure 18: Installation of SP settings...63 Figure 19: Configuration of JAVA_HOME variables.65 Figure 20: Tomcat 6 home page access66 Figure 21: JAVA_OPTS variable setting on Tomcat66 Figure 22: SSL certificate deployment on Tomcat68 Figure 23: IdP installation..69 Figure 24: IP addresses, hostnames and ports assignment...70 Figure 25: Hostname resolution test71 Figure 26: IP addresses and hostnames binding on IIS..72 Figure 27: IP addresses and hostnames binding and resolution within the network..73 Figure 28: Shibboleth2.xml configuration overview..75 Figure 29: LDAP Server installation and settings.79 Figure 30: LDAP Server installation review80 Figure 31: Simple login/authentication test83 Figure 32: Network parameters assignment for the real time implementation.86 Figure 33: Shibboleth2.xml configuration for the real time prototype implementation87 Figure 34: Multiples resources view93 Figure 35: ANS-IdP login portal98 Figure 36: User access denied by IdP view...99 Figure 37: User access to resources granted by IdP.100 Figure 38: Access to about_247lib.html resource..100 Figure 39: Access to server_variables_user_attributes.aspx resource...100 Figure 40: Example of user access attributes and Shibboleth session parameters..101 Figure 41: IdP log out portal...101 Figure 42: Risks assessment of the project management 107 Figure 43: Primary prototype implementation issues and solutions.110 Figure 44: Real time prototype implementation issues and solutions.111
Page 8 of 125
2012/2013
Acronyms and abbreviations list

AD: Active Directory ADFS: Active Directory Federation Services ANS Ltd: Applied Network Solutions Limited CAA: Central Authentication Service CD: Compact Disk CN: Common Name CSR: Certificate Signing Request DC: Domain Component DN: Distinguished Name DNS: Domain Name System DS: Discovery Service FQHN: Full Qualified Hostname HTTP: Hypertext Transfer Protocol HTTPD: Hypertext Transfer Protocol Daemon HTTPS: Hypertext Transfer Protocol Secure IdP: Identity Provider IEEE: Institute of Electrical and Electronics Engineers IIS: Internet Information Services IP: Internet Protocol ISO: International Organisation for Standardization IT: Information Technology JAAS: Java Authentication and Authorization Service JISC: Joint Information Systems Committee LDAP: Lightweight Directory Access Protocol LDAPS: Lightweight Directory Access Protocol Secure LDIF: LDAP Data Interchange Format OASIS: Organization for the Advancement of Structured Information Standards OS: Operating System POST: Power-on self-test RPC: Remote Procedure Call SAML: Security Assertion Mark-up Language SIP: Session Initiation Protocol SLO: Single Log Out SN: Surname SOAP: Simple Object Access Protocol SP: Service Provider SSO: Single Sign On SSL: Secure Shell VoIP: Voice over Internet Protocol XML: Extensible Mark-up Language
Page 9 of 125
2012/2013
Additional Materials on the Accompanying CD

Below is the list of materials on the accompanying CD provided to Coventry University on the margin of the project requirements and assessment. Among the below listed considered as appendixes in this report; only the configurations files contents are included in the actual report.
Project proposal and specifications Configuration files of the primary prototype implementation Configuration files of the real time prototype implementation Latest implementation testing data and logs Interim Progress Report and Meeting Records Progress and discussions notes with the project client
Page 10 of 125
2012/2013
Acknowledgements
If I have seen farther it is by standing on the shoulders of giants (Newton, I, 1676). I am very far away to having seen as far as Isaac Newton. However, I do have my giants to whom I would like to express my greatest thanks for their help and contribution for the accomplishment of this work.
My sincere thanks are addressed to:
My Supervisor Dr Rahat Iqbal for his assistance and good advices brought to me in this project.
The project client (ANS Ltd), especially David Johnston for the project proposal and for the support during the project progress.
Coventry University staff for their assistance
Peter Schober, Cantor Scott and all other Shibboleth mailing list and forums users who provided me with strong and helpful online assistance in regard to Shibboleth understanding, installation, deployment and troubleshooting.
IIS, OpenDJ, ASP .NET and Tomcat mailing list and forums users for their help during the deployment of those tools.
All my family, close and friends who supported me throughout this project, especially my Mother, my Father and my beloved Martine Fernande Njouakeu for their day to day motivation and assistance.
Page 11 of 125
2012/2013
Page 12 of 125
2012/2013
Chapter 1: Introduction
1.1 Project definition and context
The management of access to online resources has always been an issue to be dealt with within institutions and companies. That issue particularly crucial in that concerns shared resources generally resides on the security mechanisms and protocols to be used for services and resources access, mostly when it comes to the federation of several organisations and institutions since there is a strong growing interest in resources sharing, interactions and collaboration within business and academic areas. With the enhancement of web services and other application types, users still face considerable issues for simple, quick and safe access resources. The major question is how access to a variety of services and resources can be managed appropriately in an institution and within federated organisations without compromising the users privacy and information security. Sometimes users also need to access services or applications through a single sign on mechanism that is not always easy to implement whether locally or externally (Erdos, M and Cantor, S, 2002).
Shibboleth, the central point of this project is one of the most wanted and requested middleware used in World Wide Web infrastructures or environments to protect online resources from being accessed by illegitimate users. One of its major aspects is the implementation of the single sign on mechanism through a high level protocol called SAML (Security Assertion Mar-up Language). Because Shibboleth is an open source infrastructure platform, flexible and very powerful, it is becoming very popular and demanded across universities, colleges, research centres, banks, other business areas and more. In order to implement such an infrastructure, an organisation can either do so through a high trained IT department or outsourced to an IT services provider specialised in related projects. ANS (Applied Network Solutions) is an IT company that provides among others web applications solutions, deployment consultancy on innovative and integrations infrastructure platforms within organisations, institutions and other companies. Its main service is the library access management. However, ANS does not yet provide such a service through a single sign on mechanism such as Shibboleth for access to its library applications, neither deliver any expertise in Shibboleth implementation for customers needing Shibboleth. This project is about
Page 13 of 125
2012/2013
providing ANS with a strategy sketch of understanding and implementing Shibboleth on a basis of their specifications provided.
1.2 Background to the Project

Rahul Deshmukh (n.d.) from Kansas State University stated that Shibboleth is a kind of linguistic password that identifies one as a member of a group. According to the history, two Semitic tribes, the Ephraimites and the Gileadites, have a great battle. The Gileadites defeat the Ephraimites, and set up a blockade to catch the fleeing Ephraimites. The Gileadite sentries ask each person to say the word shibboleth. The Ephraimites, who have no sh sound in their language, pronounced the word with an s and were thereby unmasked as the enemy and slaughtered. Thus, a person who
violates a shibboleth can be rapidly identified as an outsider and immediately excluded from the group. In the English language the word Shibboleth means an arbitrary test or custom that distinguishes one group from another, or a word or slogan identified with a particular group or party.
Institutions, organisations and academia have been using various solutions in order to manage online shared resources since earliest years where resources and services started to be available online. Amongst those solutions Athens, Kerberos and more are some of them that present some alternatives. The question of a flexible, opened, reliable and even free solution that properly deals with users privacy, information security while providing a single sign on authentication mechanism within and across boundaries has always been raised. Now, Shibboleth, a trademark of Internet 2 (a USA network consortium driven by members from education, industries, government and research communities around the world) is an infrastructure- based solution and an open standard designed to fulfil the above requirements. Shibboleth is emerging and moving fast in the form of the SAML implementation that is a security protocol from the Organization for the Advancement of Structured Information Standards (OASIS). Shibboleth implements the SAML protocol through a set of open software applications (John Paschoud 2004).
ANS (Applied Network Solutions) is an IT Support company founded in 1990 that supplies IT business solutions, especially the library management systems. ANS provides among others the following services: web applications, deployment
Page 14 of 125
2012/2013
consultancy on innovative and integrations infrastructure platforms within organisations, MS windows solutions, online library services and more (Applied Network Solutions, 2013).
One of the major ANS products is 247lib.com/247libDE, a library management platform providing a robust web browser based interface to its applications access. Those applications are available for Universities, Government, Colleges, Corporate, Health Centres and many other institutions and include resources allowing the management of the following applications or services: Reports, Catalogue, Orders, Survey, Finance, Stock Items, Authorities, Borrowers, Circulation, Bookings, Periodicals and Enquiries. ANS does not yet provide access to those services via a single sign on mechanism in such a way that a tiers company who subscribed to many services is able to access them using a single username and a single password (Applied Network Solutions, 2013).
Furthermore, ANS would also like to include in the variety of its services the consultancy and the outsourcing of the single sign on mechanism implementation, notably through Shibboleth.
1.3 Project Scope and Objectives

1.3.1 Scope Scope description It is very important to precise that this project output will be a working prototype using appropriate tools. However, this is not directly intended for any commercial exploitation since further parameters need to be taken into account when it will come to apply the product in commercialisation integration. Of course ANS Ltd and any authorised user could make use of the project result and apply it to a real integration once they will meet all the technical and non technical conditions and requirements to do so. The features of this work cover all the major research aspects required to carry out the project. The paper also introduces further use of Shibboleth technology.
Page 15 of 125
2012/2013
Although the first part of this project based on the Shibboleth investigation covers all the major aspects and products used to deploy fully Shibboleth, the implementation part deals only with the products necessary for this project on a basis of the client specification. Those Shibboleth products include Service Provider and Identity Provider.
Project delimitation and exclusion This paper cannot afford to cover all the aspects of Shibboleth up to date since Shibboleth itself is a very wide project that keeps moving over the time. Instead the paper presents in depth the major concepts that Shibboleth uses and the way they work. The paper does not provide advanced concepts of the SAML protocol and other related technologies in general. Instead, it presents the SAML as Shibboleth relying protocol. The report does not claim to solve all the issues related to other Shibbolethbased projects, but should be considered as a contribution to other works and some awareness on the single sign mechanism based on Shibboleth. Although some steps of the implementation can be common to all the operating systems types, the essential operating system environment that this project addresses is Microsoft windows based. This implementation is far to be the only process to follow if one wants to implement Shibboleth over Windows based operating systems since there are many other techniques depending on the expertise level and other specifications. Although Apache Tomcat 6 is used on this implementation, the real tool to be considered as web server is IIS 7. Tomcat 6 is used just as servlets container. People willing to use this Shibboleth process implementation will face some issues if they dont follow everything step by step by also making sure that all the errors and problems from one step are solved before moving to the next step. Partial tests proving that the implementation is in the good process are provided with related successful messages. Some issues can also be encountered if one used other tools versions than those used in this project. All the concepts and terms used in this project are web- based.
Page 16 of 125
2012/2013
Assumption This report assumes the following statement: Anyone willing to exploit the content has a minimum understanding in network and especially in web-based protocols such a HTTP, HTTPS, HTTPD, XML and SSL. The ANS web platform works properly since the project does not deal with ANS web applications apart from showing how to get them (particularly 247lib.com/247libDE)
communicating with Shibboleth implementation, in other words their integration to Shibboleth. ANS web applications are ASP .Net platform based and thereby, the application of this project for other platforms may require various modifications depending on the level of compatibility aspects.
1.3.2 Objectives The aim of this project consists of two major parts: The first part aims to carry out a clear investigation by presenting a coherent description of Shibboleth protocol as a single sign on mechanism currently very demanded to address multiple web applications and services authentication. The second part has a purpose to lead and deliver an implementation strategy of Shibboleth through ANS web applications platform 247lib.com/247libDE that comprises sub- applications such as Survey, Finance, Stock items and so on. That implementation approach is driven by technical and practical experimentations via appropriate environment tools that will be presented throughout this paper. Thus an authorised user, via a web browser, will be provided authentication and identification by Shibboleth before accessing a sample of defined web applications. The strategy of implementing the testing applications will be provided for the integration of 247lib.com/247libDE, including some particularities. Therefore, at the end of the implementation, a defined and authorised user should be able to access testing applications through a single sign on mechanism that is without the need to provide access parameters for each application.
1.4 Report overview

This project first of all consists of investing and describing major Shibboleth concepts and its functioning architecture. Afterwards is followed the implementation strategy through a suitable experimentation environment. Due to the specifications of the project client, the implementation is mostly windows- based environment. components and points that this project report covers are the followings:
The main
Page 17 of 125
2012/2013
A research methodology A literature review and related works The requirements of the project implementation The Implementation analysis and design The prototype implementation The implementation test The project management A critical Appraisal Conclusions Student reflections
There are mainly three intended audiences for this document: Simple readers who want to have an idea of Shibboleth and the SAML protocol, technically-minded readers who would like to get a further idea about the implementation of the SAML protocol via Shibboleth and finally people who want to understand in depth Shibboleth and one of the means of implementing its components over web servers. Thereby, this content starts by providing from a basic understanding of the Shibboleth to its implementation steps.
Page 18 of 125
2012/2013
Chapter 2: Methodology
In order to come up with a solution to the set objectives in this project, the problem that the project description raises has to be identified and an approach of investigation and resolution methodology has to be defined.
2.1 Problem Identification

Currently, there are several identity and access management mechanisms across the web. Most part of them provides standard access mechanisms to shared resources and applications. Standard because if a user needs to access a set of given applications, they have to provide each time their credentials. A minority of them provides a single sign on mechanism to access applications. Currently one of the most powerful and most demanded single sign mechanisms which is object to this project is Shibboleth. The company client to this project (ANS) is limited to a standard mechanism to permit their customers to access their applications. That means, currently, a customer must always provide their credentials for each application they want to access, in other words they cannot access at the same time several applications within the same session and with same credentials (username/ password). Moreover, Some ANS customers such as Universities and Colleges are continuously requesting for Shibboleth implementation within their networks to allow Shibboleth-based authentication within their internal and external applications, but ANS does not yet have a Shibboleth expertise to provide such an implementation. In the context of federation within institutions and organisations in partnership where Shibboleth is the authentication mechanism for access to shared resources ANS also needs to adopt Shibboleth to extend their business.
The fundamental question in this project is therefore to investigate and provide an appropriate analysis and description about Shibboleth, emphasizing in the context of the client specifications, to provide the client with a Shibboleth implementation strategy including the integration of applications examples (in working prototype) and to define an integration strategy of 247lib.com/247libDE.
2.2 Methodology approach and justification

As this project conduct goes from a general concept of web access management within shared resources to a specific scenario that is the use case, the investigation,
Page 19 of 125
2012/2013
application strategy and methods used in this work is a user-defined methodology that aims first of all to conduct a research on the project related protocols and related works in order to farther understand the project context and therefore provide an implementation in a working prototype, on a basis of the client recommendations and the project specifications.
The reason of choosing the above methodology approach resides on the fact that this work is not totally a research defined project, nor a software or an application development, neither a survey project. Instead, this project is about a research and investigation around a protocol or technology (Shibboleth) and its application at a certain level within a defined environment. Thereby, the research, analysis and implementation methodology has to be specific and appropriate to the use case scenario. That is going from a general understanding of the single sign on mechanism, through Shibboleth and related technologies till the implementation of what has been previously investigated and described.
This methodology approach is to be achieved following the examination of the components below that need to be discussed in order to understand how Shibboleth works, analyse and understand the project specifications and requirements and therefore apply Shibboleth on the use case implementation. The diagram below
illustrates that methodology approach including the steps to be dealt with to complete this work.
Figure 1: Methodology approach
Page 20 of 125
2012/2013
The Shibboleth protocol and other relying technologies constituting the first step of this methodology will first be discussed in this current chapter. The Literature review and related works, Implementation requirements, System analysis and design, Testing and management will be discussed within different chapters.
Regarding the protocols investigation stage, the following components are to be developed: Overview of the SSO mechanism Major aspects of SAML protocol and SSO use case Shibboleth as an implementation framework of SAML Web application 247lib.com/247libDE
2.3 Overview of the Web SSO mechanism

2.3.1 Overview Actually, a lot of web applications in the same system or same organisation still requires users to register every time they want to use an individual application. The proliferation of web applications and services has led to conclude that it is impracticable and irrelevant to require users to remember several accounts (usernames and passwords) for all the applications they want to get access. It has become therefore very tough to manage credentials in such a situation of the environment of web access management. Web single sign on (SSO) protocols allow users to make use of a single password and username to get access to several and different applications or services.
2.3.2 Web SSO architecture There are four main actors interacting in an SSO mechanism: the user, the SSO server or authentication server, the SSO agent or authentication agent and the application(s). The figure below, illustrates their architectural positions.
Page 21 of 125
2012/2013
Figure 2: Simplified Web SSO architecture The SSO server is the central entity in the SSO system since its stores centralized credentials and ensures the user authentication, the link establishment between the user and other elements and the user identity propagation towards applications.
The mechanism starts when a user provides its authentication parameters to the SSO server. The server verifies those parameters and authenticates the user if the parameters match with any stored credentials or certificates. When the user has been authenticated, the server keeps maintaining the user session by setting up an HTTP cookie in the user host. The cookie data are protected and are the way of identifying the user for any future server access.
The user agent is generally integrated to the targeted application as a library or an apache or IIS module. The user agent verifies that the user is effectively authenticated that is authorised to access an application; otherwise, the user request is re- forwarded to the SSO server. If the user has been authenticated, the agent verifies again the data source and transmits them to the targeted application and connects the user to the application.
2.3.3 SSO protocols This section presents brief descriptions of some main protocols that implement the single sign on principle.
Page 22 of 125
2012/2013
Kerberos Network Authentication Service: The Kerberos protocol, owned by the MIT (Massachusetts Institute of Technology), provides an authentication service where every entity that can be a server or a client is a user to the Kerberos service and trusts Kerberos judgement of its peers party. Kerberos makes use of a shared secret key encryption in which a user password is considered like the secret key (Sandhu, S, S, 2004).
SESAME: The Secure European System for Applications in a Multi-vendor Environment is quite similar to Kerberos in terms of design, but better improves the concept of secret key protection and distribution (Sandhu, S, S, 2004).
OpenID SSO: This protocol provides a decentralized architecture that exploits existing domain names server (DNS) service in a network. The assignment of users identifiers is based on their domain names. When a user tries to access a shared resource or applications, they provide their opened ID that has been assigned to them according to their domain name. One of the most current implementation of the OpenID protocol is Microsoft identity management software (MIMS) (James, S, 2007).
SAML: Under the Organization for Advancement of Structured Information Standards (OASIS), the Security Services Technical Committee (SSTC) developed the SAML (Secure Assertion Mark-up Language). SAML is a web security protocol based on the XML (Extended Mark-up Language) architecture and implements many security mechanisms within web domains across the internet. One of its keys aspects is users authentication and authorisation through techniques such as single sign on (James, S, 2007).
The Secure Assertion Mark-up Language protocol is the one that constitutes the core protocol of this report as one of its major implementations is Shibboleth, central point of this project. SAML will be more described in another section of this paper.
2.3.4 SSO assets The implementation of the SSO provides the following advantages to a company: Time saving: A user can make about twenty seconds average to log onto an
application and even longer if they make a mistake when typing account parameters and are required to re-type them. The higher the number of applications to access, the lower is the time saving in that case. By implementing
Page 23 of 125
2012/2013
the single sign on, there is a real benefit of time saving even when there is a mistake while typing access parameters; that therefore highly increases the company productivity. Administrative costs reduction: Few passwords to manage reduce the
complexity of the administrators task, since fewer requests will be received from the users asking for the reset of forgotten passwords. Security enhancement: The security policy is simpler to manage within and
across organisations. Furthermore, all the applications guaranty the same level of security. User adoption enhancement: As users do not need to provide different
access credentials for different resources access, users better adopt applications following a standard basis.
2.4 Major aspects of SAML protocol and SSO use case

2.4.1 Definition and overview The Security Assertion Mark- up Language is an XML language defines a framework standard and format for a high security level in information exchange within web applications owned by partners in a business (OASIS, 2008).
SAML doesnt aim to specify new cryptography techniques or model of security; it rather focuses and describes standard security technologies in industry through XML based format syntax and relying on the web protocols such as HTTP, HTTPS, SSL and so on. Moreover, a business agreement defining the terms of a partnership must be made among tiers to set up a trusted environment before and where SAML will be applied since SAML itself does not automatically define a data format for safe information exchange and authorisation policy, but it is the security systems in charge of authentication, identification and authorisation that should define policies and formats within organisations in partnership. So, a real detailed definition of SAML must be based on use cases even though there is a basic and common use case that illustrates a user getting access to protected resources (Netegrity, Inc, 2001).
This section provides technical details of SAML, focusing more on its latest version SAML 2.0, key aspect to understanding Shibboleth (which is one of its implementation) in the next section.
Page 24 of 125
2012/2013
2.4.2 SAML basic use case As stated above, SAML utilization varies according to uses cases and companies are free to define their own use cases based on their needs. However, the most common use case presents users attempting to access protected applications and services as shown on the figure 3 below.
Authentication
SAML
Authirisation
c Protected resource
Authentication Authority
Authentication Assertion Attribute Assertion
SAML Token
Policy Enforcement Point d
a
End-User Credentials
Attribute Assertion
Attribute Authority (Policy Decision Point)
Figure 3: SAML Basic use case
It is supposed that an end user through their typical web browser wants to access a protected resource that is an online application. a) The end user submits its credentials (that can be username and password) to the Authentication Authority (any security or authentication application supporting SAML). b) The Authentication Authority confirms users access parameters based on their directory and produces an Authentication Assertion alongside with one or many Attribute Assertions that can be any other information about the user profile such as their function, their full name or their email address. The user can now be authenticated and identified by SAML assertions in a token. c) The user tries to get access to the resource using the SAML token. d) The Policy Enforcement (PEP) directly intercepts the user request to the resource and forwards the user SAML token, an Authentication Assertion to the
Page 25 of 125
2012/2013
Attribute Authority (Also any security application engine supporting SAML or SAML-aware). e) According to its policies the Attribute Authority also called Policy Decision Point now decides wether the user can access the resource or not. If the decision is positive, an Attribute Assertion is generated and bound to the user token. Finally, that SAML token can be provided to trusted partners addhering an SSO relationship (Netegrity, Inc, 2001).
2.4.3 SAML other use case scenarios Other SAML use cases can include among others the following scenario: Sessioning, where a session is maintained while and as the end user is navigating across the web applications and web sites that are within the SSO circle. In that case, the source web site deals with most of security processes, it notably acts as an authentication authority, a session authority, an attribute authority and a credentials collector. Destination websites act as Policy Enforcement Point (PEP) and Policy Decision Point (PDP) (Netegrity, Inc, 2001). Authorization Service: Here, the resource protector and controller in terms of security is the PEP, that verifies the user authorisation when the user attempts to access a resource via a PDP (that acts as the authorisation service provider to the PEP). In this case, the security service is considered as an authentication authority, an attribute authority, a credentials collector and PDP. The backend application considered as a PED (Netegrity, Inc, 2001). Business-To-Business Transaction: Within this scenario, business partners are involved in transactions based XML documents. Each partner is authenticated againts its own security system or all the partners can agree to use the security services of a third party engine which regulates the security in all transactions (Netegrity, Inc, 2001).
2.4.4 SAML architecture This section describes the structure and the main components constituting the SAML protocol and that contribute to the establishment, the maintaining and the release of secured information exchange within trusted organisations. Those components typically allow the exchange of authentication, authorisation, attributes, etc across shared resources (OASIS, 2008).
Page 26 of 125
2012/2013
2.4.4.1 SAML structure SAML data and assertions are encoded in the form of XML schema including basic information that defines and specifies an identifier used for the assertion date, time and name of the issuance and the time slot or interval for which there is a validation of the assertion. The submission of SAML assertion to authorisation and authentication decision points is done via a request and response protocols exchange in the respect of the following format: SAMLQuery and SAMLQueryResponse. The figure 4 below shows the basic structure of SAML (Netegrity, Inc, 2001).
Profiles (combining protocols, Assertions and Bindings) Bindings (How Assertions are communicated over industry-standard transport and messaging frameworks) Protocols (Requests / Responses pair for processing assertions) Assertions (Authentication & Authorization (Attribute) information)
Figure 4: SAML structure
Two other important concepts in SAML deployment: Metadata allow SAML parties to communicate and shared information.
Parties recognize each other through metadata. For example a Service Provider (SP) knows the profile of an Identity Provider (IdP) through its metadata and vice versa. The SAML metadata is often specified and defined by its proper XML format content. A SAML authentication context is used to carry information in regard to the
authentication strength that a user exploited when authenticating against and Identity Provider. 2.4.4.2 SAML components This part provides more details in the components that present further information in the SAML structure and environment.
Page 27 of 125
2012/2013
Assertions: A SAML assertion helps parties to use statements to confirm
security information concerning subjects. For example, an assertion in SAML can state that a subject is named GR Badouet, his ID is 3940347, his email address is badouetg@uni.coventry.ac.uk and he is a student in the department of Computing at Coventry University. Therefore, the key elements in an assertion are the subject and the statement content. Moreover, there three types of statements defined by SAML and that can be conducted within an assertion: An authentication statement (generated by a party authenticated a user successfully, it describes the way used to authenticate a user prcising the time at which the authentication has been done); an attribute statement ( containing specific attributes related to the subject, for instance, the user GR Badouet has a student status) and an authorisation decision status (specifying what a subject defined to do, for instance whether GR Badouet is allowed to access the online library resource) (OASIS, 2008).
Protocols: They are used in SAML to define requests and responses
actions. Those protocols include: Single Sign On, Single Logout protocol (specifies the mechanism of simultaneous logout for open sessions, it can be initiated by any parties related to the active session such as an IdP, A SP, or even a user); Assertion Query and Request Protocol ( Specifies a collection of queries through which SAML assertions can be gotten); Artifact Resolution Protocol (Defines a mechanism through which SAML messages might be passed using a value called artefact, an artefact can be passed to a message via an SAML binding such as an HTTP Redirect); Authentication Request Protocol (Provides a means through which a subject may request assertions comprising authentication and attribute statements); Name Identifier Management Protocol (Defines rules to change the value of identifiers name format, the request initiator can be either the identity provider or the service provider) and Name Identifier Mapping Protocol that defines mechanisms to map programmatically one SAML name identifier to another (OASIS, 2008).
Bindings: In SAML, bindings are the elements that define and describe the
ways SAML protocol messages are carried over transports protocols. SAML 2.0 defines the following bandings: HTTP Redirect Binding ( Specifying the way
Page 28 of 125
2012/2013
SAML message protocols are carried through HTTP redirect messages); HTTP POST Binding (Provides how SAML protocol messages are carried inside a content of base 64-encoded for the control of an HTML form); HTTP Artifact Binding (Specifies the means from which an artefact is carried from a message issuer to a recipient of the message through the HTTP protocol); SAML SOAP ( Simple Object Access Protocol) Binding (The means by which SAML protocol messages are carried inside SOAP 1.1; Reverse SOAP (PAOS) Binding (Specifies a message exchange allowing an HTTP client to become a SOAP responder and SAML URI Binding specifying how to retrieve an existing assertion via the resolving of a uniform resource identifier (OASIS, 2008).
Profiles: They determine how protocols, assertions and bindings are
associated to yield more advanced interoperability in specific use case scenarios. SAML profiles provided by SAML 2.0 include: Enhanced Client and Proxy (ECP) Profile (A specific single sign on profile in which specific clients or proxies may use SOAP and the PAOS bindings); Web Browser SSO Profile (Specifies how entities in SAML make use of the authentication request protocol, SAML messages and assertions to complete SSO through typical web browsers); Identity Provider Discovery Profile ( Specifies techniques for SP to know about IDP that have been previously visited by a user); Assertion Query/Request Profile (How entities in SAML make use of SAML queries and request protocols to get assertions through a synchronous binding like SOAP); Single Logout Profile ( Specifies how the Single logout protocol is used with protocols such as HTTP POST, HTTP Redirect, SOAP and HTTP Artifact bindings); Artifact Resolution Profile ( How entities can make use of the Artifact Resolution
Protocol through a synchronous binding to get a protocol message via an artefact); Name Identifier Mapping Profile (Specifies the means of which a Name Identifier Mapping Protocol utilizes synchronous bindings like SOAP; and Name Identifier Management Profile specifying how a Name Identifier Management Protocol can be utilized with HTTP Redirect, SOAP, HTTP Artifact bindings and HTTP POST (OASIS, 2008).
2.4.5 SAML Components structures Subject, Assertion and Statement Structure

Page 29 of 125
2012/2013
The figure 5 below shows the general structure of an assertion, a subject and a statement structure within a SAML/XML file fragment.
1: <saml:Assertion xmlns:saml=urn:oasis:names:tc:SAML:2.0:assertion 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: Version="2.0" IssueInstant="2013-06-13T12:00:00Z"> <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity> http://idp.example.org </saml:Issuer> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> badouetg@example.com </saml:NameID> </saml:Subject> <saml:Conditions NotBefore="2013-06-13T12:00:00Z" NotOnOrAfter="2013-06-13T12:10:00Z"> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2013-06-13T12:00:00Z" SessionIndex="67775277772"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement>
25: </saml:Assertion>
Figure 5: Simplified example of a Subject, Assertion and Statement Structure (OASIS, 2008).
Example of an Attribute Statement structure
The figure 6 below illustrates a simplified example of an attribute statement structure within a SAML/XML file fragment.
Page 30 of 125
2012/2013
1: <saml:AttributeStatement> 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: <saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:2.5.4.42" FriendlyName="givenName"> <saml:AttributeValue xsi:type="xs:string" x500:Encoding="LDAP">John</saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="LastName"> <saml:AttributeValue xsi:type="xs:string">Doe</saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat=http://smithco.com/attr-formats Name=CreditLimit> xmlns:smithco=http://www.smithco.com/smithco-schema.xsd <saml:AttributeValue xsi:type=smithco:type> <smithco:amount currency=USD>500.00</smithco:amount> </saml:AttributeValue> </saml:Attribute>
24: </saml:AttributeStatement>
Figure 6: Simplified structure of an attribute (OASIS, 2008).
2.4.6 SAML Security and Privacy aspect The main purpose of SAML is security of information exchanged between parties and the privacy of users data. How SAML is defined to prevent any attacks from any sources. Users should be guaranteed that personal data and attributes they provide are not seen or used by not authorised entities for any reason.
Security SAML therefore applies a set of security mechanisms to prevent detect and act against potential attacks. The first security measure is for relying parties and assertion parties to first of all trust each other in their partnerships that are based typically in a PKI (Public Key Infrastructure). Even though the use of a public key infrastructure is not mandated by the SAML protocol, it is strongly recommended. Particular security mechanisms used
Page 31 of 125
2012/2013
are defined and within each binding in SAML. Some recommendations in regard to the security aspect and rules are as follow (Fengming, N, Feng, X, and Rongzhi Q (2012).
To ensure the integrity and the confidentiality of exchanged messages, HTTP
over SSL 3/ TSL1.0 also known as HTTPS protocol should be applied. The same protocol should is recommended when a relying party needs an assertion from an assertion party, with the application of mutual authentication and through digital signatures (Fengming, N, Feng, X, and Rongzhi Q (2012). When delivering a response message comprising an assertion to a relying
party through a standard web browser, it is compulsory that the message be digitally signed utilizing an XML signature (Fengming, N, Feng, X, and Rongzhi Q 2012). Privacy Basically, privacy refers to users capability to control the way their data and information are used and shared within partners in relationship. The SAML protocol is generally implemented in respect to such requirements whatever the scenario. SAML consists of a set of mechanisms supporting implementations with the respect of privacy specifications and requirements (OASIS, 2008). SAML is designed to support the application of pseudonyms set up between
a service provider and an identity provider. Pseudonyms ensure that only appropriate correlations between a service provider and an identity provider are enabled (OASIS, 2008). SAML is designed to support one time identifiers, those identifiers guarantee
whatever the time a given user get access to a given service provider via a single sign on mechanism from an identity provider, that service provider might not be capable to identify them as the same user that has visited it before (OASIS, 2008). The authentication Context mechanisms in SAML are defined to permit a
user to get authenticated at an appropriate assurance level. SAML permits a user to claim some operations to make sure that all the
operations related to their profile data and information match the scope of the user right and policy (OASIS, 2008).
Page 32 of 125
2012/2013
2.4.7 SAML benefits SAML provides many detailed benefits; some of the most important of them are listed a below: Open solution: SAML has been defined to work properly with a variety of
web protocols such as HTTP, HTTPS, FTP, SMTP, SOAP and more. In addition SAML also support many XML frameworks. Single Sign On Across Sites: SAML allows users to navigate across
different websites, web applications and web services within companies in a trusted relationship with the guaranty of an advanced security and privacy level. The advantage of accessing shared resources inside a partnership without a need to provide every time credentials or other access parameters is a real asset. Interoperability: SAML allows all types of e-businesses and service
providers whatever their sizes to safely exchange data and information about resources and users; all without the need to require companies to remove their existing security solution. Standardization: The development of SAML with the multitude of its
features allows industry to use a common and standard framework to provide authentication, authorisation and identification within policies based security platforms.
The next section concerns Shibboleth, one of the protocols or frameworks that implement the SAML protocol. This provides further understanding on how SAML really works. It will be clearer to figure out how SAML components such as SP (Service Provider) and IdP (Identity Provider) communicate together via the of SAML/XML format.
2.5 Shibboleth as an implementation framework of SAML

This section 3 presented an overview of the single sign on (SSO) mechanism by providing and describing its general structure. Still in the same section, some protocols able to implement the SSO operation have also been presented by focusing on one of the majors protocols which is SAML. As SAML is the protocol for which there is more interest in this project, the section 3.2 provided further details in the description of the core structure and main components of SAML. This section (3.3) will now raise a
Page 33 of 125
2012/2013
framework that implement the SAML protocol at a certain level, which is the subject of this project. Some concepts already covered in the previous section could be overwhelmed in this section because Shibboleth is almost all about SAML. So Shibboleth will be described within the next sections, illustrating how its implements SAML over web servers. This chronological analysis helps to easily understand the project progress.
2.5.1 Shibboleth architecture and components The major components of Shibboleth architecture consist of the Identity Provider (IdP), the Service Provider (SP) and the Discovery Service (DS) (used to be called WAYF, Where Are You From). In addition to these components, two other actors perform in the web SSO system notably, the web browser and the resource. All those elements interact with each other in order to provide users identifications, authentications and authorisation in a secured manner. 2.5.1.1 Identity Provider The Shibboleth IdP is the component at the heart of security procedures; its main function is to authenticate the user through an existing authentication system such as LDAP and ensure the single sign on service in the respect of SAML protocols and assertions specifications. The IdP consists of five components namely the Authentication Authority, Inter-site Transfer Service, the Artifact Resolution Service, Single Sign-on Service and the Attribute Authority (Cantor, S, 2005). The figure 7 below summarizes the IdP structure and the communication between amongst components. Single Sign-on Service
Artifact Resolution Service
Inter-site Transfer Service
Attribute Authority
Authentication Authority
Figure 7: IdP components structure
Page 34 of 125
2012/2013
The Authentication Authority consists of a SAML based- service that initiates authentication assertions concerning relaying parties such as the Shibboleth Service Provider. Shibboleth itself does not determine the way the authentication of entities has to be performed. The single sign on service is the contact starting point at the level of the IdP; at this level, it initiates the process of authentication and redirects the user towards the Inter-site Transfer Service, that is charged to provide HTTP responses in accordance with Artifact profiles/web browser and Browser/POST. The Inter-site Transfer Service which is an HTTP service interoperates with the Authentication Authority to provide the authentication assertion required (Sidawi, M,W, 2007).
It is assumed that the Browser/Artifact prole is used, then the IdP provides an artefact to the service provider; the SP then forwards the artefact to the Artifact Resolution Service which is a SAML protocol that will help the IdP to provide the authentication assertion to the service provider. Afterwards, the Attribute Authority generates attributes requests and attributes assertions to identify and authenticate any request it may receive (Sidawi, M,W, 2007). 2.5.1.2 Service Provider A service provider is an application entity providing a web service or any type of web resource that should be in principle subject to an authorisation following a security concept provided by SAML specifications. Subject to an authorisation means before using a resource driven by the service provider, a user should have beforehand valid authentication parameters (Cantor, S, 2005).
A service provider should always have a unique identifier called entityID or providerID (in old Shibboleth specifications and products) that should be a URI (Uniform Resource Indicator) [RFC 2396] that must not be over 1024 characters. The use of HTTPS URL (Uniform Resource Locator) may be more recommended in the publication of metadata (Cantor, S, 2005). A Shibboleth SP consists of the following elements: Assertion Consumer Service: Managed by the SP, the assertion consumer service is an HTTP resource and the SP endpoint of the SSO process having the function of processing the HTTP GET requests or Browser/POST profile submissions aiming to set up new security context for an entity. Supposing that
Page 35 of 125
2012/2013
this is successful, the assertion consumer service should possibly re-orientate the users agent to a targeted resource hosted by the SP (Cantor, S, 2005). Attribute Requester: Eventually implements a back channel attribute exchange when the security context has been set up at the service provider point (Cantor, S, 2005). In addition is the target resource which is the application or the service a user wants to access. 2.5.1.3 Discovery Service /WAYF Formerly called WAYF (Where are you from), the discovery service (DS) is a very important component and function in Shibboleth when it comes to deal with a use case scenario where there are more than one identity provider. In that case, the DS helps the SP to identify to which IdP it should send authentication request. Sometimes a unique user can belong to several SP and several IdP. 2.5.1.4 Web browser and target resource The web browser is the user side application that initiates an HTTP request (by typing the URL of the wanted web application) to the SP in order to access a protected resource.
2.5.2 Overview of the web SSO steps with Shibboleth This part describes how Shibboleth works, how components cooperate each other to achieve the single sign on process. According to Cantor, S (2005) and Shibboleth (2013), the following sequence illustrates the steps and interactions that occur within a typical Shibboleth-based single sign on scenario. The main actors in that processes are the components described above. This scenario assumes that a user wants to get access to a secured resource for the first time and successfully.
1) HTTP request to SP: The user through an HTTP request attempts to access a protected resource hosted by the service provider. The resource manager checks whether the user gets an active session or not. Once noticing that the user does not have an active session, the user request is sent to the Service Provider aiming to begin the SSO operation.
Page 36 of 125
2012/2013
2) Authentication Request issued by Service Provider to Identity Provider: Once the SP has received the user request, an authentication request is prepared associated to the user request and redirected to the Identity Provider. It is worthwhile to note that the Service Provider application is usually deployed in the same server with the resource.
In the case there are many Identity Providers, the authentication request and the user request are first sent intermediately to the Discovery Service (DS)/WAYF in order for the SP to determine and select an IdP to which belongs the user before all is sent to the appropriate IdP. Shibboleth provides two services/applications to deal with this case: The Centralized Discovery Service and the Embedded Discovery Service, however, Shibboleth Responsible highly encourages the second one to service providers developers as it offers more user experience.
3) Identification and Authentication of the user by the IdP: When the request from the SP arrives at the IdP, it checks whether the user has an existing session or not, if it is the case, the step 4 is proceeded, if not, the user is prompted to provide their access parameters (e.g., a username and a password) and the user is proceeded to the next step (4).
4) IdP issues Authentication Response to SP (<samlp:Response> or SAML Artifact(s)): As the user parameters have been correct and therefore the user has been identified, the IdP generates a SAML response or more artefact(s) message(s) considered as an authentication response and sends it back with the user request to the service provider.
5) Service Provider checks the response: When the user request and the authentication response from the identity provider reach the service provider, the authentication response undergoes a validation and a user session is created by the SP that also provides some important information such as a user identifier to be used by the protected resource. Afterwards, the user is now directed to the target resource.
Page 37 of 125
2012/2013
6) Resource returns its content: Finally, since the resource knows who the user is, the resource decides to provide the user with the requested service, application or data.
The sequence diagram of the above SSO steps is illustrated on the figure 8 as bellow shown.
User Agent Service Provider Discovery Service Identity Provider
1) HTTP request to SP
2) Authentication Request issued by SP to IdP
3) Identification and Authentication of the user by the IdP
4) IdP issues Authentication Response to SP
5),6) Validates the response & provides the resource to the User
Figure 8: SSO sequence diagram
Other elements and features intervening in Shibboleth SSO By reading the above SSO steps, one may ask some questions about how are some steps or sub-steps achieved. Shibboleth (2013) explained as below described some important elements and features that also help Shibboleth to achieve the SSO mechanism and more about the way Shibboleth works. User attributes: One great benefit of using Shibboleth is the advanced capacity of a Shibboleth SP to easily receive data from a Shibboleth IdP and vice versa. Without these data also called user attributes a user cannot be indentified and authenticated. Attributes can be email address, phone number, information about a group to which the user belong, its function in an organisation and so on.
Page 38 of 125
2012/2013
Shibboleth metadata: One may also ask how do IdP and SP communicate each other over HTTP, they way each entity knows each other URLs and more. This role is completed by data about data or data for data called metadata. A metadata document describes in detail different aspects related to an IdP or an SP. The SP metadata file should be loaded in the IdP and the IdP metadata should be loaded in the SP properly to allow communication between them. A SP or IdP metadata generally comprises messages URLs, an entity ID as identifier, cryptographic information about messages creation and a humanreadable name and description.
Federated Single Sign On with Shibboleth: The above SSO steps are quite similar to most SSO systems. However, some of those systems are defined to operate only when the SP and the IdP are within the same organisation. The SSO implementation through Shibboleth performs regardless of whether the SP and the IdP are within the same network/organisation or not. This highly advantageous feature makes Shibboleth to be additionally defined as a federated SSO mechanism.
Shibboleth profiles: Generally, SAML profiles specify the components of interoperability, that means if different products support a set of defined profiles, they can cooperated each other at a certain given level. The Shibboleth profiles specification defines a set of functions that can be performed. For example, the Shibboleth IdP does not support yet the Single Logout (out of scope of this project). The figure 9 below shows the profiles supported by Shibboleth SP and IdP.
SAML 1.1 Protocol Profile

Profile Attribute Query Artifact Resolution SSO Profile Shibboleth SSO Request
Identity Provider Yes Yes Yes Yes
Service Provider Yes Yes Yes Yes
Page 39 of 125
2012/2013
SAML 2.0 Protocol Profile

SSO Attribute Query Artifact Resolution Enhanced Client Single Logout Name ID management
WS-Federation Passive (ADFS) US eAuth v1
Identity Provider Yes Yes Yes Yes No No No No
Service Provider Yes Yes Yes Yes Yes Yes Yes Yes
Figure 9: Shibboleth profiles
Shibboleth Bindings: Bindings define and describe the way messages are carried from a sender to a recipient. Some bindings examples include the POST binding that determines how to format, name and send messages to a recipient through a HTTP POST request. The Redirect binding determine the way to send a message through a URL of an HTTP redirect request.
2.6 Web application 247lib.com/247libDE

247Lib.com/247libDE is a library management application written in ASP .Net and provides an advanced and simple web browser based interface. The services provided by that web application are available for Universities, Government, Colleges, Corporate, Health Centres and many other institutions and include resources allowing the management of the following applications or services set by modules: Reports,
Catalogue, Orders, Survey, Finance, Stock Items, Authorities, Borrowers, Circulation, Bookings, Periodicals, Enquiries Online discussions and more (Applied Network Solutions, 2013).
The most use case of 247libDE consists of secured access to the services listed above. For instance, a subscriber can address any library management or resource
Page 40 of 125
2012/2013
management task by simply using modules they want to through a friendly web based configuration tool (Applied Network Solutions, 2013).
Actually 247Lib.com/247libDE application may be hosted either at the customer premises or by any third parties able to host web applications. Microsoft and HP have both endorsed 247lib.com with '247lib.com in a box' (that means a complete solution can be delivered to the customer in the cloud including hardware, operating system and the 247Lib.com/247libDE application. In other words, the package gives a 'Microsoft Windows Embedded licence' and an HP server comprising the entire required performance configuration (Applied Network Solutions, 2013).
As explained before, the project technical goal is to define an integration strategy of 247Lib.com/247libDE to Shibboleth and therefore allow Shibboleth based authentication mechanism. The figure 10 below is the printed screen of the web interface containing resources that users may need to access through the SSO principle. The existing authentication solution allows users to provide different credentials and usernames every time they want to access different applications (Applied Network Solutions, 2013).
Figure 10: 247lib.com/247libDE existing interface
Page 41 of 125
2012/2013
Chapter 3: Literature Review and related works

3.1 Introduction
Investigation and implementation of Shibboleth SSO authentication mechanism through a specific scenario The above project title states and summarizes a wide area of literature in the field of identity and access management systems in general and particularly around the concept of the single sign on implementation strategy within organisations and institutions. This chapter includes some major treated topics related to the SSO, SAML and Shibboleth. It aims to better understand the concepts described in the previous chapter and get familiarized with the main background of the topic that this whole paper is dealing with. It gives an overview idea of what has been done already by other authors in the area of the topic and presents what new the project will bring up, hence the necessity of the project. The used approach is the combination of thematic and chronological structure; this is due to the will to group and organise the sub-headings of this chapter from general (less related) to more directly related to the project topic. Therefore, the contents that this chapter includes comprise the analysis of the SAML protocol with regard to the single sign on mechanism, the implementation of SAML through Shibboleth and the application of Shibboleth within organisation or/and across federated institutions.
3.2 Web SSO protocols

Several authors provided some descriptions of protocols supporting single sign on mechanism. Those authors raised the features that those protocols can supply to a system or a set of systems. According to many articles, how powerful a protocol is depends on its use and how the user masters it.
Fengming, N., Feng, X., and Rongzhi,Q (2012) made an analysis on the web SSO mechanism and described it as a technique used to dealt with the issue of passwords and accounts management in different applications or services access. They claimed that the standard SSO cannot longer guaranty a high security level and performance in complex systems due to mutation of applications and computational systems. They
Page 42 of 125
2012/2013
raised especially the problem of legacy in different systems that face the traditional SSO and presented the SAML protocol as the new solution to deal with.
Neuman,B,C., and Ts'o, T (1994) contended that the Kerberos-based single sign-on consisting of electronic certificates supplied by centralised authentication systems and servers is one of the most widely used SSO protocols due to the simplicity of its structure. However, its legacy components need to be well known and modified in regard to the implementation application. That argument has later been supported by SHEN, Y., and Du, Z., (2012). However, Tiwari,P,B., and Joshi,S,R (2009) stated that The onetime password authentication method in Kerboros is only suitable for the SSO mechanisms without the need of high performance requirements.
Nishimura, T., and Sato, H (2008) tried to provide two sketches of solutions to deal with the issue of legacy in different systems that are automatic account bindings, automatic application systems bindings and the LESSO model, that guaranties the data security in transportation. However, those solutions are limited by web filter use and the authentication efficiency is reduced.
Another research carried out by the Organization for the Advancement of Structured Information Standards (OASIS, 2013) described another single sign on mechanism based protocol (SAML) as an XML based standard architecture providing switching authentication of data in several security domains. That description has earlier been supported and validated by many authors such as Hansen, S, M., Skriver, J., and Nielson, H, R (2005) through a common article on a static analysis of SAML SSO.
A summary of the above statements shows that SAML is the most used and the most acceptable SSO application.
3.3 The use of SAML

The rapid growth of internet, the complexity of web distributed architectures and the growing complexity of online interactions within organisations sharing somehow data and interests, there has been an increasingly demand of a flexible standard, a loosely coupled system, an open and neutral language format, and a reliable architecture able to provide an advanced interoperability within web services and beyond by enforcing the
Page 43 of 125
2012/2013
security aspect and the authentication mechanism across domains. Since several years ago, many protocols have been investigated and applied resulting to various solutions. SAML is one of those protocols which has been demonstrating its success as a result of hard works conducted by different researchers and authors. Below are some authors realisations in the scope of SAML implementation.
ZHANG, Y., and YANG, J (2010) conducted a research on a dynamic authentication mechanism crossing domains for web services based on SAML. The authors work aimed to define an SAML implementation that applies the single sign on, enhances the security and improve the interoperability within web services interoperations.
Some authors went far in the application scope of the SAML protocol in less web based domains such as the signalisation in internet protocol (IP). Through an IEEE initiative, a team of researchers comprising Tschofenig,H., and Rainer, F, R of Siemens AG ; Peterson, J., and Hodges, J of NeuStar, Inc; Sicker, D of Colorado University; and Polk, J of Cisco Systems (2006) carried out a project based on the application of SAML to protect the internet SIP (Session Initiation Protocol). The work defines and implements a convergence strategy between SAML and SIP by providing a communication technique between the two protocols, an exchange message format and a compatible common profile for the two protocols.
Still in the same scope of the internet protocol, Lutz, D., Hecht, F.,et al (2007) presented a project on Charging of SAML-based Federated VoIP Services that consists of harmonizing the SAML- based federation technology needing a payment tool to charge voice over internet protocol (VoIP) services inside the federation. To do so, the authors defined an inter-communication architecture constituting of a user, a VoIP network, an IdP (Identity Provider), a PP (Payment Provider), SP (Service Provider), the payment assertion and a DS (discovery service).
In the scope of Unified Identity Management (UIM), Zhenxiang,T., and Qian, L (2012) of Engineering Training Center of Wuhan University of Technology in China carried out a project related to the design and the implementation of an UIM system based the SAML protocol. They proved on their work that in addition to the features provided by existing and standard identity management systems, the UIM based on the SAML protocol can
Page 44 of 125
2012/2013
complete the single sign on option via a web proxy system to achieve an automatic user authentication within the application system.
To sum up the SAML related works, most SAML applications are proprietary. There are not many frameworks such as Shibboleth that make easy to implement the SAML with possibilities of very extending the implementation.
3.4 Application of Shibboleth

The Shibboleth protocol has been using for several purposes. Authors and editors worked and searched around the implementation of Shibboleth to solve or improve access identification and authentication relying on SAML protocl, to enhance institutions federation features and to better ensure the issue of user privacy, data security and confidentiality.
Ngo, L., and Apon, A (2007) investigated the use of Shibboleth in the scope of authorisation and authentication to the Subversion Version Control Repository System. The content of that work is a Subversion repository with an Apache web interface protected by a Shibboleth authentication system providing a characteristic that permit authenticated, identified and authenticated data to share resources between institutions while supplying simplicity, enforcing users privacy and helping helps local administrators from the need of performing additional account management when it comes to manage new users from other institutions. The security aspect of share resources and the users privacy in Grid computing are the largest concern of research communities when they must decide whether they should commit themselves to grid shared resources or not. Sinnott, R, O., Jiang2, J., Watt, J., and Ajayi, O (2006) demonstrated how to combine Shibboleth with other authorization technologies to enhance the security and privacy concepts in remote access to shared resources within grid communities. However, their research focuses only on the context of the grid environment and should not be applied directly to other contexts. In a similar scope, Spence,D., Martin, A., et al (2006) driven by the Joint Information System
Committee (JISC) carried out a work in the Shibboleth access for the UK national Grid service, with one of the goals of replacing the existing solution provided by Athens. They raised the importance for users of applying and using Shibboleth to protect their
Page 45 of 125
2012/2013
proxy certificates without the need to type every time and with repetition pass-phrases when accessing resources.
Through the IEEE/IPSJ and under the International Symposium on Applications and the Internet, Komura,T., Sano H., Makimura, K., and Demizu, N (2011) presented a work on a web forward proxy server providing an authentication process through Shibboleth that they experimented and tested in and electronic journals network. Their work applied a web forward proxy server working as the Shibboleth SP and supporting the single sign on to sort out the inherent problem of digest access authentication supported by existing forward proxy servers.
Still on behalf of the IEEE/IPSJ and under the International Symposium on Applications and the Internet, Sato, H., and Nishimura, T (2001) proposed advanced techniques of using Shibboleth to federate authentication in a hierarchy of IdPs. That work first of all presented the issue that due to the growing complexity of IdPs, there are scenario where a single person has their own identity at the same time in an organisation, suborganisation and even in a virtual organisation provided by independent IdPs. Assuming that one of the SSO objectives is to reduce the cost with the integration of authentication; that scenario is merely inappropriate and not desirable. To come up with a solution the above authors suggested a scenario where IdPs in sub-organisations can rely on the assertions of parent organisations that provide authentication delegation.
More related to this project and under the supervision of Schneider,G. from AlbertLudwigs-University of Freiburg and Sidawi, M, W (2008) conducted an analysis and application of Shibboleth for authorisation and authentication against a web software. Focusing on an external authentication way and mostly on the Service Provider, the author describes and analyses Shibboleth as a single sign on mechanism to safely access the web- based documentation application MediaWiki. The article shows how Shibboleth can be used to access shared environments, its flexibility and how it can be integrated to other services.
Page 46 of 125
2012/2013
3.5 Gap and contribution

All the above works have contributed somehow to the security issues concerning the management of resources and services access by users within organisations and across institutions boundaries. Many protocols and concepts are used for that purpose notably Shibboleth over SAML which is one of the most demanded nowadays due to the multitude solutions and alternatives it provides. All the authors cited in these related works carried out tasks linked to this project and each with a certain level of impact and importance.
However it appears that there is not a real case focusing in depth on an investigation that leads to a use case scenario and including both Shibboleth Service Provider and Identity Provider. Moreover, there is no clear case providing Shibboleth implementation step by step within a specific given environment and organisation. It is actually difficult for a given reader to read those related works, follow them and afford to implement Shibboleth. This work has the specificity of illustrating a chronological approach of Shibboleth implementation, analysis until its real and concrete implementation by mentioning all the essential details in the chosen deployment scenario.
Page 47 of 125
2012/2013
Chapter 4: Implementation requirements

In the previous chapters, the overall goals of the project and its background have been presented; technical concepts of the project have also been examined; and a review of the project related works has been conducted. There has been an emphasis on protocols and related technologies in order to further understand the project implementation.
Throughout this section, a requirement analysis is carried out aiming to figure out how the project prototype should look like and therefore adopt all the necessary measures to meet the implementation requirements.
4.1 Requirements gathering procedure

Getting the specifications of how a client would like the product to look like is one of the most capital tasks to do because if this step is not well followed, it would be likely that the output product may not satisfy the client needs. Since this is very important aspect, the implementation requirements have been gathered through several ways as follows. Project documentation/ proposal The project proposal itself is described in a document presenting the project specifications according to the need of the client (ANS). Through this document, the major primary information about the client exigency and therefore the first requirements has been gathered. Some of initial project specifications have been modified by the client during the project progress. Interviews In order to understand better the project specifications provided by the client and further precisions, some interviews have been conducted with the client Representative. Those interviews were verbal and non verbal. The verbal interviews were during organised meetings in the Faculty of Engineering and Computing at Coventry University; and non verbal interviews were through exchanged emails. Both two types of interviews helped for more details about the existing resources access solution and essential final product requirements. Surveys In addition to the client first requirements, some survey have also been produced, still in order to acquire as much information as possible regarding the project topic and related
Page 48 of 125
2012/2013
areas. They conducted surveys were mostly web- based and helped to obtain some information about issues that current Shibboleth end users and developers face.
Research A variety of research on technologies, protocols, mechanisms, applications related to the project wording has been carried out during the literature review analysis and other related works. Especially, many SSO and Shibboleth based articles have been analysed to understand the specifications and further details to be respected when applying the Shibboleth and SAML technologies in real life. The research helped to understand security requirement of the implementation by ensuring that the product will meet the triple security tenets namely the confidentiality, the integrity and the availability; and how the user policies should be applied. The research sources were first of all the Shibboleth consortium website and books, Shibboleth Wiki, the OASIS website and books and other reading materials available in the Coventry University online library.
Brainstorming Any investigation process probably involves somehow brainstorming. Before or during the application of any other information gathering procedures, it has been very useful to think as well as possible in order to make good decisions. The brainstorming constituted an important technique of knowing more about the project implementation and the final product requirements.
Prototypes investigation The research, surveys, brainstorming and the interviews carried out raised a global idea, orientations and indications to design logical implementation prototypes. Furthermore the related prototypes provided by other workers helped to understand how this project prototype should look like to fill the standard requirements. As for any product implementation, there are some general specifications to respect in terms of security, performance and reliability, and this is what the related prototypes clarified the requirements investigation.
Page 49 of 125
2012/2013
4.2 Requirements table

The above requirements gathering methods helped to produce a summary list of essential requirements as shown on figure 11. They are classified on a basis of priority, type and gathering technique.
The Priority notation has been applied as follows: Critical (Red): Highest priority Medium (Yellow): Medium priority Low (Green): Lowest priority
ID determines the identification number of the requirement Date is the requirement period illustration The description is the explanation of the requirement, what it states and imposes The type is classified by Business, Device and User, stating whether the requirement is Business- based, Device- based or/and User- based. Gathering technique: The method(s) from which the requirement has been acquired
ID
Date
Description The Implementation must be done within Windows based Servers The Service Provider must be deployed on IIS Detailed and clear instructions on the implementation scenario The implementation can be a prototype based on trivial applications The final implementation should demonstrate a working prototype within ANS Servers and showing a proper testing scenario. The final document should also provide a clear integration strategy of 247lib.com//247libDE web application
Type Business & Device Business & Device Business Business
R01 19/06/ 2013 R02 19/06/ 2013 R03 19/06/ 13 R04 19/06/ 2013 R05 19/06/ 2013
Business
Gathering technique Project documentation & Interviews Project documentation & Interviews Project documentation Interviews, surveys & Prototypes investigation Project documentation & Interviews
Priority Critical
Critical
Critical Medium
Critical
Page 50 of 125
2012/2013
R06 19/06/ 2013
R07 19/06/ 2013
R08 19/06/ 2013 R09 19/06/ 2013 R10 19/06/ 2013
R11 19/06/ 2013
R12 19/06/ 2013
R13 19/06/ 2013
A user should properly Business authenticate against Shibboleth & User before accessing subscribed applications A clear report containing an User overview explanation of Shibboleth and the steps of its implementation Web pages capturing to be User provided on the report The review of alternative Business solution(s) to be provided if there is still time enough The latest released versions of Business Shibboleth products should always be implemented for more stability and security The Full Qualified Domain Business Name (FQDN) protocol should be respected during implementation for good communication between entities The entities naming should be Business respected during the implementation to avoid bottlenecks Applies HTTPS rather than Business HTTP to enhance security Figure 11: requirements table
Project documentation & Brainstorming Project documentation
Critical
Medium
Project documentation Project documentation Research & Surveys
Medium Low
Critical
Research
Critical
Research
Critical
Research
Critical
Page 51 of 125
2012/2013
Chapter 5: System analysis and design

The section above presented the steps and techniques that helped to gather the implementation requirements and the list of requirements. Knowing now all the major requirements, the components, the features, the architecture, data and interfaces to meet those specified requirements can be analysed and designed. By providing a design specification and the system analysis of an application before its implementation, there is an interest of understanding the use cases, ensuring the system performance, learning about future concerns and guaranteeing the whole system reliability and modularity.
5.1 System overview

The whole system implementation consists of three entities. The user agent/ operator, the Shibboleth- based ANS Service Provider, and the Shibboleth-based ANS Identity Provider. The use of an existing Shibboleth Identity Provider could have been adopted as what primarily interests application and service suppliers such as ANS is the management of their resources that are hosted near Service Providers (in the same server). Examples of existing and free Identity Provider for test are TestShib 2 from Internet 2/ Shibboleth project or a test IdP from the UK Access Management Federation For Education and Research by joining the federation. By implementing an independent ANS IdP based on Shibboleth protocol, the following are the advantageous: The project prototype is more complete and demonstrates how an institution manages its users. The implementation shows how an institution has full control on its users and therefore on their privacy. The prototype shows not only the deployment steps of the service provider, but also the one of the IdP. Any reader of this document will have a relative understanding on resources access management in regard to both essential sides (resource release process, that is SP and the user authentication process that is IdP).
The entities within the whole system interact as follows: Through an HTTPS based URL, the User (ANS subscriber customer) requests a protected resource hosted and controlled by the ANS SP. The SP receives the request, treats it and sends an
Page 52 of 125
2012/2013
authentication request (containing the user request) to the IdP whose role is to identify and authenticate the user. The IdP receives the request, treats it and sends back an authentication response to the SP with the user authorisation to access the protected resource. The SP receives the response and grants the resource to the user (resource page, application or data).
To meet one of the most important security requirements, the SSL protocol has to be enabled within both SP and IdP sites to provide secured communication and protect data exchange when SP and IdP are talking. The context diagram summary of the whole system is shown on the figure 12 below.
Figure 12: System High-level context diagram
5.2 Use case modelling diagram

The Use case diagram shows the end and the admin users interaction with other entities of the system, also illustrating the general use cases scenarios in the scope of this project prototype implementation. There are two types of users; the principle is for any end users to access the protected applications when they are authorised. An end user having an access authorisation implies that they have been created in the IdP linked- database system by an administrator user.
Page 53 of 125
2012/2013
Shibboleth-based Resource access and management System

Request the protected resource Log into application
Cancel the resource request
Access the resource End User (Customer) Write some resource contents
Log into the whole system entities
Create, modify & delete End User
Monitor activities
Admin User (System Admin)
Maintain the system
Figure 13: System Use Case diagram
5.3 System architecture

This section describes the hardware and software architectures of the project prototype implementation. Due to some specifications modifications brought by client during the project progress and for good understanding and experience of OS based issues that can be faced when deployment Shibboleth, this project consists of two prototypes implementations: A primary prototype implemented within a simple ad-hoc network to first of all understand the behaviour of Shibboleth. The real time prototype implemented within ANS local network, through their local domain to test a closer scenario. For the above reasons, there are two system architectures in this project on a basis of the prototype level.
5.3.1 Primary prototype architecture a) Hardware architecture

Page 54 of 125
2012/2013
The hardware architecture within the primary prototype consists of: To host physically the ANS Service Provider, 01 Intel core i3 computer with 300 G of HDD and 4G RAM memory is used as the SP Server. To host physically the ANS Identity Provider, 01 Intel core i7 computer with 700G of HDD and 8G RAM memory is used as the IdP Server.
The above hardware features do not mean a general requirement to deploy Shibboleth (since even a Pentium based computer can properly run the implementation); but merely what is being used.
Both physical servers are connected through a Wi-Fi ad-hoc network with the IEEE 802/11 standard. Each server can act as user client through its web browser or any computer can be linked to that ad-hoc network to behave like the end user. The figure 14 below shows a simple diagram of the ad-hoc/peer to peer network physical structure used to connect and deploy the two servers.
Figure 14: Physical structure of the primary prototype
It is also important to note that this could have been proceeded via a virtualization set up by using tools such as VMware workstations, Virtual Box or any. However, this would have led to some implementation issues such as clocking issues within virtualized hosts and the slowness of processes (it does not mean the implementation cannot be made
Page 55 of 125
2012/2013
through a virtualisation environment). Besides by using different machines for the two servers, the deployment appears more realistic in the sense that for real life implementations, the SP and the IdP are generally at different physical sites.
b) Software architecture The software architecture of the system implementation consists of several applications, each playing an important role in the sake of running the implementation. A failure of one single software element may affect the functioning of the entire system. This architecture resides on two windows- based operating systems on which the system required applications have to be installed and deployed.
On the Service Provider side Microsoft Windows 7 ultimate edition as Operating System of all other applications to perform the Service Provider. Microsoft Internet Information Services version 7 (IIS 7) to be deployed within Windows 7 in order to host the ANS Shibboleth based Service Provider, the SSL certificate, the first simple application to test the sign on. Shibboleth Service Provider version 2.5.2 to Shibbolize web applications and therefore protect resources.
On the Identity Provider side Microsoft Windows 7 professional edition as the OS to perform all other applications helping to run the Identity Provider. Sun Java Client (JRE 7) as java processes compiler Apache Tomcat 6 not as a standard web server but just as a java servlets container with SSL enabled. Shibboleth Identity Provider version 2.4.0 to manage identities and provide authentication resources Users. OpenDJ 2.7 LDAP server as the database system to register, host users and link them to the IdP for authentication and authorisation
On the User Agent side A typical web browser integrating SSL certificates authorities or simply able to support HTTPS request; in any operating system.
Page 56 of 125
2012/2013
The figure 15 below illustrates the software architecture of the system, showing the interaction between different components that allow the deployment of the SP and IdP.
OpenDJ 2.7 LDAP Server
Figure 15: Logical structure of the primary prototype 5.3.2 Real time prototype architecture a) Hardware architecture The difference between the physical architecture in the primary prototype and in the the real time prototype resides on the characteristics and the features of machines to be used to deploy Shibboleth. In addition, there is no need to re-define the network architecture as there is already an existing local network with a local domain. Two Dell servers have been made available by ANS for the test scenario. Each server having 8GB memory with Intel processors performing with an i-Core architecture.
b) Software architecture Within servers to be used in ANS local network, there were already server- based OS that are used with the following applications to deploy the real time prototype.
For the Service Provider Windows 2008 Server R2

Page 57 of 125
2012/2013
Microsoft Internet Information Services version 7 (IIS 7) as the web server with an SSL certificate installed and enabled.
Shibboleth Service Provider version 2.5.2 Sun Java Client (JRE 7) to allow the use of OpenDJ 2.7 LDAP server OpenDJ 2.7 LDAP server as the IdP linked database system to register, host users and perform authentication and authorisation.
For the Identity Provider Windows 2003 Server R2 Sun Java Client (JRE 7) as java processes compiler and to allow the use of Tomcat & OpenDJ. Apache Tomcat 6 not as a standard web server but just as a java servlets container with SSL enabled. Shibboleth Identity Provider version 2.4.0 to manage identities and provide authentication to ANS resources Users. Note: Windows 2003 Server does not support any version of OpenDJ, that is the reason of not using OpenDJ in the same than with the IdP software (the box running Windows 2003 server). User Agent side A standard web browser with SSL enabled.
The figure 16 below illustrates the software architecture of the system in regard to the real time prototype implementation.
OpenDJ 2.7 LDAP Server
Figure 16: Logical structure of the real time prototype

Page 58 of 125
2012/2013
5.4 Human- Computer Interface

This section consists of providing the design of the system inputs and outputs related to the user agent/operator. There will not be real issues related to the ease-to-use and friendly interface aspect because the project is all about setting up web interactions to follow Shibboleth protocol within existing and deployed applications that already satisfy those issues. Moreover, this project is not about designing particular or typical software and therefore dealing in depth with the question of user interface. Instead, the project trusts the existing applications provider (ANS) in terms of the human-machine interface aspect and then concentrate on the access security aspect to those applications. However, some details are below illustrated to explain how the end user will interact in transparency with the whole system without caring about the complexity architecture of the system that satisfies their needs; the main user concerns here are related to data inputs and outputs procedure.
In that concerns the system inputs, the user should dispose a typical web browser able to handle SSL-based HTTP requests, that means containing registered certification authorities or able to permit the SSL request certificate from the Service Provider Certification Authority. The primary input that the user should provide through their web browser address bar is the address URL of the remote protected resource they want to access. The secondary inputs comprise the user access parameters also called credentials (user name & password) to be entered through the friendly ANS IdP interface. Once the resource is granted, the user can thereby start browsing within it accordingly. Browsing inside the protected resource(s) is out of the scope of this project.
Regarding the system outputs, the user after successful login can view and interact with the page(s) of requested resource(s). Again, what is important here is the authentication mechanism; so, how the applications interfaces look like, their ease to use and displayed outputs is not dealt with in this project. To log out the resource, the user proceeds via the existing sign out method provided by the existing application, or click on the sign out/log out link to be defined during implementation, or can just close the web browser to completely terminate the session in accordance with the Shibboleth rules.
Page 59 of 125
2012/2013
Chapter 6: Implementation
The previous chapter dealt with the whole system design and architecture in the two prototypes designs. The current chapter will treat the implementation part of the project based on the previous chapters and mostly focusing on the two types of system architectures. This implementation is to be carried out in two phases, the initial phase related to the primary prototype and the second phase related to the real time prototype. Some sections already covered in the initial phase and similar to the second phase will not be covered twice. Whatever the implementation phase, all is based on the Shibboleth Service Provider 2.5.2 (latest version) and the Shibboleth Identity Provider 2.4.0 (latest version).
The implementation process is valid for Microsoft Windows 7 (Ultimate and Professional editions), Microsoft Windows Sever 2008 R2 and Microsoft Windows Server 2003 R2; all 32 or 64 bits. This implementation process is also valid for all Shibboleth SP 2.X and IdP 2.X. Some steps may be modified and some elements included or excluded if one wants to follow these project implementation scenarios through other Operating Systems than the above listed. For Linux based OS, the installation processes are quite different, but the configurations are almost the same. The implementation is highly based on the Shibboleth main documentation website, Switch website and Shibboleth mailing lists. Related software deployments are based on the according documentations and mailing lists. Because Shibboleth is too wide, all the details are not mentioned in this project implementation and it is strongly recommended to refer to
wiki.shibboleth.net and Shibboleth mailing list for further understanding of some concepts. Likely, it is strongly recommended to consult the associated software
documentations accordingly and when necessary.
The two prototypes implementations rely consecutively on Windows 7 ultimate & Windows 7 professional (for the SP & IdP) first and secondly on Windows Server 2008 & Windows Server 2003 (for the SP & IdP). Regardless of the prototype implementation, below is the list of software tools to be installed and deployed.
For the Service Provider related applications IIS7 (Web server hosting the protected resource and binding Shibboleth to that resource)
Page 60 of 125
2012/2013
Shibboleth Service Provider 2.5.2 (Shibboleth SP software)
For the Identity Provider related applications JRE7 (Java client supporting Tomcat and OpenDJ processes) Apache Tomcat 6 (Servlet container for java web classes) Identity Provider 2.4.0 (Shibboleth IdP software) OpenDJ 2.7 (LDAP Server serving as the IdP database and directory system)
In addition, a suitable editor software has to be install first to edit and configure all the configuration files such as .xml, .html, .properties, .workers, .logger and other files formats. The one used in this project is Notepad++.
6.1 Primary implementation

The primary implementation aims to demonstrate step by step the deployment and the configuration of Shibboleth with a test of a sign on to a simple protected resource, in regard to the project specifications. This section will also help to understand some points of the real time implementation and there will not be a need of repeating the explanation or the description of some deployment steps. This implementation is sequenced into 6 main consecutive steps as follows and includes the above listed related applications: 1. Installation and deployment of Shibboleth Service Provider 2. Installation and deployment of Shibboleth Identity Provider 3. Network access, FQDN and addresses binding 4. Further configuration of the Service Provider 5. Further configuration of the Identity Provider 6. Integration of a simple html resource to Shibboleth and sign on test 6.1.1 Installation and deployment of Shibboleth Service Provider The prerequisite of the service provider implementation is the IIS installation and configuration, the generation and the binding of a self-sign SSL certificate to encrypt incoming and outgoing packages.
Page 61 of 125
2012/2013
6.1.1.1 Installation and Configuration of IIS 7 Windows 7 ultimate comes with IIS 7 tools; there is just a need of enabling and installing them according to the Shibboleth SP documentation. Shibboleth SP deployment within IIS 7 should satisfy the following specifications. Get to the Server rules and enable the labelled "IIS 6 Management Compatibility" services that will help Shibboleth installer to use those management interfaces and perform some automatic configurations. Make sure ISAPI filters and extensions is also installed. The services setting are shown on the figure 17 below.
Figure 17: IIS 7 required services setting
Still in respect to Shibboleth installer requirements prior to the SP installation, launch the IIS Manager, double click the Share configuration feature, disable it and apply the configuration.
To secure an IIS 7 website, it is also important to generate, install an SSL x509 certificate and bind it to the website. To do so, go to IIS service and double-click on Server Certificates feature. On actions, click on Create Self-Signed Certificate, deploy and bind it to the IIS default website. To test the certificate installation, request
Page 62 of 125
2012/2013
https://localhost/ in the web browser, a security alert should appear asking for a permission to proceed; that means the certificate has been deployed successfully. In this implementation, the SSL certificate is self-signed and named shibssl with the extension .pfx. 6.1.1.2 Installation of Shibboleth SP 2.5.2 Setup After downloading the shibboleth .msi file from shibboleth.net website, run the installer and set parameters as shown on the figure 18. All other options let default.
Figure 18: Installation of SP settings After setting the above parameters, click on next, then complete the installation.
Check Shibboleth SP installation To check the success of the application installation, get to windows Administrative tools> Services and make sure the Shibboleth 2 Daemon service has the following parameters: Status: Started, Start-up Type: Automatic, Log on As: Local System. Check the integration of Shibboleth SP to IIS In order to verify whether the integration of Shibboleth to IIS has been done properly, open the IIS manager and check if the Shibboleth ISAPI filter is installed by clicking on the server name and opening ISAPI filters. The integration success is indicated by the following information: Name: Shibboleth, Executable: C:\opt\shibboleth-sp\lib\shibboleth\isapi-shib.dll.
Page 63 of 125
2012/2013
The initial installation of Shibboleth and its integration to IIS is now done successfully. Following is the description of Shibboleth main directories that will be of a particular interest for the next steps in the whole system deployment. C:\opt\shibboleth-sp\etc\shibboleth:
Directory of main configuration files, notably the
most important one, shibboleth2.xml. C:\opt\shibboleth-sp\var\log\shibboleth:
Directory of log files to be consult in case of
system issues. The most important file in this directory is shibd.log C:\opt\shibboleth-sp\var\run\shibboleth:
Process ID and socket files are stored in this
runtime directory. C:\opt\shibboleth-sp\var\cache\shibboleth:
It is here that CRL files and metadata backup
are stored. C:\opt\shibboleth-sp\lib\shibboleth:
Directory containing.dll and .so files
Initial test The initial test is to definitely ensure that Shibboleth has been installed, is running properly and its surrounding environment is ok. To do so, browse
https://localhost/Shibboleth.sso/Status
to view the Shibboleth SSO status. By also running via command line, it is noticeable that the overall
C:\opt\shibboleth-sp\sbin>shibd.exe check
configuration is loadable. This command can be used every time to test whether the SP is running properly or not. When the initial test is successful, it means the Service Provider is running well and ready for further configuration.
To stop the SP daemon/ service, run on command line net stop shibd_default and to start it net start shibd_default. Or these can be achieved by stopping and starting the web server IIS.
6.1.2 Installation and deployment of Shibboleth Identity Provider The IdP installation and deployment sequence within Windows 7 professional is as follows.
Page 64 of 125
2012/2013
6.1.2.1 Installation and configuration of JRE 7 Without Java Runtime Environment (JRE) installed and configured accordingly, it cannot be possible to install Tomcat and the IdP successfully regarding this implementation scenario. This JRE 7 is also the prerequisite for the OpenDJ installation. After the installation of JRE 7, JAVA_HOME environment variables in windows is set by going to Advanced system settings >System Properties>Advanced>Environment Variables. Under
System variables, (x86)\Java\jre7
click New and type JAVA_HOME for the Variable name and C:\Program Files
(the JRE 7 installation directory) for the Variable value and apply. The
figure 19 shows the overview of the above configuration.
Figure 19: Configuration of JAVA_HOME variables
6.1.2.2 Installation and configuration of Apache Tomcat 6 Installation The installation of Tomcat is quite simple since there is only the need of specifying the installation directory (that can be any), the HTTP/1.1 Connector at 8080 (default), providing administrator credentials and the path of JRE previously installed.The verification of Tomcat installation is done by browsing the http://localhost:8080 after
Page 65 of 125
2012/2013
starting the tomcat service; the apache tomcat home page is displayed as on the figure 20 below, that is the successful result of the installation.
Figure 20: Tomcat 6 home page access
Configuration changes in regard to the IdP Xerces and Xalan endorsement: To endorse Xerces and Xalan libraries, create a directory called endorsed under Tomcat 6 directory, i.e. C:\Tomcat 6.0\endorsed, then copy all the .jar files from the IdP source endorsed directory i.e \shibbolethidentityprovider-2.4.0\endorsed into
the new endorsed directory (C:\Tomcat 6.0\endorsed).
Setting of JAVA_OPTS environment variable in Tomcat: This is done by going to

Tomcat Manager>Configure>Java.
Under Java Options, type -Xmx512m
and -
XX:MaxPermSize=128m
and apply. Where 512 is the value of memory in Megabytes
to be allowed and 128 the maximum value of memory specified by Sun Java Virtual Machine (JVM) for the generation object space. Below on figure 21 is the overview of the JAVA_OPTS variable setting.
Figure 21: JAVA_OPTS variable setting on Tomcat
Page 66 of 125
2012/2013
SOAP Endpoints and SSL configuration Because Shibboleth SP and IdP are intended to communicate and exchange remotely information each other, there is a need of configuring an additional port called Connector for secure communication. This will help both providers to enhance their security requirements. Below is the procedure followed to satisfy that configuration. Download the Tomcat library tomcat6-dta-ssl-1.0.0.jar and place it into C:\Tomcat
6.0\lib.
Modify the server.xml file in C:\Tomcat 6.0\conf by adding the following connector definition (that content should be inside <Service> element of server.xml file).
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" SSLImplementation="edu.internet2.middleware.security.tomcat6 .DelegateToApplicatio nJSSEImplementation" scheme="https" SSLEnabled="true" clientAuth="want" keystoreFile=" C:\IDP\credentials\idp.jks" keystorePass="mypassword" />
idp.jks
is the certificate provided by Shibboleth that will help to secure Tomcat by
enabling the SSL protocol. Note: C:\IDP\ is the directory used to install the IdP and mypassword used during the IdP installation. Note: Another method of creating and using an SSL certificate within Tomcat can be done as below: Generating a keystore, that contains a single self-sign certificate to store the private key of the server by executing C:\Program Files (x86)\Java\jre7\bin\keytool genkey -alias ans -keyalg RSA
on the command line. The output of that execution is
set as shown on the figure 22 (where password, path, organisation and other parameters are defined).
Page 67 of 125
2012/2013
Figure 22: SSL certificate deployment on Tomcat The keystore is saved at the root (directory) of the user at which it has been ran, i.e. C:\Users\Shibboleth IdP\.keystore Activating the certificate to make it usable by Tomcat. As the certificate is already in place within the keystore, just configure Tomcat to import it by modifying
server.xml
file included in C:\Tomcat 6.0\conf. The configuration consists of
commenting out the section <Connector> after the comment-line that starts "Define a
SSL HTTP/1.1 Connector on port 8443"
and add more parameters according to the
keystore registration as follows.

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" keystoreFile="C:\Users\ShibbolethIdP\.keystore" keystorePass="somepassword" clientAuth="false" sslProtocol="TLS" />
Save the server.xml file, restart Tomcat and check if the certificate has been properly implemented. To test, browser https://localhost:8443, as a result the, the security notification page is displayed and after the validation the home page of Tomcat is displayed successfully as it was the case for http://localhost:8080 browsing.
The above self-signed certificate should not be used at the same time with the certificate provided by Shibboleth Identity provider. Otherwise, the implementation will face some issues.
6.1.2.3 Installation of the Identity Provider software There are two ways to proceed to the IdP installation under Windows environment: Either by simply executing the Shibboleth IdP .msi file (windows installer) and follow the instructions or running the install.bat (in the IdP folder source) via the command line.
Page 68 of 125
2012/2013
The second option is adopted for a better control of the installation. The figure 23 below shows the successful installation of the IdP with parameters customized appropriately.
Figure 23: IdP installation
idp.war deployment strategy on Tomcat This configuration is to specify how Tomcat will deploy properly the idp.war web application. The technique used is called Context Deployment Fragment that consist of creating a short xml code named idp.xml and put it inside \conf\Catalina\localhost\ under Tomcat directory; i.e. C:\Tomcat6.0\conf\Catalina\localhost\idp.xml. The code content is the following:
<Context docBase="C:\IDP\war\idp.war" privileged="true" antiResourceLocking="false" antiJARLocking="false" unpackWAR="false" swallowOutput="true" />
This code tells to Tomcat where to get the idp.war to deploy and also specify to Tomcat the properties of the web application. By browsing http://localhost:8080/idp/profile/Status, the web page displays ok, the same result for https://localhost:8443/idp/profile/Status to indicate that idp.war has been successfully deployed within Tomcat.
Page 69 of 125
2012/2013
The IdP service can be stop and restart by stopping and restarting the servlet container Tomcat.
6.1.3 Network access, FQDN and addresses binding Before proceeding to advanced configuration of the SP and the IdP in order to get them communicating, there is a mandatory need to set up an IP network with successful resolution of IP addresses to fake hostnames. Fake hostnames are discretionary full qualified domain names (FQDN). The reason of using FQDN is because it is one of the main Shibboleth recommended requirements mostly when it comes to define entitiesID. 6.1.3.1 Network access configuration Two private IP addresses in the same network have been chosen and the network has been configured suitably in order to get the two servers exchanging packets properly. The mask used for the two addresses is 255.255.255.0. The figure 24 below shows the IP addresses assignment with corresponding fake hostnames and ports.
Hosts (Servers) Service
OS
IP addresses Fake hostnames
http ports
https ports
Windows 7
192.168.0.2
ans.247lib.com
80
443
Provider Server Ultimate Identity Windows 7 192.168.0.3 amlib.co.uk 8080 8443
Provider Server Professional Figure 24: IP addresses, hostnames and ports assignment
To fake the hostnames or map IP addresses to arbitrary domain names (ans.247lib.com and amlib.co.uk), get to C:\Windows\System32\drivers\etc of each machine server and modify the entries of hosts files by adding addresses and corresponding hostnames as follows.
# localhost name resolution is handled within DNS itself. # # 127.0.0.1 ::1 192.168.0.2 192.168.0.3 localhost localhost ans.247lib.com amlib.co.uk
Page 70 of 125
2012/2013
After doing the above configuration, it should be already possible to ping IP addresses through hostnames in the same machine (not yet remotely). To get remote ping access of IP address through hostnames, the host name resolution has to be configured on each machine by going to the corresponding wireless network Properties then Internet Protocol Version 4 (TCP/IPv4)>Advanced>DNS and add the IP address mapping each server. After that configuration it should now be possible for each server to convert IP addresses in hosts entries to host names for remote access. The ping of hostnames and IP addresses work properly regardless of where the ping is initiated from and to. The successful ping example below shows how amlib.co.uk is reachable (through 192.168.0.3) from 192.168.0.2 (ans.247lib.com).
Figure 25: Hostname resolution test 6.1.3.2 Binding IP addresses & Hostnames to IIS and Tomcat By default, IIS and Tomcat are all bound to the IP address 127.0.0.1 corresponding to the hostname localhost. It means the way to access both web servers default pages is the browsing of the local hostname or IP address (specifying the port number and the protocol where and when appropriate). There is the need to be able to do the same through the defined IP addresses and hostnames. For IIS Get to IIS default website in IIS Manager, then Bindings>Add to provide the entries of a new binding regarding the corresponding IP address, hostname and ports. The figure 26 below shows the two bindings added in the default website.
Page 71 of 125
2012/2013
Figure 26: IP addresses and hostnames binding on IIS
The result of the above bindings is that the default IIS page is accessible through 192.168.0.2 and ans.247lib.com from 192.168.0.2 (SP Server) and from 192.168.0.2 (IdP Server) as well.
For Tomcat Get to C:\Tomcat 6.0\conf and edit the server.xml file by adding the following code:
<Connector port="8080" protocol="HTTP/1.1" address="192.168.0.3" hostname="amlib.co.uk connectionTimeout="20000" redirectPort="8443" />
The result of this Tomcat binding is that the default Tomcat web page is accessible through 192.168.0.3 and amlib.co.uk from 192.168.0.3 (IdP Server) and from 192.168.0.2 (SP Server) as well.
The figure 27 below shows a successful test example of
the IP addresses and
hostnames binding and resolution within the network. Each request is browsed from a different server.
Page 72 of 125
2012/2013
Browsed from the SP Server (IIS), the same result will be obtained if the HTTPS protocol is applied on the request.
Browsed from the IdP Server (Tomcat), the same result will be obtained if the HTTPS protocol is applied on the request.
Figure 27: IP addresses and hostnames binding and resolution within the network
All the parameters are ready to proceed to further configurations of the SP and the IdP. It is necessary to define the entitiesID of both SP and IdP. It is a sort of naming format that will help the SP and the IdP to know and identify each other. It has been specified as below: SP: entityID="https://ans.247lib.com/shibboleth" IdP: entityID="https://amlib.co.uk:8443/idp/shibboleth"
Note: Throughout the following configurations, the SP and IdP metadata are not dynamically updated. That means any modification made that can affect both IdP and SP metadata is to be manually updated within those metadata.
Page 73 of 125
2012/2013
6.1.4 Further configuration of the Service Provider The amount of needed SP configuration depends on the specifications of the project. The configuration consists of modifying and adjusting the default configured values automatically set during the installation. The full content of files to be modified will be available in the Appendixes. The configuration processes can be better controlled and fixed in case of failure or errors by checking when necessary the SP log files located in
C:\opt\shibboleth-sp\var\log\shibboleth.
The most useful log file in that directory is shibd.log. The
use of Shibboleth log files is also the best way of diagnosing and troubleshooting occurred issues within Shibboleth systems.
The first configuration step to be viewed in the next figure consists of: Modifying primary default configuration by replacing the default SP entity ID by the one set above (https://ans.247lib.com/shibboleth), modifying and adjusting the IdP entityID, defining the error template message and indicating the right hostname. Allowing IIS web server to enable ISAPI filter by populating ISAPI element with
sites
elements reflecting the host configuration and make use of the RequestMapper
element to apply content setting. Every time the ISAPI is modified, IIS has to be restarted. Getting the SP to communicate with the IdP by informing the SP about the IdP metadata location. To trust and talk together, both SP and IdP need to know and have access to each other metadata. That function is set within the
Metadataprovider
element. The Metadatafilter elements have been commented out at
this stage of configuration because there is no need of them currently.

Shibboleth2.xml
is the main service provider configuration file located in C:\opt\shibbolethThe concerned parameters to be configured/ modified at this step of
sp\etc\shibboleth.
implementation are within the table below with related xml elements. Parameters
ISAPI and Site
Xml element
<ISAPI> &<Site>
Configuration value
ISAPI normalizeRequest="true" safeHeaderNames="true" Site id="1" name="ans.247lib.com"
Request Mapper and Host name
<RequestMapper>,<Re questMap> & <Host>
RequestMapper type="Native" RequestMap applicationId="default" Host name="ans.247lib.com" Path name="secure" authType="shibboleth"
Page 74 of 125
2012/2013
requireSession="true" entityID <ApplicationDefault s> ApplicationDefaults entityID="https://ans.247lib.com/shibboleth " REMOTE_USER="eppn persistent-id targetedid" IdP/SSO entityID <SSO> entityID="https://amlib.co.uk:8443/idp/shib boleth" SAML2 SAML1 Error template and property <Error> Errors supportContact="support@247lib.com" helpLocation="/about.html" styleSheet="/shibboleth-sp/main.css" IdP metadata <MetadataProvider> MetadataProvider type="XML" file="C:\opt\shibbolethsp\etc\shibboleth\idp-metadata.xml" Sessions policy <Sessions> Sessions lifetime="28800" timeout="3600" relayState="ss:mem" checkAddress="false" handlerSSL="false" cookieProps="http"
Figure 28: Shibboleth2.xml configuration overview
The second configuration step consists of modifying another important file in the same directory, attribute-map.xml that determines users attributes to be mapped and released to applications to Shibbolize. The default configuration comes with most of the attributes elements commented out. Apart from the attribute element with the
id="targeted-id"
(not needed), all others are to be uncommented out to allow a maximum
of attributes to be released for experimentation purpose. The full content of that file is also included in appendix part of this report. Other configuration xml files within C:\opt\shibboleth-sp\etc\shibboleth (attribute-policy.xml,
example-metadata.xml, protocols.xml, and security-policy.xml)
are let by default in this
implementation because they are more reserved to very advanced implementations.
The idp-metadata.xml file present in the above directory has been copied from the IdP metadata directory to define and set the IdP metadata loading by the SP through a local path as indicated in the file parameter within the Metadataprovider element in the figure 28 above, instead of the http manner. This is because the deployment is within a local network. With a deployment where the SP and the IdP are not in a local network, it would be necessary and recommended to inform each entity about the other metadata
Page 75 of 125
2012/2013
through http path. As the idp-metadata.xml is an IdP file, its setting details will be provided in the next section related to the IdP configuration.
It is also important to set the debug logging for the SP most important log file by adding in C:\opt\shibboleth-sp\etc\shibboleth\shibd.logger the following line
log4j.rootCategory=DEBUG, shibd_log.
6.1.5 Further configuration of the Identity Provider The full contents of all the configuration files to be manipulated in this section will be included in the Appendix as well. IdP log files are located in C:\IDP\logs. The most useful log file is idp-process.log, whereby occurred errors can be checked when something is going wrong in the system or to see regularly if a configuration has been set and applied successfully or also to see a test result following a specific configuration. The IdP configuration is to be proceeded relying on the following steps:
6.1.5.1 Getting the IdP to know and communicate with the SP The main IdP configuration file in regard to the SP is relying-party.xml that is included as other IdP configuration files within the directory C:\IDP\conf\ . relying-party.xml needs to be modified by indicating the SP metadata in Metadataprovider element. Below are the parameters and values to be set in that element.
id="ShibbolethMetadata" xsi:type="metadata:FilesystemMetadataProvider" metadataFile="C:\IDP\metadata\some-metadata.xml" maxRefreshDelay="P1D"
Note: The SP metadata (some-metadata.xml) specified in the above path has been first downloaded and renamed from the SP server by browsing
https://ans.247lib.com/Shibboleth.sso/Metadata.
Update the relying-party.xml and idp-metadata.xml files within C: \IDP\metadata by adding the port number 8443 in front of all https://amlib.co.uk within URLs; and even in any other files. Example: entityID="https://amlib.co.uk:8443/idp/shibboleth instead of
entityID="https://amlib.co.uk/idp/shibboleth, Location="https://amlib.co.uk:8443/idp/profile/Shibboleth/SSO
instead of Location="https://amlib.co.uk/idp/profile/Shibboleth/
Page 76 of 125
2012/2013
Basically, the port number of the IdP hostname should be specified everywhere throughout this implementation.
Define which user attributes can be released to the SP by making sure those attributes elements are uncommented out in C:\IDP\conf\attribute-resolver.xml. The attributes made available in this implementation are in the Appendix part of this report. One of those releasable attributes below shows that a user surname can be sent to the SP using the LDAP database as reference.
<resolver:AttributeDefinition xsi:type="ad:Simple" id="surname" sourceAttributeID="sn"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:sn" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.4" friendlyName="sn" /> </resolver:AttributeDefinition>
It is also necessary to filter (for more security) which user attributes should be effectively sent to the Service Provider portal. This is set in C:\IDP\conf\attribute-filter.xml. The
configuration of attribute-filter.xml presenting all the attributes to be released is in the Appendix. Below is the example of an authorised attribute within
<afp:AttributeFilterPolicy>
and
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://ans.247lib.com/shibboleth" />
elements permitting a user
surname to be effectively released to the SP portal.

<afp:AttributeRule attributeID="surname"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> </afp:AttributeFilterPolicy>
6.1.5.2 Creation of user login and authentication system Shibboleth itself does not authenticate users; it instead relies on and makes use of an authentication method or system. There are several authentication methods supported by Shibboleth (IdP). All the authentication methods are by default included in handler.xml file within C:\IDP\conf\ and in LoginHandler elements. After choosing one of the methods,
Page 77 of 125
2012/2013
the rest should be deleted or commented out except the last LoginHandler at the bottom of the file that provides the single sign on mechanism.
Based on the project specifications, the authentication method used in this implementation is Username/Password through LDAP JAAS. The login handler in
handler.xml
file is configured as below:
<ph:LoginHandler xsi:type="ph:UsernamePassword" jaasConfigurationLocation="file:C:/IDP/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProte ctedTransport</ph:AuthenticationMethod> </ph:LoginHandler>
Regardless of the Operating System running, forward slashes are used to specify that JAAS configuration location, that is an Oracle/java specification. login.config is the LDAP JAAS configuration file. The code within login.config will be set on a basis of the LDAP server deployment. 6.1.5.3 LDAP Server deployment The LDAP Server used is OpenDJ, a forks of Java OpenDS. The version is 2.7 which supports LDAP3 protocol and integrates an LDAP browser client and entries examples to quickly make initial configurations. The figures 29 and 30 below show the installation of OpenDJ and linked to the IdP by the localhost connection handler (same physical server). The installation is initialized by executing the setup.bat file within the decompressed path \OpenDJ-2.7.0-20130627\opendj.
Page 78 of 125
2012/2013
Figure 29: LDAP Server installation and settings
Page 79 of 125
2012/2013
Figure 30: LDAP Server installation review
At the end of the installation, the system automatically imports 20 entries as indicated earlier during the installation process. The 20 entries correspond to a creation template of 20 users that can be modified and made use as proper users. The most important settings during the installation in regard to the connection to login.config or generally regarding the communication with the IdP are: Fully Qualified Hostname: amlib.com Base DN: dc=amlib,dc=com Password: somepassword Ldapurl:localhost Port:389
If login.config content and the ldap connector within attribute-resolver.xml do not match the above settings, the connection to LDAP Server (OpenDJ ) or the authentication will fail. The fully qualified name is just to meet the installation requirement as the real hostname of the server hosting the IdP and OpenDJ is amlib.co.uk or localhost. Localhost is used because both IdP and OpenDJ are in the same physical server. OpenDJ is started by running \OpenDJ-2.7.0-20130627\opendj\bat\start-ds.bat and stopped by running stop-ds.bat in the same directory.
Page 80 of 125
2012/2013
6.1.5.4 Login and authentication configuration After LDAP server has been implemented, the next step of the system authentication deployment is to add a code in the login.config file that matches the LDAP settings and directory data and then to configure in attribute-resolver.xml the mechanism by which the IdP should connect to the LDAP server and entries. Both login.config and attributeresolver.xml
are located at C:\IDP\conf\login.config.
login.config content
ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule required ldapUrl="ldap://localhost:389" base="dc=amlib,dc=com" ssl="false" userField="uid" subtreeSearch="true" ServiceCredential="somepassword"; };
The serviceCredential is he password used during the installation of OpenDJ
attribute-resolver.xml LDAP Connector/ DataConnector element

<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc" ldapURL="ldap://localhost:389" baseDN="dc=amlib,dc=com" principalCredential="kenardo">
<FilterTemplate> <![CDATA[ (uid=$requestContext.principalName) ]]> </FilterTemplate> </resolver:DataConnector>
logging.xml
Moreover, the logging of LDAP related messages should be enabled in the file
C:\ \IDP\conf\logging.xml
with the following codes:
<logger name="edu.vt.middleware.ldap.jaas.JaasAuthenticator" level="DEBUG" /> <logger name="edu.vt.middleware.ldap" level="DEBUG"/>
Page 81 of 125
2012/2013
That will help to know about process logs affecting LDAP and JAAS
Normally at this stage and if all have been proceeded well, a successful test can be made properly. However it is more interesting to make a test with a configuration and customized login page.
Configuration of the ANS IdP login page In order to have an IdP login page with ANS logo, labels, links and other options, the Shibboleth IdP default login page must be changed within the IdP installation package. The file to be modified is login.jsp, located at \shibboleth-identityprovider-2.4.0-bin\shibbolethidentityprovider-2.4.0\src\main\webapp.
The login.jsp content is included in the Appendix. After
the modification, the IdP installation should be updated to apply the customization to the system. Note: Updating the IdP installation implies reinstalling the IdP application by not overwriting the existing installation. Before starting the login page customization, a backup of the current system configuration must be made for more security as any inconvenience can occur when updating the installation.
The login page customization can also be made prior to the IdP first installation to avoid the need of having to reinstall the IdP after configurations.
6.1.6 Integration of a simple html resource to Shibboleth and sign on test To test the IdP connection to OpenDJ and the primary implementation, the simple sign on and the authentication performance when a user wants to access, a simple html page (index.html, describing 247lib.com) has been created and hosted into
C:\inetpub\wwwroot\secure
(a created sub directory within IIS hosting directory) as defined
in shibboleth2.xml in RequestMapper element, host and path sub-elements. The test is made by using one of the created users in OpenDJ. The user credentials comprise username: jean and password: jean2.
The test process consists of the following: A user (Jean) with Google chrome browser requests the protected html resource (index.html) hosted in the SP server. The SP redirects the user request to the IdP server for the IdP to verify if there is an existing session with the user's attributes, if yes the user is granted the resource, if not the IdP
Page 82 of 125
2012/2013
sends an ANS- IdP authentication page to the SP to be redirected to the user. The user enters their credentials (jean & jean2). The SP receives those credentials and redirects them again to the IdP. The IdP check through its Ldap database to see if the user is registered, if not the access is denied, if yes the IdP gives a positive authentication response to SP ( user access authorisation). The SP verifies the IdP signature through its metadata just to confirm that the IdP is valid and legal and then finally grants the resource to the user. The figure 31 below shows the IdP login/authentication page after the user Jean has requested the protected resource, after the user authentication has succeeded, the resource has been granted by the user access to the html page.
Login/authentication page
Html page resource
Figure 31: Simple login/authentication test

Page 83 of 125
2012/2013
To log out and completely close the session in accordance with Shibboleth recommendations, the user should close the browser. More details about partial log out and log in back will be provided in the next section dealing with the real time prototype implementation. Furthermore, attributes and servers variables to be used to integrate the ANS web application will also be provided in that next section.
6.2 Real time implementation

The real time implementation aims to describe what has been done in real time within ANS premises and how. Some steps of Shibboleth deployment such as applications installation are not repeated or not presented in detail in this section. However, the main steps are mentioned and for more understanding about a non detailed step, refer to the primary prototype implementation. The main differences between the above implementation and the current one are:
The use of Windows Server 2008 (for the SP) and Windows Server 2003 (for the IdP) during the real time implementation.
The local network with a local domain name was already set, that means no need to care about the FQDN (full qualified domain name) definition and setting.
The above bullet point means the use and the configuration of different hostnames and entitiesID during Shibboleth deployment.
The installation of the LDAP server in the SP box instead of IdP box as in the primary implementation because Windows Server 2003 does not support the LDAP server used in this project.
Different implementation passwords Emphasis on the single sign on, log in back after a log out concerning the real time implementation.
One of the most important aspects in the real time implementation is the precision of attributes release and the particular attribute that the
247lib.com/247libDE Developers need to integrate into the 247libDE login file alongside with servers variables in order to shibbolise 247lib.com/247libDE application and other applications they will need to integrate to Shibboleth in the future.
Page 84 of 125
2012/2013
In addition to the html resource used to test the sign on during the primary prototype, two samples of ASP .NET applications are integrated into the implementation for this prototype, both allowing an authorised user to see their attributes as set in the LDAP server OpenDJ and Shibboleth Server variables to be used to integrate an application that has many pages and/or already has an existing authentication mechanism. The difference between these two ASP .NET applications is the layout of displayed variables.
Regarding the above statements, the real time implementation is conducted relying on the following steps:
1. Installation and deployment of Shibboleth Service Provider within Windows Server 2008 2. Installation and deployment of Shibboleth Identity Provider within Windows Server 2003 3. Specification of the used domain, IP addresses and hostnames 4. Configuration of the Service Provide 5. Configuration of the Identity Provider 6. Integration of many protected resources to Shibboleth and single sign on test 7. Integration approach of 247lib.com/247libDE web application 6.2.1 Installation and deployment of Shibboleth Service Provider Likely Windows 7, the prerequisite of the service provider implementation within Windows Server 2008 is the IIS installation and configuration, the generation and the binding of a self-sign SSL certificate to encrypt incoming and outgoing packages.
Installation and Configuration of IIS 7 within Windows Server 2008
Windows Server 2008 R2 also comes with IIS 7 tools; there is just a need of enabling and installing those tools exactly like the scenario in the primary implementation. Therefore, refer to the previous implementation for the installation and the configuration of IIS 7 as Shibboleth SP requires. The SSL certificate is also created and bound to the default website the same way.
Installation of Shibboleth SP 2.5.2 Setup
Page 85 of 125
2012/2013
The same primary implementation scenario regarding the installation of Shibboleth SP Setup is followed during the real time implementation. So, the reference of this installation is the SP installation scenario in the previous implementation; that is also valid for installation test and the SP binding to IIS verification. 6.2.2 Installation and deployment of Shibboleth Identity Provider The IdP installation and deployment sequence within Windows Server 2003 is alike to the scenario completed within Windows 7 professional in the primary implementation. For further details and deployment screen shots, refer to the section 6.1.2 of the primary implementation. Installation and configuration of JRE 7 Installation and configuration of Apache Tomcat 6 Installation of the Identity Provider software into C:\ANSIdP directory
6.2.3 Specification of the used domain, IP addresses and hostnames Within ANS local network, the local domain used is ans.local that will be used for Shibboleth configuration. The figure 32 below shows the assignment of existing IP addresses, local domain, hostnames within Windows Server 2008 and Windows Server 2003 to the SP and the IdP to be implemented. So this implementation assumes that all the network parameters including IP addresses and hostnames binding to IIS7 and Tomcat 6 have been set and there is no need to deal with that question as it was the case for the primary implementation. Hosts (Servers) Service Provider Server Identity Provider Server Figure 32: Network parameters assignment for the real time implementation To start further configuration and in regard to the above figure, the entitiesID of both SP and IdP are specified as below: Windows Server 2003 172.28.28.33 ans.local rips4.ans.local 8080 8443 Windows Server 2008 172.28.28.31 OS IP addresses Local domain ans.local lonfp2.ans.local Hostnames http ports 80 https ports 443
Page 86 of 125
2012/2013
SP: entityID="https://lonfp2.ans.local/shibboleth" IdP: entityID="https://rips4.ans.local:8443/idp/shibboleth"
6.2.4 Configuration of the Service Provider The first configuration step is the same as in the primary prototype apart from the change of the entity ID, the hostname, the site name and the error element as shown on the figure 33 below regarding Shibboleth2.xml file at this first step as required the real time implementation. Parameters
ISAPI and Site
Xml element
<ISAPI> &<Site>
Configuration value
ISAPI normalizeRequest="true" safeHeaderNames="true" Site id="1" name="lonfp2.ans.local"
Request Mapper and Host name
<RequestMapper>,<Re questMap> & <Host>
RequestMapper type="Native" RequestMap applicationId="default" Host name=" lonfp2.ans.local " Path name="secure" authType="shibboleth" requireSession="true"
entityID
<ApplicationDefault s>
ApplicationDefaults entityID="https:// lonfp2.ans.local /shibboleth" REMOTE_USER="eppn persistent-id targetedid"
IdP/SSO entityID
<SSO>
entityID="https:// rips4.ans.local :8443/idp/shibboleth" SAML2 SAML1
Error template and property
<Error>
Errors supportContact="support@ans.local" helpLocation="/about.html" styleSheet="/shibboleth-sp/main.css"
IdP metadata
<MetadataProvider>
MetadataProvider type="XML" file="C:\opt\shibbolethsp\etc\shibboleth\idp-metadata.xml"
Sessions policy
<Sessions>
Sessions lifetime="28800" timeout="3600" relayState="ss:mem" checkAddress="false" handlerSSL="false" cookieProps="http"
Figure 33: Shibboleth2.xml configuration for the real time prototype implementation The second configuration step consists of exactly referring to the primary implementation and modifying the attribute-map.xml and shibd.logger files as described in
Page 87 of 125
2012/2013
that implementation. The whole contents of these two files configuration can be viewed in the Appendix.
6.2.5 Configuration of the Identity Provider Like in the primary implementation, the entire configuration files are in the Appendix and the principle remains about the same, that is:
- Getting the IdP to communicate with the SP First load the SP metadata in the metadata element within the file C:\ANSIdP\conf\relyingparty.xml.
The SP metadata (some-metadata.xml) is first downloaded by browsing and renaming the downloaded file into some-
https://lonfp2.ans.local/Shibboleth.sso/Metadata metadata.xml.
Then update the relying-party.xml and idp-metadata.xml files within C:\ANSIdP \metadata by adding the port number 8443 in front of all https://rips4.ans.local within URLs; and in any other files. Example: entityID="https:// rips4.ans.local:8443/idp/shibboleth instead of
entityID="https://rips4.ans.local/idp/shibboleth. Basically,
the port number of the IdP hostname
should be specified everywhere throughout the configuration process.
- Configure attributes to be released to the Service Provider First define in C:\ ANSIdP \conf\attribute-resolver.xml users attributes which must be retrieved from the LDAP server and resolved. Then specify in
C:\ANSIdP\conf\attribute-filter.xml
which
retrieved
and
resolved
usersattributes must be effectively released to the Service Provider.
- Creation of user login and authentication system This is done by setting up the Username/password method on the appropriate
LoginHandler
element within the handler.xml in C:\ ANSIdP\conf. The last LoginHandler at the
bottom of the file should also be enabled to provide the single sign on mechanism.
login.config
within C:\ ANSIdP\conf is the LDAP JAAS configuration file. Its content is
defined on a basis of the LDAP server deployment.
Page 88 of 125
2012/2013
- LDAP Server installation and deployment As stated before, instead of deploying OpenDJ LDAP server near the IdP (i.e. in Windows Server 2003 box), this is done near the SP (i.e. in Windows Server 2008 box). The installation process is similar to the one in the primary implementation apart from the FQDN that is set to lonfp2.ans.local in this case and the first dc=example. The overview of these installation settings is: Fully Qualified Hostname: lonfp2.ans.local Base DN: dc=example,dc=com Root User DN: cn=Directory Manager Password: somepassword Ldapurl: lonfp2.ans.local or 172.28.28.31 Port:389 Administration Connector Port:4444 LDAP secure access: disabled Runtime options: Default Directory data: dc=example,dc=com & importation of 20 entries templates Start Server when configuration has completed: enabled Run the server as Windows Service: Disabled
As the LDAP server and the IdP are not in the same box, the LDAP connection handler is configured to allow remote connection to the SP-box IP address 172.28.28.31 since the IdP-box IP address is 172.28.28.33. That configuration is achieved by running on command line C:\OpenDJ-2.7.0-20130627\opendj\bat\dsconfig.bat, authenticating with the installation parameters and following the instructions appropriately to add and enable the IP address 172.28.28.31 & the port 389 within the LDAP connection handler. - IdP connection to the LDAP server This is done in attribute-resolver.xml, by defining the LDAP Connector within the
DataConnector
element in respect to the LDAP installation and configuration as below:
<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc" ldapURL="ldap://lonfp2.ans.local:389" baseDN="dc=example,dc=com" principal="cn=Directory Manager" principalCredential="somepassword">
Page 89 of 125
2012/2013
<FilterTemplate> <![CDATA[ (uid=$requestContext.principalName) ]]> </FilterTemplate> </resolver:DataConnector>
- Login and authentication configuration This is achieved in C:\ANSIdP\conf\login.config, in respect to the above LDAP server installation and the configuration is as below:
ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule required ldapUrl="ldap:// lonfp2.ans.local:389" base="dc=example,dc=com" ssl="false" userField="uid" subtreeSearch="true" principal="cn=Directory Manager" ServiceCredential="somepassword"; };
- Enabling JAAS and LDAP processes to write in idp-process.log Modify C:\ ANSIdP\conf\logging.xml by adding the following codes:
<logger name="edu.vt.middleware.ldap.jaas.JaasAuthenticator" level="DEBUG" /> <logger name="edu.vt.middleware.ldap" level="DEBUG"/>
This helps to diagnose JAAS and LDAP based errors and mistakes.
- Configuration and customization of ANS- IdP login page Like in the primary implementation, the file to be modified is login.jsp, located at
\shibboleth-identityprovider-2.4.0-bin\shibboleth-identityprovider-2.4.0\src\main\webapp
(the IdP installation package). The login.jsp content of the current implementation is also included in the Appendix. After the configuration, the IdP installation is updated as in the primary implementation.
- Configuration and customization of ANS- IdP logout page
Page 90 of 125
2012/2013
This part has not been dealt with during the primary implementation because the process of configuring the login page is similar to the process of configuring the logout page; that is by configuring accordingly logout.jsp within the same directory and applying the configuration the same way. A login back link and other options are also configured in that jsp file to better accommodate the browsing interface. The configuration result of both login page and logout page will be viewed from the initial SSO and logout tests and the configurations contents in the Appendix.
6.2.6 Integration of many protected resources to Shibboleth, SSO & logout tests In the primary prototype implementation, just the single sign on or sign on (i.e. access to a single protected resource) and the log out (by closing the browser) have been achieved and tested successfully. The real time prototype implementation aims to demonstrate the following achievements: Release of defined attributes that can be used to integrate applications with multiple pages and/or with existing authentication mechanism. Those attributes help applications having an existing and internal authentication mechanism to associate Shibboleth as an external authentication system to their existing one; Effective Shibboleth-based Single Sign on access to multiple protected resources or applications; Effective Shibboleth logout by sending a session termination request via the browser.
- Attributes release This section shows the effective attributes released (as defined in the attribute-filter.xml file) when an authenticated and authorised user attempts to access the secure directory
even though there is no content in that directory. Below are the
attributes released and other Shibboleth parameters when the user Fernande Yolande
Kentsa
with username (uid) yoyo attempts to access the above directory by browsing miscellaneous and attributes are obtained by browsing
https://lonfp2.ans.local/secure. These
https:// lonfp2.ans.local /Shibboleth.sso/Session.
Miscellaneous Session Expiration (barring inactivity): 479 minute(s)
Page 91 of 125
2012/2013
Client Address: 172.28.28.33 SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol Identity Provider: https://rips4.ans.local:8443/idp/shibboleth Authentication Time: 2013-08-01T14:20:00.324Z Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport Authentication Context Decl: (none)
Attributes cn: Yolande email: yolande.kentsa@answeb.co.uk givenName: Fernande mobile: 00447445988766 sn: Kentsa telephoneNumber: 00441676637633 uid: yoyo
- Integration of many resources to be protected and SSO For the real time implementation, three applications/ resources are integrated into the SP, by merely customizing them and putting them in the IIS7 protected directory
of Windows Server 2008. The first resource is the one used in
the primary implementation called what_is_247lib, that is a simple html resource describing the ANS application 247lib.com/247libDE. In addition to that resource, two other ASP.NET resources (respectively named
server_variables_user_attributes.aspx &
another_view_of_server_vars_and_attrib.aspx)
and are placed in the same directory. Both
allow a user to view in different layout their attributes and all the Server variables. These ASP .NET applications are particularly important as they help applications Developers to define Shibboleth variables and attributes within the applications login pages and therefore permit the use of Shibboleth as an external authentication system providing the SSO mechanism to applications with existing authentication.
The ASP .NET applications used here are an ASP .NET library downloaded from the internet and customized to match and satisfy the implementation. Both
server_variables_user_attributes.aspx
and another_view_of_server_vars_and_attrib.aspx contents are
included in the Appendix.
Page 92 of 125
2012/2013
The single sign on access to the three resources is achieved by browsing and attempting the access to the secure directory that contains the resources following the same scenario used in the primary implementation. Any user created and authorised in OpenDJ can access all the three resources by browsing https://lonfp2.ans.local/secure. The output is displayed as follows on the figure 34 below.
Figure 34: Multiples resources view
- Log out from the application(s) As recommended by Shibboleth, the best way to log out from application(s) is to close the browser. In addition the current version of Shibboleth does not support the single log out (SLO) mechanism (the mechanism of logging out from many applications at once). However, a user can close a session by sending a session termination to the Identity Provider via Shibboleth Log out request. The log out link is https:// lonfp2.ans.local
/Shibboleth.sso/Logout.
The tests for the full navigation to resources, applications log out, are more described within the next chapter related to the implementation testing.
6.2.7 Integration strategy of 247lib.com/247libDE web application This section provides the strategy whereby the 247lib.com/247libDE Developers will need to apply on the application login file in order to integrate properly that application and other needed applications to Shibboleth for a successful SSO mechanism through Shibboleth/SAML2 protocol. The straight forward integration of 247lib.com/247libDE is not described in this report for some reasons dependent on ANS Ltd security policy. Moreover, that application was
Page 93 of 125
2012/2013
built to directly provide external authentication mechanisms such as Shibboleth. However, this report section describes what ANS Developers will need to include in their application to communicate with Shibboleth and allow its authentication object. It is first of all important to note that HTTP Request Header is the only approach supported by ASP.NET/IIS applications in terms of their integration to Shibboleth. An example of ASP.NET Header Access is Request.Headers("Shib-Identity-Provider"). The principle is quite simple as The IdP and SP have already been configured to add user information to the HTTP Request within attribute-map.xml file on the SP side and within attribute-resolver.xml & attribute-filter.xml files (IdP side). attribute-map.xml configures what attributes to get from the IdP and put in the HTTP Request. attribute-resolver.xml &
attribute-filter.xml
are the similar mapping on the IdP end releasing those attributes to the
SP. The released attributes come through to ASP.NET in Request.ServerVariables; so the key configuration to be done by
247lib.com/247libDE
Developers
resides
on
Request.ServerVariables
within the application login variable. Since 247lib.com/247libDE
existing authentication mechanism is Username/Password based, Developers will just need to set the attribute uid within Request.ServerVariables.
247lib.com/247libDE
will then need to serve all its pages with common URL within Once the ASP .NET application is placed into the secure
C:\inetpub\wwwroot\secure.
directory, it will then need to look for authentication information (from Shibboleth) in
Request.ServerVariables
dictionary and once more the specific key is on the attribute-map.xml
regarding the most important authentication credential (uid) and other attributes
247lib.com/247libDE
would like to get from users controlled by Shibboleth.
Below is an example of Request.ServerVariables setting aiming to understand how and which attributes and variables to take from Shibboleth. In this example, the application retrieves not only specific variables and attributes, but all possible variables and attributes defined by Request.ServerVariables.AllKeys . This example being one of the applications within C:\inetpub\wwwroot\secure will be used within the testing chapter where its output will be provided.
<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Page 94 of 125
2012/2013
<html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server"> <title>HTTP Server Variables</title> </head> <body> <h2>HTTP Server Variables</h2> <table border="1"> <tr> <th>Variable</th> <th align="left">Value</th> </tr> <% foreach (string key in Request.ServerVariables.AllKeys) { %> <tr> <td><%=key %></td> <td><%=Request.ServerVariables[key]%></td> </tr> <% } %>
</table> </body> </html>
To sum up, this chapter constituted one of the most important of this project. It was about the technical aspect of the project implementation. That implementation has been organised into two parts: the primary prototype implementation consisted of defining and deploying architecture of Shibboleth SP and IdP within a self-defined network environment of Windows 7 Ultimate and Windows 7 Professional. That implementation then helped to further understand Shibboleth and implement the real time prototype within ANS local network through Windows Server 2008 R2 and Windows Server 2003 Server. The next chapter will consist of the entire real time implementation testing strategy.
Page 95 of 125
2012/2013
Chapter 7: Testing
The previous chapter dealt with the implementation part of the project. It covered all the major deployment steps of Shibboleth within some Windows based operating systems. It also demonstrated how to prepare the implementation tools and environment. The current chapter deals with the testing strategy of the project implementation. As the real time prototype implementation is more complete and as the primary implementation has been tested, this chapter will be more about the real time deployment testing.
7.1 Testing strategy

As the implementation has been tested in places when the deployment was in progress, the test strategy chosen here is the System testing, also called black box testing. This means there is no need of testing individual units or units groups of the implementation because all the components of the implementation have passed the unit testing and the integration testing.
In this project implementation, unit testing and integration testing, considered to have been taken into account during both primary and real time prototypes implementation, consisted of verifying whether specific system components or group of components have been installed, deployed or configured successfully. For example, the results of
shibd check
command line showed that Shibboleth SP has been installed and runs well
within IIS/Windows Server 2008. The display of Tomcat default page by browsing
https://localhost:8443
or https://rips4.ans.local:8443 proved that the SSL protocol has been
properly deployed within Tomcat/ Windows Server 2003 and is enabled.
The System testing, the most important in this chapter consists of the test of the whole system without requiring the examination of individual and internal configurations aspects of the system. This testing level has been chosen at the end of the implementation because the project client (ANS) needed to see whether the entire implementation is working or not. Moreover, without the other components working well, the entire system could not work, for getting a Shibboleth implementation working successfully is all about getting all its individual installations, deployments and configurations working properly first. For that reason, there was not need to proceed again to individual tests or group tests at the end of the implementation.
Page 96 of 125
2012/2013
7.2 Testing area, stakeholders and environment

As already stated above, the test covered the entire implementation from a user login till their log out as required the project client. This test has been done within ANS local network and in presence of two ANS Representative. After the implementation was finished and after several successful tests, other testing phases have been scheduled and to be carried out with the presence of ANS Representative. As the implementation has been driven within ANS local network and precisely within Windows Server 2008 and Windows Server 2003, those operating systems have been considered to be the only testing area since this project is not a software development where the final application software can easily be deported from a system to other systems or where the test of the software can be made easily in different environments.
7.3 Testing plan, parameters and scenario

The testing plan consisted of creating many users in the LDAP Server (OpenDJ) and providing them with some attributes. All attributes, except the password supposed to be retrieved after successful login. The resources to access to after logging once are:
about_247lib.html, server_variables_user_attributes.aspx another_view_of_server_vars_and_attrib.aspx
Any authenticated users (i.e. registered and authorised within LDAP Server) had to be able to access the above resources and their attributes should be viewed when requested.
Below are examples of attributes of a created user. The user Gilles Rubens Badouet was supposed to access the above listed applications and his attributes viewable upon request.
cn( common name): Gilles email: badouetg@uni.coventry.ac.uk givenName: Gilles Rubens mobile: 07424486426 sn(surname): Badouet telephoneNumber: 07424486426 uid (username): gillo
Page 97 of 125
2012/2013
Password: somepassword
One of the scenarios similar to others consisted of the following: The process assumes there is not a user existing session, which means the user has been newly created and attempts to access resources for the first time.
The user Gilles Rubens Badouet with any internet browser requests the protected resources (the ASP .NET and HTML applications above listed) hosted in the SP server (running in Windows Server 2008). The user launches the request by browsing
https://lonfp2.ans.local/secure.
The SP redirects the user request to the IdP server for the
IdP to verify if there is an existing session with the user's attributes, if yes the user is granted the resource straight forward, if not the IdP sends the ANS IdP authentication page to the SP to be redirected to the user as shows the figure 35 below.
Figure 35: ANS-IdP login portal
The user enters their credentials (gillo & somepassword ). The SP receives those credentials and redirects them again to the IdP. The IdP checks through its Ldap database (using the object uid) to see if the user with uid= gillo is registered with the provided password. If not the access is denied and the user is asked to double check the couple username/password as shows the figure 36 where wrong credentials were provided to the login portal.
Page 98 of 125
2012/2013
Figure 36: User access denied by IdP view
If yes the IdP gives a positive authentication response to SP (user access authorisation). The SP verifies the IdP signature through its metadata just to confirm that the IdP is valid and legal and then finally grants the resources to the user as shows the figure 37 below.
Figure 37: User access to resources granted by IdP
The figure 37 above is the result one of the successful tests made with the testing stakeholders. Further to the above result is the browsing to resources. By clicking on the first resource (about_247lib.html), the user gillo got access to general information about the ANS application 247lib.com/247libDE as shows the figure 37 below, without the need of providing again his credentials.
Page 99 of 125
2012/2013
Figure 37: Access to about_247lib.html resource
By clicking or opening in another tab server_variables_user_attributes.aspx resource, the user also got access to the content of that resource. The figure 39 below shows a little part of that resource content.
Figure 39: Access to server_variables_user_attributes.aspx resource
The third resource was also accessible without the need of providing credentials.
Once the successful test to resources access through the single sign on mechanism was completed, the user attributes defined in the LDAP server and above described could be viewed upon https request, by browsing
https:// lonfp2.ans.local
/Shibboleth.sso/Session.
The figure 40 shows the Shibboleth session parameters and the
attributes output as predefined in OpenDJ LDAP Server.

Page 100 of 125
2012/2013
Figure 40: Example of user access attributes and Shibboleth session parameters The session log out to resources could now be tested as well. The scenario continued, and by clicking on one of the links within the above applications indication the close of session, the user session within all the open resources was terminated and there was need to provide again credentials to log in back to resources. The figure 41 below shows the log out page after the user gillo sent a session close request.
Figure 41: IdP log out portal
Page 101 of 125
2012/2013
However, closing a session does not mean completely logging out from the resource(s) as describes Shibboleth protocol. Terminating a session just sends a request to the IdP to stop maintaining an opened session. The only mechanism of completely logging out from resources/ applications is the close of the browser.
The above testing scenario shows the success of the real time prototype implementation involving a real use case scenario and in presence of ANS Representative. Further testing data are included in the Appendix. Those testing data are some logs in regard to the scenario from a login till the log out. They are notably some extracts from the idp-process.log (IdP end) and shibd.log (SP end). With the implementation test completed successfully, the next part of this work deals with the project management issues and accomplishments.
Page 102 of 125
2012/2013
Chapter 8: Project Management

The previous chapter dealt with the testing aspect of the project implementation in working prototype. This chapter explains the steps, the adjustments and the issues encountered during the project management. It is also about the project schedule, the risk and the quality management.
8.1 Project Schedule and adjustment

As described on the project brief, the project breakdown structure has been similarly followed in some chapters as initially set despite some modifications brought by the project client at a certain level of the project implementation, especially for the real time and working prototype.
The first two months of the project conduct were focused on the project assimilation, investigation and understanding of protocols and related technologies to be used later during the implementation phase of the project. During these months the meetings were organised more with academic supervisors. The first outputs as mentioned within the first chapter of this report covered the general introduction of the whole project consisting of its background, objectives/ incomes and the project scope. The second output covered the project methodology and the literature review whereby further investigation has been conducted to better understand the project related works, protocols to be studied and what the project will definitely deal with than other works did not covered specifically. The
Being further aware of the project objectives, having more information about the protocols and surrounded technologies areas to be examined and knowing the methodology to be used, it was clearer to move forward to the next steps of the project, notably the implementation requirements examination and the system analysis and design. The above two points were covered during the third month of the project management.
The project implementation itself started at the fourth month within a self-defined deployment environment. At a certain level of that implementation considered as the primary prototype implementation in this report, precisely during the early fifth month of
Page 103 of 125
2012/2013
the project conduct, all was almost done and the remaining implementation task was to gather the client application to be integrated within the implementation, as it was initially in accordance with the project client and the supervisors planned to carry out the prototype implementation only within a self-defined implementation environment. However, the client for some reason decided that a real time prototype implementation had to be conducted within his own servers. For that reason, a new implementation considered as the real time prototype throughout this report has been initiated within the client local network. As one of the result of this, the system analysis and design part as well as other points of the project previously examined had to be modified in conformity with the new recommendation of the project client. Furthermore, the initial plan and schedule have to be reviewed and a move and a stay had to be arranged with the project client to carry out the real time implementation within a certain period of time. Already knowing how to implement the major concepts related to the project, it has therefore been easier to proceed to the new and more complete implementation despite some compatibility issues faced during that implementation. The new implementation has been made in about ten days globally.
One of the major modifications was also the fact that the client application itself has not been integrated, but rather some samples of applications, because the client application was not built to accept external authentication systems. However, the integration strategy and all the related aspects have been provided to the client in terms of what exactly to modify on the aforesaid application in order to integrate it to the Shibboleth implementation made.
After the above details and adjustments, the project implementation, alongside with the deployment testing has been totally covered on the first of the sixth month regarding the whole project conduct. completion. The rest of the time has then been granted to the report
8.2 Risk Management and issues

Risk can be defined as an impact or an event having a probability to occur and may have a positive or negative impact to a project management should it occur. The causes of a risk may be diverse and can also have diverse impact when it occurs. This project management section defines the risk management process employed throughout this
Page 104 of 125
2012/2013
project lifecycle. This aims to identify all the risks and issues encountered throughout the project management and would be for a great interest for future works in the field of the project.
8.2.1 Risk analysis techniques The following techniques have been used to support the risk management process on this project: Identification, consisting of identifying threats that have got a certain impact on the project progress during the project lifecycle. Assessment, the impact degree that each risk has had on the project progress or impact probability. Response strategy or risk mitigation, the technique allowing the tackle of each identified risk. Reporting, risk report to supervisors and project client
8.2.2 Risks list, assessment and mitigation strategy The figure 41 below is the summary of the major identified risks during the project conduct, their assessment and actions employed to come up with them.
On that figure, the probability of occurrence is measured with the following values: Frequent with the value 5: The risk occurred frequently Likely with the value 4: The risk occurred less frequently when appropriate action was applied Occasional with the value 3: Occurred sporadically Seldom with the value 2: Unlikely to occur Improbable with the value 1: Very unlikely to occur
The impact degree on the project is how serious the project conducts and management could be affected and this characteristic is classified with the following values: Critical (Red): most serious impact causing >=5 days late in the project progress High (Yellow): Less critical causing between 3 and 4 days late Medium (Blue): Average impact causing between 1 and 2 days Low (Green): Lowest impact causing less than 1 day late
Page 105 of 125
2012/2013
The mitigation strategy is the taken action to provide a positive response to an occurred risk and the code is the assignment and identification number of the risk.
Code
Risk
Probability of occurrences
Impact degree on the project progress
Mitigation strategy
Ri1
Ri2
Computers unavailable to set and conduct the project implementation anytime Unavailability of books related to the project in the University Library
Frequent
Critical
Borrow a computer from a friend
Frequent
Medium
Ri3
Minor misunderstanding on the project real objectives
Seldom
Low
Ri4
Ri5
Modification of the some project initial specifications by the client during the implementation stage Modification of the prototype implementation environment and area
Occasional
Medium
Made use of electronic books, websites, online discussions forums, online publications and the University databases partners Conducted further discussion with the project client and got along on final objectives and deliverables Followed the new client recommendations and specifications
Seldom
Critical
Ri6
Failure of starting the primary implementation within a virtualization environment
Occasional
Low
Ri7
Ri8
Compatibility problems when deploying some tools Some advancement blocking due to configurations problems, errors and mistakes
seldom
Medium
Moved to the client premises and deployed a new prototype implementation in real time within the client servers as specified by the client Set a physical environment consisting of a local ad-hoc network as advised in forums of the project technology (Shibboleth) Proceeded through alternative methods Searched and found the solutions within technologies mailing lists archives or
Occasional
High
Page 106 of 125
2012/2013
discussions Figure 42: Risks assessment of the project management
8.3 Other management issues and countermeasures

This section deals with more technical based issues encountered throughout the project progress during the primary prototype implementation as well as during the real time implementation. The code is the assignment and identification number of the issue. The impact degree on the project progress classified from 1 to 5 shows how long was the time taken to find the solution to a problem (where 1 represents less than one day and 5 over 5 days and over). All this aims to help the future workers to easily find the solution to the same issues or if possible avoid them by anticipation.
8.3.1 Primary implementation issues faced and solutions The figure 43 presents the major problems encountered during the primary prototype implementation, their impact degree on the project advancement and countermeasures.
Code I1
Concerned Area(s)/part(s) Java Runtime Environment
Issue Issue when setting the JAVA_HOME environment variables due to a wrong enter of the JRE7 bin installation directory. Failed to install Tomcat 6 because there was a previous installation of Tomcat 6 that had been uninstalled and it service was still present within windows services Failed to start properly Tomcat service after the installation and the definition of JAVA_OPTS environment variables due to an error of launching the file Tomcat/Java
bootstrap.jar
Impact degree 1
Solution Copied and pasted

C:\Program Files\Java\jre7\bin
to
avoid typing mistakes
I2
Tomcat
Deleted the Tomcat 6 service within windows services by running on command line
C:\>sc delete Tomcat 6 And obtained [sc] Delete Service Success
I3
Tomcat
Had to write -Xmx512m instead of -Xmx512M Within the Java options.
I4
Tomcat & MS Windows
Sometime failed to run Tomcat normally with the error message Access is
Run Tomcat Monitor (tomcat6w.exe) within Tomcat \bin directory as

Page 107 of 125
2012/2013
Denied. Unable to open the service 'Tomcat6'
administrator. 2 Proceeded with install.bat within shibbolethidentityprovider-2.4.0bin.zip, another installer package type When installing the IdP, the hostname has to fulfil the FQHN requirement rule. amlib.ac.uk has therefore been provided instead of localhost. The keystoreFile directory within the connector element had to be properly specified to match the IdP credentials directory set by the IdP installation.
I5
Identity Provider
I6
Identity Provider
I7
Identity Provider Tomcat
&
I8
Identity Provider
Failed to install the IdP using the Microsoft installer shibbolethidentityprovider-2.4.0.msi, due to windows internal error. Failed to continue with the IdP installation at the step of the hostname supply, due to the wrong format of the hostname first provided (localhost). Error when testing if the IdP is running well within Tomcat at the first attempt due to a wrong configuration applied on the file C:\Tomcat 6.0\conf\server.xml in the IdP connector element. Failed to locate the java authentication file login.jsp due to wrong specification syntax of the file path within the handler.xml configuration file and precisely within the LoginHandler element.
I9
Identity Provider
After the configuration and customization of the IdP login portal, faced issues after the IdP installation update to apply the above configurations. In fact when proceeding to the installation update, the existing installation and configuration did not have to be overwritten Failed to connect the IdP
I10
Identity
Within the LoginHandle element, modified the location path setting of java authentication file to file:C:/IDP/conf/login.config" (a special Oracle/Java requirement even if it is about a Windows environment) instead of file:C:\IDP\conf\login.config" as it could normally be according to the Windows slashes syntax As the IdP initial configurations were backed up, just needed to replace the modified configurations files (due to the new installation) by the backed up configurations files. As note, during the IdP installation update, the existing installation and configurations should not be overwritten. Modified within that file the
Page 108 of 125
2012/2013
Provider & LDAP Server
to the LDAP server due to some precision errors within the IdP login.config file. Encountered error when checking if the SP has been installed well and is running properly, due to the directory of the ISAPI configuration to allow the communication with Shibboleth which has not been deployed automatically during the SP installation Failed to locate each entity metadata when testing the communication between the SP and the IdP 2
previous key words spellings as follows: baseDN to base; BindDn to principal; BindCredential to
ServiceCredential
I11
Service Provider & IIS
Manually pointed the Shibboleth ISAPI compatibility element (isapi_shib.dll) to IIS by going to the IIS ISAPI Filters feature and adding the path to isapi_shib.dll.
I12
Service Provider & Identity Provider
I13
Service Provider, Identity Provider & LDAP Servers
I14
Service Provider, Identity Provider, Tomcat & OpenDj LDAP Server
Failed to authenticate users due to wrong configurations or no master, deployments issues of the first tested LDAP server (OpenLdap, OpenDS and Apache Directory Studio). Other issues due to words mistyping, special characters missing (such as \,/, <, >, , ), (, ;,) and more, Case sensitive incorrectness (mostly as Shibboleth is case sensitive and the used LDAP server not.
Instead of using any of the http(s ) based metadata provider within the metadata elements, merely used the Filesystem metadata provider strategy consisting of getting each entity metadata manually and placing it in each configuration directory, and indicating the metadata path within the metadata providers elements through the Filesystem metadata provider manner Finally got a suitable server provider and opted for an LDAP server which is OpenDJ 2.7
Had to check logs files to identify the surrounding areas of mistakes and check the concerned .xml files and other file types in order to correct the mistakes. To avoid such types of mistakes within the next steps of the implementation had to concentrate when editing configuration files
Page 109 of 125
2012/2013
and avoid to type when it is possible to copy and paste. Figure 43: Primary prototype implementation issues and solutions
8.3.2 Real time implementation issues faced and solutions The figure 44 presents the major problems encountered during the primary prototype implementation, their impact degree on the project advancement and countermeasures. Already knowing most types of possible issues and mistakes, it was easier to avoid them and as a result issues faced during the real time implementation were quite few compared to the primary implementation.
Code I15
Concerned Area(s)/part(s) Tomcat/ Identity Provider
Issue Failed to use the Identity Provider based certificate due to the wrong password provided within the
C:\Tomcat6.0\conf\server.xml,
Impact degree 1
Solution Provided the right password used during the IdP installation
I16
OpenDJ
in the connector element Incompatible with the Operating System (Windows Server 2003) hosting Tomcat and the Identity Provider
I17
IIS7 & Service Provider
Failed to launch ASP. NET applications with the error message HTTP Error 403.14 Forbidden The Web server is configured to not list the contents of this directory because of a
Deployed OpenDJ LDAP Server within the Operating system (Windows Server 2008) hosting the Service Provider. Enabled the IIS
Directory Browsing
missing configuration within IIS7/Windows Server 2008 I18 IIS7 & Service Provider Failed to display ASP .NET applications due to the ASP .NET tools missing in IIS. Other mistakes on special characters typing and some words spelling. 1
feature by expanding the IIS Web sites, opening Directory Browsing and enabling it in Actions pane. Installed ASP .NET Tools and features through IIS Roles and Services pane. Checked and corrected the related files
Page 110 of 125
I19
Identity Provider, Service
2012/2013
Provider & Tomcat Figure 44: Real time prototype implementation issues and solutions
8.4 Quality Management

The capability to constantly modify and improve the quality of a product is a strength to a project management. Within a project management, the quality management is the field that aims to ensure that the project output is consistent and provide techniques to evaluate and improve that project output. The standards used to proceed and evaluate this project quality management and its outcomes are the set of techniques within the QMS (Quality Management System) from the ISO (International Organization for Standardization). The specific QMS used in this project management are: The ISO 9000 aiming to guarantee that the project output meets the client requirements and needs and also to ensure that the project will release outcomes. The ISO 190111 audit deals with the project sustainability, quality, transparency and consistency. Satisfaction of the client requirements and needs The project client is ANS Ltd and all the major requirements provided by the client on the project proposal and reviews recommendations and specifications have been fulfilled with the approbation of the client. Therefore and for that reason, it is possible to affirm that the project output satisfied the client.
Project outcomes guaranty The project product released outcomes; apart from the initial implementation made within a self-defined deployment environment, the client requested a real time implementation within his own premises, which has been done successfully. The client will therefore use that prototype implementation alongside with the implementation guide for his future experience and the adoption of the technologies used when appropriate. Moreover, the client requested especially the project management with encountered issues and will be provided with that as well. To support a will of investing in this project, most of the tools used for its deployment are free and open source.
Page 111 of 125
2012/2013
Project consistency assurance To make sure that the project meets the consistency quality, the implementation check up has been made in regard to Shibboleth recommendations in all the aspects of the deployment. Moreover, the initial investigation with the analysis of old related works helped to underline and figure out most crucial aspects to examine throughout the project management.
Project sustainability Since this project output is not a piece of software or an application, the sustainability aspect here resides on this produced report that could contribute for years and could be used by future students, generations and workers interested in the surrounding technologies and protocols. This is one of the reasons for what the project report has been done as clear and detailed as possible. The project client could also make use for long time the real time implementation within his servers.
Page 112 of 125
2012/2013
Chapter 9: Critical Appraisal

The project Investigation and implementation of Shibboleth SSO mechanism through ANS Ltd web application 247lib.com/247libDE dealt with a detailed study of a SAML based protocol with focus on its authentication and single sign on aspect. That protocol or technology called Shibboleth after its examination and its related technologies study has been used for a concrete use case implementation. This project is the final stage of the my master course and aims to explain major aspects and concepts related to Shibboleth and provide one of strategy to implement it on web applications. Based on the specifications and requirements provided by the project client, the objective of this project conduct was to drive advanced research within specialised documentations, forums and seminars about Shibboleth based SAML protocol in order to apply that protocol within a specific use case and following a chosen scenario on a basis of the project client specifications. Further to the completion of the project from the investigation to the implementation, below are personal experiences, the project outcomes and some problems faced throughout the project process.
9.1 Experience and knowledge gained

This project has been a great opportunity to gain rich experience and new skills in regard to the variety of its related fields, technologies, concepts and the dynamism of all the project stakeholders. The technical and analytical steps of the task were for a particular interest as many concepts were quite new to me, at least in terms of the implementation scenario. The investigation and application led me to get in touch with famous and specialised people in the field of the project through forums and webinars. Those specialists provided me with advanced understanding and application of the technologies and concepts related to the project. People contributions across the web and the project stakeholders helped me to accomplish an advanced work and provide a document which may be a contribution to other future workers and to the client for their perspectives and ambitions.
Regarding the analytical and technical aspects of the project I learned from the project, I am definitely glad to affirm at the end of this project that, I am able to define and provide a more advanced analysis and investigation level any specific IT project management. I am mostly capable to define and set up any Shibboleth based protocol project.
Page 113 of 125
2012/2013
Following are the technical fields that I experienced in this project stages and new learnt skills:
- First of all, by investigating the project related works I have already got general ideas and notions about technical aspects to be taken into account throughout the project. Alternatives technologies used to applied similar implementations or how to handle different protocols to provide similar implementations. I can define properly what is Shibboleth, related technologies such as SAML and LDAP and in which context or how to implement it to deal with the security and privacy issues in shared resources or applications access.
- From the above point and due to further research, I learnt from the middle stage of the project how to analyse and design project architectures regarding project requirements in general and this Shibboleth based project particularly. It has also been interesting to understand what prerequisites in terms of applications, Operating Systems and other tools should be set in order to provide an authentication and a single sign on mechanism based on Shibboleth.
- It is clearer to me what specific Shibboleth product should be implemented regarding specific needs. For example the context in which Shibboleth Identity Provider, Shibboleth Service Provider or Shibboleth Discovery Service should be deployed; or when and how to deploy two or all the three Shibboleth main products. Furthermore it is evident to know when the other Shibboleth tools such as OpenSAML-C++ and OpenSAML-Java are needed.
- Before starting this project and although Shibboleth was totally new to me, I had a general Idea or generic definitions on some concepts and protocols such as LDAP, SAML, XML, SOAP, HTTPD, HTTPS, SSO or SSL, but without knowing well how to apply them. I am currently able to apply at a certain level the above protocols for a concrete use. I also know what sort of issues can be faced when implementing such protocols and how to avoid them.
Page 114 of 125
2012/2013
- Still like the above protocols, I had some ideas about technologies such as IIS, Tomcat, Apache Server, Apache DS and more. I now know how to install and deploy them.
- As each project implementation should be followed by a test and evaluation, I learnt during the testing phase of the project how to plan and test a product and how to adjust it to satisfy the client needs.
9.2 Interesting and difficult aspects of the project

Throughout the project process, I have first all of all enjoyed discovering new concepts that were still new to me. I highly appreciated working with my supervisors and the project client. I have also been positively impressed by how committed unknown people across the web could be when it comes to help others. All the forums, webinars and mailing list where I registered in order to find solutions to specific problems have been so helpful and I am pretty sure to keep active within those working spaces even after the project. I registered with Shibboleth, Tomcat, OpenDJ and ASP .NET mailing lists and forums and noticed that people over there were all happy to provide somehow helps to raised problems. It was therefore a great pleasure to work with them.
Even though this project consisted of interesting and great aspects, all has not been always easy. It was quite difficult to start and grasp the context of the project in the beginning since the protocol to examine was almost completely new to me and I took some time to understand the technologies to use and therefore the project itself. I exploited the online databases of the University Institutions partners, but almost none hard book was available in the University Library dealing with the project aspects and surrounding technologies and I therefore based my research and work on online and digital documentations, that was not easy. Another difficulty was when I was about to start the implementation part of the project, I have not be able to borrow a full time computer from the University and was obliged to get it from a friend of mine.
Finally, another point positive and negative was the implementation plan because the project client changed the initial plan that was to set the project implementation within my own self-defined environment. Negative because the new specification
Page 115 of 125
2012/2013
recommended me to travel and provide another prototype implementation within the client servers, and it took me extra long time and I could not finish the project and look beyond for new possibilities as I wanted. Positive because I profited and apply another implementation in real time, and within a different environment. Furthermore, working closer to the client was easier and the collaboration was more realistic as it was within a professional context and area.
9.3 Project outcomes

These project outcomes consist of the following: A detailed report of the Shibboleth and relied technologies and protocols
investigation on a basis of old related works, latest released documentations and personal experience from diverse informative areas mostly day to day discussions with professional of Shibboleth and other linked technologies. Requirements analysis report on a basis of a Shibboleth based project
specifications A system design and analysis report illustrating two types of architectures
according to the two types of implementations. A integration strategy of applications to Shibboleth Two concrete prototypes implementations within different environments, each
with its specificities. A detailed document report on the project management with emphasis on
the issues encountered throughout the project management and solutions.
9.4 Conclusion from the experiences

To sum up, I would like to say that the deliverables provided for this project and the work processes based on advanced investigation and implementation of a core protocol alongside with related protocols led me to highly improve my computer networking and systems integration skills, especially in security aspect within shared resources and web applications access despite some issues encountered during the task achievement. This major stage of my master course in Network Computing Management has been very rich and interesting.
Page 116 of 125
2012/2013
9.5 Case study relation to my course

This project has a straight link with all the previous modules studied within my course, for it treated at a certain level networking aspects in terms of getting remote entities to communicate together and exchange data. It also dealt with the aspect of security of information and infrastructure access, which was one of the fundamental taught topics in my previous modules. In addition, one of the key points of this project was the concept of network protocols on the application layer of OSI model and who says OSI model refers to network protocols and who says network protocols refers to computer networking which is my course name.
Page 117 of 125
2012/2013
Chapter 10: Conclusions

Reached the end of this project, the overall work can be summed up with the following statements. The task consisted first of researching and investigating within and around Shibboleth protocol with the focus on its aspect of single sign on mechanism. Based on the client specifications, the second core stage of the work consisted of using the research result to provide a Shibboleth prototype implementation with an integration strategy of the ANS web application 247lib.com/247libDE.
10.1 Achievements
From the problematic raised by the project description and the project specifications, following are the results and the set of objectives achieved. A methodology of the project investigation and implementation has been accomplished followed by related work with alternative technologies. The investigation methodology helped to understand further the project and grasp the context of Shibboleth within relied protocols. After the methodology and a literature review that aimed to define the implementation approach and what to include within the implementation, the implementation requirements analysis has been provided. That analysis was followed by the system design and analysis that allowed the preparation of the implementation hardware and software architectures and the question of Human-User Interface regarding the implementations specifications aspect. The system design and analysis thereby permitted to first
understand how the implementation stages should look like and to know with exactitude what elements to integrate on the implementation in terms of Operating System environments and software tools. Still following the design analysis and the new client recommendations, it came to conclude the necessity of applying two implementations (primary and real time implementation). The primary implementation gave necessary ideas about all the elements needed to implement Shibboleth and therefore hugely simplified the real time prototype implementation. As the most important was the real time implementation within the client premises, a complete implementation testing has been carried out within that real time implementation including a real scenario of the main use case illustrating a user requesting a protected resources directory and being granted an access authorisation. After the success of that testing, a work related to the project management has been achieved, highlighting the major risks and issues faced
Page 118 of 125
2012/2013
throughout the project conduct. Finally a critical appraisal has been done, describing the main steps including experience and skills gained in the project. It also highlighted the difficulties or negative aspects and the main outcomes of the project.
So the project implementation and final report provided covered the achieved objectives and deliverables set within the project specifications with the respect of the latest specifications modifications and recommendations brought by the project client at certain levels of the project progress.
10.2 Future Work

Although the major objectives and deliverables set by the project specifications have been achieved, although the client recommendations have been fulfilled, it cannot be said at hundred percent that all have been done perfectly. Nevertheless, to the asked questions by the project description, some answers have been provided, to raised problems, some solutions have been found. I therefore think that the accomplished work supplied will contribute to future works in the field of access management within online shared resources, within the single sign on mechanism to multiple shared applications, within SAML protocol and related technologies and mostly within Shibboleth protocol. Future workers could enhance the security aspect of the project implementation, integrating applications and put the implementation in exploitation, which is within the internet since the scope of the actual work is limited to a working prototype. The improvement of this work can also be done by integrating Shibboleth to a set of applications having an existing authentication mechanism and using the Shibboleth Discovery Service to address a context of many Identity Providers. Other workers may also see beyond to extend the idea within the cloud access and any resource types or any web entities access through Shibboleth in terms of user authentication and authorisation aspect.
Page 119 of 125
2012/2013
Chapter 11: Student Reflections

This course module consisting of my individual master project that the conduct is just at the end, has provided me with strong experience in project management in general and in particularly in an advanced IT project management. I learnt throughout the project progress a lot of skills starting from the project investigation until the project implementation. I learnt how to provide high quality research, understand, organise, filter and report professionally information related to a specific track, notably in the field of Shibboleth. Regarding the project implementation, I learnt how to analyse an implementation requirements; based on that requirements, providing a project design and analysis before carrying out the implementation effectively. Therefore, the skills and experience I assimilated during this project are as well managerial, analytical as technical. Technical aspects are highlighted by an advanced understanding and a good implementation of Shibboleth protocol and other related technologies.
As any project, some problems have been encountered throughout the project progress fortunately, alternative solutions have been provided. Some of those problems included a lack of documentation in terms of hard books, the difficulty of acquiring some implementations tools, the modification of the project initial specifications and recommendations, the need to travel to the client company whereas not planned before and sometimes some stress due to the fear of not finishing the project on time. However, those problems got converted into experience since they led to think further in order to get alternative solutions. For example, having failed to get available hard book in the field of my project from the Coventry University library helped to focus and emphasize my research within online and digital resources.
I am glad for the overall output of this project and for the new skills, knowledge and experience this project brought to me. But, I would have liked to move from the working prototype to the real implementation for exploitation in order to better study and analyse the product in real time exploitation and to examine end users comments and behaviours. Also, the prototype implementation could have been more advanced if the project specifications planned everything properly; for example if they planned a real time implementation within the client premises during the hold deployment period and also if the client application to integrate within the implementation was fully ready.
Page 120 of 125
2012/2013
Bibliography and References

Badouet, G, R (2013) Appendix A1: Master Project Brief Form 2012-13: Coventry University
Cantor, S. (2005) Shibboleth Architecture: Protocols and Profiles Coventry University (2013) Master Project Guide
Deshmukh, R (n.d.) A Great Plains Network Report on Shibboleth: Kansas State
Erdos, M., and Cantor, S. (2002) Shibboleth-Architecture DRAFT v05
JISC (2006) Shibboleth, Connecting People to Resources
Neuman, B,C., and Ts'o, T (1994) Kerberos: An Authentication Service for Computer Networks. IEEE Communications Magazine, vol. 32(9), pp. 33-38, Sept. 1994.
Paschoud, J. (2004) Shibboleth and SAML: At least, a viable global standard for resource access management Pub.
Routledge Taylor and Francis Group: New Review of Information Networking, Vol.10, No.2, 2004
Shen, Y., and Du Z.j. (2011) Research and design of single sign-on based on Kerberos protocol: Computer Engineering and Design. vol. 32(7), pp. 2249-2251, July 2011
Tiwari,P,B., and Joshi,S,R. (2009) Single Sign-on with One Time Password. 1st South Central Asian Himalayas Regional IEEE/IFIP International Conference on Internet, AHICI 2009, Nov. 2009
Hansen, S,M., Skriver, J., and Nielson H,R. (2005) Using static analysis to validate the SAML single sign-on protocol: Proceedings of the 2005 Workshop on Issues in the Theory of Security. WITS '05, pp. 27-40, 2005
Page 121 of 125
2012/2013
Nishimura, T., and Sato, H. (2008) LESSO Legacy Enabling SSO: Proceedings - 2008 Inter. Symp. on Applications and the Internet, pp. 301-304, 2008.
Long, Y,H., Li C,Y., Tang, Z,H., and Liu, X. (2010) A Transparent Single Sign-on Solution for Web Legacy System. Information Security and Communications Privacy, pp. 67-69, Oct. 2010.
Fengming, N., Feng, X., and Rongzhi, Q. (2012) SAML-Based Single Sign-On for Legacy System: College of Computer and Information. Hohai University
Ngo, L., and Apon, A. (2007) Using Shibboleth for Authorization and Authentication to the Subversion Version Control Repository System. University of Arkansas
Sinnott, R,O., Jiang2, J., Watt, and Ajayi, O. (2006) Shibboleth-based Access to and Usage of Grid Resources, National e-Science Centre. University of Glasgow
Spence,D., Martin, A., et al. (2006) ShibGrid: Shibboleth Access for the UK National Grid Service
Komura,T., Sano, H., Makimura, K., and Demizu, N. (2011) : Design and Implementation of Web Forward Proxy with Shibboleth Authentication. IEEE/IPSJ under the International Symposium on Applications and the Internet
Sato, H., and Nishimura, T. (2001) Federated Authentication in a Hierarchy of IdPs by using Shibboleth Zhang, Y., and Yang, J., (2010) 2nd International Conference on Future Computer and Communication. School of Information Science and Engineering Shandong Normal University, Volume2
Tschofenig,H., Rainer, F., Hodges, J., et al. (2006) Using SAML to Protect the Session Initiation Protocol (SIP): IEEE Network
Lutz, D., Hecht, F.,et al. (2007) Charging of SAML-based Federated VoIP Services
Page 122 of 125
2012/2013
Zhenxiang,T., and Qian, L. (2012) Design and Implementation of Unified Identity Management System Based on SAML. Engineering Training Center of Wuhan University of Technology in China
OASIS (2008) Security Assertion Markup Language (SAML) V2.0 Technical Overview Committee Draft 02
Salan, O. (2013) Introduction to web architectures of web single sign on
Sandhu, S,S. (2004) Single Sign On Concepts & Protocols. GSEC Practical Assignment Version 1.4b, Option 1
Netegrity, Inc (2001) Security Assertions Markup Language (SAML): The standard XML framework for secure information exchange. Netegrity White Paper
Sidawi, M, W.(2007) Analyzing & Applying Shibboleth at Wikis for Authentication and Authorization
Applied Network Solutions (2013), Welcome to ANS [Online] available from <http://www.answeb.co.uk/index.aspx?menuId=top_home> [10 March 2013]
Applied Network Solutions (2013) Introduction to 247lib.com, Library Management System [Online] available from <http://247lib.com/247libDE/frmLogin.aspx?ReturnUrl=%2f247libDE%2ffrmAuthority.as px>
ANS Ltd, (n.d.) Introduction to 247Lib.com library management system [Online] available from <http://www.247lib.com/ > [28 May 2013]
ForegeRock Community (2013) OpenDJ Directory Services Project [Online] available from <http://opendj.forgerock.org/> [02 July 2013]
Page 123 of 125
2012/2013
ForegeRock Community (2013) OpenDJ: Home [Online] available from < https://wikis.forgerock.org/confluence/display/OPENDJ/Home> [04 July 2013]
James, S. (2007) Web Single Sign-On Systems [Online] available from <http://www.cse.wustl.edu/~jain/cse571-07/ftp/websso/> [10 April 2013]
Microsoft (2013) IIS 7 Configuration Reference [Online] available from <http://www.iis.net/configreference> [05 June 2013]
Organization for the Advancement of Structured Information Standards, OASIS (2007) Assertions and Protocols for the OASIS Security Assertion Markup Language V2.0"[EB/OL] [Online] available from <http://does.oasisopen.Org/security/saml/v2.0> [10 May 2013]
Shibboleth (2013) Shibboleth Consortium [Online] available from <https://wiki.shibboleth.net/confluence/display/consort/Shibboleth+Consortium> [02 March 2013]
Shibboleth (2013) How Shibboleth Works: Basic Concepts [Online] available from <http://shibboleth.net/about/basic.html > [15 March 2013]
Shibboleth (2013) How Shibboleth Works: Intermediate Concepts [Online] available from <http://shibboleth.net/about/basic.html> [16 May 2013]
Shibboleth (2013) How Shibboleth Works: Advanced Concepts [Online] available from <http://shibboleth.net/about/basic.html> [16 May 2013]
Shibboleth (2013) Understanding Shibboleth [Online] available from <https://wiki.shibboleth.net/confluence/display/SHIB2/UnderstandingShibboleth> [20 May 2013]
Shibboleth (2013) Welcome to the Shibboleth Documentation [Online] available from < https://wiki.shibboleth.net/confluence/dashboard.action> [15 June 2013]
Page 124 of 125
2012/2013
Shibboleth (2013) Home [Online] available from < https://wiki.shibboleth.net/confluence/display/SHIB2/Home> [17 June 2013]
Shibboleth (2013) Embedded Discovery Service [Online] available from <https://wiki.shibboleth.net/confluence/display/EDS10/Embedded+Discovery+Service> [20 June 2013]
Shibboleth (2013) Installation [Online] available from <https://wiki.shibboleth.net/confluence/display/SHIB2/Installation> [20 June 2013]
Shibboleth (2013) Configuration [Online] available from <https://wiki.shibboleth.net/confluence/display/SHIB2/Configuration> [25 June 2013]
Shibboleth (2013) Troubleshooting [Online] available from <https://wiki.shibboleth.net/confluence/display/SHIB2/Troubleshooting > [29 July 2013]
SSL Shopper (2013) How to Create a Self Signed Certificate in IIS 7 [Online] available from <http://www.sslshopper.com/article-how-to-create-a-self-signed-certificate-in-iis7.html> [15 July 2013]
Switch (2013) Shibboleth Architecture [Online] available from <http://www.switch.ch/aai/about/shibboleth/index.html >[29 July 2013]
The Apache Software Foundation (2013) Apache Tomcat 6.0: Tomcat Setup [Online] available from <http://tomcat.apache.org/tomcat-6.0-doc/setup.html> [30 June 2013]
The Apache Software Foundation (2013) Apache Tomcat 6.0: Apache Tomcat Configuration Reference [Online] available from < http://tomcat.apache.org/tomcat-6.0doc/config/context.html> [01 July 2013]
Page 125 of 125
2012/2013
Appendix A Configuration files of the primary prototype implementation

Shibboleth2.xml
<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config" xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" clockSkew="180"> <!-The InProcess section contains settings affecting web server modules. Required for IIS, but can be removed when using other web servers. --> <InProcess logger="native.logger"> <ISAPI normalizeRequest="true" safeHeaderNames="true"> <!-Mapping of IIS Instance ID values to the host scheme/name/port. The name is required so that the proper <Host> in the request map above is found without having to cover every possible DNS/IP combination the user might enter. --> <Site id="1" name="ans.247lib.com"/> </ISAPI> </InProcess>  <RequestMapper type="Native"> <RequestMap applicationId="default"> <!-Requirement of a session for documents in /secure on the containing host with http and https on the default ports. --> <Host name="ans.247lib.com"> <Path name="secure" authType="shibboleth" requireSession="true"/> </Host> </RequestMap> </RequestMapper>  <ApplicationDefaults entityID="https://ans.247lib.com/shibboleth" REMOTE_USER="eppn persistent-id targeted-id">  <Sessions lifetime="28800" timeout="3600" relayState="ss:mem" checkAddress="false" handlerSSL="false" cookieProps="http">  <SSO entityID="https://amlib.co.uk:8443/idp/shibboleth"> SAML2 SAML1 </SSO>  <Logout>SAML2 Local</Logout> 
M08CDE Project| Coventry University| 2012-2013
Gilles Rubens Badouet
2012/2013
<Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>  <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>  <Handler type="Session" Location="/Session" showAttributeValues="true"/>  <Handler type="DiscoveryFeed" Location="/DiscoFeed"/> </Sessions> <!-Allows overriding of error template information/filenames. <Errors supportContact="support@247lib.com" helpLocation="/about.html" styleSheet="/shibboleth-sp/main.css"/>  <MetadataProvider type="XML" file="C:\opt\shibboleth-sp\etc\shibboleth\idpmetadata.xml"> </MetadataProvider>  <AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>  <AttributeResolver type="Query" subjectMatch="true"/>  <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>  <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/> </ApplicationDefaults>  <SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>  <ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/> </SPConfig>
-->
attribute-map.xml
<Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <!-The mappings are a mix of SAML 1.1 and SAML 2.0 attribute names agreed to within the Shibboleth community. The non-OID URNs are SAML 1.1 names and most of the OIDs are SAML 2.0 names, with a few exceptions for newer attributes where the name is the same for both versions. You will usually want to uncomment or map the names for both SAML versions as a unit. -->  <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName" id="eppn"> <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
2012/2013
</Attribute> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="eppn"> <AttributeDecoder xsi:type="ScopedAttributeDecoder"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" id="affiliation"> <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" id="affiliation"> <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonAffiliation" id="unscopedaffiliation"> <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" id="unscoped-affiliation"> <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonEntitlement" id="entitlement"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" id="entitlement"/>  <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID" id="persistentid"> <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/> </Attribute>  <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id"> <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/> </Attribute>  <Attribute name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" id="persistent-id"> <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/> </Attribute>  <Attribute name="urn:mace:dir:attribute-def:eduPersonPrimaryAffiliation" id="primary-affiliation"> <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonNickname" id="nickname"/> <Attribute name="urn:mace:dir:attribute-def:eduPersonPrimaryOrgUnitDN" id="primary-orgunit-dn"/> <Attribute name="urn:mace:dir:attribute-def:eduPersonOrgUnitDN" id="orgunit-dn"/> <Attribute name="urn:mace:dir:attribute-def:eduPersonOrgDN" id="org-dn"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.5" id="primary-affiliation"> <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.2" id="nickname"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.8" id="primary-orgunit-dn"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.4" id="orgunit-dn"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.3" id="org-dn"/>
2012/2013
<Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.11" id="assurance"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" id="member"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.6.1.1" id="eduCourseOffering"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.6.1.2" id="eduCourseMember"/>  <Attribute name="urn:mace:dir:attribute-def:cn" id="cn"/> <Attribute name="urn:mace:dir:attribute-def:sn" id="sn"/> <Attribute name="urn:mace:dir:attribute-def:uid" id="uid"/> <Attribute name="urn:mace:dir:attribute-def:givenName" id="givenName"/> <Attribute name="urn:mace:dir:attribute-def:displayName" id="displayName"/> <Attribute name="urn:mace:dir:attribute-def:mail" id="email"/> <Attribute name="urn:mace:dir:attribute-def:telephoneNumber" id="telephoneNumber"/> <Attribute name="urn:mace:dir:attribute-def:mobile" id="mobile"/> <Attribute name="urn:mace:dir:attribute-def:title" id="title"/> <Attribute name="urn:mace:dir:attribute-def:initials" id="initials"/> <Attribute name="urn:mace:dir:attribute-def:description" id="description"/> <Attribute name="urn:mace:dir:attribute-def:carLicense" id="carLicense"/> <Attribute name="urn:mace:dir:attribute-def:departmentNumber" id="departmentNumber"/> <Attribute name="urn:mace:dir:attribute-def:employeeNumber" id="employeeNumber"/> <Attribute name="urn:mace:dir:attribute-def:employeeType" id="employeeType"/> <Attribute name="urn:mace:dir:attribute-def:preferredLanguage" id="preferredLanguage"/> <Attribute name="urn:mace:dir:attribute-def:manager" id="manager"/> <Attribute name="urn:mace:dir:attribute-def:seeAlso" id="seeAlso"/> <Attribute name="urn:mace:dir:attribute-def:facsimileTelephoneNumber" id="facsimileTelephoneNumber"/> <Attribute name="urn:mace:dir:attribute-def:street" id="street"/> <Attribute name="urn:mace:dir:attribute-def:postOfficeBox" id="postOfficeBox"/> <Attribute name="urn:mace:dir:attribute-def:postalCode" id="postalCode"/> <Attribute name="urn:mace:dir:attribute-def:st" id="st"/> <Attribute name="urn:mace:dir:attribute-def:l" id="l"/> <Attribute name="urn:mace:dir:attribute-def:o" id="o"/> <Attribute name="urn:mace:dir:attribute-def:ou" id="ou"/> <Attribute name="urn:mace:dir:attribute-def:businessCategory" id="businessCategory"/> <Attribute name="urn:mace:dir:attribute-def:physicalDeliveryOfficeName" id="physicalDeliveryOfficeName"/> <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute name="urn:oid:2.5.4.3" id="cn"/> name="urn:oid:2.5.4.4" id="sn"/> name="urn:oid:0.9.2342.19200300.100.1.1" id="uid"/> name="urn:oid:2.5.4.42" id="givenName"/> name="urn:oid:2.16.840.1.113730.3.1.241" id="displayName"/> name="urn:oid:0.9.2342.19200300.100.1.3" id="email"/> name="urn:oid:2.5.4.20" id="telephoneNumber"/> name="urn:oid:0.9.2342.19200300.100.1.41" id="mobile"/> name="urn:oid:2.5.4.12" id="title"/> name="urn:oid:2.5.4.43" id="initials"/> name="urn:oid:2.5.4.13" id="description"/> name="urn:oid:2.16.840.1.113730.3.1.1" id="carLicense"/> name="urn:oid:2.16.840.1.113730.3.1.2" id="departmentNumber"/> name="urn:oid:2.16.840.1.113730.3.1.3" id="employeeNumber"/> name="urn:oid:2.16.840.1.113730.3.1.4" id="employeeType"/> name="urn:oid:2.16.840.1.113730.3.1.39" id="preferredLanguage"/> name="urn:oid:0.9.2342.19200300.100.1.10" id="manager"/> name="urn:oid:2.5.4.34" id="seeAlso"/> name="urn:oid:2.5.4.23" id="facsimileTelephoneNumber"/> name="urn:oid:2.5.4.9" id="street"/> name="urn:oid:2.5.4.18" id="postOfficeBox"/> name="urn:oid:2.5.4.17" id="postalCode"/> name="urn:oid:2.5.4.8" id="st"/> name="urn:oid:2.5.4.7" id="l"/>
2012/2013
<Attribute <Attribute <Attribute <Attribute </Attributes>
name="urn:oid:2.5.4.10" name="urn:oid:2.5.4.11" name="urn:oid:2.5.4.15" name="urn:oid:2.5.4.19"
id="o"/> id="ou"/> id="businessCategory"/> id="physicalDeliveryOfficeName"/>
some-metadata.xml (SP metadata)
 <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_7be67ad6e799cc5fdf9631f8904e15120bc0400c" entityID="https://ans.247lib.com/shibboleth"> <md:Extensions xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport"> <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/> <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha384"/> <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224"/> <alg:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsasha512"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsasha384"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsasha256"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsasha224"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <alg:SigningMethod Algorithm="http://www.w3.org/2009/xmldsig11#dsa-sha256"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1"/> <alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> </md:Extensions> <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol"> <md:Extensions> <init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:requestinit" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://ans.247lib.com/Shibboleth.sso/Login"/> </md:Extensions> <md:KeyDescriptor> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyName>gilles-pc</ds:KeyName> <ds:X509Data> <ds:X509SubjectName>CN=gilles-pc</ds:X509SubjectName> <ds:X509Certificate>MIIC4jCCAcqgAwIBAgIJALq6popo+NyfMA0GCSqGSIb3DQEBBQUAMBQxEjAQBgNV BAMTCWdpbGxlcy1wYzAeFw0xMzA2MjYyMDE4NTlaFw0yMzA2MjQyMDE4NTlaMBQx EjAQBgNVBAMTCWdpbGxlcy1wYzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAOCraykAzLzpLmC7PN9iGflNaEP7rlxQFAbLsRJ28K54QdidiuMRsC9eGIFN rFmK+y0yG1DIrvHAdg4yxmIWJaA9G59F3tQLEsACnog0CgPB/OY+LElp9f8Wy+Kp bbPMcvZNOMtZiWwHmS2N8BJNc2KqXWwEkW+7LfvbeorEUX6UugMLoZ9peT5+LkvK GVyMGZPF3guu1qxUswFNJOeGy7yTbMU5J/woiq867EUX3qIyD/rZJblYBgqX2NGO IBjCatYY0tC/L1hXvXR8pUZQSs51ZaLQX0GkC4j/EWh2yX9z8yIA3Pc9QhaWdTz7 V06ek3bwmJeXyltl6mxUMnBPPocCAwEAAaM3MDUwFAYDVR0RBA0wC4IJZ2lsbGVz LXBjMB0GA1UdDgQWBBQ9Qx93/D0k41FP4/mPXvs7U9o4jDANBgkqhkiG9w0BAQUF AAOCAQEAAOUadbzEtOTpOW/dCoXRmpzeLa/+UhSUe0g7w2PDODPh4Bqccrqwlv6q M6ehwKl2W/wggnFSuCPGlAUMh5Uo3sdAyL19JdxMmn7b7mXSeU9OBRcMA9Hk6Gwr qKjsECQchJGCRPRirH8AViJSEOcfofL+tEd29T6v74PH20aS6+zb8zI+PMWyvIHO 4MbflmWbHIKs3ZSsjM6jp5Wgi0sKSjaMhWfublVanRlIEfgqDEGjF+OT2sJVjSPS XMyw21nvxFx20ZKfK+mWvtr30EUoIH6VikQRtqhp/YBDjftjqbWQlt1kZaETfRRA QzvYLoaAEstHHFIHmR7cNT7jQ2Ht4w==
2012/2013
</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes128-gcm"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes192-gcm"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes192-cbc"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledescbc"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#rsa-oaep"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaepmgf1p"/> </md:KeyDescriptor> <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://ans.247lib.com/Shibboleth.sso/Artifact/SOAP" index="1"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://ans.247lib.com/Shibboleth.sso/SLO/SOAP"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect" Location="https://ans.247lib.com/Shibboleth.sso/SLO/Redirect"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ans.247lib.com/Shibboleth.sso/SLO/POST"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTPArtifact" Location="https://ans.247lib.com/Shibboleth.sso/SLO/Artifact"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST" Location="https://ans.247lib.com/Shibboleth.sso/SAML2/POST" index="1"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST-SimpleSign" Location="https://ans.247lib.com/Shibboleth.sso/SAML2/POSTSimpleSign" index="2"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTPArtifact" Location="https://ans.247lib.com/Shibboleth.sso/SAML2/Artifact" index="3"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://ans.247lib.com/Shibboleth.sso/SAML2/ECP" index="4"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://ans.247lib.com/Shibboleth.sso/SAML/POST" index="5"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://ans.247lib.com/Shibboleth.sso/SAML/Artifact" index="6"/> </md:SPSSODescriptor> </md:EntityDescriptor>
shibd.logger
# set overall behavior log4j.rootCategory=INFO, shibd_log, warn_log # set DEBUG loging log4j.rootCategory=DEBUG, shibd_log # fairly verbose for DEBUG, so generally leave at INFO log4j.category.XMLTooling.XMLObject=INFO log4j.category.XMLTooling.KeyInfoResolver=INFO log4j.category.Shibboleth.IPRange=INFO log4j.category.Shibboleth.PropertySet=INFO # raise for low-level tracing of SOAP client HTTP/SSL behavior log4j.category.XMLTooling.libcurl=INFO # logs XML being signed or verified if set to DEBUG log4j.category.XMLTooling.Signature.Debugger=INFO, sig_log log4j.additivity.XMLTooling.Signature.Debugger=false # the tran log blocks the "default" appender(s) at runtime # Level should be left at INFO for this category log4j.category.Shibboleth-TRANSACTION=INFO, tran_log
2012/2013
log4j.additivity.Shibboleth-TRANSACTION=false # define the appenders log4j.appender.shibd_log=org.apache.log4j.RollingFileAppender log4j.appender.shibd_log.fileName=C:/opt/shibboleth-sp/var/log/shibboleth/shibd.log log4j.appender.shibd_log.maxFileSize=1000000 log4j.appender.shibd_log.maxBackupIndex=10 log4j.appender.shibd_log.layout=org.apache.log4j.PatternLayout log4j.appender.shibd_log.layout.ConversionPattern=%d{%Y-%m-%d %H:%M:%S} %p %c %x: %m%n log4j.appender.warn_log=org.apache.log4j.RollingFileAppender log4j.appender.warn_log.fileName=C:/opt/shibbolethsp/var/log/shibboleth/shibd_warn.log log4j.appender.warn_log.maxFileSize=1000000 log4j.appender.warn_log.maxBackupIndex=10 log4j.appender.warn_log.layout=org.apache.log4j.PatternLayout log4j.appender.warn_log.layout.ConversionPattern=%d{%Y-%m-%d %H:%M:%S} %p %c %x: %m%n log4j.appender.warn_log.threshold=WARN log4j.appender.tran_log=org.apache.log4j.RollingFileAppender log4j.appender.tran_log.fileName=C:/opt/shibbolethsp/var/log/shibboleth/transaction.log log4j.appender.tran_log.maxFileSize=1000000 log4j.appender.tran_log.maxBackupIndex=20 log4j.appender.tran_log.layout=org.apache.log4j.PatternLayout log4j.appender.tran_log.layout.ConversionPattern=%d{%Y-%m-%d %H:%M:%S} %p %c %x: %m%n log4j.appender.sig_log=org.apache.log4j.FileAppender log4j.appender.sig_log.fileName=C:/opt/shibboleth-sp/var/log/shibboleth/signature.log log4j.appender.sig_log.layout=org.apache.log4j.PatternLayout log4j.appender.sig_log.layout.ConversionPattern=%m
relying-party.xml
<?xml version="1.0" encoding="UTF-8"?> <!-This file specifies relying party dependent configurations for the IdP, for example, whether SAML assertions to a particular relying party should be signed. It also includes metadata provider and credential definitions used when answering requests to a relying party. --> <rp:RelyingPartyGroup xmlns:rp="urn:mace:shibboleth:2.0:relying-party" xmlns:saml="urn:mace:shibboleth:2.0:relying-party:saml" xmlns:metadata="urn:mace:shibboleth:2.0:metadata" xmlns:resource="urn:mace:shibboleth:2.0:resource" xmlns:security="urn:mace:shibboleth:2.0:security" xmlns:samlsec="urn:mace:shibboleth:2.0:security:saml" xmlns:samlmd="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:relying-party classpath:/schema/shibboleth-2.0-relying-party.xsd urn:mace:shibboleth:2.0:relying-party:saml classpath:/schema/shibboleth-2.0-relying-party-saml.xsd urn:mace:shibboleth:2.0:metadata classpath:/schema/shibboleth-2.0-metadata.xsd urn:mace:shibboleth:2.0:resource classpath:/schema/shibboleth-2.0-resource.xsd urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd urn:mace:shibboleth:2.0:security:saml classpath:/schema/shibboleth-2.0-security-policy-saml.xsd urn:oasis:names:tc:SAML:2.0:metadata classpath:/schema/saml-schema-metadata-2.0.xsd"> 
2012/2013
<!-Relying Party Configurations -->  <rp:AnonymousRelyingParty provider="https://amlib.co.uk:8443/idp/shibboleth" defaultSigningCredentialRef="IdPCredential"/> <rp:DefaultRelyingParty provider="https://amlib.co.uk:8443/idp/shibboleth" defaultSigningCredentialRef="IdPCredential"> <!-Each attribute in these profiles configuration is set to its default value, that is, the values that would be in effect if those attributes were not present. We list them here so that people are aware of them (since they seem reluctant to read the documentation). --> <rp:ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile" includeAttributeStatement="false" signAssertions="never" assertionLifetime="PT5M" signResponses="conditional" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML1AttributeQueryProfile" assertionLifetime="PT5M" signResponses="conditional" signAssertions="never" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML1ArtifactResolutionProfile" signResponses="conditional" signAssertions="never"/> <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="never" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile" includeAttributeStatement="true" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="never" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="conditional" signAssertions="never" encryptAssertions="conditional" encryptNameIds="never" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile" signResponses="never" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never"/> <rp:ProfileConfiguration xsi:type="saml:SAML2LogoutRequestProfile" signResponses="conditional"/> </rp:DefaultRelyingParty> <!-Metadata Configuration -->
<metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:FilesystemMetadataProvider" metadataFile="C:\IDP\metadata\some-metadata.xml"
2012/2013
maxRefreshDelay="P1D" > </metadata:MetadataProvider> <!-Security Configurations -->  <security:Credential id="IdPCredential" xsi:type="security:X509Filesystem"> <security:PrivateKey>C:\IDP\credentials\idp.key</security:PrivateKey> <security:Certificate>C:\IDP\credentials\idp.crt</security:Certificate> </security:Credential>  <security:TrustEngine id="shibboleth.SignatureTrustEngine" xsi:type="security:SignatureChaining"> <security:TrustEngine id="shibboleth.SignatureMetadataExplicitKeyTrustEngine" xsi:type="security:MetadataExplicitKeySignature" metadataProviderRef="ShibbolethMetadata"/> <security:TrustEngine id="shibboleth.SignatureMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXSignature" metadataProviderRef="ShibbolethMetadata"/> </security:TrustEngine> <security:TrustEngine id="shibboleth.CredentialTrustEngine" xsi:type="security:Chaining"> <security:TrustEngine id="shibboleth.CredentialMetadataExplictKeyTrustEngine" xsi:type="security:MetadataExplicitKey" metadataProviderRef="ShibbolethMetadata"/> <security:TrustEngine id="shibboleth.CredentialMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXX509Credential" metadataProviderRef="ShibbolethMetadata"/> </security:TrustEngine> <security:SecurityPolicy id="shibboleth.ShibbolethSSOSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay" required="false"/> <security:Rule xsi:type="samlsec:IssueInstant" required="false"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML1AttributeQuerySecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML1ArtifactResolutionSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2SSOSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:SAML2AuthnRequestsSigned"/>
2012/2013
<security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2AttributeQuerySecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2ArtifactResolutionSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2SLOSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy> </rp:RelyingPartyGroup>
idp-metadata.xml
<?xml version="1.0" encoding="UTF-8"?> <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
2012/2013
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entityID="https://amlib.co.uk:8443/idp/shibboleth"> <IDPSSODescriptor protocolSupportEnumeration="urn:mace:shibboleth:1.0 urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <Extensions> <shibmd:Scope regexp="false">co.uk</shibmd:Scope> </Extensions> <KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDFzCCAf+gAwIBAgIUavRuKmcJp2Bc6UGeRV1EKos7n6YwDQYJKoZIhvcNAQEF BQAwFjEUMBIGA1UEAxMLYW1saWIuY28udWswHhcNMTMwNjI1MTE1OTA5WhcNMzMw NjI1MTE1OTA5WjAWMRQwEgYDVQQDEwthbWxpYi5jby51azCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMIVwFY3e5Kp9msxe62VIC6zxSdflqok+Wpd6/Mn ywl8uAPw+cehuAmjnJtdFZni0XcEvQzj8rj/MUAn+HJwfQilaj+fl9Z6vCiD2KiB 51hir9+ZVRGpAFytsjBnIDQHMD1gtT7upDHr1iGmF7yV5+ohTGaBGJ9AMJRE7jhT XwezO6AN/WMPdJs3/09EZ7G7TJhF84Av+FlD83r2KQVua506Hn9vb/CAnYDNU4wZ Tva47TP42t07rTz6pX1Lm5BdTb9pTM/QeBnVWxYrq90D/GiMxilpPaGGVcqEfNJA TgLgA/UfOfuGXbGUDrbL5TKQ/nd0J2Bel6lI2spYaSbaQzcCAwEAAaNdMFswOgYD VR0RBDMwMYILYW1saWIuY28udWuGImh0dHBzOi8vYW1saWIuY28udWsvaWRwL3No aWJib2xldGgwHQYDVR0OBBYEFNoncBsF9r5t3gGnIoZQYVpw02mAMA0GCSqGSIb3 DQEBBQUAA4IBAQCpHNmN1YyXK9bSq8lu79xyCUWfNecr24XTr/aK8/Fx2XpWC+qw nhV3tHK0QxzCWHqDJ4IiKknL9aYAat0TTpZL/N3N7s4rxEktaNJS+2I6JpLOmmj9 TywqNbdhs9NGa2XJbnjQW90oSiopQhMWM9mYINaNYwDVybeImONsj6L7HRlJjoKV ah+ZuhRvi219ncsvOl4HJByorkUMM8f2iwq0Kor2ugDqMyT7uOMuD3/l+oYTlNi8 T1+VdcaTJKzs+znSxubAaJmjeYRBTPj8tRk4fxowxGG45Q2+Jv46Js+ryD/aRygV VG3T2QNRpQUbZH5AJaH+UEki5dyBt5UltmN8 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAPbinding" Location="https://amlib.co.uk:8443/idp/profile/SAML1/SOAP/ArtifactResolution" index="1"/> <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://amlib.co.uk:8443/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"/> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect" Location="https://amlib.co.uk:8443/idp/profile/SAML2/Redirect/SLO" /> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://amlib.co.uk:8443/idp/profile/SAML2/POST/SLO" /> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://amlib.co.uk:8443/idp/profile/SAML2/SOAP/SLO" /> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameidformat:transient</NameIDFormat> <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://amlib.co.uk:8443/idp/profile/Shibboleth/SSO"/> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://amlib.co.uk:8443/idp/profile/SAML2/POST/SSO"/> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POSTSimpleSign" Location="https://amlib.co.uk:8443/idp/profile/SAML2/POSTSimpleSign/SSO"/>
2012/2013
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect" Location="https://amlib.co.uk:8443/idp/profile/SAML2/Redirect/SSO"/> </IDPSSODescriptor> <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <Extensions> <shibmd:Scope regexp="false">co.uk</shibmd:Scope> </Extensions> <KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDFzCCAf+gAwIBAgIUavRuKmcJp2Bc6UGeRV1EKos7n6YwDQYJKoZIhvcNAQEF BQAwFjEUMBIGA1UEAxMLYW1saWIuY28udWswHhcNMTMwNjI1MTE1OTA5WhcNMzMw NjI1MTE1OTA5WjAWMRQwEgYDVQQDEwthbWxpYi5jby51azCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMIVwFY3e5Kp9msxe62VIC6zxSdflqok+Wpd6/Mn ywl8uAPw+cehuAmjnJtdFZni0XcEvQzj8rj/MUAn+HJwfQilaj+fl9Z6vCiD2KiB 51hir9+ZVRGpAFytsjBnIDQHMD1gtT7upDHr1iGmF7yV5+ohTGaBGJ9AMJRE7jhT XwezO6AN/WMPdJs3/09EZ7G7TJhF84Av+FlD83r2KQVua506Hn9vb/CAnYDNU4wZ Tva47TP42t07rTz6pX1Lm5BdTb9pTM/QeBnVWxYrq90D/GiMxilpPaGGVcqEfNJA TgLgA/UfOfuGXbGUDrbL5TKQ/nd0J2Bel6lI2spYaSbaQzcCAwEAAaNdMFswOgYD VR0RBDMwMYILYW1saWIuY28udWuGImh0dHBzOi8vYW1saWIuY28udWsvaWRwL3No aWJib2xldGgwHQYDVR0OBBYEFNoncBsF9r5t3gGnIoZQYVpw02mAMA0GCSqGSIb3 DQEBBQUAA4IBAQCpHNmN1YyXK9bSq8lu79xyCUWfNecr24XTr/aK8/Fx2XpWC+qw nhV3tHK0QxzCWHqDJ4IiKknL9aYAat0TTpZL/N3N7s4rxEktaNJS+2I6JpLOmmj9 TywqNbdhs9NGa2XJbnjQW90oSiopQhMWM9mYINaNYwDVybeImONsj6L7HRlJjoKV ah+ZuhRvi219ncsvOl4HJByorkUMM8f2iwq0Kor2ugDqMyT7uOMuD3/l+oYTlNi8 T1+VdcaTJKzs+znSxubAaJmjeYRBTPj8tRk4fxowxGG45Q2+Jv46Js+ryD/aRygV VG3T2QNRpQUbZH5AJaH+UEki5dyBt5UltmN8 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://amlib.co.uk:8443/idp/profile/SAML1/SOAP/AttributeQuery"/> <AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://amlib.co.uk:8443/idp/profile/SAML2/SOAP/AttributeQuery"/> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameidformat:transient</NameIDFormat> </AttributeAuthorityDescriptor> </EntityDescriptor>
attribute-resolver.xml
<?xml version="1.0" encoding="UTF-8"?> <resolver:AttributeResolver xmlns:resolver="urn:mace:shibboleth:2.0:resolver" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pc="urn:mace:shibboleth:2.0:resolver:pc" xmlns:ad="urn:mace:shibboleth:2.0:resolver:ad" xmlns:dc="urn:mace:shibboleth:2.0:resolver:dc" xmlns:enc="urn:mace:shibboleth:2.0:attribute:encoder" xmlns:sec="urn:mace:shibboleth:2.0:security"
2012/2013
xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver classpath:/schema/shibboleth-2.0-attribute-resolver.xsd urn:mace:shibboleth:2.0:resolver:pc classpath:/schema/shibboleth-2.0-attribute-resolver-pc.xsd urn:mace:shibboleth:2.0:resolver:ad classpath:/schema/shibboleth-2.0-attribute-resolver-ad.xsd urn:mace:shibboleth:2.0:resolver:dc classpath:/schema/shibboleth-2.0-attribute-resolver-dc.xsd urn:mace:shibboleth:2.0:attribute:encoder classpath:/schema/shibboleth-2.0-attributeencoder.xsd urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd">  <!-Attribute Definitions -->   <resolver:AttributeDefinition xsi:type="ad:Simple" id="uid" sourceAttributeID="uid"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:uid" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="email" sourceAttributeID="mail"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="homePhone" sourceAttributeID="homePhone"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:homePhone" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.20" friendlyName="homePhone" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="homePostalAddress" sourceAttributeID="homePostalAddress"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:homePostalAddress" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.39" friendlyName="homePostalAddress" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="mobileNumber" sourceAttributeID="mobile"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mobile" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.41" friendlyName="mobile" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="pagerNumber" sourceAttributeID="pager"> <resolver:Dependency ref="myLDAP" />
2012/2013
<resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:pager" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.42" friendlyName="pager" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="commonName" sourceAttributeID="cn"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:cn" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.3" friendlyName="cn" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="surname" sourceAttributeID="sn"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:sn" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.4" friendlyName="sn" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="locality" sourceAttributeID="l"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:l" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.7" friendlyName="l" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="stateProvince" sourceAttributeID="st"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:st" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.8" friendlyName="st" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="street" sourceAttributeID="street"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:street" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.9" friendlyName="street" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="organizationName" sourceAttributeID="o"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:o" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.10" friendlyName="o" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="organizationalUnit" sourceAttributeID="ou"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:ou" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.11" friendlyName="ou" /> </resolver:AttributeDefinition>
2012/2013
<resolver:AttributeDefinition xsi:type="ad:Simple" id="title" sourceAttributeID="title"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:title" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.12" friendlyName="title" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="postalAddress" sourceAttributeID="postalAddress"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:postalAddress" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.16" friendlyName="postalAddress" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="postalCode" sourceAttributeID="postalCode"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:postalCode" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.17" friendlyName="postalCode" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="postOfficeBox" sourceAttributeID="postOfficeBox"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:postOfficeBox" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.18" friendlyName="postOfficeBox" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="telephoneNumber" sourceAttributeID="telephoneNumber"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:telephoneNumber" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.20" friendlyName="telephoneNumber" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="givenName" sourceAttributeID="givenName"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:givenName" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.42" friendlyName="givenName" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="initials" sourceAttributeID="initials"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:initials" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.43" friendlyName="initials" /> </resolver:AttributeDefinition>

2012/2013
<resolver:AttributeDefinition xsi:type="ad:Simple" id="departmentNumber" sourceAttributeID="departmentNumber"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:departmentNumber" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.2" friendlyName="departmentNumber" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="displayName" sourceAttributeID="displayName"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:displayName" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.241" friendlyName="displayName" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="employeeNumber" sourceAttributeID="employeeNumber"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:employeeNumber" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.3" friendlyName="employeeNumber" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="employeeType" sourceAttributeID="employeeType"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:employeeType" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.4" friendlyName="employeeType" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="jpegPhoto" sourceAttributeID="jpegPhoto"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:jpegPhoto" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.60" friendlyName="jpegPhoto" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="preferredLanguage" sourceAttributeID="preferredLanguage"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:preferredLanguage" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.39" friendlyName="preferredLanguage" /> </resolver:AttributeDefinition>
 <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonAffiliation" sourceAttributeID="eduPersonAffiliation"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonAffiliation" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" friendlyName="eduPersonAffiliation" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonEntitlement" sourceAttributeID="eduPersonEntitlement">
2012/2013
<resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonEntitlement" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" friendlyName="eduPersonEntitlement" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonNickname" sourceAttributeID="eduPersonNickname"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonNickname" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.2" friendlyName="eduPersonNickname" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonOrgDN" sourceAttributeID="eduPersonOrgDN"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonOrgDN" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.3" friendlyName="eduPersonOrgDN" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonOrgUnitDN" sourceAttributeID="eduPersonOrgUnitDN"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonOrgUnitDN" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.4" friendlyName="eduPersonOrgUnitDN" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonPrimaryAffiliation" sourceAttributeID="eduPersonPrimaryAffiliation"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonPrimaryAffiliation" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.5" friendlyName="eduPersonPrimaryAffiliation" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonPrimaryOrgUnitDN" sourceAttributeID="eduPersonPrimaryOrgUnitDN"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonPrimaryOrgUnitDN" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.8" friendlyName="eduPersonPrimaryOrgUnitDN" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonPrincipalName" scope="co.uk" sourceAttributeID="uid"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonPrincipalName" /> <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonScopedAffiliation" scope="co.uk" sourceAttributeID="eduPersonAffiliation"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" /> <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" friendlyName="eduPersonScopedAffiliation" />
2012/2013
</resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonAssurance" sourceAttributeID="eduPersonAssurance"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonAssurance" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.11" friendlyName="eduPersonAssurance" /> </resolver:AttributeDefinition>  <resolver:AttributeDefinition id="transientId" xsi:type="ad:TransientId"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier"/> <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> </resolver:AttributeDefinition>  <resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc" ldapURL="ldap://locahost:389" baseDN="dc=amlib,dc=com" principalCredential="kenardo"> <FilterTemplate> <![CDATA[ (uid=$requestContext.principalName) ]]> </FilterTemplate> </resolver:DataConnector>
<!-Principal Connectors -->  <resolver:PrincipalConnector xsi:type="pc:Transient" id="shibTransient" nameIDFormat="urn:mace:shibboleth:1.0:nameIdentifier"/> <resolver:PrincipalConnector xsi:type="pc:Transient" id="saml1Unspec" nameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/> <resolver:PrincipalConnector xsi:type="pc:Transient" id="saml2Transient" nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> </resolver:AttributeResolver>
<?xml version="1.0" encoding="UTF-8"?> <afp:AttributeFilterPolicyGroup id="ShibbolethFilterPolicy" xmlns:afp="urn:mace:shibboleth:2.0:afp" xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic" xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:afp classpath:/schema/shibboleth-2.0-afp.xsd urn:mace:shibboleth:2.0:afp:mf:basic classpath:/schema/shibboleth-2.0-afp-mf-basic.xsd urn:mace:shibboleth:2.0:afp:mf:saml classpath:/schema/shibboleth-2.0-afp-mf-saml.xsd">  <afp:AttributeFilterPolicy id="releaseTransientIdToAnyone"> <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
2012/2013
<afp:AttributeRule attributeID="transientId"> <afp:PermitValueRule xsi:type="basic:ANY"/> </afp:AttributeRule> </afp:AttributeFilterPolicy> <afp:AttributeFilterPolicy id="releaseToAnyone"> <afp:PolicyRequirementRule xsi:type="basic:ANY" /> <afp:AttributeRule attributeID="givenName"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="uid"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="email"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="surname"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="mobileNumber"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="telephoneNumber"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="commonName"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="organizationName"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="eduPersonAffiliation"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="eduPersonEntitlement"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> </afp:AttributeFilterPolicy>
</afp:AttributeFilterPolicyGroup>
handler.xml
<?xml version="1.0" encoding="UTF-8"?> <ph:ProfileHandlerGroup xmlns:ph="urn:mace:shibboleth:2.0:idp:profile-handler" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:idp:profilehandler classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd">  <ph:ErrorHandler xsi:type="ph:JSPErrorHandler" jspPagePath="/error.jsp"/> 
2012/2013
<ph:ProfileHandler xsi:type="ph:Status"> <ph:RequestPath>/Status</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAMLMetadata" metadataFile="C:\IDP/metadata/idpmetadata.xml"> <ph:RequestPath>/Metadata/SAML</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:ShibbolethSSO" inboundBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" outboundBindingEnumeration="urn:oasis:names:tc:SAML:1.0:profiles:browser-post urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"> <ph:RequestPath>/Shibboleth/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML1AttributeQuery" inboundBinding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" outboundBindingEnumeration="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"> <ph:RequestPath>/SAML1/SOAP/AttributeQuery</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML1ArtifactResolution" inboundBinding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" outboundBindingEnumeration="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"> <ph:RequestPath>/SAML1/SOAP/ArtifactResolution</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/POST/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/POST-SimpleSign/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/Redirect/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:mace:shibboleth:2.0:profiles:AuthnRequest" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/Unsolicited/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2ECP" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP">
2012/2013
<ph:RequestPath>/SAML2/SOAP/ECP</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/Redirect/SLO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/POST/SLO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/POST-SimpleSign/SLO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"> <ph:RequestPath>/SAML2/SOAP/SLO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:mace:shibboleth:2.0:profiles:LocalLogout"> <ph:RequestPath>/Logout</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2AttributeQuery" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"> <ph:RequestPath>/SAML2/SOAP/AttributeQuery</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2ArtifactResolution" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"> <ph:RequestPath>/SAML2/SOAP/ArtifactResolution</ph:RequestPath> </ph:ProfileHandler> <!-Username/password login handler -->
<ph:LoginHandler xsi:type="ph:UsernamePassword" jaasConfigurationLocation="file:C:/IDP/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTrans port</ph:AuthenticationMethod> </ph:LoginHandler>
<!-SSO support authentication mechanism configuration
2012/2013
--> <ph:LoginHandler xsi:type="ph:PreviousSession"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</ph:Au thenticationMethod> </ph:LoginHandler> </ph:ProfileHandlerGroup>
logging.xml
<?xml version="1.0" encoding="UTF-8"?> <configuration>  <logger name="edu.internet2.middleware.shibboleth" level="DEBUG"/>
 <logger name="org.opensaml" level="WARN"/>  <logger name="edu.vt.middleware.ldap.jaas.JaasAuthenticator" level="DEBUG" /> <logger name="edu.vt.middleware.ldap" level="DEBUG"/>
<!-Logging appenders define where and how logging messages are logged. --> <appender name="IDP_ACCESS" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>C:\IDP\logs\idp-access.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>C:\IDP\logs\idp-access-%d{yyyy-MMdd}.log</FileNamePattern> </rollingPolicy> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <charset>UTF-8</charset> <Pattern>%msg%n</Pattern> </encoder> </appender> <appender name="IDP_AUDIT" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>C:\IDP/logs/idp-audit.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>C:\IDP/logs/idp-audit-%d{yyyy-MMdd}.log</FileNamePattern> </rollingPolicy> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <charset>UTF-8</charset> <Pattern>%msg%n</Pattern> </encoder> </appender> <appender name="IDP_PROCESS" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>C:\IDP\logs\idp-process.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>C:\IDP\logs\idp-process-%d{yyyy-MMdd}.log</FileNamePattern>
2012/2013
</rollingPolicy> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <charset>UTF-8</charset> <Pattern>%date{HH:mm:ss.SSS} - %level [%logger:%line] - %msg%n</Pattern> </encoder> </appender> <logger name="Shibboleth-Access" level="ALL"> <appender-ref ref="IDP_ACCESS"/> </logger> <logger name="Shibboleth-Audit" level="ALL"> <appender-ref ref="IDP_AUDIT"/> </logger> <logger name="org.springframework" level="OFF"/> <logger name="org.apache.catalina" level="ERROR"/> <root level="ERROR"> <appender-ref ref="IDP_PROCESS"/> </root> </configuration>
login.config
ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule required ldapUrl="ldap://localhost:389" base="dc=amlib,dc=com" ssl="false" userField="uid" subtreeSearch="true" ServiceCredential="kenardo";
};
login.jsp
<!DOCTYPE html> <%@ taglib uri="urn:mace:shibboleth:2.0:idp:ui" prefix="idpui" %> <html> <head> <meta charset="utf-8" /> <title>247lib Login Page</title> <link rel="stylesheet" type="text/css" href="<%= request.getContextPath()%>/login.css"/> </head> <body> <div class="wrapper"> <div class="container"> <header> <a class="logo" href="../images/247lib.jpg"><img src="<%= request.getContextPath()%>/images/247lib.jpg" alt="Replace or remove this logo"/></a> </header> <div class="content"> <div class="column one">
2012/2013
<% if(request.getAttribute("actionUrl") != null){ %> <form id="login" action="<%=request.getAttribute("actionUrl")%>" method="post"> <% }else{ %> <form id="login" action="j_security_check" method="post"> <% } %> <% if ("true".equals(request.getAttribute("loginFailed"))) { %> <section> <p class="form-element form-error">Login has failed. Double-check your username and password or contact the ANS/247lib Support service.</p> </section> <% } %> <legend> Log in to <idpui:serviceName/> </legend> <section> <label for="username">Username</label> <input class="form-element form-field" name="j_username" type="text" value=""> </section> <section> <label for="password">Password</label> <input class="form-element form-field" name="j_password" type="password" value=""> </section> <section> <button class="form-element form-button" type="submit">Login</button> </section> </form> <% // // SP Description & Logo (optional) // These idpui lines will display added information (if available // in the metadata) about the Service Provider (SP) that requested // authentication. These idpui lines are "active" in this example // (not commented out) -- this extra SP info will be displayed. // Remove or comment out these lines to stop the display of the // added SP information. // // Documentation: // https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPassLoginPage // // Example: %> <p> <idpui:serviceLogo>247lib.com</idpui:serviceLogo> <idpui:serviceDescription>is a library management system maintained and supplied by the ANS Service Provider</idpui:serviceDescription> </p>
</div> <div class="column two"> <ul class="list list-help"> <li class="list-help-item"><a href="http://www.answeb.co.uk/support/support.aspx?menuId=top_support"><span class="item-marker">&rsaquo;</span> Forgot your password?</a></li> <li class="list-help-item"><a href="http://www.answeb.co.uk/support/support.aspx?menuId=top_support"><span class="item-marker">&rsaquo;</span> Need Help?</a></li>
2012/2013
<li class="list-help-item"><a href="http://www.answeb.co.uk/contactus.aspx?menuId=top_about_us"><span class="itemmarker">&rsaquo;</span> Get in touch with ANS Ltd</a></li> </ul> </div> </div> </div> <footer> <div class="container container-footer"> <p class="footer-text"> Copyright Applied Network Solutions Limited. All Rights Reserved</p> </div> </footer> </div> </body> </html>
server.xml
<?xml version='1.0' encoding='utf-8'?> <Server port="8005" shutdown="SHUTDOWN">  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />  <Listener className="org.apache.catalina.core.JasperListener" />  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" /> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<GlobalNamingResources>  <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /> </GlobalNamingResources> <Service name="Catalina"> <!-Define a non-SSL HTTP/1.1 Connector on port 8080 --> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />  <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />  <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" SSLImplementation="edu.internet2.middleware.security.tomcat6.DelegateToApplicationJSSE Implementation" scheme="https"
2012/2013
SSLEnabled="true" clientAuth="want" keystoreFile="C:\IDP\credentials\idp.jks" keystorePass="mypassword" />  <Connector port="8080" protocol="HTTP/1.1" address="192.168.0.3" hostname="amlib.co.uk" connectionTimeout="20000" redirectPort="8443" />
 <Engine name="Catalina" defaultHost="localhost">
 <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>  <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
</Host> </Engine> </Service> </Server>
idp.xml
<Context docBase="C:\IDP\war\idp.war" privileged="true" antiResourceLocking="false" antiJARLocking="false" unpackWAR="false" swallowOutput="true" />
2012/2013
Appendix B Configuration files of the real time prototype implementation

Shibboleth2.xml
<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config" xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" clockSkew="180"> <!-The InProcess section contains settings affecting web server modules. Required for IIS, but can be removed when using other web servers. --> <InProcess logger="native.logger"> <ISAPI normalizeRequest="true" safeHeaderNames="true"> <!-Maps IIS Instance ID values to the host scheme/name/port. The name is required so that the proper <Host> in the request map above is found without having to cover every possible DNS/IP combination the user might enter. --> <Site id="1" name="lonfp2.ans.local"/> </ISAPI> </InProcess>
<RequestMapper type="Native"> <RequestMap applicationId="default"> <!-This requires a session for documents in /secure on the containing host with http and https on the default ports. Note that the name and port in the <Host> elements MUST match Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element above. --> <Host name="lonfp2.ans.local"> <Path name="secure" authType="shibboleth" requireSession="true"/> </Host> </RequestMap> </RequestMapper> <!-The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. Resource requests are mapped by the RequestMapper to an applicationId that points into to this section (or to the defaults here). --> <ApplicationDefaults entityID="https://lonfp2.ans.local/shibboleth" REMOTE_USER="eppn persistent-id targeted-id"> <!-Controls session lifetimes, address checks, cookie handling, and the protocol handlers. --> <Sessions lifetime="28800" timeout="3600" relayState="ss:mem" checkAddress="false" handlerSSL="false" cookieProps="http">  <SSO entityID="https://rips4.ans.local:8443/idp/shibboleth"> SAML2 SAML1 </SSO>  <Logout>SAML2 Local</Logout>  <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>  <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>  <Handler type="Session" Location="/Session" showAttributeValues="true"/>  <Handler type="DiscoveryFeed" Location="/DiscoFeed"/> </Sessions> <!-Allows overriding of error template information/filenames. You can also add attributes with values that can be plugged into the templates. --> <Errors supportContact="support@answeb.co.uk" helpLocation="/about.html" styleSheet="/shibboleth-sp/main.css"/> <!-IdP metadata loading configuration. -->
<MetadataProvider type="XML" file="C:\opt\shibboleth-sp\etc\shibboleth\idpmetadata.xml"> </MetadataProvider>  <AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>  <AttributeResolver type="Query" subjectMatch="true"/>  <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>  <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/> </ApplicationDefaults>  <SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>  <ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/> </SPConfig>
attribute-map.xml
<Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">   <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName" id="eppn"> <AttributeDecoder xsi:type="ScopedAttributeDecoder"/> </Attribute> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="eppn"> <AttributeDecoder xsi:type="ScopedAttributeDecoder"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" id="affiliation"> <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" id="affiliation"> <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonAffiliation" id="unscopedaffiliation"> <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" id="unscoped-affiliation"> <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonEntitlement" id="entitlement"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" id="entitlement"/>
 <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID" id="persistentid"> <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/> </Attribute>
 <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id"> <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/> </Attribute>  <Attribute name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" id="persistent-id"> <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/> </Attribute>  <Attribute name="urn:mace:dir:attribute-def:eduPersonPrimaryAffiliation" id="primary-affiliation"> <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="false"/>
2012/2013
</Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonNickname" id="nickname"/> <Attribute name="urn:mace:dir:attribute-def:eduPersonPrimaryOrgUnitDN" id="primary-orgunit-dn"/> <Attribute name="urn:mace:dir:attribute-def:eduPersonOrgUnitDN" id="orgunit-dn"/> <Attribute name="urn:mace:dir:attribute-def:eduPersonOrgDN" id="org-dn"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.5" id="primary-affiliation"> <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="false"/> </Attribute> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.2" id="nickname"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.8" id="primary-orgunit-dn"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.4" id="orgunit-dn"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.3" id="org-dn"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.11" id="assurance"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" id="member"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.6.1.1" id="eduCourseOffering"/> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.6.1.2" id="eduCourseMember"/>
 <Attribute name="urn:mace:dir:attribute-def:cn" id="cn"/> <Attribute name="urn:mace:dir:attribute-def:sn" id="sn"/> <Attribute name="urn:mace:dir:attribute-def:uid" id="uid"/> <Attribute name="urn:mace:dir:attribute-def:givenName" id="givenName"/> <Attribute name="urn:mace:dir:attribute-def:displayName" id="displayName"/> <Attribute name="urn:mace:dir:attribute-def:mail" id="email"/> <Attribute name="urn:mace:dir:attribute-def:telephoneNumber" id="telephoneNumber"/> <Attribute name="urn:mace:dir:attribute-def:mobile" id="mobile"/> <Attribute name="urn:mace:dir:attribute-def:title" id="title"/> <Attribute name="urn:mace:dir:attribute-def:initials" id="initials"/> <Attribute name="urn:mace:dir:attribute-def:description" id="description"/> <Attribute name="urn:mace:dir:attribute-def:carLicense" id="carLicense"/> <Attribute name="urn:mace:dir:attribute-def:departmentNumber" id="departmentNumber"/> <Attribute name="urn:mace:dir:attribute-def:employeeNumber" id="employeeNumber"/> <Attribute name="urn:mace:dir:attribute-def:employeeType" id="employeeType"/> <Attribute name="urn:mace:dir:attribute-def:preferredLanguage" id="preferredLanguage"/> <Attribute name="urn:mace:dir:attribute-def:manager" id="manager"/> <Attribute name="urn:mace:dir:attribute-def:seeAlso" id="seeAlso"/> <Attribute name="urn:mace:dir:attribute-def:facsimileTelephoneNumber" id="facsimileTelephoneNumber"/> <Attribute name="urn:mace:dir:attribute-def:street" id="street"/> <Attribute name="urn:mace:dir:attribute-def:postOfficeBox" id="postOfficeBox"/> <Attribute name="urn:mace:dir:attribute-def:postalCode" id="postalCode"/> <Attribute name="urn:mace:dir:attribute-def:st" id="st"/> <Attribute name="urn:mace:dir:attribute-def:l" id="l"/> <Attribute name="urn:mace:dir:attribute-def:o" id="o"/> <Attribute name="urn:mace:dir:attribute-def:ou" id="ou"/> <Attribute name="urn:mace:dir:attribute-def:businessCategory" id="businessCategory"/> <Attribute name="urn:mace:dir:attribute-def:physicalDeliveryOfficeName" id="physicalDeliveryOfficeName"/> <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute name="urn:oid:2.5.4.3" id="cn"/> name="urn:oid:2.5.4.4" id="sn"/> name="urn:oid:0.9.2342.19200300.100.1.1" id="uid"/> name="urn:oid:2.5.4.42" id="givenName"/> name="urn:oid:2.16.840.1.113730.3.1.241" id="displayName"/> name="urn:oid:0.9.2342.19200300.100.1.3" id="email"/> name="urn:oid:2.5.4.20" id="telephoneNumber"/> name="urn:oid:0.9.2342.19200300.100.1.41" id="mobile"/>
2012/2013
<Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute <Attribute
name="urn:oid:2.5.4.12" id="title"/> name="urn:oid:2.5.4.43" id="initials"/> name="urn:oid:2.5.4.13" id="description"/> name="urn:oid:2.16.840.1.113730.3.1.1" id="carLicense"/> name="urn:oid:2.16.840.1.113730.3.1.2" id="departmentNumber"/> name="urn:oid:2.16.840.1.113730.3.1.3" id="employeeNumber"/> name="urn:oid:2.16.840.1.113730.3.1.4" id="employeeType"/> name="urn:oid:2.16.840.1.113730.3.1.39" id="preferredLanguage"/> name="urn:oid:0.9.2342.19200300.100.1.10" id="manager"/> name="urn:oid:2.5.4.34" id="seeAlso"/> name="urn:oid:2.5.4.23" id="facsimileTelephoneNumber"/> name="urn:oid:2.5.4.9" id="street"/> name="urn:oid:2.5.4.18" id="postOfficeBox"/> name="urn:oid:2.5.4.17" id="postalCode"/> name="urn:oid:2.5.4.8" id="st"/> name="urn:oid:2.5.4.7" id="l"/> name="urn:oid:2.5.4.10" id="o"/> name="urn:oid:2.5.4.11" id="ou"/> name="urn:oid:2.5.4.15" id="businessCategory"/> name="urn:oid:2.5.4.19" id="physicalDeliveryOfficeName"/>
</Attributes>
some-metadata.xml (SP metadata)
<!-This is example metadata only. Do *NOT* supply it as is without review, and do *NOT* provide it in real time to your partners. --> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_b8d70e3b3969a640c7668cb9c8260ee2d51616b8" entityID="https://lonfp2.ans.local/shibboleth"> <md:Extensions xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport"> <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/> <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsigmore#sha384"/> <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsigmore#sha224"/> <alg:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsigmore#ecdsa-sha512"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsigmore#ecdsa-sha384"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsigmore#ecdsa-sha256"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsigmore#ecdsa-sha224"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsasha512"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsasha384"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsasha256"/> <alg:SigningMethod Algorithm="http://www.w3.org/2009/xmldsig11#dsasha256"/> <alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsigmore#ecdsa-sha1"/> <alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1"/>
2012/2013
<alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsasha1"/> </md:Extensions> <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol"> <md:Extensions> <init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://lonfp2.ans.local/Shibboleth.sso/Login"/> </md:Extensions> <md:KeyDescriptor> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyName>lonfp2.ans.local</ds:KeyName> <ds:X509Data> <ds:X509SubjectName>CN=lonfp2.ans.local</ds:X509SubjectName> <ds:X509Certificate>MIIC9zCCAd+gAwIBAgIJAIlaIOgUcbOaMA0GCSqGSIb3DQEBBQUAMBsxG TAXBgNV BAMTEGxvbmZwMi5hbnMubG9jYWwwHhcNMTMwNzI0MTEyNDE4WhcNMjMwNzIyMTEy NDE4WjAbMRkwFwYDVQQDExBsb25mcDIuYW5zLmxvY2FsMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAwZzobv2IUvbxowvxFYNkr6lkBYo10TPbJmKwWIE/ YPcT3MF51uLDVEPjMDVtMkPF7PdUlmG6sSP5lYJmMUh1D9NO9jntYvZCfURNkKPn 7NLiJSZ7EYnrmKs868x5pF5aI0/iiqD5JT+6LNlr39aI/jBT8qIoaGsh4ybibpX1 DxwTufue0pgjMTRVnUg1DFH27d5SO/IrfQqEnJN0ndoZ/1J4ml8c6WV3dxUbg52e FG6y2HFiO950M7QjhdK2nWYnesBCdkI6ygTRTKK6AXA+17UNQct/YiMD7kTsrb0z 83IVPaRQtathJXUJDKPRunlbbQzZc7gSH1y2Mh+lU87OZQIDAQABoz4wPDAbBgNV HREEFDASghBsb25mcDIuYW5zLmxvY2FsMB0GA1UdDgQWBBSum4w+tkTEtxKuy+FU pWpHiGPK9jANBgkqhkiG9w0BAQUFAAOCAQEAsXaoEM/iyg+BVrjRgZhia/pvAn4w HoDzTd/AvvP5ck/bPVEpp1JQf6YoRwyqYc1cwGSu/psnUCJP8GAMRxxKMq88OQkT MOIWpQwiQvJ1XdKVNQs9m5OI9dq+k12epWqV5bbhyke3eFgN/uNpSA7sEHnPabRB 4Cu+oLoQihRPx4PLpn3A49JtXqCBLAUBtftewcxqqG4Qyr+jvLQqyuqSj1tVW/ya c5EP6/h/UMJpaFbelCU6p+PAqq3a9Q/vE4vMbpx17PnmW54izGhnHFyIWJgVHXbg RgyK47v3hWVoZSx3FMREFurDVr7BaFj/CfJxvr2VqvPvknW9bU2IE6LKMQ== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes128gcm"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes192gcm"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes256gcm"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes192-cbc"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#rsaoaep"/> <md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsaoaep-mgf1p"/> </md:KeyDescriptor> <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://lonfp2.ans.local/Shibboleth.sso/Artifact/SOAP" index="1"/>
2012/2013
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://lonfp2.ans.local/Shibboleth.sso/SLO/SOAP"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://lonfp2.ans.local/Shibboleth.sso/SLO/Redirect"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://lonfp2.ans.local/Shibboleth.sso/SLO/POST"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://lonfp2.ans.local/Shibboleth.sso/SLO/Artifact"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://lonfp2.ans.local/Shibboleth.sso/SAML2/POST" index="1"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://lonfp2.ans.local/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://lonfp2.ans.local/Shibboleth.sso/SAML2/Artifact" index="3"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://lonfp2.ans.local/Shibboleth.sso/SAML2/ECP" index="4"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://lonfp2.ans.local/Shibboleth.sso/SAML/POST" index="5"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://lonfp2.ans.local/Shibboleth.sso/SAML/Artifact" index="6"/> </md:SPSSODescriptor> </md:EntityDescriptor>
shibd.logger
# set overall behavior log4j.rootCategory=INFO, shibd_log, warn_log # set DEBUG loging log4j.rootCategory=DEBUG, shibd_log # fairly verbose for DEBUG, so generally leave at INFO log4j.category.XMLTooling.XMLObject=INFO log4j.category.XMLTooling.KeyInfoResolver=INFO log4j.category.Shibboleth.IPRange=INFO log4j.category.Shibboleth.PropertySet=INFO # raise for low-level tracing of SOAP client HTTP/SSL behavior log4j.category.XMLTooling.libcurl=INFO # useful categories to tune independently: # logs XML being signed or verified if set to DEBUG log4j.category.XMLTooling.Signature.Debugger=INFO, sig_log log4j.additivity.XMLTooling.Signature.Debugger=false # the tran log blocks the "default" appender(s) at runtime # Level should be left at INFO for this category log4j.category.Shibboleth-TRANSACTION=INFO, tran_log M08CDE Project| Coventry University| 2012-2013 Gilles Rubens Badouet
2012/2013
log4j.additivity.Shibboleth-TRANSACTION=false # define the appenders log4j.appender.shibd_log=org.apache.log4j.RollingFileAppender log4j.appender.shibd_log.fileName=C:/opt/shibbolethsp/var/log/shibboleth/shibd.log log4j.appender.shibd_log.maxFileSize=1000000 log4j.appender.shibd_log.maxBackupIndex=10 log4j.appender.shibd_log.layout=org.apache.log4j.PatternLayout log4j.appender.shibd_log.layout.ConversionPattern=%d{%Y-%m-%d %H:%M:%S} %p %c %x: %m%n log4j.appender.warn_log=org.apache.log4j.RollingFileAppender log4j.appender.warn_log.fileName=C:/opt/shibbolethsp/var/log/shibboleth/shibd_warn.log log4j.appender.warn_log.maxFileSize=1000000 log4j.appender.warn_log.maxBackupIndex=10 log4j.appender.warn_log.layout=org.apache.log4j.PatternLayout log4j.appender.warn_log.layout.ConversionPattern=%d{%Y-%m-%d %H:%M:%S} %p %c %x: %m%n log4j.appender.warn_log.threshold=WARN log4j.appender.tran_log=org.apache.log4j.RollingFileAppender log4j.appender.tran_log.fileName=C:/opt/shibbolethsp/var/log/shibboleth/transaction.log log4j.appender.tran_log.maxFileSize=1000000 log4j.appender.tran_log.maxBackupIndex=20 log4j.appender.tran_log.layout=org.apache.log4j.PatternLayout log4j.appender.tran_log.layout.ConversionPattern=%d{%Y-%m-%d %H:%M:%S} %p %c %x: %m%n log4j.appender.sig_log=org.apache.log4j.FileAppender log4j.appender.sig_log.fileName=C:/opt/shibbolethsp/var/log/shibboleth/signature.log log4j.appender.sig_log.layout=org.apache.log4j.PatternLayout log4j.appender.sig_log.layout.ConversionPattern=%m
relying-party.xml
<?xml version="1.0" encoding="UTF-8"?> <rp:RelyingPartyGroup xmlns:rp="urn:mace:shibboleth:2.0:relying-party" xmlns:saml="urn:mace:shibboleth:2.0:relying-party:saml" xmlns:metadata="urn:mace:shibboleth:2.0:metadata" xmlns:resource="urn:mace:shibboleth:2.0:resource" xmlns:security="urn:mace:shibboleth:2.0:security" xmlns:samlsec="urn:mace:shibboleth:2.0:security:saml" xmlns:samlmd="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:relying-party classpath:/schema/shibboleth-2.0-relying-party.xsd urn:mace:shibboleth:2.0:relying-party:saml classpath:/schema/shibboleth-2.0-relying-party-saml.xsd urn:mace:shibboleth:2.0:metadata classpath:/schema/shibboleth-2.0-metadata.xsd urn:mace:shibboleth:2.0:resource classpath:/schema/shibboleth-2.0-resource.xsd urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd urn:mace:shibboleth:2.0:security:saml classpath:/schema/shibboleth-2.0-security-policy-saml.xsd
2012/2013
urn:oasis:names:tc:SAML:2.0:metadata classpath:/schema/saml-schema-metadata-2.0.xsd"> <!-Relying Party Configurations --> <rp:AnonymousRelyingParty provider="https://rips4.ans.local:8443/idp/shibboleth" defaultSigningCredentialRef="IdPCredential"/> <rp:DefaultRelyingParty provider="https://rips4.ans.local:8443/idp/shibboleth" defaultSigningCredentialRef="IdPCredential"> <!-Each attribute in these profiles configuration is set to its default value, that is, the values that would be in effect if those attributes were not present. We list them here so that people are aware of them (since they seem reluctant to read the documentation). --> <rp:ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile" includeAttributeStatement="false" assertionLifetime="PT5M" signResponses="conditional" signAssertions="never" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML1AttributeQueryProfile" assertionLifetime="PT5M" signResponses="conditional" signAssertions="never" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML1ArtifactResolutionProfile" signResponses="conditional" signAssertions="never"/> <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="never" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile" includeAttributeStatement="true" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="never" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="conditional" signAssertions="never" encryptAssertions="conditional" encryptNameIds="never" includeConditionsNotBefore="true"/> <rp:ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile" signResponses="never" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never"/> <rp:ProfileConfiguration xsi:type="saml:SAML2LogoutRequestProfile" signResponses="conditional"/> </rp:DefaultRelyingParty>

2012/2013

<metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:FilesystemMetadataProvider" metadataFile="C:\ANSIdP\metadata\some-metadata.xml" maxRefreshDelay="P1D" > </metadata:MetadataProvider>
 <!-Security Configurations -->  <security:Credential id="IdPCredential" xsi:type="security:X509Filesystem"> <security:PrivateKey>C:\ANSIdP\credentials\idp.key</security:PrivateKey> <security:Certificate>C:\ANSIdP\credentials\idp.crt</security:Certificate> </security:Credential> <!-The following trust engines and rules control every aspect of security related to incoming messages. Trust engines evaluate various tokens (like digital signatures) for trust worthiness while the security policies establish a set of checks that an incoming message must pass in order to be considered secure. Naturally some of these checks require the validation of the tokens evaluated by the trust engines and so you'll see some rules that reference the declared trust engines. --> <security:TrustEngine id="shibboleth.SignatureTrustEngine" xsi:type="security:SignatureChaining"> <security:TrustEngine id="shibboleth.SignatureMetadataExplicitKeyTrustEngine" xsi:type="security:MetadataExplicitKeySignature" metadataProviderRef="ShibbolethMetadata"/> <security:TrustEngine id="shibboleth.SignatureMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXSignature" metadataProviderRef="ShibbolethMetadata"/> </security:TrustEngine> <security:TrustEngine id="shibboleth.CredentialTrustEngine" xsi:type="security:Chaining"> <security:TrustEngine id="shibboleth.CredentialMetadataExplictKeyTrustEngine" xsi:type="security:MetadataExplicitKey" metadataProviderRef="ShibbolethMetadata"/> <security:TrustEngine id="shibboleth.CredentialMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXX509Credential" metadataProviderRef="ShibbolethMetadata"/> </security:TrustEngine> <security:SecurityPolicy id="shibboleth.ShibbolethSSOSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay" required="false"/> <security:Rule xsi:type="samlsec:IssueInstant" required="false"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML1AttributeQuerySecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy>
2012/2013
<security:SecurityPolicy id="shibboleth.SAML1ArtifactResolutionSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2SSOSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:SAML2AuthnRequestsSigned"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2AttributeQuerySecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2ArtifactResolutionSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2SLOSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"/> <security:Rule xsi:type="samlsec:IssueInstant"/> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
2012/2013
<security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/> <security:Rule xsi:type="samlsec:MandatoryIssuer"/> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/> </security:SecurityPolicy> </rp:RelyingPartyGroup>
idp-metadata.xml
<?xml version="1.0" encoding="UTF-8"?> <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entityID="https://rips4.ans.local:8443/idp/shibboleth"> <IDPSSODescriptor protocolSupportEnumeration="urn:mace:shibboleth:1.0 urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <Extensions> <shibmd:Scope regexp="false">ans.local</shibmd:Scope> </Extensions> <KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDKDCCAhCgAwIBAgIVAN8On83uMYwVUL5+VF1e4q2ohp95MA0GCSqGSIb3DQEB BQUAMBoxGDAWBgNVBAMTD3JpcHM0LmFucy5sb2NhbDAeFw0xMzA3MjQxMDE4Mjha Fw0zMzA3MjQxMDE4MjhaMBoxGDAWBgNVBAMTD3JpcHM0LmFucy5sb2NhbDCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALfhpgnp4pOuqgGyW930eCaJ4XNK cHRHndJjQC1RxGNLg6Zdr5W01ysgbT216wtmY5fshrRfFssnTTwT5L3FeD5sZVcG kvwO/xTz8OxzieOptyNkUBlCwPpw9bc9RRZP0sD6UhA+fUfRu/20ycEg63J3crRC zBx3NOaoNfQF/E0F6jdPfycbbt08P8hyMGCPTBUfPWEzV0CdmubIC1e6MvHEh4Ji bpfSBc7RQmVswgKRAmsMhMlcNfHHqdQJLO3e2if+wCwUv+2pE2yOYT4PrzxHwhoE SMuz/lg8tRbEIhzF3gWwBxSphXY95sEUQRmrfJnNHkCQE9qjYsqqnqftGzMCAwEA AaNlMGMwQgYDVR0RBDswOYIPcmlwczQuYW5zLmxvY2FshiZodHRwczovL3JpcHM0 LmFucy5sb2NhbC9pZHAvc2hpYmJvbGV0aDAdBgNVHQ4EFgQU6XMshwc74FyrW9vp GkY3ZngvIYIwDQYJKoZIhvcNAQEFBQADggEBABr92Sl1VKmC67P7DXwPoQkhht7b ttgVqBqfIaKYXP3QlM7O76jm+BwD3Djqs4cr/ptq42L+km2F88N88mm0epsCddk0 KNF27hkqUeZecrwCcpqyI8fDUVYXRTwcP2DVkH24lHGmiJagPruPWmHrYBIY9Q84 1WeNnJ/TzgYGEI/JElBiLILfY55YWBhtS0F1c7ajQfwr0yG5ZH0Rs0B9toXNqhLk R36eBFyrjOrKu+V2VlGkiCprYNLfCpu3oDjBE/G3IJEmrQj4IxmLyPLyKciAfR+y EEmBT24tKsHXAzHAf9fMstWYGTcpcw8+G/oJo9xrtO14+lSzpJn+O9HSJAU= </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAPbinding" Location="https://rips4.ans.local:8443/idp/profile/SAML1/SOAP/ArtifactResolution" index="1"/> <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://rips4.ans.local:8443/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"/> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect" Location="https://rips4.ans.local:8443/idp/profile/SAML2/Redirect/SLO" /> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://rips4.ans.local:8443/idp/profile/SAML2/POST/SLO" />
2012/2013
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://rips4.ans.local:8443/idp/profile/SAML2/SOAP/SLO" /> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameidformat:transient</NameIDFormat> <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://rips4.ans.local:8443/idp/profile/Shibboleth/SSO"/> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://rips4.ans.local:8443/idp/profile/SAML2/POST/SSO"/> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POSTSimpleSign" Location="https://rips4.ans.local:8443/idp/profile/SAML2/POSTSimpleSign/SSO"/> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect" Location="https://rips4.ans.local:8443/idp/profile/SAML2/Redirect/SSO"/> </IDPSSODescriptor> <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <Extensions> <shibmd:Scope regexp="false">ans.local</shibmd:Scope> </Extensions> <KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDKDCCAhCgAwIBAgIVAN8On83uMYwVUL5+VF1e4q2ohp95MA0GCSqGSIb3DQEB BQUAMBoxGDAWBgNVBAMTD3JpcHM0LmFucy5sb2NhbDAeFw0xMzA3MjQxMDE4Mjha Fw0zMzA3MjQxMDE4MjhaMBoxGDAWBgNVBAMTD3JpcHM0LmFucy5sb2NhbDCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALfhpgnp4pOuqgGyW930eCaJ4XNK cHRHndJjQC1RxGNLg6Zdr5W01ysgbT216wtmY5fshrRfFssnTTwT5L3FeD5sZVcG kvwO/xTz8OxzieOptyNkUBlCwPpw9bc9RRZP0sD6UhA+fUfRu/20ycEg63J3crRC zBx3NOaoNfQF/E0F6jdPfycbbt08P8hyMGCPTBUfPWEzV0CdmubIC1e6MvHEh4Ji bpfSBc7RQmVswgKRAmsMhMlcNfHHqdQJLO3e2if+wCwUv+2pE2yOYT4PrzxHwhoE SMuz/lg8tRbEIhzF3gWwBxSphXY95sEUQRmrfJnNHkCQE9qjYsqqnqftGzMCAwEA AaNlMGMwQgYDVR0RBDswOYIPcmlwczQuYW5zLmxvY2FshiZodHRwczovL3JpcHM0 LmFucy5sb2NhbC9pZHAvc2hpYmJvbGV0aDAdBgNVHQ4EFgQU6XMshwc74FyrW9vp GkY3ZngvIYIwDQYJKoZIhvcNAQEFBQADggEBABr92Sl1VKmC67P7DXwPoQkhht7b ttgVqBqfIaKYXP3QlM7O76jm+BwD3Djqs4cr/ptq42L+km2F88N88mm0epsCddk0 KNF27hkqUeZecrwCcpqyI8fDUVYXRTwcP2DVkH24lHGmiJagPruPWmHrYBIY9Q84 1WeNnJ/TzgYGEI/JElBiLILfY55YWBhtS0F1c7ajQfwr0yG5ZH0Rs0B9toXNqhLk R36eBFyrjOrKu+V2VlGkiCprYNLfCpu3oDjBE/G3IJEmrQj4IxmLyPLyKciAfR+y EEmBT24tKsHXAzHAf9fMstWYGTcpcw8+G/oJo9xrtO14+lSzpJn+O9HSJAU= </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://rips4.ans.local:8443/idp/profile/SAML1/SOAP/AttributeQuery"/> <AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://rips4.ans.local:8443/idp/profile/SAML2/SOAP/AttributeQuery"/> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameidformat:transient</NameIDFormat> </AttributeAuthorityDescriptor>
2012/2013
</EntityDescriptor>
attribute-resolver.xml
<?xml version="1.0" encoding="UTF-8"?> <resolver:AttributeResolver xmlns:resolver="urn:mace:shibboleth:2.0:resolver" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pc="urn:mace:shibboleth:2.0:resolver:pc" xmlns:ad="urn:mace:shibboleth:2.0:resolver:ad" xmlns:dc="urn:mace:shibboleth:2.0:resolver:dc" xmlns:enc="urn:mace:shibboleth:2.0:attribute:encoder" xmlns:sec="urn:mace:shibboleth:2.0:security" xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver classpath:/schema/shibboleth-2.0-attribute-resolver.xsd urn:mace:shibboleth:2.0:resolver:pc classpath:/schema/shibboleth-2.0-attribute-resolver-pc.xsd urn:mace:shibboleth:2.0:resolver:ad classpath:/schema/shibboleth-2.0-attribute-resolver-ad.xsd urn:mace:shibboleth:2.0:resolver:dc classpath:/schema/shibboleth-2.0-attribute-resolver-dc.xsd urn:mace:shibboleth:2.0:attribute:encoder classpath:/schema/shibboleth-2.0-attributeencoder.xsd urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd"> <!-Attribute Definitions -->
 <resolver:AttributeDefinition xsi:type="ad:Simple" id="uid" sourceAttributeID="uid"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:uid" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="email" sourceAttributeID="mail"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="homePhone" sourceAttributeID="homePhone"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:homePhone" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.20" friendlyName="homePhone" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="homePostalAddress" sourceAttributeID="homePostalAddress"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:homePostalAddress" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.39" friendlyName="homePostalAddress" />
2012/2013
</resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="mobileNumber" sourceAttributeID="mobile"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mobile" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.41" friendlyName="mobile" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="pagerNumber" sourceAttributeID="pager"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:pager" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.42" friendlyName="pager" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="commonName" sourceAttributeID="cn"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:cn" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.3" friendlyName="cn" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="surname" sourceAttributeID="sn"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:sn" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.4" friendlyName="sn" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="locality" sourceAttributeID="l"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:l" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.7" friendlyName="l" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="stateProvince" sourceAttributeID="st"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:st" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.8" friendlyName="st" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="street" sourceAttributeID="street"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:street" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.9" friendlyName="street" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="organizationName" sourceAttributeID="o"> <resolver:Dependency ref="myLDAP" />
2012/2013
<resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:o" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.10" friendlyName="o" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="organizationalUnit" sourceAttributeID="ou"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:ou" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.11" friendlyName="ou" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="title" sourceAttributeID="title"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:title" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.12" friendlyName="title" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="postalAddress" sourceAttributeID="postalAddress"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:postalAddress" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.16" friendlyName="postalAddress" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="postalCode" sourceAttributeID="postalCode"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:postalCode" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.17" friendlyName="postalCode" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="postOfficeBox" sourceAttributeID="postOfficeBox"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:postOfficeBox" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.18" friendlyName="postOfficeBox" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="telephoneNumber" sourceAttributeID="telephoneNumber"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:telephoneNumber" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.20" friendlyName="telephoneNumber" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="givenName" sourceAttributeID="givenName"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:givenName" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.42" friendlyName="givenName" /> </resolver:AttributeDefinition>
2012/2013
<resolver:AttributeDefinition xsi:type="ad:Simple" id="initials" sourceAttributeID="initials"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:initials" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.43" friendlyName="initials" /> </resolver:AttributeDefinition>
 <resolver:AttributeDefinition xsi:type="ad:Simple" id="departmentNumber" sourceAttributeID="departmentNumber"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:departmentNumber" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.2" friendlyName="departmentNumber" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="displayName" sourceAttributeID="displayName"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:displayName" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.241" friendlyName="displayName" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="employeeNumber" sourceAttributeID="employeeNumber"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:employeeNumber" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.3" friendlyName="employeeNumber" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="employeeType" sourceAttributeID="employeeType"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:employeeType" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.4" friendlyName="employeeType" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="jpegPhoto" sourceAttributeID="jpegPhoto"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:jpegPhoto" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.60" friendlyName="jpegPhoto" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="preferredLanguage" sourceAttributeID="preferredLanguage"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:preferredLanguage" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.16.840.1.113730.3.1.39" friendlyName="preferredLanguage" /> </resolver:AttributeDefinition> 
2012/2013
<resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonAffiliation" sourceAttributeID="eduPersonAffiliation"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonAffiliation" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" friendlyName="eduPersonAffiliation" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonEntitlement" sourceAttributeID="eduPersonEntitlement"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonEntitlement" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" friendlyName="eduPersonEntitlement" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonNickname" sourceAttributeID="eduPersonNickname"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonNickname" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.2" friendlyName="eduPersonNickname" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonOrgDN" sourceAttributeID="eduPersonOrgDN"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonOrgDN" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.3" friendlyName="eduPersonOrgDN" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonOrgUnitDN" sourceAttributeID="eduPersonOrgUnitDN"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonOrgUnitDN" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.4" friendlyName="eduPersonOrgUnitDN" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonPrimaryAffiliation" sourceAttributeID="eduPersonPrimaryAffiliation"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonPrimaryAffiliation" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.5" friendlyName="eduPersonPrimaryAffiliation" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonPrimaryOrgUnitDN" sourceAttributeID="eduPersonPrimaryOrgUnitDN"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonPrimaryOrgUnitDN" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.8" friendlyName="eduPersonPrimaryOrgUnitDN" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonPrincipalName" scope="co.uk" sourceAttributeID="uid"> <resolver:Dependency ref="myLDAP" />
2012/2013
<resolver:AttributeEncoder xsi:type="enc:SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonPrincipalName" /> <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Scoped" id="eduPersonScopedAffiliation" scope="co.uk" sourceAttributeID="eduPersonAffiliation"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" /> <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" friendlyName="eduPersonScopedAffiliation" /> </resolver:AttributeDefinition> <resolver:AttributeDefinition xsi:type="ad:Simple" id="eduPersonAssurance" sourceAttributeID="eduPersonAssurance"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:eduPersonAssurance" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.11" friendlyName="eduPersonAssurance" /> </resolver:AttributeDefinition>  <resolver:AttributeDefinition id="transientId" xsi:type="ad:TransientId"> <resolver:Dependency ref="myLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier"/> <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> </resolver:AttributeDefinition>  <resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc" ldapURL="ldap://lonfp2.ans.local:389" baseDN="ou=People,dc=example,dc=com" principal="cn=Directory Manager" principalCredential="shibans"> <FilterTemplate> <![CDATA[ (uid=$requestContext.principalName) ]]> </FilterTemplate> </resolver:DataConnector>
<!-Principal Connectors -->  <resolver:PrincipalConnector xsi:type="pc:Transient" id="shibTransient" nameIDFormat="urn:mace:shibboleth:1.0:nameIdentifier"/> <resolver:PrincipalConnector xsi:type="pc:Transient" id="saml1Unspec" nameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/> <resolver:PrincipalConnector xsi:type="pc:Transient" id="saml2Transient" nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> </resolver:AttributeResolver>
<?xml version="1.0" encoding="UTF-8"?> <afp:AttributeFilterPolicyGroup id="ShibbolethFilterPolicy" xmlns:afp="urn:mace:shibboleth:2.0:afp" xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
2012/2013
xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:afp classpath:/schema/shibboleth-2.0-afp.xsd urn:mace:shibboleth:2.0:afp:mf:basic classpath:/schema/shibboleth-2.0-afp-mf-basic.xsd urn:mace:shibboleth:2.0:afp:mf:saml classpath:/schema/shibboleth-2.0-afp-mf-saml.xsd">  <afp:AttributeFilterPolicy id="releaseTransientIdToAnyone"> <afp:PolicyRequirementRule xsi:type="basic:ANY"/> <afp:AttributeRule attributeID="transientId"> <afp:PermitValueRule xsi:type="basic:ANY"/> </afp:AttributeRule> </afp:AttributeFilterPolicy>
 <afp:AttributeFilterPolicy id="releaseToAnyone"> <afp:PolicyRequirementRule xsi:type="basic:ANY" /> <afp:AttributeRule attributeID="givenName"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="uid"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="email"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="surname"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="mobileNumber"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="telephoneNumber"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="commonName"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="organizationName"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="eduPersonAffiliation"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="eduPersonEntitlement"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> </afp:AttributeFilterPolicy>
</afp:AttributeFilterPolicyGroup>
2012/2013
handler.xml
<?xml version="1.0" encoding="UTF-8"?> <ph:ProfileHandlerGroup xmlns:ph="urn:mace:shibboleth:2.0:idp:profile-handler" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:idp:profilehandler classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd">  <ph:ErrorHandler xsi:type="ph:JSPErrorHandler" jspPagePath="/error.jsp"/>  <!-All profile handlers defined below are accessed via the Servlet path "/profile" so if your profile handler's request path is "/Status" then the full path is "<servletContextName>/profile/Status" --> <ph:ProfileHandler xsi:type="ph:Status"> <ph:RequestPath>/Status</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAMLMetadata" metadataFile="C:\ANSIdP/metadata/idp-metadata.xml"> <ph:RequestPath>/Metadata/SAML</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:ShibbolethSSO" inboundBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" outboundBindingEnumeration="urn:oasis:names:tc:SAML:1.0:profiles:browser-post urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"> <ph:RequestPath>/Shibboleth/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML1AttributeQuery" inboundBinding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" outboundBindingEnumeration="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"> <ph:RequestPath>/SAML1/SOAP/AttributeQuery</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML1ArtifactResolution" inboundBinding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" outboundBindingEnumeration="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"> <ph:RequestPath>/SAML1/SOAP/ArtifactResolution</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/POST/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
2012/2013
outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/POST-SimpleSign/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/Redirect/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SSO" inboundBinding="urn:mace:shibboleth:2.0:profiles:AuthnRequest" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/Unsolicited/SSO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2ECP" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"> <ph:RequestPath>/SAML2/SOAP/ECP</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/Redirect/SLO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <ph:RequestPath>/SAML2/POST/SLO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect
2012/2013
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POSTSimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTPArtifact"> <ph:RequestPath>/SAML2/POST-SimpleSign/SLO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"> <ph:RequestPath>/SAML2/SOAP/SLO</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2SLO" inboundBinding="urn:mace:shibboleth:2.0:profiles:LocalLogout"> <ph:RequestPath>/Logout</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2AttributeQuery" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"> <ph:RequestPath>/SAML2/SOAP/AttributeQuery</ph:RequestPath> </ph:ProfileHandler> <ph:ProfileHandler xsi:type="ph:SAML2ArtifactResolution" inboundBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" outboundBindingEnumeration="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"> <ph:RequestPath>/SAML2/SOAP/ArtifactResolution</ph:RequestPath> </ph:ProfileHandler>  <ph:LoginHandler xsi:type="ph:UsernamePassword" jaasConfigurationLocation="file:C:/ANSIdP/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTrans port</ph:AuthenticationMethod> </ph:LoginHandler> <!-SSO setting (without this, the SSO mechanism cannot work --> <ph:LoginHandler xsi:type="ph:PreviousSession"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</ph:Au thenticationMethod> </ph:LoginHandler> </ph:ProfileHandlerGroup>
logging.xml
<?xml version="1.0" encoding="UTF-8"?> <configuration>
 <logger name="edu.internet2.middleware.shibboleth" level="DEBUG"/>  <logger name="org.opensaml" level="WARN"/> 
2012/2013
<logger name="edu.vt.middleware.ldap.jaas.JaasAuthenticator" level="DEBUG" /> <logger name="edu.vt.middleware.ldap" level="DEBUG"/> <!-Logging appenders define where and how logging messages are logged. --> <appender name="IDP_ACCESS" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>C:\ANSIdP/logs/idp-access.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>C:\ANSIdP/logs/idp-access-%d{yyyy-MMdd}.log</FileNamePattern> </rollingPolicy> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <charset>UTF-8</charset> <Pattern>%msg%n</Pattern> </encoder> </appender> <appender name="IDP_AUDIT" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>C:\ANSIdP/logs/idp-audit.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>C:\ANSIdP/logs/idp-audit-%d{yyyy-MMdd}.log</FileNamePattern> </rollingPolicy> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <charset>UTF-8</charset> <Pattern>%msg%n</Pattern> </encoder> </appender> <appender name="IDP_PROCESS" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>C:\ANSIdP/logs/idp-process.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>C:\ANSIdP/logs/idp-process-%d{yyyy-MMdd}.log</FileNamePattern> </rollingPolicy> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <charset>UTF-8</charset> <Pattern>%date{HH:mm:ss.SSS} - %level [%logger:%line] - %msg%n</Pattern> </encoder> </appender> <logger name="Shibboleth-Access" level="ALL"> <appender-ref ref="IDP_ACCESS"/> </logger> <logger name="Shibboleth-Audit" level="ALL"> <appender-ref ref="IDP_AUDIT"/> </logger> <logger name="org.springframework" level="OFF"/> <logger name="org.apache.catalina" level="ERROR"/> <root level="ERROR"> <appender-ref ref="IDP_PROCESS"/> </root> </configuration>
2012/2013
login.config
ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule required ldapUrl="ldap://lonfp2.ans.local:389" base="ou=People,dc=example,dc=com" ssl="false" userField="uid" subtreeSearch="true" principal="cn=Directory Manager" ServiceCredential="shibans";
};
login.jsp
<!DOCTYPE html> <%@ taglib uri="urn:mace:shibboleth:2.0:idp:ui" prefix="idpui" %> <html> <head> <meta charset="utf-8" /> <title>247lib Login Page</title> <link rel="stylesheet" type="text/css" href="<%= request.getContextPath()%>/login.css"/> </head> <body> <div class="wrapper"> <div class="container"> <header> <a class="logo" href="../images/247lib.jpg"><img src="<%= request.getContextPath()%>/images/247lib.jpg" alt="Replace or remove this logo"/></a> </header> <div class="content"> <div class="column one"> <% if(request.getAttribute("actionUrl") != null){ %> <form id="login" action="<%=request.getAttribute("actionUrl")%>" method="post"> <% }else{ %> <form id="login" action="j_security_check" method="post"> <% } %> <% if ("true".equals(request.getAttribute("loginFailed"))) { %> <section> <p class="form-element form-error">Login has failed. Double-check your username and password or contact the ANS/247lib Support service.</p> </section> <% } %> <legend> Log in to <idpui:serviceName/> </legend> <section> <label for="username">Username</label> <input class="form-element form-field" name="j_username" type="text" value=""> </section>
2012/2013
<section> <label for="password">Password</label> <input class="form-element form-field" name="j_password" type="password" value=""> </section> <section> <button class="form-element form-button" type="submit">Login</button> </section> </form> <% // // SP Description & Logo (optional) // These idpui lines will display added information (if available // in the metadata) about the Service Provider (SP) that requested // authentication. These idpui lines are "active" in this example // (not commented out) -- this extra SP info will be displayed. // Remove or comment out these lines to stop the display of the // added SP information. // // Documentation: // https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPassLoginPage // // Example: %> <p> <idpui:serviceLogo>247lib.com</idpui:serviceLogo> <idpui:serviceDescription>is a library management system maintained and supplied by the ANS Service Provider</idpui:serviceDescription> </p>
</div> <div class="column two"> <ul class="list list-help"> <li class="list-help-item"><a href="http://www.answeb.co.uk/support/support.aspx?menuId=top_support"><span class="item-marker">&rsaquo;</span> Forgot your password?</a></li> <li class="list-help-item"><a href="http://www.answeb.co.uk/support/support.aspx?menuId=top_support"><span class="item-marker">&rsaquo;</span> Need Help?</a></li> <li class="list-help-item"><a href="http://www.answeb.co.uk/contactus.aspx?menuId=top_about_us"><span class="itemmarker">&rsaquo;</span> Get in touch with ANS Ltd</a></li> </ul> </div> </div> </div> <footer> <div class="container container-footer"> <p class="footer-text"> Copyright 2013 Applied Network Solutions Limited. All Rights Reserved</p> </div> </footer> </div> </body> </html>
server.xml
<?xml version='1.0' encoding='utf-8'?> <Server port="8005" shutdown="SHUTDOWN">
2012/2013
 <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />  <Listener className="org.apache.catalina.core.JasperListener" />  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" /> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<GlobalNamingResources>  <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /> </GlobalNamingResources> <Service name="Catalina"> <!-Define a non-SSL HTTP/1.1 Connector on port 8080 --> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />  <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />  <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" SSLImplementation="edu.internet2.middleware.security.tomcat6.DelegateToApplicationJSSE Implementation" scheme="https" SSLEnabled="true" clientAuth="want" keystoreFile="C:\ANSIdP\credentials\idp.jks" keystorePass="shibans" />
 <Engine name="Catalina" defaultHost="localhost">
 <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>  <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
2012/2013
</Host> </Engine> </Service> </Server>
idp.xml
<Context docBase="C:\ANSIdP\war\idp.war" privileged="true" antiResourceLocking="false" antiJARLocking="false" unpackWAR="false" swallowOutput="true" />
about_247lib.html
<html> <head> <style type="text/css"> .auto-style1 { color: #0000FF; } </style> </head> <body> <span class="auto-style1"><strong>You are logged in using Shibboleth-based ANS IdP!</strong></span> <hr /> <div id="rightCntr">  <div class="webtermsBox">
<h1 class="auto-style1">247lib.com Library Management System</h1> <div style="text-align:justify"> <p> "247Lib.com is library management software, which provides an exciting robust web browser based interface. Configurations are available for charities, colleges, schools, health libraries, corporate libraries, law libraries, prisons, public libraries, government libraries and special libraries. 247lib.com is suitable for organisations of any size from those run by volunteers to large enterprises. </p> <p> With its colourful web browser interface and clear screens with online help, staff and users find 247lib.com library software intuitive and easy to use. You can access your library and resources from anywhere including your school, workplace or home. 247lib.com will raise the profile of your library. </p> <p> 247lib.com configurations provide a complete integrated library management system with modules available
2012/2013
for authorities, biometrics, book covers, bookings, borrowers/patrons, catalogue, enquiry management, finance and budgets, orders and invoices, periodicals, reports (emails, files and SMS), reviews and ratings, self-issue ( SIP2 ), stock item, supervisor, surveys and polls, z39.50. You can address any library management or resource management task by simply enabling the modules you want to use from the friendly web based configuration tool. </p> <p> 247lib.com allows you to manage all your resources including books, eBooks, periodicals, eJournals, art, assets, room bookings, news, events, online discussions and much more ... </p> <p> 247lib.com may be hosted either at your premises or by third party hosters. 247lib.com is t he only UK developed library management system, which has been approved on the government procurement website the G-Cloud. </p> <p> Microsoft and HP have both endorsed 247lib.com with '247lib.com in a box', which gives you a 'Microsoft Windows Embedded licence' ( a long-life unlimited user license from Microsoft) and a powerful server ( from HP). '247lib.com in a box' means that you can have a complete solution delivered to you including hardware, operating system and 247lib.com, which you just plug in - no awkward installation problems or installation fees. 247lib.com is the only library management system, which has been endorsed by Microsoft and HP in this way. </p> <p> If you are converting from an existing system, well also take care of the data migration for you." </p> </div> </div>  </div> To close your session, <a href="https://ans.247lib.com/Shibboleth.sso/Logout">Click on this link </a> <hr /> <span class="auto-style1">Note:</span> To completely log out, close your internet browser for more security. <hr /> </body></html>
server_variables_user_attributes.aspx
<%@ Page Language="C#" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server"> <title>HTTP Server Variables </title> </head> <body> You are logged in using ANS Identity Provider!
To close your session, <a href="https://ans.247lib.com/Shibboleth.sso/Logout">Click here</a> <hr style="background-color: #CCFFFF" /> Note: To completely log out, close your internet browser.
2012/2013
<hr style="background-color: #CCFFFF" /> Below are the variables you requested. Your identity attributes can be viewed at the end of this page. <hr style="background-color: #66CCFF" /> <h2>HTTP Server Variables and user attributes</h2> <table border="1"> <tr> <th style="background-color: #66FFFF">Variable</th> <th align="left" style="background-color: #66FFFF">Value</th> </tr> <% foreach (string key in Request.ServerVariables.AllKeys) { %> <tr> <td><%=key %></td> <td><%=Request.ServerVariables[key]%></td> </tr> <% } %> </table> </body> </html>
another_view_of_server_vars_and_attrib.aspx
<%@ Page Language="VB" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server"> <title>HTTP Server Variables </title> </head> <body> You are logged in using Shibboleth-based ANS IdP!
To close your session, <a href="https://ans.247lib.com/Shibboleth.sso/Logout">Click here</a> <hr /> Note: To completely log out, close your internet browser. <hr /> Below are the variables you requested. Your identity attributes can be viewed at the end of this page. <hr /> <h2>HTTP Server Variables and user attributes</h2> <pre> <% Dim k as Integer = 0 For k=0 To Request.Servervariables.Count - 1 Response.Write(Request.Servervariables.Keys(k) & " = " & Request.Servervariables(k) & "<br>") Next %> </pre> </body> </html>
2012/2013

Investigation and Implementation of Shibboleth SSO Authentication Mechanism Through A Specific Scenario'

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Investigation and Implementation of Shibboleth SSO Authentication Mechanism Through A Specific Scenario'

Transféré par

Droits d'auteur :

C

Author: Gilles Rubens Badouet MSc Network Computing

Supervisor: Dr. Rahat Iqbal

Academic Year: 2012/13

Signed: Gilles Rubens Badouet

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Document map and summary view

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

2.5 Shibboleth as an implementation framework of SAML ................................. 33

6.2 Real time implementation ................................................................................ 84

8.3 Other management issues and countermeasures ....................................... 107

8.4 Quality Management....................................................................................... 111

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Acronyms and abbreviations list

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Additional Materials on the Accompanying CD

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

My sincere thanks are addressed to:

Coventry University staff for their assistance

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

1.2 Background to the Project

1.3 Project Scope and Objectives

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

1.4 Report overview

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

2.1 Problem Identification

2.2 Methodology approach and justification

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Figure 1: Methodology approach

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

2.3 Overview of the Web SSO mechanism

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

2.4 Major aspects of SAML protocol and SSO use case

Authentication Assertion Attribute Assertion

Policy Enforcement Point d

Attribute Authority (Policy Decision Point)

Figure 3: SAML Basic use case

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Figure 4: SAML structure

Assertions: A SAML assertion helps parties to use statements to confirm

Protocols: They are used in SAML to define requests and responses

Profiles: They determine how protocols, assertions and bindings are

2.4.5 SAML Components structures Subject, Assertion and Statement Structure

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Example of an Attribute Statement structure

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Figure 6: Simplified structure of an attribute (OASIS, 2008).

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

To ensure the integrity and the confidentiality of exchanged messages, HTTP

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

2.5 Shibboleth as an implementation framework of SAML

Artifact Resolution Service

Inter-site Transfer Service

Figure 7: IdP components structure

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013

Gilles Rubens Badouet| M08CDE Project| Coventry University| 2012-2013