Successfully reported this slideshow.

Implementing MITREid - CIS 2014 Presentation

5

Share

Loading in …3
×
1 of 39
1 of 39

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Implementing MITREid - CIS 2014 Presentation

  1. 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. 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. 3. 1. Make local accounts
  4. 4. 1. Make local accounts
  5. 5. 1. Make local accounts
  6. 6. 2. Use LDAP
  7. 7. 2. Use LDAP
  8. 8. 3. Use Enterprise SSO
  9. 9. 3. Use Enterprise SSO
  10. 10. 3. Use Enterprise SSO Firewall Intranet Internet
  11. 11. What to do?
  12. 12. Give people a digital identity
  13. 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. 14. Why OpenID? • Open standard protocol • Network-based federation • User-driven trust model • Simple to use and develop
  15. 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. 16. Usage Profile: The prototype Firewall Intranet Internet OpenID Server SSO
  17. 17. Usage Profile: The external service Firewall Intranet Internet OpenID Server SSO
  18. 18. User Profiles: The mobile user Firewall Intranet Internet OpenID Server 2FA
  19. 19. The architecture Firewall User Profiles Shared Database Internal OP External OP Intranet Internet Two-Factor AuthnCorporate SSO
  20. 20. Runtime security decisions
  21. 21. Adoption by the extended enterprise
  22. 22. The Long Tail 1 10 100 1000 10000
  23. 23. We didn’t even plan this
  24. 24. Multiple types of user
  25. 25. Moving on from OpenID 2.0
  26. 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. 27. Open Source
  28. 28. We’re running it ourselves
  29. 29. Building the specifications
  30. 30. Moving toward federation across the extended enterprise
  31. 31. Better security: Separation OpenID Provider
  32. 32. Delegating services: OAuth OpenID Provider
  33. 33. Better security: Revocation
  34. 34. Easier integration by developers OpenID Provider• Standard • Agile • Flexible • Distributed • Proprietary • Fragile • Rigid • Centralized
  35. 35. Better administration: An abstraction layer OpenID Provider
  36. 36. 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
  37. 37. Conclusions • Use open standards • Give your people digital identities and let them decide where to use them • Use federation where possible
  38. 38. Questions? jricher@mitre.org

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)
  • ×