91 lines
3 KiB
Org Mode
91 lines
3 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 proposal I made was using the work already done by CSA.
|
|
Of course we could have many other mechanisms.
|
|
|
|
The "Link your account to another IdP" had my preference a long time ago
|
|
and this solution has always been discarded.
|
|
In our current situation, unlike in other product when you are asked to
|
|
link your twitter/google/FB account, in our case the user will probably do
|
|
not have any existing SXSO account.
|
|
|
|
That mean that the workflow to follow is not trivial to build.
|
|
This is exactly the work that the CSA team made for the migration.
|
|
|
|
So technically, every user in SecureX has a list of =idp-mapping=.
|
|
So a user identified as user1 in SXSO can be mapped to multiple users in
|
|
SecureX.
|
|
And the same user in SecureX can be associated to multiple IdP identities
|
|
from different IdPs.
|
|
|
|
Currently, all TG user have an =idp-mapping= with
|
|
|
|
#+begin_src json
|
|
{"idp":"tg-idb",
|
|
"user-identity-id":"user-id-in-tg",
|
|
"organization-id":"org-in-tg"}
|
|
#+end_src
|
|
** Problem
|
|
|
|
User are confused by too many login options into SecureX.
|
|
|
|
** Solutions
|
|
|
|
|
|
*** Migrate every user to login only via SXSO
|
|
*** Find a way for SXSO to
|