[WIP][v7r2] OAuth2/OIDC AuthN/AuthZ mechanism#4648
Closed
TaykYoku wants to merge 69 commits into
Closed
Conversation
…tDNsForUsernameFromSC,getIDsForUsername,getVOsWithVOMS,getDNForUsernameInGroup,getDNsForUsernameInGroup,findSomeDNToUseForGroupsThatNotNeedDN
…up, this is authQuery work
… changes in ProxyManager, modify authed check
…gistry and ProxyManader
… fix test, use username instead DN
…changes, fix test
… providers, not use persistent flag
Contributor
|
Before I go through all that: is that all of it, including what is in the current Oauth extension of DIRAC ? |
Contributor
Author
|
No, these are just changes related to the DIRAC project.. and I'll probably close it now. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces the AuthN/AuthZ mechanism to DIRAC based on the use of Identity Provider
services using OAuth2/OIDC protocols.
Few remarks about the implementation.
The user Authn/AuthZ paradigm changes. Before we collected all the necessary user information
in the CS Registry and then used it to identify and authorize client requests. Now we can use
external identity providers dynamically. Each time a user is starting a DIRAC session, the
authentication can be delegated to an external identity provider. If authentication is successful,
then actual user profile information is cached in a dynamic session object which is created
for each active user. This session is used for further identification of user requests. Therefore,
DIRAC CS Registry becomes just one of the possible sources of the user profile information. Other
sources are (Federated) Identity Providers, e.g. Check-In, Indigo AIM, Google, etc, VOMS.
The use of X509 certificates is no more the only way for user identification. Therefore,
certificate DN's are no more the primary user identifiers. Now there can be also user IDs
from various identity providers. Within DIRAC, user name becomes the main, single and unique
user identifier independent on various user identities from different providers. As a consequence,
all the CS options with user identities as values, e.g. pilot user, should be expressed in terms
of user names rather than DNs. For backward compatibility current options in a form of DN are
still accepted but should be replaced eventually.
There can be now DIRAC users that do not have usual personal certificates and will identified
via OAuth2/OIDC mechanism. However, in order to ensure the work of the DISET protocol still based
on the use of X509 certificate proxies, the us of Proxy Provider services is enabled. These
services can create a certificate proxy on demand to be used by users in CLI interfaces and
by DIRAC services for performing operation on the users' behalf. Current solution is DIRAC Proxy
Provider using DIRAC CA certificates to generate user proxies (for the DIRAC internal use only).
Solution using RCauth Proxy Provider service is tested and will be available in later PRs.
Users having usual X509 certificates will continue to use those in a usual way.
Identity Providers and Proxy Providers are added as new types of Resources.
Although this PR introduces new functionalities, the current mechanisms of X509 based user
authentication are still maintained. Installations and users using old good X509 certificates
will continue to work without any changes.
BEGINRELEASENOTES
NEW: Multiple changes to provide OAuth2/OIDC user AuthN/AuthZ and OAuth session management.
CHANGE: multiple changes to use username instead of DN where applicable.
Changes affect the following Systems: Transformation, Configuration, DataManagement, Framework, RequestManagement, WorkloadManagement. Also tests, Core, Interfaces, Resources.
*ConfigurationSystem
CHANGE: Registry - modified for using cached users information on the clients
*Core
NEW: DictCache - add getDict method
CHANGE: AuthManager - split authorization logic, modify to use new Registry
CHANGE: RequestHandler - fill credDict by AuthManager methods
CHANGE: align with the PR changes
*FrameworkSystem
CHANGE: ProxyManager - modify to use user/group in requests, add VOMS information cache
NEW: dirac-proxy-init - able to use OAuth authentication flow
NEW: halo - new class to use spinners for waiting process, for ex. waiting authentication
*RequestManagementSystem
CHANGE: Request - add owner argument, use AuthManager methods
CHANGE: align with the PR changes
*WorkloadManagementSystem
CHANGE: align with the PR changes
*TransformationSystem
CHANGE: align with the PR changes
*DataManagementSystem
CHANGE: align with the PR changes
*Resources
CHANGE: align with the PR changes
*Interfaces
CHANGE: align with the PR changes
*tests
CHANGE: align with the PR changes
ENDRELEASENOTES