From 18e15c8dee8e5261b66efff5e94d188881ae4a00 Mon Sep 17 00:00:00 2001 From: "Yann Esposito (Yogsototh)" Date: Wed, 1 Jun 2022 11:53:28 +0200 Subject: [PATCH] notes/token_exchange_in_iroh_auth.org --- notes/token_exchange_in_iroh_auth.org | 69 +++++++++++++++------------ 1 file changed, 39 insertions(+), 30 deletions(-) diff --git a/notes/token_exchange_in_iroh_auth.org b/notes/token_exchange_in_iroh_auth.org index 4d3d2a7c..c26e637d 100644 --- a/notes/token_exchange_in_iroh_auth.org +++ b/notes/token_exchange_in_iroh_auth.org @@ -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/.