This document is intended for customers who decided at the intake meeting with ISC that federation best suits the needs of their application and further that have chosen to participate in the InCommon federation. This document reviews the steps necessary to comply with InCommonís policies and makes reference to InCommonís publicly available documentation to best inform the customer regarding the InCommon application registration process. As part of this process, the InCommon Registration form must be completed in addition to the SP Registration form and is not intended as a replacement. The completed forms should be submitted to ISC.
Web-based applications may be deployed using Single Sign On (SSO) architecture such as the one that Shibboleth provides, using the Security Assertion Markup Language (SAML) protocol. This provides scalability and security for user accounts and applications, by cleanly separating management of the application (service provider, or SP) from management of accounts of applications users, which are maintained at their home institution behind an identity provider (IdP). SAML assertions allow authentication decisions to be made at the userís home institution, leaving authorization decisions to the application. This is made possible by a predefined trust relationship between the application provider and home institutions of the users. Furthermore, using the Shibboleth/SAML SSO technologies, it is straightforward to enable thousands of users from many different administrative domains to all utilize the same web application. All these benefits are realized without giving up control or ownership at either the application side or the institution side.
The InCommon federation manages a web of such trust relationships, making for easier on-boarding of future identity providers. InCommon vets its members and provides a standardized format to reduce the need for repeat integration of new resources.
To operate as a service provider within federation, InCommon mandates a standard set of operational practices. These practices form the backbone of the federation by ensuring support, transparency, privacy and security for all participating organizations. Before becoming a member of the InCommon federation, service providers need to comply with InCommon policy, business and technical standards. The following steps act as a guide to bring a service provider into compliance before they can register their application with InCommon.
Included is an excerpt from the InCommon POP containing only the worksheet that the customer will need to complete. The customer should still review the full POP document referenced at http://www.incommon.org/policies.html as well as the Federated Identity Resources Booklet, from which this document borrows heavily, at https://spaces.internet2.edu/display/InCCollaborate/Information+from+InCommon.
Penn is allowed a certain number of SPs as part of its membership in InCommon at no additional cost, but as the number of SPs increase, ISC will reassess the funding model as needed to ensure that the service is sustainable.
Review InCommon Policies page, particularly the Participant Operation Policies (POP).
The InCommon Policies page not only contains important information regarding the policies of the federation but also examples and references to actual POPs from other participating organizations. These will be useful as a guide for the types of information required from the POP worksheet which will need to be completed.
Determine service(s) and target user group for application.
Determine audience and risk for each offered service and related requirements. How will your organization decide whether a user is eligible or not to use the service? What kind of assurance of the userís identity will your organization require from the accessing organizations?
Develop policy around use of received attributes (retention, sharing, etc).
Will your organization keep the identity attribute information that identity providers send and if so, for how long? Will your organization release any identity attribute information to third parties, if so, under what circumstances and will a user have any control over such a release?
Ensure your policies comply with the current InCommon federation requirements.
Check the InCommon site (http://www.incommon.org/policies.html) to ensure your organizationís policies are in compliance with the current federation requirements. It may be necessary to update your organizations policies to remain in compliance with InCommonís standards in the event that the standards change.
Business Practice Steps
Identify who is responsible for managing the federated access to your service(s).
Information for the managing parties as well as the involved technical parties ensures that there is a clear point of contact for any issues that may arise during federated access to your application.
Ensure you have a defined problem resolution process for remote users.
If a user has a problem when accessing your service, these should be a predefined and obvious process for the user to follow for assistance.
Identify what attributes will be required from an IdP for the application.
InCommon recommends using the standardized attributes as much as possible to minimize the cost of scalability. An overview of recommended attributes is available at http://www.incommon.org/attributes.html. If any non-standard attributes are required, this may inhibit authorization into your application.
Define problem escalation and support procedure for external identity providers.
If you have a break in service, how will you let your partners know? If you find one or more users abusing your service, how will you contact their home organization?
If you require IdPs to register with you, define a process for requesting services.
Defining a process surrounding the on-boarding of IdPs will minimize the resources necessary to add additional IdPs, provide a formal and trackable trail, simplify and reduce troubleshooting and offer transparency and clarity to the IdP. Also, define a process for responding to these requests.
Complete and post your InCommon POP.
InCommon requires that a participantís POP should either be publicly available or information regarding who to contact for the POP should be readily available. To accomplish this for Penn, ISC requires SPs to complete the InCommon Request form at the end of this document. The form is an abbreviated version of the full POP but customer should still familiarize themselves with the full POP document on InCommon Policies Page. For reference, Pennís POP is available online.
Install SAML-capable service provider federation software (e.g. Shibboleth).
Software such as Shibboleth manages the receipt of security assertions, their verification and their processing in addition to requesting authentication from a userís home institution.
Connect application to federation software and configure to authorize by IdP attributes.
The application will need to be connected to the federation software so that it can access the authentication assertion generated by the IdP. It will need access to this so that it can make an authorization decision based on the attributes.
Configure SP software with federation metadata and credentials.
This is what causes the new service provider to trust the incoming identity assertions from other InCommon members. The federation metadata contains credentials which allow the SP to verify the senderís signature and/or decrypt the contents of the message.