2013-08-09 - Technology Issues Subgroup Notes

Action Items

• Ann Racuya-Robins will provide a brief report from this meeting for the full Cohortium meeting on Wednesday, 8/21/2013.
• David Walker will reword our third objective about APIs to clarify its meaning.  [done]

Highlights

• The following deployment scenarios were discussed.
  • Integration with individual services
  • Alternate enterprise SSO for specific services
  • Integration with single enterprise SSO
• It appears to be very common for institutions to deploy multi-factor authentication for only one or two applications initially. This minimizes risk and allows the support organization to come up to speed with a controlled set of users.  On the other hand, it can be difficult to broaden the use of MFA beyond those initial applications, as each application must be interfaced with the MFA system.
  • Integrating with an SSO is the natural way to leverage MFA for multiple applications. The University of Washington started their MFA deployment with a single application, but integrated MFA with their PubCookie SSO, rather than directly with the application.  This allowed easier integration of additional applications.
  • Most institutions integrated MFA into their existing SSO, rather than deploying a second SSO for applications that require MFA. The two institutions that used a second SSO later moved to a single-SSO architecture.
• User opt-in for multi-factor authentication is also a popular first or early step. This has the advantage of deploying first to people who want to use the new technology and, so, are more likely to be tolerant of rough edges.

Added details from the meeting

Duo invented with Service Provider in mind, integrate with a bunch of services

Arizona - Duo – started with proof of concepts specific to service

• but now into CAS & Shib (working on this now)

Would you still have started with a specific app even if easy to put into SSO?

• starting with lower potential impact (to overall user base, services) app(s) would be relatively easy and less risky
• political/funding
  app providers having a fairly fine-grained control over when MFA is done
• set of business processes around management of MFA, these are significant processes that need to be developed and improved over time
  permeates the business, touches a lot of people, how do we make that the best that it can be
• Can Cohortium speed up that process, provide enough background, examples, support that institutions feel the risk of deployment is reduced and start with a broader deployment perspective/plan than they might have otherwise?

Architectures for MFA management and how it integrates into overall IdM architecture

Vendor/marketplace perspective – HE & corporate, challenges – set of tools under purview of SSO is much less than the # of services that employees need to use; how do you then get MFA for all these other cloud/outsourced services that don't work with organizational SSO?

• just to open websites, behind the gate of "initial authn"
• ready to outsource your passwords, no greater risk to outsourcing than internally if done right?
• 13 logins average, 12 plus those that can be covered by SSO

Use cases like Connection to SQL databases, how do we incorporate MFA?

VPN "as shim" – used to give access to higher risk services that didn't offer an easier path to adding MFA requirements

• blocking access at the network level
• VPN firewall sets up port/host access for a given user

Parallel SSO –

• Bradley, decided too cumbersome
• Arizona, considered 2nd level of CAS server (client of primary), broke down with finer-grained decisions on when to require
• ADFS Server – trusts our Shib IdP, per SP basis
  • But with latest ADFS and its MFA support, perhaps integrate directly

Produce a High-level document/diagram(s) to illustrate integration of MFA with IdM/SSO/apps, patterns of integration architecture?