Layered Identity in Partnerships Networks (2E)

Session Topic: Layered Identity in Partnership Networks (T2E)

Convener: Justin Richer, (MITRE)

Notes-taker(s): Heather Flanagan

Tags for the session - technology discussed/ideas considered:

OpenID Connect; federation; collaboration

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

MITRE Partner Network - Justin Richer

Problem space = we have a social networking system on the DMZ where MITRE employees can log in, and external people can be invited ("handshake"), collaboration can happens; but all the external people coming need a site-specific user name and password to get in tot he site, so the question is how to get external people with their own credentials that are trusted at some level

this is something where a distributed and federated protocol fits the bill

GOAL of today’s session: get the idea of this model out in to the community to encourage other companies to think about a better user experience for their collaborators and employees

Current concept is concentric rings of trust [diagram] = employees to trusted partners to invited partners to identified public; these terms are open to discussion

• employees = employees of MITRE
• trusted partners = organizations that MITRE has agreed to trust, have MoU or other legal agreements with to hold legally accountable for user actions
• Invited partners = employees have determined these people are the ones they want to collaborate with (and don't need to clear it with corporate)
• identified public = we know you are a person (probably), and (probably) the same person that came by last time with that pseudonym, and that's good enough; MITRE wants the info just to have some idea of who is using/downloading their docs

key design goals = the apps created by "shadow IT" should be equally supportable in the corporate IT world

Q: is this opensource or proprietary or both?

A: approaching it with the idea of making it as open source as possible, with the local proprietary bits being add-on's that won't be required for other sites to use it

OpenID Connect allows a very tight integration at the inner levels (employees, trusted partners), but also discovery and dynamic registration for outer levels (invited partners, identified public)

The whole enrollment process that depends on sending an email with the registration info and passwords is just a sad state of affairs, and yet it is explicitly trusted in today's systems; we must be able to do better than that and stop using email for identity provisioning

Q: why have more than 2 rings (employees/non-employees)?

A: Need a certain amount of granularity due to sensitivity of information; if you build something like this, you can build an interesting invite-gated community

Q: this model implies trust is reciprocated. At data access time is the data service responsible for obeying not only the individuals invite but also the company policy that may provide conflicting requirements?

A: the blacklist is underlying all of this, and it does not actually require reciprocation; that’s the problem with SAML federations, that trust must be 2-way; MITRE doesn’t want to require 2-way at all, want a model that allows the trust to just go 1-way

Q: how stable are these different rings? The outer ring looks like it can just keep growing, and proportionally the inner rings are smaller and smaller

A: NSTIC lives in the ink in the ring between trusted partner and invited partner; the diagram as it is right now is not the final answer, but it has holes and just starts the conversation

Q: this model implies that all employees have access to all the data

A: the model vastly oversimplifies the authZ model; there is a rules engine that must apply

Q: so why not just model it as groups?

A: because the venn diagram will make your head spin, an unreadable morass of endless circles; and note that access control does not need to be centralized, and arguably it would be better not to be

Q: in Handshake, do you trust domains for the trusted partners?

A: effectively, yes, but you still need a local-to-app username/password; trying to abstract out the user list from handshake so other apps can use it

Q: in terms of identity management, what happens when deprovisioning happens on the other side?

A: MITRE is thinking about that; use case of employee invites someone in, employee leaves, what should happen to the invited person? Lifecycle management is a big open question; also, what happens as employees leave, come back – what happens to their data? Their invites? Their profile? Also an interesting account linking problem

Q: this requires your partner(s) to be an OP, so what happens then?

A: yes, and right now, the partners usually say “OK, so what do I need to install, and what are your policies for access?”

If anyone is interested in participating in this effort of an OpenID Connect reference app, let Justin know