91 lines
3.6 KiB
Org Mode
91 lines
3.6 KiB
Org Mode
: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.
|
|
|
|
So the workflow would start from a SecureX user clicking on "login via ThreatGrid".
|
|
Which means that we will not be able to remove the button until the last
|
|
user in SecureX has migrated his account or as suggested but an ultimatum
|
|
after which a user only using TG to login into SecureX will not be able to
|
|
retrieve his SecureX account if he didn't migrate in time.
|
|
|
|
Another important remark, the "verify the email" work might not be
|
|
necessary if we think that the security risk involved is low.
|
|
For example, 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.
|
|
The risk that a paying customer try to use this flaw as an attack vector is low.
|
|
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).
|
|
|
|
So if the end goal is to remove the TG login button, we could simply inform
|
|
the user to use SXSO with the same email he used to create the TG account,
|
|
and that's it.
|