#+TITLE: IROH Auth Presentation #+Author: Yann Esposito #+Date: [2021-04-16] - tags :: [[file:2021-04-16--13-35-21Z--cisco.org][Cisco]] * IROH Auth :ATTACH: :PROPERTIES: :ID: dc5070c0-9040-4175-9a67-c85a21f65f35 :END: [[attachment:_20210416_150439Screenshot%202021-04-16%20at%2015.04.30.png]] Yann Esposito * Plan 1. Introduction, History 2. Login 3. OAuth2/OIDC Provider 4. Specific Usages Cisco * 1 - Introduction * When did you interacted with IROH-Auth? - *Login* in SecureX - *Login* in CTR - *Login* in Orbital - *Authorized* the Ribbon - *Invited* someone to your Org - *Cross Launch* with SSE - Dealing with JWT - Changed the role of some user - When you investigate in CTR (via CTIA's module) - Created an OAuth2 client * What is IROH-Auth? (overview) This is a software subcomponent of /IROH/[fn:iroh] taking care of: + *Authentication* - provide a user unique identifier + *Authorization* - decide what user can or cannot do + *User Data Model* + *Tenancy (Org) Management* + *API Clients Management* + *OAuth2*, *OpenID Connect* provider (half of IROH-Auth dedicated to this) [fn:iroh]: *IROH* The software serving the API behind SecureX, CTR, Ribbons, integrations... * What is IROH-Auth? (technical) /IROH-Auth/ is a set of /Services/ within /IROH/ some of them exposing HTTP APIs. - Login + Login (core service + web API) + Org (service) + User (service + web API) + Scopes (service) + Auth Management (core service) + Invite (core service + web API) + Session (web API) + Profile (web API, =/whoami=) + SCIM Client (service) + IdP Migrate (core service + web API) /deprecated a few months ago/ + Provision (service + web API) /used instead of IdP Migrate/ - OAuth2 + OAuth2 (core service + web API) + OAuth2 Clients (core service + web API) + OAuth2 Clients Presets (service) + Grant Service (User's client authorizations) - Admin + Auth Management (web API) + OAuth2 Clients Management (web API) * History: IROH/Visibility (1/?) :ATTACH: :PROPERTIES: :ID: dab23b61-a766-4eda-a1e9-1d39258ef5c0 :END: Login using AMP SAML (generate JWT) Worked with Guillaume. Use AMP as an *IdP*[fn:idp] After the dance of their people AMP provides: - user-id - org-id - role (admin/user) *No DB of users!* [fn:idp] Idp: Identity Provider * History: IROH/Visibility - SAML (2/?) :ATTACH: :PROPERTIES: :ID: 07dabe43-9563-430c-a729-87b5154d6d18 :END: Doc & Libs > It's bad. > It's really bad. > It's like eating a hot circle of garbage... > Kevin [[attachment:_20210416_152516.jpeg]] * History: IROH/Visibility (3/?) 2nd goal: Support OAuth2 (become an OAuth2 provider) 3rd goal: Support AMP and Threatgrid login (OpenID Connect) Become both an OAuth2 client and provider. Need Clients/Users/Orgs in DB!!! OAuth2 RFC => OAuth2 GRANTS - Authorization Code Grant (the classic) - Client Grant (for scripts) - Implicit Grant (for Single Page Applications, now deprecated) * History: IROH/Visibility (4/?) 4rd goal: Support Account Activation => SCIM[fn:scim] Client Call a SCIM server. Check if the account is part from an activated Org inside AMP. - Become an OpenID Connect provider, made before the start of SecureX. - OpenID Connect with SSE (we are the IdP now) [fn:scim] *SCIM*: System for Cross-domain Identity Management * History: CTR (IDB SSE) :ATTACH: :PROPERTIES: :ID: 83c6d508-003a-4c81-8385-b9fa13137b92 :END: To integrate with SSE (devices) we have to use an SSE hosted IdP provider: the *IDB* The *IDB* stand for *Identity Broker*. This is a *Ping Federate Identity Provider*. *Ping Federate* is a server from PingIdentity a company specialized in Identity Providers and Management. Since then we only use OpenID Connect => IROH-Auth SAML support start to rot and is now probably completely deprecated [[attachment:_20210416_155119Yesssss--meme-40935.jpg]] * History: SecureX (5/?) From =idp-mapping= to =idp-mappings= From Idp managing Orgs to IdP providing only a User Identity Id. => generate random user-id/org-id and stop using the the one given by the IdP. Lot of DB migrations ensues. * 2 - Login Lot of IROH-Auth services dedicated just for *Login* * IROH-Auth Login Generally: enter your username & password => set a cookie with an id of the user of the user Not in IROH-Auth. The first goal was (and still is) not to take care of user's credentials. *There are no user password in IROH Auth.* The password security is handled by external *IdPs*. Currently SXSO, CSA & TG. * IROH-Auth Login Dance (1/?) :ATTACH: :PROPERTIES: :ID: e12ca021-c030-47f8-a9e5-4fb815a88735 :END: So the dance of login via IROH-Auth [[attachment:_20210416_154054Screenshot%202021-04-16%20at%2015.38.37.png]] 1. Login page => Select an IdP (all buttons are just links) 2. When a user click on the link: - generate and save an unique Id - redirect the user to the IdP with that unique Id as parameter 3. Wait for the user to come back to =/iroh/iroh-auth/:idp/answer= with - =code= query parameter - =state= query paramter that should be equal to the generate unique Id 4. We check our DB for that unique Id then call the IdP with the =code= and a secret shared between IROH-Auth and the IdP only. 5. The IdP returns an =id_token= with all user's information. After this first dance, we have: 1. A Users's Identity Id (the id of the user in the IdP) 2. The user email * IROH-Auth Login Dance (2/?) After the "Login Workflow" we know: - The user IdP - /User Identity id/ - the user's email Depending on the IdP we can also have an associated Org-id. So login now? no. * IROH-Auth Login Dance: Check the IdP configuration (3/?) #+begin_example clojure {:id "idb-amp" <- idp-id :name "Cisco Security Account" <- to display on the login page :msg "For existing Threat Response & AMP users." <- ??? :position 1 <- position on the login page :legacy true <- old? :auth-kind :oidc <- SAML or OpenId Connect? :user-namespace "idb-amp" <- if legacy, user-id will be (str user-namespace "-" user-identity-id) :authorize-uri "https://staging-sse.cisco.com/providers/sse/services/ident/as/authorization.oauth2" :token-uri "https://staging-sse.cisco.com/providers/sse/services/ident/as/token.oauth2" :idp-account-url "https://console.qa1.immunet.com/users/current" :idp-logout-url "https://console.qa1.immunet.com/logout" :grant-type :code <- OAuth2 detail ;; Correlation table how to transform the `id_token` claims :correlation-table {:org-id [:companyId] :org-name [:companyName] :user-name [:user_name] :user-email [:email] :role [:role]} :scopes ["profile" "email"] <- asked to the IdP OIDC provider :client-id "mylocalamp" <- client-id on the IdP provider :allow-all-role-to-login false <- default allow non-admin to login :client-secret "******" :additional-authorize-query-params {:selector "amp"} <- ping fed magic :scim-id :qa1} <- SCIM server id (refer to another part in the conf) #+end_example 2. Depending on the config We consider the IdP will manage the org (give an org-id, provide an user role, etc...) If that's the case we update our users inside IROH-Auth everytime the user login. There is no mechanism to push user's change from IdP directly in IROH-Auth. With CSA Migraiton should be deprecated. If SecureX Sign-On, we only take care of the =user-identity-id=. In this case. We generate the =idp-mapping= out of the =id_token=. The =idp-mapping= contain: - The idp-id - The User Identity Id (the user id in the IdP not in IROH) If this is the first time we see the user: -> Show the Org's creation page We check * 3 - OAuth2 / OpendID Connect Provider * 4 - Specifc Cisco Usage - Orbital - AMP