deft/notes/remove_securex_tg_login_button.org

Remove SecureX TG IdP login button

• Proposal 1
  • Solution 1: Enforce verified email in TG
  • Solution 2: Provisioning API
  • Notes
• After TG Proposal

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:

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.