IRIS/DiRAC TBAn&Az trial
I
R
I
S
/
D
i
R
A
C
T
B
A
n
&
A
z
t
r
i
a
l
Combining HPC with federated identity management
Jens Jensen (UKRI)
Co-conspirators:
José Caballero Bejar (UKRI)
Matt Rásó-Barnett ((then) Univ of Cambridge)
NSF CyberSecurity Summit 2022, WoTBAn&Az workshop
D
r
a
m
a
t
i
s
P
e
r
s
o
n
a
e
U
K
R
e
s
e
a
r
c
h
a
n
d
I
n
n
o
v
a
t
i
o
n
(
U
K
R
I
,
w
w
w
.
u
k
r
i
.
o
r
g
)
f
u
n
d
s
,
s
u
p
p
o
r
t
s
a
n
d
c
o
n
d
u
c
t
s
r
e
s
e
a
r
c
h
o
n
b
e
h
a
l
f
o
f
t
h
e
U
K
g
o
v
’
t
S
T
F
C
,
o
n
e
o
f
9
c
o
u
n
c
i
l
s
i
n
U
K
R
I
,
s
u
p
p
o
r
t
s
l
a
r
g
e
f
a
c
i
l
i
t
i
e
s
(
s
y
n
c
h
r
o
t
r
o
n
s
,
l
a
s
e
r
s
,
e
t
c
)
,
c
o
s
m
o
l
o
g
y
,
a
s
t
r
o
n
o
m
y
,
p
a
r
t
i
c
l
e
p
h
y
s
i
c
s
,
s
p
a
c
e
s
c
i
e
n
c
e
,
a
n
d
m
u
c
h
m
o
r
e
I
R
I
S
(
w
w
w
.
i
r
i
s
.
a
c
.
u
k
)
s
u
p
p
o
r
t
s
c
o
m
p
u
t
i
n
g
f
o
r
S
T
F
C
-
f
u
n
d
e
d
r
e
s
e
a
r
c
h
(
i
n
c
l
.
L
I
G
O
,
S
K
A
,
D
U
N
E
,
V
R
u
b
i
n
T
e
l
e
s
c
o
p
e
,
…
)
D
i
R
A
C
(
w
w
w
.
d
i
r
a
c
.
a
c
.
u
k
)
i
s
a
n
e
t
w
o
r
k
o
f
H
P
C
a
n
d
s
u
p
e
r
c
o
m
p
u
t
i
n
g
s
i
t
e
s
s
u
p
p
o
r
t
i
n
g
c
o
m
p
u
t
a
t
i
o
n
a
l
c
o
s
m
o
l
o
g
y
–
n
o
w
p
a
r
t
o
f
I
R
I
S
(
n
o
t
t
o
b
e
c
o
n
f
u
s
e
d
w
i
t
h
o
t
h
e
r
t
h
i
n
g
s
c
a
l
l
e
d
D
I
R
A
C
)
I
R
I
S
c
o
m
p
u
t
e
o
v
e
r
v
i
e
w
:
c
u
r
r
e
n
t
GridPP
(particle
physics)
IRIS
community
cloud
DiRAC HPC
X.509
user cert
federated
or
password
ssh key
HTC
cloud
HPC
I
R
I
S
c
o
m
p
u
t
e
o
v
e
r
v
i
e
w
:
d
e
s
i
r
e
d
GridPP
(particle
physics)
IRIS
community
cloud
DiRAC HPC
federated
VO
mgmt
A
A
R
C
h
i
t
e
c
t
u
r
e
IRIS runs a BPA proxy
connected to eduGAIN
The IRIS BPA proxy is
Indigo IAM
(There is a parallel setup for
SKA UKSRC, globally
accessible)
I
R
I
S
I
A
M
Adding SAFE as “Community Identity Provider” to the
proxy
DiRAC resources as service providers
SAFE users
DiRAC
services
Not-DiRAC
services
Not-SAFE
users
IAM
“legacy”
access
(ssh keys)
In practice, SAFE access is used in prod’n
Federated access needs rollout across DiRAC
“legacy”
access
(X.509 cert)
U
s
e
r
I
n
f
o
a
n
d
A
u
t
h
o
r
i
s
a
t
i
o
n
UserInfo
(depends on scopes etc)
Name (sn, givenName)
preferred_username
Group memberships
Authorisation (individually
selectable)
Individual local mapping
LDAP query successful
Group membership
“Project,” fetch list of groups
belonging to project from
proxy’s server
P
A
M
m
o
d
u
l
e
f
o
r
s
s
h
l
o
g
i
n
SAFE
IAM
ssh
•
DiRAC test of PAM module for federated ssh access
•
Code is forked from Mazarykova Univerzita
•
Durham and Cambridge were volunteered to test this…
•
SAFE added as Community IdP to IRIS IAM
•
Spent most of August ‘21 refactoring and hardening the code
•
Advantages
•
No need for ssh keys
•
Harmonise user mgmt. between DiRAC and IRIS\DiRAC
•
Future proofing
•
Still does accounting via SAFE
•
Full UserInfo available to authorisation
•
No change to ssh client. No change to ssh server.
•
Disadvantages
•
Extra levels of indirection for current ssh key users
S
i
n
g
l
e
s
s
h
,
s
i
n
g
l
e
P
A
M
s
t
a
c
k
auth required pam_sepermit.so
auth sufficient pam_oauth2_device.so
auth
include passwd # or whatever
Bypass for named users or LDAP lookup
Non-bypassed users go through federation login
pam_oauth2 must come first, or everyone gets asked about the
fallback login
L
D
A
P
PAM module looks up local (PAM) username
and compares the remote (IAM) username
with an LDAP attribute
Added local username LDAP query as alternative
Query just has to be successful
Bypass checks which supports local users
through fall-through to password
The
account name
(local Unix) may be
different again
Tested at Cambridge and RAL
LDAP
bypass
query
LDAP auz
qry on
remote
username
LDAP auz
qry on local
username
authorised
No LDAP
No bypass
Bypass
F
o
r
k
f
r
o
m
I
C
S
-
M
U
N
I
.
C
Z
w
o
r
k
Goodish bit of refactoring done (next slide)
Stayed with upstream decisions for now
C++11
Config in JSON
Build with make
Using modern C++ features for code correctness
Albeit limited to C++11, see above
conventional commits
www.conventionalcommits.org
M
a
i
n
U
K
c
h
a
n
g
e
s
s
i
n
c
e
f
o
r
k
Improved certificate checking
Debug mode
curl refactored, support for NSS clients
Improved logging
Including syslog
Config file can be split into sections
E.g. keeping secrets or usermaps in separate files
Bypass mode x2 (LDAP or config file or both)
External contrib: HTTP BASIC auth (Brian Bockelman)
Additional authorisations (Will Furnell)
Including local
suffix
for (say) pool accounts
Exception handling
Worked on unit tests but they still need more work
M
a
i
n
u
p
s
t
r
e
a
m
c
h
a
n
g
e
s
s
i
n
c
e
f
o
r
k
(According to the commit messages)
Multiple LDAP servers
syslog
REFEDS MFA support
Exception handling
I
n
i
t
i
a
l
f
e
e
d
b
a
c
k
f
r
o
m
S
K
A
No ssh client state: need to authenticate every time
No modifications to ssh client
In contrast, KIT’s oidc-agent would obviously cache user side creds
No delegated token on ssh server
à la MEG (MyProxy-enhanced GSISSH)
Would need some thought
Federation infrastructure (BPA proxy) needs HA setup
O
t
h
e
r
m
o
d
u
l
e
c
o
n
s
i
d
e
r
a
t
i
o
n
s
Sharing code
Working with other groups (Mazarykova, Karlsruhe, EOSC, OSG, …)
Evolving/emerging standards
Communities from AARC projects’ extended collaborations (appint,
OIDCre, voPerson, REFEDS groups, FIM4R, GEANT …)
User communities
The PAM module is quite large…
Config is JSON: slightly temperamental and no comments
Need to validate every config file after change
PAM module includes JSON parser => larger code
O
t
h
e
r
c
o
n
s
i
d
e
r
a
t
i
o
n
s
-
A
u
t
h
o
r
i
s
a
t
i
o
n
No user manageable attributes (à la VOMS)
Except users specify the (local) username through ssh
Authorisation extended to meet community needs
Is it doing the Right Thing™? Some choices seem a bit exotic
Need for more sophisticated authorisation?
E.g. (optional) callout to external decision process?
Indigo IAM not G069 (née G002) compliant
Though subgroup
⊆
parent
Meaning IAM will send for example,
"groups": { "skao", "skao/uksrc", "skao/uksrc/purple" }
Using a hypothetical RFC6453 subspace, G069 would say,
entitlement: { "urn:ogf:aaops:skao:group:uksrc:purple" }remote
D
e
p
l
o
y
m
e
n
t
:
a
c
c
o
u
n
t
m
a
n
a
g
e
m
e
n
t
local
user1
user2
user3
user4
user5
user3
ssh user3@remote
Users must know their remote username
Human administrators must have approved the account creation
Usernames (
preferred_username
) not necessarily consistent across sites
Accounting must be tied to federated account (or group(s))
D
e
p
l
o
y
m
e
n
t
:
a
c
c
o
u
n
t
m
a
n
a
g
e
m
e
n
t
Either consistently use
preferred_username
across all sites
Or look up local username in LDAP/usermap (site specific
config)
Users would
ssh @remote
, à la Moonshot
Or use mapping tools, à la LCMAPS/GUMS (remember those?)
Option to allocate from
pool accounts
?
Synchronise accounts with proxy
SCIM or some (other) LDAP schema
N
e
x
t
s
t
e
p
s
(
m
o
d
u
l
o
e
f
f
o
r
t
a
v
a
i
l
a
b
l
e
)
Production rollout across DiRAC
Testing with SKA
Support for G069 attributes
Merge upstream support for MFA?
Indigo IAM will get MFA support “in due course”
Investigate caching sessions?
Acks: this work was funded by UKRI-STFC through IRIS and DiRAC
T
h
a
n
k
y
o
u
@SciComp_STFC
scd.stfc.ac.uk
https://github.com/stfc/pam_oauth2_device
the integration of high-performance computing (HPC) with federated identity management in UKRI projects like IRIS and DiRAC. Details on the collaboration, infrastructure support, and desired enhancements for community cloud and access control. Insights into IAM, authorization, user info handling, and PAM module testing for secure access to DiRAC resources."
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
IRIS/DiRAC TBAn&Az trial Combining HPC with federated identity management Jens Jensen (UKRI) Co-conspirators: Jos Caballero Bejar (UKRI) Matt R s -Barnett ((then) Univ of Cambridge) NSF CyberSecurity Summit 2022, WoTBAn&Az workshop
Dramatis Personae UK Research and Innovation (UKRI, www.ukri.org) funds, supports and conducts research on behalf of the UK gov t STFC, one of 9 councils in UKRI, supports large facilities (synchrotrons, lasers, etc), cosmology, astronomy, particle physics, space science, and much more IRIS (www.iris.ac.uk) supports computing for STFC-funded research (incl. LIGO, SKA, DUNE, V Rubin Telescope, ) DiRAC (www.dirac.ac.uk) is a network of HPC and supercomputing sites supporting computational cosmology now part of IRIS (not to be confused with other things called DIRAC)
IRIS compute overview: current federated or password X.509 user cert ssh key GridPP (particle physics) IRIS community cloud DiRAC HPC HTC cloud HPC
IRIS compute overview: desired IRIS community cloud GridPP (particle physics) federated DiRAC HPC VO mgmt
AARChitecture IRIS runs a BPA proxy connected to eduGAIN The IRIS BPA proxy is Indigo IAM (There is a parallel setup for SKA UKSRC, globally accessible)
IRIS IAM Adding SAFE as Community Identity Provider to the proxy DiRAC resources as service providers In practice, SAFE access is used in prod n Federated access needs rollout across DiRAC Not-SAFE users SAFE users legacy access (ssh keys) IAM legacy access (X.509 cert) DiRAC services Not-DiRAC services
UserInfo and Authorisation UserInfo (depends on scopes etc) Mail Name (sn, givenName) preferred_username Group memberships Authorisation (individually selectable) Individual local mapping LDAP query successful Group membership Project, fetch list of groups belonging to project from proxy s server
PAM module for ssh login SAFE DiRAC test of PAM module for federated ssh access Code is forked from Mazarykova Univerzita Durham and Cambridge were volunteered to test this SAFE added as Community IdP to IRIS IAM Spent most of August 21 refactoring and hardening the code Advantages No need for ssh keys Harmonise user mgmt. between DiRAC and IRIS\DiRAC Future proofing Still does accounting via SAFE Full UserInfo available to authorisation No change to ssh client. No change to ssh server. Disadvantages Extra levels of indirection for current ssh key users IAM ssh
Single ssh, single PAM stack auth required pam_sepermit.so auth sufficient pam_oauth2_device.so auth include passwd # or whatever Bypass for named users or LDAP lookup Non-bypassed users go through federation login pam_oauth2 must come first, or everyone gets asked about the fallback login
No bypass No LDAP Bypass LDAP LDAP bypass query PAM module looks up local (PAM) username and compares the remote (IAM) username with an LDAP attribute Added local username LDAP query as alternative Query just has to be successful Bypass checks which supports local users through fall-through to password The account name (local Unix) may be different again Tested at Cambridge and RAL LDAP auz qry on remote username LDAP auz qry on local username authorised
Fork from ICS-MUNI.CZ work Goodish bit of refactoring done (next slide) Stayed with upstream decisions for now C++11 Config in JSON Build with make Using modern C++ features for code correctness Albeit limited to C++11, see above conventional commits www.conventionalcommits.org
Main UK changes since fork Improved certificate checking Debug mode curl refactored, support for NSS clients Improved logging Including syslog Config file can be split into sections E.g. keeping secrets or usermaps in separate files Bypass mode x2 (LDAP or config file or both) External contrib: HTTP BASIC auth (Brian Bockelman) Additional authorisations (Will Furnell) Including local suffix for (say) pool accounts Exception handling Worked on unit tests but they still need more work
Main upstream changes since fork (According to the commit messages) Multiple LDAP servers syslog REFEDS MFA support Exception handling
Initial feedback from SKA No ssh client state: need to authenticate every time No modifications to ssh client In contrast, KIT s oidc-agent would obviously cache user side creds No delegated token on ssh server la MEG (MyProxy-enhanced GSISSH) Would need some thought Federation infrastructure (BPA proxy) needs HA setup
Other module considerations Sharing code Working with other groups (Mazarykova, Karlsruhe, EOSC, OSG, ) Evolving/emerging standards Communities from AARC projects extended collaborations (appint, OIDCre, voPerson, REFEDS groups, FIM4R, GEANT ) User communities The PAM module is quite large Config is JSON: slightly temperamental and no comments Need to validate every config file after change PAM module includes JSON parser => larger code
Other considerations - Authorisation No user manageable attributes ( la VOMS) Except users specify the (local) username through ssh Authorisation extended to meet community needs Is it doing the Right Thing Need for more sophisticated authorisation? E.g. (optional) callout to external decision process? Indigo IAM not G069 (n e G002) compliant Though subgroup parent Meaning IAM will send for example, "groups": { "skao", "skao/uksrc", "skao/uksrc/purple" } Using a hypothetical RFC6453 subspace, G069 would say, entitlement: { "urn:ogf:aaops:skao:group:uksrc:purple" } ? Some choices seem a bit exotic
Deployment: account management local remote user1 user2 user3 user3 ssh user3@remote user4 user5 Users must know their remote username Human administrators must have approved the account creation Usernames (preferred_username) not necessarily consistent across sites Accounting must be tied to federated account (or group(s))
Deployment: account management Either consistently use preferred_username across all sites Or look up local username in LDAP/usermap (site specific config) Users would ssh @remote, la Moonshot Or use mapping tools, la LCMAPS/GUMS (remember those?) Option to allocate from pool accounts? Synchronise accounts with proxy SCIM or some (other) LDAP schema
Next steps (modulo effort available) Production rollout across DiRAC Testing with SKA Support for G069 attributes Merge upstream support for MFA? Indigo IAM will get MFA support in due course Investigate caching sessions? Acks: this work was funded by UKRI-STFC through IRIS and DiRAC
Thank you https://github.com/stfc/pam_oauth2_device scd.stfc.ac.uk @SciComp_STFC
