deft/notes/remove_securex_tg_login_button.org

:PROPERTIES:
:ID:       3290e028-b7a6-4be3-a5d2-45bf89ff2f0d
:END:
#+TITLE: Remove SecureX TG IdP login button
#+Author: Yann Esposito
#+Date: [2022-02-01]
- tags :: [[id:91f33b35-6e4e-4213-b214-972ee20722df][Cisco]]
- source ::


In order to remove TG IdP as a SecureX login we need to find a way to link
the SecureX user account to another IdP login account.
* Proposal 1

** Solution 1: Enforce verified email in TG

Using this solution we could link the accounts using the email address.

If Threatgrid ensure that every login has a verified email, SecureX could
remove a flag, and the Threatgrid user could login into SecureX in the TG
created org by using the same email.
The only change to be done in SecureX will be to change a configuration flag.

*Why?*

If TG does not verify the emails and we enable the flag, it would be
possible for a TG user to trick another user with another email into their
own SecureX account.

Example:

1. User1 in Threatgrid, change its email address in TG to =chuck@cisco.com=
2. User1 create a new SecureX account (SecureX save =chuck@cisco.com= for his email)
3. The real Chuck login via SXSO, and is automatically logged in into the
   User1 account.

** Solution 2: Provisioning API

Using this solution we link using internal =user-id= provided by the IdPs.

We have an API currently used by the CSA team =/iroh/provisioning=

This API must be called everytime a user in TG "migrates" its account to SXSO.
Or if not migrates, at least, links its TG account to an SXSO account.
The next time the user will use SXSO to login into SecureX he will be able
to join the Threatgrid created org.

This API was created for a specific workflow where the entire Org decide to
migrate.
Thus there are specific routes such that Threatgrid could declare that for
some Org, login via TG IdP is forbidden and user must login via SXSO only.

** Notes

Both solutions can be used concurrently as this is the case for CSA currently.
* After TG Proposal

The previous proposal I made was using the work already done by CSA as reference.
Of course we could have many other mechanisms.

The proposed solution by Alex is to have a "Link your account" feature.
This always had my preference a long time ago but this solution has always
been discarded.
I think this is because in our case, most of our customer do not already have
an existing SXSO account.

The "Link your account" feature will look a lot like the work made by the
CSA team to migrate the account to SXSO.
So in order to do that we need to replicate this work inside SecureX.
This is probably a lot of work.

Note, the workflow would start from a SecureX user clicking on "login via ThreatGrid".
Or perhaps we will need to add new button to the login page to redirect the
user to the Threagrid account migration workflow.

For SecureX it means that to link both account, we need that the same user
first login to SecureX via Threatgrid, then during the same session login
to SXSO in SecureX.
As consequence we will not be able to remove the button until the last
user in SecureX has migrated his account or, as suggested, put an ultimatum
after which TG-only user will lose access to their SecureX account.

Let me make another remark regarding the first proposal (link accounts
using the email).
While I pointed a security risk, it does not appear to be a major security risk.
The risk that a paying customer try to use this flaw as an attack vector is low.
Changing the email in TG does not make possible for someone to
steal an account.
With an error, someone with the correct email might be put in another
account.
There is a risk that a typo in the email might makes it difficult for a
TG user to retrieve its SecureX account, but that could be fixed by a
manual fix (via TAC for example).

If we were able to simply use the email as an identifier it would simplify
the overall technical work a lot.
We could for example, replace the "login via TG button" by another link
that will redirect the user to a page that explain that as a TG user they
should now use SXSO, create a new account, take care to use the same email
as the one of their TG account and that will be it.

So to resume

1. Yes, we could take care of linking the TG account to SXSO account inside
   SecureX.
   Pros:
   - will be perfectly secure (no risk of linking the wrong account)
   - no work to be done on TG side
   Cons:
   - probably lot of work on SecureX side (both backend and frontend) as a
     comparison it took many months for CSA to build this account
     migration wofklow and I think there were a lot of UX work and concern before the
     development work started.
   - we still need to propose a login via TG for a long period of time
   - we will probably force an ultimatum on customer that might open many
     TAC cases.
2. We could try to merge account via the email (even if they are not verified by TG)
   Pros:
   - Limited work to be done on SecureX side
   - no work to be done on TG side
   Cons:
   - open some security concern that will need to be evaluated
   - UX should be evaluated, we don't want end user to be even more confused.