1 Name of Meeting Location Date - Change in Slide Master Authentication & Authorization Technologies for LSST Data Access Jim Basney February 23, 2016

2 LSST IAM Group − − − Bi-weekly meeting using ls.st/sup Google hangout Thursdays 10am Pacific / noon Central

3 Goals of Session − What is feasible technically − Policy implications − State of current prototype − IAM system goals include: – Identify members of US/Chilean astronomy community – Identify named individuals and delegates with data rights – Manage collaborative L3 data sharing

4 Standard Authentication Mechanisms − Federated user identities – SAML, OpenID, OAuth – Web single sign-on from universities, labs, GitHub, Google − Kerberos – password-based single sign-on – Self-service registration, password change/reset – Web, API, and command-line SSO − OAuth – token delegation – Web and API access − 2nd authentication factor – FIDO U2F – browser-based – OATH – smartphone, hard token − X.509 certificates for authenticating services

5 Federated Identity – Academic Providers − SAML identity providers operated by universities and labs in US, Chile, France, and other countries − National SAML federations connected via eduGAIN.org interfederation service – US: InCommon.org – Chile: COFRe.REUNA.cl – France: services.RENATER.fr/federation

6

10

11

12 Federated Identity - eduPersonAffiliation − Definition: Specifies the person's relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc. − Permissible values: faculty, student, staff, alum, member, affiliate, employee, library-walk-in − no "astronomer" attribute − departmental affiliation not well supported

13 Federated Identity - eduPersonAffiliation − Proposed: gets L2 data rights – "Member" is intended to include faculty, staff, student, and other persons with a full set of basic privileges that go with membership in the university community (e.g., they are given institutional calendar privileges, library privileges and/or vpn accounts). It could be glossed as "member in good standing of the university community."

14 Technical Prototype - Authentication − InCommon authentication with eduPersonAffiliation – – Using Shibboleth, CILogon and Globus middleware − Kerberos authentication for SSH single sign-on – Kerberos ticket in user’s SSH session – Ticket-based authentication to Web APIs − MariaDB – Kerberos authentication – Kerberos password authentication via PAM – Kerberos ticket-based authentication new in MariaDB authentication-plugin/

15

16

17 Authorization − L2 data rights − L3 collaboration groups − Access to applications/services − Admin/staff roles

18 Access Control Components − User/Group Manager – Implements the logic and workflows to determine who has L2 Data Access Rights and who is involved in L3 collaborations. These workflows set/unset User Attributes (i.e., group memberships). − User Attribute Store – Receives information from User/Group Manager and publishes the resulting User Attributes via a standard LDAP interface. − Service Level Authorization – Services implement authorization (access control) based on access control lists (ACLs) or database GRANT statements or other service-specific methods, based on the User Attributes.

19

20 L2 Data Rights − National professional astronomical community – Use eduPersonAffiliation when available – Otherwise will require manual review/approval − Named individuals from international partners – Lookup existing LSST accounts – -based invitations − A limited number of designated additional individuals (post- docs, grad students) per named individual – Named individuals can invite/grant others (from same institution)

21 Managing an L3 Group (Proposed) − Via ORACLE – ORACLE (Observatory Resource Allocation Committee for Level Elevation) process defines a group indicating the users (group members) who can use the resource allocation. Also create an associated L3 data workspace private to that group. − Via User/Group Manager – […]

22 Managing an L3 Group (Proposed) − Via ORACLE − Via User/Group Manager – Any user with Data Access Rights can click "Create L3 Data Product Group" in the User/Group Manager web interface to create an L3 group and define its initial members. That user will be the initial owner of the group. – Users who own L3 groups will also see a "Manage My L3 Data Product Group(s)" button/link that allows them to add/remove members and add owners / transfer ownership. – Users with Data Access Rights will see a "Manage My L3 Data Product Group Memberships" button/link that allows them to request to join L3 groups or leave L3 groups they are currently a member of.

23 Technical Prototype - Authorization − pam_sss and sssd – set Unix groups from LDAP − mod_authnz_ldap – set WebDAV permissions using LDAP groups − LDAP to SQL Provisioner – set SQL roles from LDAP

24 Leveraging NCSA IAM Improvements − Self-service user registration, profile management, password reset − Delegated group administration – Group invitation process – Custom group registration questions, membership policies − Kerberos and LDAP replication

25 User/Group Manager Options − New NCSA IAM web interfaces − Internet2 COmanage/Grouper – Very flexible workflows, group logic, and provisioners − Globus Groups – Cloud service under development

26 Identity Linking − External identities (University, GitHub, etc.) linked to individual’s LSST identity – Established during initial enrollment and managed by user − Group memberships based on LSST identity – LDAP queries using LSST IDs and external IDs

27 IAM Next Steps − Technical prototyping continued – MariaDB Kerberos tickets – DAX integration – Delegation (OAuth, X.509) − Admin/Staff roles − COFRe/eduGAIN exploration − NCSA IAM deployment

28 Thanks! − Contacts: – – –