Identity Clearing House – Loosely Coupled open standards based architecture for Identiy in the extendedenterprise

From IIW
Jump to: navigation, search

Session Topic: Identity Clearing House

Tuesday 1A

Convener: Justin Richer

Notes-taker(s): Amanda Anganes

Goal: Building a collaboration environment at MITRE.


1) variable levels of control/security tied to different accounts

  • Employees using companiy-issued credentials
  • Government personnel using CAC
  • Invited partners
  • Collaborators
  • the general public (registered)

Anyone logging in may have multiple accounts with different rights/permissions tied to them. Ex: General with a CAC account as well as Facebook or Google account. May want to log in with either to gain access to different levels of secured information.

2) Identity Clearing House: Account Chooser, allows users to authenticate using a variety of protocols. Entry protocol is translated into OpenID Connect on the wire, with additional attributes indicating which account the user logged in with. If user has multiple accounts, bound together, then if the user tries to access something requiring more security than the account they logged in with, system can request step-up authentication for the user to authenticate with a higher-security credential.

Users with low-trust accounts (coming from an IDp we don't have a relationship with) could be vouched for by users with higher-trust accounts (gov't employee, MITRE employee).

Use SCIM to store attributes about the user.

User UMA authorization manager for 1) user control and 2) admin/enterprise controls

Another group in MITRE is building an authorization decision engine, which the UMA

AM would refer to for decisions.

Goal of overall architecture is to make every piece optional - new apps looking to get on the network could opt-in to using any of the services. Ex, could manage local user accounts if they really wanted to, but option to use ID clearing house authentication would be available (and hopefully easier and with better support).

This is a work-in-progress architecture, looking for comments.

Question: how would we tie multiple accounts to the same person (FB, CAC, MITRE)? Thinking of using SCIM for an attribute store

Within the system, the ID Clearing House would allow RPs to not worry about the user. Authentication is delegated, authorization & access controls are all delegated and accessible for retrieving info about the user.

Suggestion: Binding multiple accounts to the same user sounds really complicated, why not just let the RPs do it individually?

Answer: goal is that RPs would not have to be that smart. ID Clearing House would take care of acct binding, etc so that RP can just ask the system what the logged-in user should be allowed to access/do.

Clarification: access/auth decisions are not centralized. Decision services are centralized, but it is still up to the RP to decide whether the returned decision is acceptable, or if they should take another action, etc.

Discovery is very important in this kind of situation

Question: What about BrowserId?

Question: Are people at MITRE likely to trust these systems and be happy to use them? Yes, we think so - already have OpenID 2.0 server, partially blessed by InfoSec, lots of folks are using it already and InfoSec actually likes it.

Also - everything will be open source. Want to play along? Get in touch with us!