43 lines
1.8 KiB
Org Mode
43 lines
1.8 KiB
Org Mode
# Created 2021-10-28 Thu 15:13
|
|
#+title:
|
|
#+author: Yann Esposito
|
|
* SSE CCO_id :work:discussion:
|
|
[2021-10-28 Thu 14:52]
|
|
- ref :: https://github.com/advthreat/iroh/discussions/5754
|
|
|
|
So after giving more thoughts on the subject.
|
|
Here are some scenarios:
|
|
|
|
1. A person login via Okta with the email ~user-1@domain.com~
|
|
2. This person want to connect his account, then he must login via Okta
|
|
again but using another Okta account ~user-1@smart-account.com~ for example.
|
|
|
|
In this scenario there are two issues:
|
|
|
|
The first is that we do not control the Okta session.
|
|
The Okta session will keep being the one for ~user-1@smart-account.com~.
|
|
When the user will launch another product he will not use his usual
|
|
~user-1@domain.com~ Okta session.
|
|
|
|
The second, is that we should have a mechanism to understand that on the
|
|
second login, we don't want to login the user, but to merge two different
|
|
IdP accounts.
|
|
|
|
Mainly we will need to develop a new workflow, so a user could merge
|
|
multiple IdP accounts to his current SecureX account.
|
|
|
|
The implications are:
|
|
|
|
- SecureX users should support multiple email addresses. (also note that
|
|
user login via TG have a non verified email addresses and are treated
|
|
separately on different login flows.)
|
|
- We need to support more metas data in the IdP Mappings in general,
|
|
(typically the CCO_id). Now, what if a user login multiple times, and has
|
|
two different IdP Mapping with a different CCO_id.
|
|
- We will need to provide a new route, that will present a new HTML page
|
|
similar to the login page but with subtle modifications.
|
|
We might, for example, negotiate another login buttons that will behave
|
|
differently (typically a login button forcing the user to use CCO).
|
|
|
|
In the end, it means we should deliver a "Merge a new Login" flow to
|
|
SecureX Accounts. And it doesn't seem to be trivial.
|