123 lines
5 KiB
Org Mode
123 lines
5 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.
|
|
|
|
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.
|