1 / 25

Squaring the Circle. Reflections on Identities, Authentication & Authorization at CERN

Squaring the Circle. Reflections on Identities, Authentication & Authorization at CERN. Stefan Lüders IT Technical Forum 20120316. Objectives.

ojal
Download Presentation

Squaring the Circle. Reflections on Identities, Authentication & Authorization at CERN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Squaring the Circle.Reflections on Identities, Authentication & Authorization at CERN Stefan LüdersIT Technical Forum20120316

  2. Objectives The Problem: Legacy of the Past.Eligibility of accounts, ownership of computing resources and authorization for using computing services (or not) are undefined and uncontrolled. The Future: Federation, anyone?What if CERN wants to join identity federations? Our chances: Regain control.Define who is eligible for owning computing accounts/resources and using computing services.Have a full lifecycle for accounts and resources.

  3. Disclaimer • I am poking around this already for a while.Wherever I look, inconsistencies pop up. • I started with a documentation what is out there……and where we might want to go. • You might come up with use-cases. Thanks for them.However, please distinguishreal ones from technical ones from convenient ones. • This is a start.I can show you how deepthe rabbit hole goes. • But: Please don’t believethat I have an answer toeverything.

  4. The Problem: Legacy of the Past.There is no policy who is eligible to useCERN computing resources. Nada.Once you’re in you can own/use/eat what you want. Yum-Yum.

  5. The Final Drop

  6. Booom! Computer Security Report for September 2011 ==================================================== Beginning of this year, a so-called "logic/time bomb" has been detected at CERN. Such digital "bombs" trigger under certain conditions as defined by the attacker. In this particular case, the "bomb" has been implemented by an CERN employee on a CERN web site and rendered that site unusable at the moment when his contract ended in November 2010. The operational impact was, however, very limited. CERN takes this type of conduct extremely seriously and acts appropriately.

  7. Quiz 1: Do you know... • …that nearly everybody registered at CERN can get a CERN account? • …that your account is still valid for two months after you’ve left CERN? Even if you just worked two days at CERN painting a wall? • …that FP is struggling with “ETAS” who access team accounts only twice a year? • …how to identify all accounts of CERN people? • …who owns/uses your computing service? Should they? • …the differencebetween secondary and service accounts? • …that there is no consistent usage of them? • …that both are used to give access to thirds? • …what a “lightweight account” is? • …that mails to Your.Name@cern.ch areforever forwarded to your favorite external mailbox?

  8. Eligibility: The “Easy”… NOT

  9. …and the “Weird” HR/PH/LS work on re-defining all HR categories (AC11), but still this list grows… More: Service accounts, secondary accounts, lightweight accounts. NOT

  10. Quiz 2: Why… • …should e.g. users of category “CLUB” have a CERN mailbox? • …do we still have personal web pages? …for “CLUB” or “PART”? • …should a “PART” (who is supposed to never be at CERN) be able to own LANDB devices? What about VMs? • …should an “ETAS”/“GUID”/“RETR” have access to more than AIS? • …do we create accounts for some visitor just getting reimbursed? • …should someone with an account at his/her instituteown one at CERN? • …must service/secondary accounts beuseable from outside CERN?

  11. Eligibility (Today) • Plus: Own/use CVS/SVN repos, use engineering apps, use/own Twiki pages, … • Is this really what we want?

  12. Eligibility (Ideal?) • Plus: Grace periods… • Yes. This is too complex to implement. Bigger “blobs” are needed.

  13. Eligibility (Optimal) • Two easy classes could be“Those who can OWN” (MoP) and “Those who can USE” (MoP + EXTN) • Comments welcome (…after this session, please ;-) ???

  14. The Future: Federation, anyone? We are not the center of the world.Why shouldn’t a FNAL person usehis FNAL identity at CERN?

  15. Federated IDs • Many users atCERN have identities with their university, lab or institute. They work from there and forward their CERN mail “home”. • Why not permitting those identities being used at CERN instead of creating a CERN identity? We already do this on the WLCG (based on x509)… • Vice versa, CERN identities might be used abroad! • Of course, we would need to establish a network of trust à la IGTF. • Also, others might just need lightweight access and already own an Google/Facebook identity. • En plus: The CERN library works on a project called ORCID which ensures the relation between documents and their authors. For this, a unique identity is needed, worldwide! • How would this look like?

  16. First Pilot (1): ATLAS Twiki • Select AuthN system: choice can be remembered (by cookie). • Selector will be merged into the current SSO page. • Here: User authenticates via his home BNL login page.

  17. First Pilot (2): Google • Use OpenID/Facebook/Gmail/… compatible IdP. • Here: User now authenticates via the Google login page.

  18. En Plus: Enable Multi-Factor AuthN • Mapping of IDs with e.g. Yubikeys, x509 or SmartChip(latter are auto-mapped). • LXADM will come first with multi-factor AuthN (Yubikey & SMS).

  19. Joining ID Federation(s) • Nomenclature:IdP= Identity ProviderSP = Service ProviderAA = Attribute AuthoritySSO = Single Sign OnAuthN= AuthenticationAuthZ= Authorization • Establish a CERN IdP. • Define clear public and private attributes (“CERN”, “MoP”, “IT”, “German”, …) Resolve technical / legal issues with HR & LS. • Deploy AA for experiments to sync Greybook (more attributes: “ATLAS”). • Protect attributes to avoid modification (FedID problem ). • Separate AuthN and AuthZ:No more confusion about “AIS roles” or “Lightweight accounts”. • Use attributes for AuthZ.

  20. Our Chances: Regain Control.Separate AuthN and AuthZ.Align eligibility of computing resources with SLDs, service catalog, and lifecycle.

  21. Separate AuthN & AuthZ CERN IdP/AA External SSO/IdP/AA 4. Attributes?![ID] SSO 3. Sign-in[Fed, ID, credentials] 2. AuthN?N-factor! 5. AuthN![ID, attributes] 1. Access? Service 8. Access! Individual 6. AuthZ?[ID, attributes] 7. AuthZ! AuthZ-groups

  22. New AuthZ Scheme(?) Services define eligibility: • Access permission based on attributes e.g. CERN MoP, ATLAS, … • Access permission based on opt-in e.g. John.Doe@gmail.com Security measures per service: • Deny rights based on attributes e.g. SERVICE ACCOUNTS, CLUB, … • Deny rights based on names e.g. John.Doe@gmail.com, jdoe, … Personalize usage of service and secondary accounts. Merge them.

  23. The Catalogue of Services • A Resource Broker:The user is presented with all computing resources he owns and services he can opt into/use: • Permit a full life-cycle with opt-in approval and “Exit” procedure. • Handling of “grace-periods” in one central place. • Alignment with SNOW service catalog, SLDs, …

  24. All there! • Vague. OTOH, many ingredients are already there. • But. E-groups/AD/LDAP might not scale and we have to review how to do…. SSO Login[ID, credentials] HRDB LDAPAD Register IdP / Attribute Authority AuthN Opt-in [IT, attr] AuthZ LDAPAD AuthZ-groups e-groups Configure [ID, attr] Resource Broker SP FIM+

  25. Regain Control.Clean up the past.Prepare for the future.Nothing comes for free…Nor is this simple…But also: Is it worth it?

More Related