Federated Identity Service - FAQ

Federated Identity Service provides an environment in which users can authenticate/log in one time with their respective Identikey username and password to a central server in order to access multiple services protected with Federated Identity Service without needing to re-authenticate.

Your Digital ID card outlines the identifying information that is shared with the service(s) you are logging into to provide you access to that service. Due to a recent update of the Federated Identity Service, you may see your Digital ID Card and be prompted with release consent options. You have the option to provide consent for each login, or store consent and not be prompted again unless there is a change in the information. First-time users of a protective service will always be prompted for consent.

The system and each service have pre-set timeouts, which aid in minimizing the exposure of forgotten Web browser sessions.

No. Once you have started a session in Federated Identity Service, you are logged in to all CU Boulder services that utilize Federated Identity Service to authenticate. Don't forget to log out once you are finished.

Federated Identity Service enables Single-Sign-On (SSO) with other Federated Identity Service enabled services. The consequences of this SSO are the service provider’s. In some cases, SSO may not be a desirable outcome for a given application service. Alternative authentication technologies utilizing LDAP or custom token-exchange approaches may be required.

Perhaps, however there are several considerations:

• Is the application compatible?  Federated Identity Service is designed to work with Shibboleth enabled applications.  The underlying technology used by Shibboleth includes Security Access Markup Language (SAML).   Most Shibboleth and many SAML applications are potential candidates for Federated Identity Service authentication.
• Are you able to make the application compatible? With the right technical skills and resources, it is possible to make a web application Shibboleth compatible. If your team has the technical know-how and resources to create a Shibboleth or SAML authentication service layer, commonly referred to as a “service provider,” then Federated Identity Service may be an option. OIT can work with you to determine if this is an option for you. OIT’s Federated Identity Service service strategy includes a roadmap item for providing basic service provider development support for the most common campus Web platforms at some future date.
• Is Federated Identity Service the best solution for your application need?  Federated Identity Service is a “federated” authentication service. The design for federation adds certain constraints and complexities that may not represent the best choice for any particular authentication requirement. It may be advisable to implement a directory login or token-exchange solution in some cases.
• Do you have a sufficient support structure to handle application-related help calls and functionality problems?  OIT will assist Web application owners with creating the initial integration and attribute release policies that enable Federated Identity Service authentication. OIT can also assist with validating authentication data and attribute release. However, the application owner must provide incident resolution and application support, or provide vendor support for these.  OIT cannot assist with application support, including login problems that occur after a valid Federated Identity Service data release.
• What data attributes does your application require? See the Federated Identity Service Digital ID Card attributes page for a list of attributes that are currently approved for release.  We may add additional directory attributes as business requirements indicate.  Attribute release may require data owner and custodian approval and is subject to security, legal, and privacy considerations.  Any data release must be compliant with regulatory and policy requirements and in the best interest of the university.

No, but it is recommended.  Federation is built on a trust fabric, agreements, practices and language that all enable cooperation across organizational boundaries.  If your application is provided through an InCommon federation agreement, then the operating policies and expected behaviors related to attribute data exchanges are already established. 

If not, you must demonstrate a comparable agreement with the application provider to ensure university data is managed in accordance with all applicable policies and requirements.  In some cases, application provider membership in InCommon may expedite the facilitation of Federated Identity Service Integration.  We recommend any web application provider that wishes to use federated authentication be familiar with the InCommon Federation and its practices and participant expectations. 

Fill out the Service Provider Enablement Request. For simple requests, it may be sufficient for you to complete the form. For more complex requests, as a next step, an OIT team member will reach out to you to further discuss your request to determine if Federated Identity Service is right for your web application. 

The list of information needed to request SSO includes:

• IDP Target url and certificate
• Static Landing page
• Service Owner Information (including organization, role/title and contact information)
• How is this service being built/acquired?
• Technical Contact Name and Role
• Organization or Provider
• Technical/Support contact information
• Service Name and Purpose
• Service URL
• Other Service Designation/Common Reference
• What date will this service be live?
• Are you using shibboleth SP? 
• Is this an existing Federated Identity service?
• Will this application be collecting additional biographical information from user
• Service Purpose Statement
• Service Attributes

Visit the Service Provider Enablement Request form for more information. 

Perhaps. Single-sign-on (SSO) is a native capability of Shibboleth and thus Federated Identity Service. It cannot be turned off or bypassed. Federated Identity Service is primarily a federation authentication service, not a SSO solution. As a result, SSO may be a beneficial feature for some federated authentication solutions, but it may also represent a less-than-optimal consequence to others. OIT can help a web application provider consider the consequences and alternatives of Federated Identity Service SSO.

Visit the Digital ID Card attributes page for a table with explanations of each attribute.