drhgfdjhngngfmhgmghmghjmghfmf NLIT 2018 FEDERATED IDENTITY AT ARGONNE NATIONAL LABORATORY PETE FRIEDMAN Enterprise Architect Business and Information Services (BIS) Argonne National Laboratory
ABOUT THE PRESENTER Pete Friedman is an Enterprise Architect in the Business and Information Services division within Mission Support. He joined the Laboratory in 2012 as a Unix systems administrator and became a full time Enterprise Architect in 2016. B.S Computer Science Carnegie Mellon University 2
ABOUT THE LAB Argonne National Laboratoryseeks solutions to pressing national problems in science and technology. The nation's first national laboratory Argonne conducts leading-edge basic and applied scientific research in virtually every scientific discipline. Argonne researchers work closely with researchers from hundreds of companies, universities, and federal, state and municipal agencies Argonne is managed byuchicago Argonne, LLCfor theu.s. Department of Energy's Office of Science. 3
OUR JOURNEY: REFLECTIONS ON THE EXCITING, CAPTIVATING, AND INSPIRING DISCIPLINE OF IDENTITY MANAGEMENT. ;)
SOME DEFINITIONS In case you haven t heard them before SAML Security Assertion Markup Language. It s the method that backs a lot of federated identity systems, including DOE OneID and InCommon IdP Identity Provider. The system which sends identity data about a user (usually in SAML but can also be e.g. OAuth2) SP Service provider. The system which consumes the identity assertion from the IdP Metadata(SAML) Usually XML, describes the SP or IdP scapabilities, URLs, accepted fields, etc. SSO Single Sign-On InCommon An Internet2 initiative which aggregates IdPand SP metadata. Participating institutions and public SPs can consume the aggregate so that InCommon participants can access the resource (modulo SP-configured AuthZ) AuthN, AuthZ Authentication and Authoriziation DOE OneID Kind of like InCommon but way more advanced in terms of canonicalization, institutional control, and directory services provided XSD XML Schema Description 5
HOW IT ALL STARTED Our Environment, Then and Now THEN Went production with our SAML IdP around 2013. Had a few (n<5) applications which were registered with InCommon, or configured to accept non-argonne Identity Providers Had more (n > 5) cloud applications which were accessed thru our SSO/IdP NOW Have about 40 SAML SPs Argonne 8k in InCommon Using Shibboleth 3.x for IdP Username/Password Kerberos Smart Cards Mostly using Shibboleth SP Also using SimpleSAMLPHP PySAML Others across the Lab 6
NEEDED TO SUPPORT COLLABORATION Why can t another Laboratory user or someone from a University access our business applications like those InCommonapps? We understood the model of an IdP providing access to multiple applications We understood the model of multiple IdPsproviding access to a single application 7
THERE MUST BE A BETTER WAY! Each application manages its own mapping of users! 8
FEDERATED IDENTITY MANAGEMENT To the rescue! We realized what we needed Now we had to solution it! 9
BRAINSTORMING Requirements and Commercial Evaluation Our Requirements: Users can manage their external identities (we re never going to know about all of them, but they do) Example: I have 4! ANL, CMU, OneID, ORCID Don t even get me started on Social logins Applications can map incoming assertions to a user Security and Audit can traverse accounts associated to a person Products like Okta, OneLogin, Ping, etcare great for the provide access to cloud applications from one or more internal identity sources Products do internal(from system perspective) de-dup and canonicalization Unify your AD, LDAP, etc SCIM System for Cross-Domain Identity Management, RFC7643, Usually implemented as HTTPS- POST w/ JSON Payload 10
OUR IMPLEMENTATION CPOs, FAOs, FAOTypes CPO Canonical Person Object Represents a person affiliated with Argonne Aligned to the Enterprise Information Model for a Person FAO Federated Account Object Many to One relationship with a CPO Represents a digital credential Aligned to a SAML assertion, but extensible FAOType Describes the IdPsassociated with an FAO LoAlist XML XSD 11
THE FAO AND FAOTYPE 12
SERVICE DESIGN 13
WHAT IT ALL LOOKS LIKE * Showing as Point to Point to describe information flow, but actually implemented via service bus 14
THIS DOESN T SOLVE ALL THE PROBLEMS It may make some new ones Can t assume a user s login account is ever inactive Applications need to be aware of this, and transition to dealing with people, not accounts It s going to be a while before all our apps support this 15
WHERE TO GO FROM HERE Things we ve talked about but not yet implemented Authorization Service Central authorization service which takes in an FAO Uses the CPO to look up roles Uses the FAO to look up LoAsand other context attributes Returns a filtered permission set Additional Attribute Services Training Admin interface for local identity providers (e.g. user facility systems) to manage creating FAOTypes 16
QUESTIONS?
APPENDIX
EXAMPLE ARGONNE FAOTYPE XSD 19
20
www.anl.gov