Implementing MITREid - CIS 2014 Presentation

Editor's Notes

• #3: It’s 2009. I’m not part of corporate IT, but I build interesting stuff that people want to use.
• #4: Make everybody sign up for accounts
• #5: But now I have to do key management And I’ll probably get it wrong
• #6: But mine isn’t the only application that people use Bad UX Password management Extra credentials floating around And I probably got something wrong Besides, the user already has an account, let’s use that…
• #7: Use same password across many sites, all backed by the same user store
• #8: Benevolent MITM: user sends me their credentials directly, I replay those credentials against another service to make sure they’re good. Site could easily replay user credentials somewhere else, and users still need to enter UN/PW I never want to see your passwords! Plus, it’s not an HTTP protocol
• #9: Why not use traditional enterprise SSO? Users get a cookie that represents them, it’s easy to integrate, it’s how we’ve always done it…
• #10: HAHA: No. SSO domains are closely guarded and protected, centrally controlled I’m not an official IT app developer, I don’t have permission (and often can’t get permission) Many implementations suffer from the same MITM problems via domain-wide cookies (this has been used as a “feature” to proxy content for users)
• #11: Additionally, the traditional SSO approach can’t extend to sites outside the firewall.
• #13: “Welcome to your first day, now go get a gmail account so we can get started.” We give employees a phone, we give them an email address, why not an identity?
• #14: OpenID 2.0 server backed by corporate SSO “We do SSO so you don’t have to” Running on corporate hardware in corporate environment Funded by a (tiny) corporate research initiative
• #15: Automatically cross-platform
• #16: Libraries available for OpenID 2.0 in a wide array of languages and platforms. One discussion with identity vendor: “We support *both* platforms!” … ?
• #17: User is inside, the site they’re accessing is also inside. Typical development prototype system, driving much of my original use case.
• #18: User is inside, site is on the outside. This bridges corporate SSO credentials to an outside site, like Stack Overflow. MITRE now has a nearly-SSO user experience for a site that we have no contract or other special relationship with. Think about the implications of that.
• #19: User outside, site outside. We want more factors (especially with personal devices) but want to allow access to any external sites. We do *not* allow people to tunnel into the firewall.
• #20: We have deployed both OpenID 2.0 and OpenID Connect using this architecture Shared DNS between servers (both look like “id.mitre.org”)
• #21: Screenshot of MITREid OpenID 2.0 server Security decisions for users If you don’t know the answer to a trust question, ask the end user. Remember the decision. Log the event. TOFU: Trust On First Use.
• #22: MITRE’s Handshake system (at the time another research prototype, now a well-used production service) is hosted outside of MITRE’s firewall to allow external user access. Handshake needed a mechanism that allowed MITRE people to log in using SSO credentials. They used the OpenID prototype to great success. Handshake is whitelisted by the OpenID server, meaning most users have an SSO-experience and don’t realize they’re using OpenID at all.
• #23: Each bar is one site that was used, at least once, at the OpenID 2.0 server Logarithmic scale, number of users per site. Traditional IT likes to take care of the top couple sites (the “80%” rule) But what about all the sites with 5 users? 50 users? Most of the top ten aren’t whitelisted – some of the top sites aren’t even run by MITRE! There are 416 total sites There are 7896 total users There are 12611 total site approvals.
• #24: Somebody had set up a Gitorious instance inside the firewall. Gitorious already had built-in OpenID 2.0 support. I typed in my identifier and it just worked.
• #25: id.mitre.org: current MITRE users partnerid.mitre.org: extneral-to-MITRE username/password accounts cacproxy.mitre.org: DoD CAC holders We can separate classes of users foremost based on their IdP of origin In the future we hope to have other IdPs not run by MITRE
• #26: We tried to make our OpenID 2.0 system as compatible and capable as possible (PAPE, SREG, AX, directed identities), but the world was starting to look into future capabilities of OAuth2 and OpenID Connect
• #27: MITREid Connect MITREid was built on a shoestring budget with duct tape and bailing wire, MITREid Connect was engineered much more deliberately and released as open source (before any code was developed
• #28: Apache 2.0 license Transitioned to MIT KIT in fall 2013 (co-owned by MITRE) MITRE continues to contribute through the OSS process
• #29: Server and client in Java / Spring / Spring Security Related projects: JWK generator, JS account chooser, example custom server, example custom client All major development, bugs, documentation done on GitHub (small adaptor layers for
• #31: Track and help build the specifications in IETF and OIDF Bring our use cases to the table and participate in the discussions, make sure the general solution is robust and powerful for all
• #33: No need for domain-wide cookies to get SSO-like behavior (like “classic” enterprise SSO uses) Primary and global-secondary credentials aren’t leaked through sites, pairwise authentication only
• #34: (incidentally, that back-end connection is where OAuth comes in, and we’re also using that extensively)
• #35: We can revoke access to specific sites autonomously at the IdP Different sites get different parts of my identity
• #36: Don’t need to ask a sysadmin’s permission (!!) Support across a wide variety of platforms and use cases
• #37: Avoid mass upgrades to all the sites that are connected to your infrastructure (as long as the protocol doesn’t change) When we switched from CA SiteMinder to Oracle Access Manager, the hundreds of sites (MITRE and not) that were using the OpenID system never even knew the change happened.
• #38: End users know what they’re trying to do – ask them to make the decisions (in the right circumstances)