yogsototh/deft
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

notes/token_exchange_in_iroh_auth.org

Browse source
This commit is contained in:
Yann Esposito (Yogsototh) 2022-06-01 11:53:28 +02:00
parent 8ee9b2b262
commit 18e15c8dee
Signed by untrusted user who does not match committer: yogsototh
GPG key ID: 7B19A4C650D59646
1 changed files with 39 additions and 30 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

69
notes/token_exchange_in_iroh_auth.org
View file

@ -20,36 +20,8 @@ The terminology used in the Authentication/Authorization context are often
fuzzy, and even worse, ambiguous depending on which side you are looking into
them.
A *user* in not the same entity when looked from an Okta engineer from a SecureX
engineer, from another Cisco team perspective. So here is an explicit list of
meaning for each word restricted to this document:
- /IROH/ => the main API that powers Threat Response and SecureX
- /IROH-Auth/ => the component of IROH focused on Authorization, Authentication,
User and Org (Tenant) management. It provides a full OAuth2 and OpenID Connect
provider, as well as an OAuth2 and OpenID Connect client. It exposes API to
manage Orgs, Users and OAuth2 clients.
- /SXSO/ => The IdP which is powered via Okta. It is mostly seen in this document
as an OpenID Connect provider, but it also has the ability to be a SAML provider.
- /SecureX user/ or simply /user/ => a SecureX user belongs to a known org
- /SecureX org/ or simply /org/ => The org in SecureX, can be assimilated to the tenant
- /SecureX account/ or simply /account/ => a couple SecureX user with its associated SecureX org
- /User Identity/ or /IdP User/ or /Okta User/ => a user identified via an IdP. Such a user can reach
potentially multiple SecureX accounts.
- /tenant/ => can be assimilated to SecureX org in this document
- /client/ => the client of the OAuth2 IROH-Auth Provider, an entity making HTTP
requests to IROH-Auth
- /client object/ or /client entity/ => the OAuth2 clients entity that could be
created, and configured in IROH-Auth.
- /client credentials/ => both an OAuth2 Client object ~client_id~ and
~client_secret~. This is used to identify the /client/.
- /token/ => A token is a string that could be used to retrieve user information
(~id_token~), access some API (~access_token~) or retrieve new tokens (~refresh_token~).
In this document, most token will be JWT (JSON Web Token)
- /subject/ => in the terminology used in the Token Exchange RFC, a subject would
be a /SecureX user id/.
engineer, from another Cisco team perspective.
This is why at the bottom of this document there is a Terminology section.
*** Using SXSO tokens vs SXSO User Identity
@ -128,3 +100,40 @@ could optionally return an ~id_token~ as well as a ~refresh_token~.
- Optionally add ~subject_token~ to the account selection API, probably depending
on some scope and/or some audience of the token making the call
- Add support for Token Exchange RFC
*** Terminology
The terminology used in the Authentication/Authorization context are often
fuzzy, and even worse, ambiguous depending on which side you are looking into
them.
A *user* in not the same entity when looked from an Okta engineer from a SecureX
engineer, from another Cisco team perspective. So here is an explicit list of
meaning for each word restricted to this document:
- /IROH/ => the main API that powers Threat Response and SecureX
- /IROH-Auth/ => the component of IROH focused on Authorization, Authentication,
User and Org (Tenant) management. It provides a full OAuth2 and OpenID Connect
provider, as well as an OAuth2 and OpenID Connect client. It exposes API to
manage Orgs, Users and OAuth2 clients.
- /SXSO/ => The IdP which is powered via Okta. It is mostly seen in this document
as an OpenID Connect provider, but it also has the ability to be a SAML provider.
- /SecureX user/ or simply /user/ => a SecureX user belongs to a known org
- /SecureX org/ or simply /org/ => The org in SecureX, can be assimilated to the tenant
- /SecureX account/ or simply /account/ => a couple SecureX user with its associated SecureX org
- /User Identity/ or /IdP User/ or /Okta User/ => a user identified via an IdP. Such a user can reach
potentially multiple SecureX accounts.
- /tenant/ => can be assimilated to SecureX org in this document
- /client/ => the client of the OAuth2 IROH-Auth Provider, an entity making HTTP
requests to IROH-Auth
- /client object/ or /client entity/ => the OAuth2 clients entity that could be
created, and configured in IROH-Auth.
- /client credentials/ => both an OAuth2 Client object ~client_id~ and
~client_secret~. This is used to identify the /client/.
- /token/ => A token is a string that could be used to retrieve user information
(~id_token~), access some API (~access_token~) or retrieve new tokens (~refresh_token~).
In this document, most token will be JWT (JSON Web Token)
- /subject/ => in the terminology used in the Token Exchange RFC, a subject would
be a /SecureX user id/.