#+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 <yaesposi@cisco.com>

* 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.

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.

* 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                                                    :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
2. When a user click on the link, we save an unique Id in DB and we
   redirect the user to the IdP's URL
3. IROH-Auth is just waiting for the user to come back (via browser
   redirect) with infos from the IdP.
   Generally the user come back to the =/iroh/iroh-auth/:idp/answer= endpoint
   with a query parameter containing a =code=


* 3 - OAuth2 / OpendID Connect Provider
* 4 - Specifc Cisco Usage
- Orbital
- AMP