Summary: An explanation of how to request access to UCI's IdP.
Overview
This document describes the process involved in adding a system to UCI's Shibboleth IdP. It is not meant to be a tutorial on configuring Shibboleth in any way, rather to facilitate interactions with OIT employees in configuring your service. It is assumed that you already have your shibboleth SP configured before contacting OIT or that you intend to bring it up as a part of shibbolizing with OIT.
Step 1: Authorization
The first step in setting up your application for use with Shibboleth is to contact
The Office
of Information Technology (OIT)
to request approval for access to the resources you require.
The following information must be included in your request:
- Administrative Contact
- Name
- Telephone
- Technical Contact
- Name
- Telephone
- UCI Support Contact
- Name
- Telephone
- A description of your service
- The attributes you wish us to release
- Metadata or just your ProviderID/EntityID if with InCommon
Step 2: Configuration
OIT needs two pieces of information in order to configure it's IdP to communicate with your SP: Metadata and a list of attributes you request.
Metadata
Incommon
The InCommon Federation consists of all campuses in the UC system, many other educational institutions and many services providers. Joining InCommon has some overhead, especially for a single SP interacting with just UCI. However, if you intend to expand your service to several institutions it is very advantageous to register with InCommon. The reason for this is that you don't have to manage distribution of metadata to every organization you interact with. Instead, you rely on the procedures of the federation to distribute the metadata and ensure everyone is up to data with your current information. Additionally, the federation provides a basis of trust between you and the IdP. The federation ensures members act according to some established guidelines, or risk losing their membership to the federation. This lets you focus less on certain security concerns and more on the implementation of your service.
If you are an organization within UCI, you do not have to rejoin as a separate entity. OIT has already become a member of InCommon and it is likely we can simply add your servers to our configuration and you will be included in the normal flow of metadata distribution. Please request this in the normal flow of getting set up with UCI's IdP and we will work together to get your InCommon data configured.
Once you have successfully been registered with InCommon, operation is just a matter of ensuring that OIT has updated our metadata (something we do daily) and that the ARPs are in order. You should supply OIT with your ProviderID/EntityID to simplify configuration.
For more information on joining InCommon as a separate entity visit their web site.
You can view your metadata by visiting https://(hostname)/Shibboleth.sso/Metadata on most default-configured Shib 2.x servers.
Attribute Release Policies (ARP)
Once the servers have exchanged Metadata they should be able to communicate. However, they will not do anything useful as all they will be able to exchange is an acknowledgement that somebody successfully authenticated (not even an admission of who). In order to make them useful, the IdP must authorize release of specific attributes (eg. UCInetID, E-mail Address, Name, etc...)
This list should have been provided to us in step #1 and will be configured during this step by OIT.
Step 3: Profit!
That's it. Shibboleth should be functional and all you will need to do now is configure your application and SP to properly handle the attributes received from the IdP. At this point, maintenance mode is entered and updates, changes and service problems will be communicated to OIT as necessary.
