notes/token_exchange_in_iroh_auth.org
This commit is contained in:
Yann Esposito (Yogsototh)
parent
8ee9b2b262
commit
18e15c8dee
GPG key ID:
7B19A4C650D59646
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
|
fuzzy, and even worse, ambiguous depending on which side you are looking into
|
||||||
them.
|
them.
|
||||||
A *user* in not the same entity when looked from an Okta engineer from a SecureX
|
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
|
engineer, from another Cisco team perspective.
|
||||||
meaning for each word restricted to this document:
|
This is why at the bottom of this document there is a Terminology section.
|
||||||
|
|
||||||
- /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/.
|
|
||||||
|
|
||||||
|
|
||||||
*** Using SXSO tokens vs SXSO User Identity
|
*** 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
|
- Optionally add ~subject_token~ to the account selection API, probably depending
|
||||||
on some scope and/or some audience of the token making the call
|
on some scope and/or some audience of the token making the call
|
||||||
- Add support for Token Exchange RFC
|
- 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