| Title | Created | Resolved | |
|---|---|---|---|
| Service Maintenance: Microsoft Exchange | Friday, June 21, 2013 - 10:00pm | Friday, June 21, 2013 - 11:59pm | VIEW |
| Service Maintenance: UCB Files | Friday, June 21, 2013 - 10:00pm | Friday, June 21, 2013 - 11:59pm | VIEW |
Federated Identity Service - FAQ
These commonly asked questions will help web application owners determine whether Federated Identity Service authentication will work with, and is appropriate for, their web application.
General FAQ
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.
Please call the IT Service Center at 303-735-4357 (or 5-HELP from an on-campus phone) to request additional information.
You may request consideration by calling the IT Service Center at 303-735-4357 (or 5-HELP from an on-campus phone) or help@colorado.edu.
Once you submit a request with the IT Service Center, you will be asked to complete the Federated Identity Service request/agreement form. 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 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.
Please refer to the Federated Identity Service Service webpage.
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.
Federated Identity Service provides an environment in which users can authenticate/log in one time with their respective CU Login Name and Identikey password to a central server in order to access multiple services protected with Federated Identity Service without needing to re-authenticate.
You 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. You can review and release your approvals at any time. If the attributes change for any reason, you will be prompted to review and release at your next login.