notes/token_exchange_in_iroh_auth.org
This commit is contained in:
parent
8ee9b2b262
commit
18e15c8dee
1 changed files with 39 additions and 30 deletions
|
@ -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/.
|
||||
|
|
Loading…
Reference in a new issue