Implementing MITREid - CIS 2014 Presentation
•Download as PPTX, PDF•
5 likes•3,338 views
The story of MITREid, a corporate identity system implemented at MITRE built around OpenID 2.0 and, later, OpenID Connect.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Implementing MITREid - CIS 2014 Presentation
Similar to Implementing MITREid - CIS 2014 Presentation (20)
Recently uploaded
Recently uploaded (20)
Implementing MITREid - CIS 2014 Presentation
- 1. The story of MITREid Justin Richer The MITRE Corporation © 2014 The MITRE Corporation. All rights reserved. Approved for Public Release: Distribution Unlimited (Case Number: 14-1639)
- 2. The plight of a software developer • I build things that people use • I want to know who’s there • What can I do?
- 3. 1. Make local accounts
- 4. 1. Make local accounts
- 5. 1. Make local accounts
- 6. 2. Use LDAP
- 7. 2. Use LDAP
- 8. 3. Use Enterprise SSO
- 9. 3. Use Enterprise SSO
- 10. 3. Use Enterprise SSO Firewall Intranet Internet
- 11. What to do?
- 12. Give people a digital identity
- 13. Let’s build something • OpenID 2.0 Server • Running on corporate IT hardware in corporate IT environment • Backed by corporate SSO and user profile information • “We do SSO so you don’t have to”
- 14. Why OpenID? • Open standard protocol • Network-based federation • User-driven trust model • Simple to use and develop
- 15. Make it easy for developers: Platform support • Libraries: – Java – PHP – Python – Javascript – Ruby – Perl – … • Platforms & Plugins: – Spring Security – Elgg – Wordpress – Mediawiki – Omniauth – Drupal – …
- 16. Usage Profile: The prototype Firewall Intranet Internet OpenID Server SSO
- 17. Usage Profile: The external service Firewall Intranet Internet OpenID Server SSO
- 18. User Profiles: The mobile user Firewall Intranet Internet OpenID Server 2FA
- 19. The architecture Firewall User Profiles Shared Database Internal OP External OP Intranet Internet Two-Factor AuthnCorporate SSO
- 21. Adoption by the extended enterprise
- 23. We didn’t even plan this
- 24. Multiple types of user
- 25. Moving on from OpenID 2.0
- 26. Let’s build it (again)! • OAuth 2.0 and OpenID Connect server • OpenID Connect client library • Enterprise-friendly features and platform • Flexible deployment and...
- 27. Open Source
- 29. We’re running it ourselves
- 31. Moving toward federation across the extended enterprise
- 35. Easier integration by developers OpenID Provider• Standard • Agile • Flexible • Distributed • Proprietary • Fragile • Rigid • Centralized
- 36. Better administration: An abstraction layer OpenID Provider
- 37. Scalable security decisions Whitelist Trusted partners, business contracts, customer organizations, trust frameworks Graylist User-based trust decisions Follow Trust on First Use model, keep logs Blacklist Very bad sites we don’t want to deal with, ever Organizations decidethese End-users decidethese
- 38. Conclusions • Use open standards • Give your people digital identities and let them decide where to use them • Use federation where possible
Editor's Notes
- It’s 2009. I’m not part of corporate IT, but I build interesting stuff that people want to use.
- Make everybody sign up for accounts
- But now I have to do key management And I’ll probably get it wrong
- 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…
- Use same password across many sites, all backed by the same user store
- 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
- 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…
- 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)
- Additionally, the traditional SSO approach can’t extend to sites outside the firewall.
- “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?
- 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
- Automatically cross-platform
- Libraries available for OpenID 2.0 in a wide array of languages and platforms. One discussion with identity vendor: “We support *both* platforms!” … ?
- User is inside, the site they’re accessing is also inside. Typical development prototype system, driving much of my original use case.
- 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.
- 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.
- We have deployed both OpenID 2.0 and OpenID Connect using this architecture Shared DNS between servers (both look like “id.mitre.org”)
- 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.
- 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.
- 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.
- 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.
- 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
- 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
- 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
- Apache 2.0 license Transitioned to MIT KIT in fall 2013 (co-owned by MITRE) MITRE continues to contribute through the OSS process
- 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
- 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
- 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
- (incidentally, that back-end connection is where OAuth comes in, and we’re also using that extensively)
- We can revoke access to specific sites autonomously at the IdP Different sites get different parts of my identity
- Don’t need to ask a sysadmin’s permission (!!) Support across a wide variety of platforms and use cases
- 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.
- End users know what they’re trying to do – ask them to make the decisions (in the right circumstances)