DIRAC Authentication/Authorization
Andrii Lytovchenko, CPPM
CONTENT
INTRODUCTION
DIRAC is using only X509 certificates for user authentication, but using X509 certificates is complicated for the end-users.
INTRODUCTION
Identity Provider (IdP) is a service that creates, maintains and manages user identity information and provides it together with the user authentication.
Proxy Provider is a service that creates, maintains, and manages X509 certificate proxies and provides them together with the user authentication.
INTRODUCTION
Most of users have accounts in their institutes or popular services that act as Identity Providers (IdPs).
EGI Check-in is a proxy service that operates as a central hub to connect federated Identity Providers (IdPs) with EGI service providers.
OAuth2 roles:
Resource owner is the user who is giving access to some portion of their account.
Resource server is the server that contains the user’s information that is being accessed by the third-party application, capable of accepting and responding to protected resource requests using access tokens.
Authorization server is the server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Client is the app that is attempting to act on the user’s behalf or access the user’s resources.
INTRODUCTION
OAuth 2.0 is the industry-standard delegation protocol for conveying authorization decisions across a network of web-enabled applications and APIs, full specification - RFC6749. More information here.
Open ID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. More information here.
LOG IN
Our task is to use the OAuth2 protocol to allow the user to log in through his favorite IdP.
DIRAC server
Authorization Server (AS)
DIRAC CLI
EGI Check-in
requests device authorization
authorization URL & user code
Authorization Server (AS)
requests tokens OR proxy
access & refresh tokens OR proxy
http services
dips services
Browser
authorization
/auth/authorization
RPC call with access token OR proxy
RPC call with proxy
$ dirac-login --token�Authorization pending.. (use CNTL + C to stop)
New token is saved to /tmp/bt_u504.
subject : 22bca818-acea-46bd-b290-c7536c56f962
issuer : https://wlcg.cloud.cnaf.infn.it/
timeleft : 01:59:56
username : alytov
DIRAC group : wlcg_user
properties : NormalUser
LOG IN
The login with DIRAC CLI is as follows:
1
2
3
Authenticate via EGI Check-in in a browser
Initialize authorization flow
Save the received token
LOG IN
WebApp portal users will be able to choose authorization methods by selecting a certificate or identity provider:
ACCESS TO DIRAC SERVICES
Consider the process of accessing the DIRAC service:
DIRAC Client
X509 proxy
Bearer token
DIRAC Service
decode & verify
discovery user & group
check group properties
Users delegate their access rights to DIRAC by uploading their long proxy certificates. In the case of OAuth2 access tokens, it will also have to be saved and updated, to be readily available without additional user interaction.
The existing method of delegation is to delegate a proxy by uploading it to ProxyManager. This happens transparently when executing the dirac-proxy-init command, or through the web interface.
Tokens are also deposited in the database in a similar service after successful authorization through the IdP, and an access token signed by DIRAC is returned to the user. Thus, DIRAC service being a registered client of the IdP, is able to maintain these tokens valid.
DELEGATION
USER MANAGEMENT
The main element of user management is the DIRAC group to manage permissions and separate activities.
DIRAC groups must be created for the registered VO, it must be associated with one of the roles defined by the VO.
At the moment, DIRAC groups are in "many-to-one" relation with VOMS role. For example, the user and pilot groups, which usually have the same VOMS role.
After the transition from VOMS VO to IdPs, it is necessary to ensure one-to-one correspondence between DIRAC groups and associated VO roles, for correct authorization using tokens.
USER MANAGEMENT
Currently, all users are described in the DIRAC configuration in the Registry section. The user information is synchronized with the VOMS servers using VOMS2CS agent.
USER MANAGEMENT
Registry service receives information about VO users from IdP or VOMS. There is no need to store this information in the DIRAC configuration.
User management is completely outside DIRAC, this is done by the VO administrators using appropriate web interface provided to VO upon registration.
DIRAC relies entirely on the information received from the relevant IdP.
Need to implement
The most obvious use case of asynchronous user task execution is the pilot job framework. Pilots should be able to obtain valid tokens of the users owners of the payloads to be executed.
Discussions are currently underway on how the flow to getting user tokens by pilots will look like. The concept is being developed in DIRAC, but the work is still ongoing.
PILOT FRAMEWORK WITH TOKENS
Need to implement
Several prototypes of using tokens were developed to provide user authentication and access to the DIRAC service as a technology preview. The elaborated architecture will be implemented and included in the release 8.0. For now DIRAC 8.0 exists as a pre-release.�
We study interactions with CEs and Clouds using access tokens.
STATUS AND PLANS
Thank you for listening
This work is co-funded by the EOSC-hub project (Horizon 2020) under Grant number 777536
EGI-ACE receives funding from the European Union's Horizon 2020 research and Innovation programme under grant agreement no. 101017567
Acknowledgements