Executive Summary
TBD
Problem Statement: Why is Such a Service Needed?
Research Service Providers (SPs) often find that the population they want to serve includes individuals who are not represented by campus-based or other institutional Identity Providers (IdPs), or whose organizational IdP refuses to release attributes necessary for the operation of the SP. Ideally in those cases such individuals could be directed to register with a participating IdP that offered no-cost, easy registration processes. However, none of the existing IdPs meet all the requirements of the research community. What is needed is an IdP of Last Resort specifically addressing this service gap.
To illustrate how this plays out, take the example of InCommon. As each new R&S SP comes online, it must address the gaps in coverage of the SP's user community by InCommon R&S IdPs. The lack of an IdPoLR offering by InCommon requires the SP to choose a non-InCommon solution to this problem. Typically the SP decides to use local user passwords and/or Google logins, and the SP either makes InCommon logins a secondary option or decides that InCommon integration isn't worth the additional effort and so doesn't register with InCommon at all. As new R&S SPs come online all the time, availability of an InCommon IdPoLR is an urgent need for growing InCommon's relevance in the research community.
The “IdP of Last Resort” is, as the name suggests, only intended as a last resort and is not intended to take the place of an organizational IdP. Having an IdP run by an organization with which the user is affiliated, and which meets the user’s needs in interacting with SPs, is clearly the desirable state for all users.
It is our implicit recommendation that InCommon continue to make it very plain to its participants that, if they are not doing so already, they should endeavor to run an IdP for its user community which is managed in such a way as to meet their needs. E.g., if organizational policy is preventing the IdP from releasing attributes required by SPs that the user needs to access, then the policy should be revisited in that light, and/or a clear and flexible exception process implemented. Users should use their organizational IdP unless:
the organization doesn't have an IdP
the organization’s IdP doesn't release required attributes to the SP
the SP requires ECP but the organization’s IdP doesn't support ECP
the SP requires MFA but the organization’s IdP doesn't support MFA
Generally the user can and will use the organizational IdP for most SPs, but due to attribute release policy constraints, or an unmet need for ECP or MFA, the user may find it necessary to use the IdPoLR with a few SPs. In sum, using the IdPoLR should be the exception, not the rule.
Requirements
- Support for user self-registration
- User registration incorporated into sign-in flow, so new user is not stranded at IdP
- User registers once for sign-in to multiple Research and Scholarship (R&S)-tagged SPs (i.e., user identity is not SP-specific)
- Once user has authenticated at the IdP, user is not prompted for password again when visiting other SPs during the same browser session, unless required by the SP
- IdP must support the R&S entity category and be tagged as such
- Ability to Assign/Assert ePPNs
- Ability to Assign/Assert ePTIDs if ePPNs are re-assignable
- Must address the service longevity issue (even if for now the response is "TBD")
- Support for SAML Enhanced Client or Proxy (ECP)
- Accepts SP requests for authentication contexts via the standard SAML2 Authentication Request Protocol
- This is for their InCommon Bronze, as well as Silver and MFA, if supported.
- Support for Recommended Technical Basics for IdPs
- Conforms to the 'Interoperable SAML 2.0 Web Browser SSO Deployment
Profile' as documented at http://saml2int.org - Self-assertion of InCommon Bronze compliance
- No commercial interest in the use of user data
- IdP must be available globally to any R&S tagged SP
- NOTE: This can only be achieved at the federation level, not unilaterally by an IdP
- Available to users throughout the world (perhaps with invitation from "approved" projects)
The following criteria are highly desirable, but not required.
- Publishes aggregate usage statistics to give feedback to campus IT on use by their constituency (i.e., motivate campus to participate in R&S so the campus users don't need the IdPoLR anymore)
- Support for user consent
- Support for Silver credentials and authN (to be combined with local identity vetting to achieve Silver LoA
- Low/no cost to SPs for use
- No cost for users
- Accepts non-ASCII characters (e.g. uses UTF-8 as the default encoding) in user-entered data
- Support for some form of multi-factor authentication
Risks and Their Mitigation
Risk: Loss of incentive for institutions to support R&S and its associated attribute release policy. Mitigation: Foster better understanding by campus leadership how essential it is to support the research communities' needs with regard to federated identity. See also the second half of the problem statement above.
Risk: Potential users will be unaware of the option to use IdPoLR. Mitigation: Research SPs actively market the option to their users and make it easy to use.
Risk: If InCommon launches a trial service and at the end of the trial it is decommissioned, users & SPs could be orphaned. Mitigation: Lower the risk of service decommissioning by fostering adoption and use of the IdPoLR service and working together to develop a plan for service sustainability.
Risk: If InCommon waits until we have the perfect service, the Research SPs will have found one or more non-InCommon solutions. Mitigation: Roll out version 1.0 of the service as recommended in this document.
Risk: Self-registration without additional requirements around identity proofing would not satisfy the security concerns of R&S SPs. Mitigation: Add identity proofing steps to a post 1.0 version of the service. In the meantime, it is our understanding that many research organizations vet identities of their remote users through out-of-band means. In such cases the SP admins are relying only on the IdP's assertion that user x controls a set of authentication credentials (i.e. they successfully authenticated). If the SP admins have established to their satisfaction through other means that the person controlling those credentials is someone known to their community, the admins may have mitigated, to their satisfaction, the risk implied by the IdP's low/zero level of ID proofing. If the process involves some form of stronger authentication, such as the use of two factors, the risk that the credential is under the control of someone other than the original holder is mitigated to a further degree.
Recommendations
Short and Long Term Recommendations
In recent years InCommon has expressed interest in offering stronger and more direct support for the research mission of member campuses and virtual organizations. One of the more concrete ways to back this up with action in the near term would be for InCommon to help bring into existence an IdP of Last Resort service meeting the needs of R&S service providers. Therefore, our primary recommendation is that InCommon take steps to help make available a production IdPoLR service. An IdP meeting all these requirements is unlikely to appear through spontaneous generation. On the other hand, InCommon does not necessarily need to operate the IdP in question, it may be enough for InCommon to identify and support the launch of an independent service operator.
Our recommendations include a near-term plan to get an IdPoLR service into production as quickly as possible and a longer-term plan to create a level playing field for any potential provider to offer a comparable or better service. The urgency behind the short-term recommendation comes from the research service providers who have a critical unmet need to enable all of their potential users to access there research sites and tools. The long-term value of fostering multiple IdPs that meet this requirement is to mitigate the risk that failure of a single IdP would mean that the required service goes away.
Having a clear set of requirements is one important prerequisite to creating a level playing field on which multiple IdPoLRs can play. Another is some form of identity federation-based vetting and tagging of candidate IdPoLR services. Both of these prerequisites could be met by leveraging emerging practices in the entity category space. The REFEDS Research and Scholarship Entity Category specification (https://refeds.org/category/research-and-scholarship/) provides a concrete example of this approach in action. Again by having short and long term plans, an initial IdPoLR service could be made operational prior to committing to define an entity category (and registration processes) for candidate IdPoLRs.
Near Term and Possible Longer Term Candidate Services
The working group recommends working with the non-profit UnitedId (unitedid.org) to roll out an initial version of the defined IdPoLR service. We see no other ready candidates in the non-commercial space. Could the R&S needs be met by an existing external IdP offered by a commercial company? Such a solution would fall short of meeting several of the mandatory requirements: 1) Most obviously it would not be able to truthfully proclaim that it has no commercial interest in the use of user data; 2) Unless it becomes a member of an existing identity federation, it would not be able to qualify as an R&S-supporting IdP or be certified at federation-defined levels of assurance such as InCommon bronze; 3) It would not support ECP; and 4) With one possible exception it could not provide a suitable identifier: None of the known providers guarantee non-reassignability of usernames for supplying an ePPN and only one offers a directed identifier (like ePTID) as an alternative. A social-to-SAML gateway could be designed to mitigate many of these deficiencies, but it would not be a straight-forward or issue-free effort to come up with such a design.
Alternatives to recommended solution
We also investigated the extent to which existing or planned identity provider services within InCommon could meet the mandatory requirements. The certificate manager application and the federation manager application use an Multifactor IdP Proxy combined with a social-to-SAML gateway to serve administrators who do not (yet) have a home IdP. There are plans to supplement this with a native IdP service to address cases where users don't want to use commercial identity providers and have no home IdP. This "embedded IdP" could theoretically be enhanced to act as an IdP for R&S SPs, but that is several technical steps and a few major service portfolio decisions away from realization.
Looking longer term, the TIER initiative is committed to address a number of gaps in identity and access management and an IdPoLR service might be considered one of those gaps, but the TIER effort is at the requirements gathering stage, and development priorities are yet to be defined.
Assessment of recommended solution with respect to defined requirements
The near-term solution should initially offer a basic set of identity provider services. The suite of services could grow over time as needs evolve and resources permit. Here is an assessment of UnitedId against the requirements defined above:
UnitedId meets the following MUST requirements today:
- Support for user self-registration (but see first bullet under 'some dev. work needed' below
- Once user has authN (there is an SSO session)
- Ability to assign ePPN (these are non-reassignable)
- Accepts SP requests for authentication contexts via the standard SAML2 Authentication Request Protocol
- Support for Tech Basics for IdPs
- Conforms to saml2int
- No commercial interest in the use of user data (by organizational principle, backed by support of Code of Conduct)
- Available to users throughout the world
By joining InCommon and taking a set of procedural steps, UnitedId could also meet the following MUST Requirements
- IdP must support R&S
- Support for ECP (already on UnitedId roadmap under near-term goals)
- InCommon and UnitedId will work together to define approaches to service sustainability, but the first goal is to get an initial IdPoLR in service and in use
- Self assertion of bronze
- IdP must be available globally to any R&S tagged SP (both InCommon and Refeds R&S for now)
Some development work would be needed to meet the remaining MUST Requirement
- In case user is a first-time registrant at UnitedId, an appropriate SAML error message is returned to the SP so that the user is not stranded between IdP and SP, but is returned to the SP where the error can be handled gracefully.
UnitedId also meets the following desired conditions:
- Support for user consent
- Accepts non-ASCII characters in user-entered data
- Supports multi-factor authN
- No cost for users* *if they have a smart phone, or SP subsidizes other 2nd factor
Steps Entailed if Recommendation is Accepted
If InCommon endorses the primary recommendation, the next steps would include the following:
TBD