3.7 KiB
Remove SecureX TG IdP login button
- tags
- 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:
- User1 in Threatgrid, change its email address in TG to
chuck@cisco.com - User1 create a new SecureX account (SecureX save
chuck@cisco.comfor his email) - 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.
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.
CSA team built a workflow to drive their user to a migration workflow. And we could replicate it in SecureX. This looks like 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.