Federated Identity Management at BNL

FIM4R@FNAL

September 12, 2019

John Hover <jhover@bnl.gov>

Mizuki Karasawa <mizuki@bnl.gov>

​

​

Overview

• Lab-level authZ/authN, federation
• SDCC Context
• SDCC Federation
• Observations/Progress
• Issues/Problems
• Future Options
• Open Questions
• Diagram

Brookhaven Lab-Level SSO and Federation

• Managed/operated by lab-level Information Technology Division (ITD)
• Runs InCommon IDP backed by central campus Active Directory (AD) accounts system (~5000 accounts).
• Federation via CILogon to InCommon (w/ unconditional Duo MFA) for certs.
• Federation via standard InCommon for other services (MFA external, no-MFA internal)
• ITD uses SimpleSAMLPhp to broker to InCommon (and to AD for internal apps)
• Services have SSPHP tokens (not CILogon or InCommon)
• ~50 production services, ~40+ dev/test moving into production.
• NSLS2 Proposal Allocation, Safety, and Scheduling System (PASS) uses federation to InCommon and Google.

Info: Dave Cortijo BNL ITD

​

Scientific Data and Computing Center (SDCC)

• Multi-experiment facility.
• A campus-wide scientific computing provider, along with support for multi-institutional projects that extend beyond BNL.
• Distinct (from ITD) user accounts domain (~2000 accounts).
• Accounts are for scientific computing. BNL AD accounts for enterprise tools.
• Recently migrated to Redhat-supported FreeIPA (Kerberos/LDAP)
• Most SDCC users do not have BNL AD accounts. Many have identities at InCommon institutions.
• Local SSO using SAML, transitioning to KeyCloak (supporting both SAML and OAuth/OIDC).

SDCC Federation Mechanisms (1)

• Ready to use KeyCloak to federate with InCommon
• Awaiting cybersecurity approval for production.
• Additional attributes available from SDCC accounts.
• First application probably a chat service (RocketChat or MatterMost)..
• Another service is BNLBox, a NextCloud-based open source DropBox.
• Using CILogon to federate with InCommon, with COManage instances providing AuthZ and user management.
• Pilot/pre-production projects! Provisional cybersecurity approval for these contexts...
• ASCR pilot (DCDE) demonstrating inter-DOE-laboratory resource sharing.
• Services: JupyterHub, Oauth-SSH, Globus endpoint
• DOE lab personnel only.
• For an Invenio-based web application (Genesis)
• Users from several InCommon institutions.
• Currently working to set up local CILogon COManage instance.
• OAuth functionality key here (some of our services come with OAuth plugins, but not SAML).

​

SDCC Federation Mechanisms (2)

​

• Implicitly federating via Globus when using a Globus endpoint.
• Also when using Oauth-SSH
• Have discussed federating using OneID.
• https://eams-hub.yc.energy.gov/hub/home
• SAML-only currently, so not a fit.
• AuthN only. No mechanism to manage user AuthZ attributes.
• May be required for apps with OUO/sensitive information.

Glance at Keycloak Central IDP Hub

IDP selections are configurable per App/Service bases.

Observations, Progress

• COManage has worked very well, allowing us to delegate group membership invitation/vetting to a project leader in another department.
• We have had success adding AuthZ to several services based on COManage-provided group membership claims.
• Invenio, Jupyterhub (pre-production)
• We build globus-acct-map files using direct queries to COManage LDAP back-end.
• Beginning experience handling external users, and are discussing what authZ/authN needs various services will present.
• E.g. SDCC users only vs. SDCC+BNL AD users
• BNL-only vs. BNL + InCommon
• Google, LinkedIn, Orchid, etc...

Issues, Challenges

• Non-web services that assume a local system UNIX context.
• For the DCDE project we pre-allocated UNIX pool accounts, and assign them upon login.
• JupyterHub can dynamically create local host accounts, but those restrict usage of facility storage and compute.
• Complexity with two distinct user accounts domains at BNL.
• InCommon does not permit more than one IDP per institution.
• DOE context brings up cybersecurity requirements
• Questions about CILogon operators, guarantees. FedRAMP?
• Multi-factor authentication required for some services.
• InCommon REFEDS/MFA assertions useful here.
• Need for user attributes such as citizenship, country of origin, etc.

​

Likely Future Directions, Options

• Establish SDCC-operated COManage instance, linked to CILogon.
• Provides API access and custom plugin usage without cost.
• Sort out the account model between ITD and SDCC
• Set up our web authenticating proxy(ies) to use KeyCloak.
• Adding services:
• Indico @BNL
• Additional Invenio instances
• Ticketing
• Integrate the usage of OneID?
• Already DOE cybersercurity approved for usage with OUO, sensitive info.
• Encourage BNL OneID IDP--Reportedly in ITDs plans.
• BUT OneID at this point is AuthN only. Can they be encouraged to support COManage?

Questions

• Should we link SDCC accounts with federated accounts via custom COManage synchronization? (E.g. group definition/membership).
• Or does it make more sense to manage separately?
• Or do linking only within KeyCloak?
• Will InCommon provide sufficient attributes to meet DOE requirements? If not, additional user vetting may be needed.
• Could InCommon bridge to the OneID federation (as it does to the European federations)?

​

​

Current Prod + Pre-prod

​

Pilot projects directly federating with CILogon/COManage. Plugins doing AuthZ.

​

Shared cloud-based COManage instances.

​

KeyCloak bridging to InCommon, using BNL IDP, ready to use rest of InCommon.

​

​

One Possible Future...

​

KeyCloak as main glue, primary service auth server. Bridging to CILogon, OneID. Service-by-service auth choice.

​

COManage could be provided, or run locally, with attribute syncing via API.

​

OIDC as standard protocol, but supporting SAML where needed.

​

Questions? Discussion...