2021-12-07 14:09:36 +00:00
|
|
|
:PROPERTIES:
|
|
|
|
:ID: 1208f09c-d37d-4e6b-9110-151f3c6b7d34
|
|
|
|
:END:
|
2021-12-07 14:11:45 +00:00
|
|
|
#+TITLE: Cisco FT SecureX Simplified Registration
|
2021-12-07 14:09:36 +00:00
|
|
|
#+Author: Yann Esposito
|
|
|
|
#+Date: [2021-12-07]
|
|
|
|
|
|
|
|
- tags :: [[id:299643a7-00e5-47fb-a987-3b9278e89da3][Auth]]
|
|
|
|
- source :: https://github.com/advthreat/response/issues/821
|
2021-12-07 14:11:45 +00:00
|
|
|
- dashboard :: https://github.com/advthreat/iroh/projects/32
|
|
|
|
|
2022-01-17 14:08:37 +00:00
|
|
|
* Table of Content :TOC_3:QUOTE:
|
|
|
|
#+BEGIN_QUOTE
|
2022-01-17 13:51:34 +00:00
|
|
|
- [[#functional-spec][Functional Spec]]
|
|
|
|
- [[#technical-plan][Technical Plan]]
|
|
|
|
- [[#support-private-email-vs-public-emails][Support private email vs public emails]]
|
|
|
|
- [[#canceled-support-allow-list-exceptions-for-some-cisco-user][CANCELED Support allow-list exceptions for some Cisco user.]]
|
|
|
|
- [[#support-search-admin-with-same-email-domain][Support, search admin with same email domain]]
|
|
|
|
- [[#new-ui-sync][New UI Sync]]
|
|
|
|
- [[#new-auth-apis][New Auth APIs]]
|
|
|
|
- [[#new-api-jwt-middleware][New API JWT middleware]]
|
2022-01-17 14:12:33 +00:00
|
|
|
- [[#new-iroh-auth-crud-services][New IROH-Auth CRUD Services]]
|
2022-01-17 13:51:34 +00:00
|
|
|
- [[#new-iroh-auth-api][New IROH-Auth API]]
|
2022-01-17 14:10:08 +00:00
|
|
|
- [[#new-iroh-auth-login-process][New IROH-Auth login process.]]
|
2022-01-17 13:51:34 +00:00
|
|
|
- [[#email-notification-of-org-request-accesses][Email Notification of Org Request Accesses]]
|
|
|
|
- [[#notes][Notes]]
|
|
|
|
- [[#org-requests-crud-api-for-admins-of-the-orgs][Org Requests CRUD API for Admins of the Orgs]]
|
|
|
|
- [[#list][List]]
|
|
|
|
- [[#read][Read]]
|
|
|
|
- [[#accept-the-org-access][Accept the Org Access]]
|
|
|
|
- [[#reject-the-org-access][Reject the Org Access]]
|
2022-01-17 14:08:37 +00:00
|
|
|
#+END_QUOTE
|
2022-01-17 13:50:12 +00:00
|
|
|
|
2021-12-16 14:15:16 +00:00
|
|
|
* Functional Spec
|
|
|
|
|
|
|
|
Response issues:
|
|
|
|
- https://github.com/advthreat/response/issues/821
|
|
|
|
|
|
|
|
Figma: https://www.figma.com/file/Bz3m25kpWXpdct7AnhmNsW/SXSO-Registeration?node-id=759%3A5926
|
|
|
|
|
2021-12-07 14:11:45 +00:00
|
|
|
* Technical Plan
|
2022-01-17 13:51:34 +00:00
|
|
|
** DONE Support private email vs public emails
|
2021-12-07 14:14:39 +00:00
|
|
|
|
2022-01-17 10:42:11 +00:00
|
|
|
*DONE*
|
|
|
|
+/Estimate: 1 release cycles after the list is provided./+
|
2021-12-15 15:23:58 +00:00
|
|
|
|
2021-12-07 14:14:39 +00:00
|
|
|
The solution is to use a blacklist of domains where any user could create
|
|
|
|
multiple email accounts pseudo-anonymously.
|
|
|
|
|
2021-12-16 14:16:36 +00:00
|
|
|
Details: https://github.com/advthreat/response/issues/979
|
|
|
|
|
2022-01-17 09:59:21 +00:00
|
|
|
*** CANCELED Support allow-list exceptions for some Cisco user.
|
|
|
|
:LOGBOOK:
|
|
|
|
- State "CANCELED" from "HOLD" [2022-01-17 Mon 10:57] \\
|
|
|
|
This only concern new account creation. User with gmail account could still login.
|
|
|
|
:END:
|
2021-12-16 14:18:02 +00:00
|
|
|
|
2021-12-16 14:21:13 +00:00
|
|
|
/Estimate: 1 release cycles after the list is provided./
|
|
|
|
|
2021-12-16 14:18:02 +00:00
|
|
|
Typically we should allow some users with an email like =some-user+XXX@gmail.com=
|
|
|
|
|
2021-12-07 14:13:30 +00:00
|
|
|
** Support, search admin with same email domain
|
2021-12-07 14:16:58 +00:00
|
|
|
|
2021-12-15 15:25:14 +00:00
|
|
|
/Estimate: 1 release cycle./
|
|
|
|
Note: *Work in progress*
|
2021-12-15 15:23:58 +00:00
|
|
|
|
2021-12-07 14:16:58 +00:00
|
|
|
We should be able given an email from a user, to find all the orgs for
|
|
|
|
which at least one of its admin has a matching domain name.
|
|
|
|
|
|
|
|
1. Most efficient: add an invisible field =email-domain= to all users. This
|
|
|
|
should be lower-case, and we will need a migration.
|
2021-12-07 14:20:00 +00:00
|
|
|
Doing this we could have a faster match than using string related queries.
|
|
|
|
|
|
|
|
Problems, users can login in the same user, with the same public email with
|
|
|
|
different emails.
|
|
|
|
This should be rare.
|
2021-12-07 14:16:58 +00:00
|
|
|
|
2021-12-07 14:21:58 +00:00
|
|
|
2. Search via text match.
|
|
|
|
|
|
|
|
|
|
|
|
The algorithm should look a bit like:
|
|
|
|
|
|
|
|
#+begin_src clojure
|
2021-12-07 14:24:11 +00:00
|
|
|
|
|
|
|
;; only when this is an unknown user
|
2021-12-07 14:59:57 +00:00
|
|
|
;; so a single approval will prevent the user to see this page.
|
2021-12-07 14:21:58 +00:00
|
|
|
(let [user-email ,,,
|
2021-12-07 14:24:11 +00:00
|
|
|
domain (string/replace user-email #".*@" "")
|
2021-12-07 14:25:27 +00:00
|
|
|
users (matching-admins domain) ;; returns a potentially big list of admin users
|
|
|
|
indexed-orgs (group-by :org-id users)]
|
|
|
|
(vals indexed-orgs))
|
2021-12-07 14:21:58 +00:00
|
|
|
#+end_src
|
|
|
|
|
2021-12-07 14:58:36 +00:00
|
|
|
|
|
|
|
Once this list of orgs is found.
|
2021-12-07 14:59:57 +00:00
|
|
|
We should also check the list of pending or rejected OrgAccessRequest for this user in
|
|
|
|
order to prevent the user to request access multiple time.
|
|
|
|
|
2022-01-17 10:44:55 +00:00
|
|
|
** New UI Sync
|
2022-01-17 10:31:19 +00:00
|
|
|
|
2022-01-17 10:32:23 +00:00
|
|
|
/Estimate: 5 release cycles/
|
|
|
|
|
2022-01-17 10:31:19 +00:00
|
|
|
We should find a way to hand the UI work to the UI team.
|
|
|
|
Right now, the page are all generated in IROH.
|
|
|
|
|
|
|
|
To reach that ideally we should sync the source code as a jar in IROH.
|
|
|
|
|
2022-01-17 10:44:55 +00:00
|
|
|
In order to give the UI the ability to make a front-end application, we
|
2022-01-17 10:39:18 +00:00
|
|
|
should create news APIS that support a new UserIdentity-level JWT
|
2022-01-17 10:33:46 +00:00
|
|
|
|
2022-01-17 10:37:23 +00:00
|
|
|
|
2022-01-17 10:46:39 +00:00
|
|
|
*** New Auth APIs
|
|
|
|
|
2022-01-17 10:48:28 +00:00
|
|
|
Continue to use the =/code= route of iroh-auth.
|
2022-01-17 10:51:39 +00:00
|
|
|
But instead of returning a Session Token, it will return a UserIdentity Token.
|
2022-01-17 10:50:04 +00:00
|
|
|
This is a JWT with the important data from the IdP:
|
2022-01-17 10:46:39 +00:00
|
|
|
|
2022-01-17 10:50:04 +00:00
|
|
|
- idp-id
|
|
|
|
- user-identity-id
|
|
|
|
- user-email
|
|
|
|
- etc…
|
|
|
|
|
2022-01-17 10:51:39 +00:00
|
|
|
When the user is redirected to an HTML generated page, we should add the
|
|
|
|
=code= in the anchor parameter of the route so the UI will be able to use
|
|
|
|
that code to retrieve a UserIdentity Token.
|
2022-01-17 10:46:39 +00:00
|
|
|
|
2022-01-17 10:54:23 +00:00
|
|
|
*** New API JWT middleware
|
2022-01-17 10:52:43 +00:00
|
|
|
|
|
|
|
/Estimate: 1 release cycle/
|
|
|
|
|
|
|
|
We need to change the configuration of the check JWT middleware to support
|
|
|
|
UserIdentity Token instead. And use this configuration for this new API.
|
|
|
|
|
2022-01-17 11:01:42 +00:00
|
|
|
The =user-identity-jwt= should contain enough data to retrieve:
|
|
|
|
- =idp-mapping=
|
|
|
|
- =user-email=
|
|
|
|
- all other metas, as user-name, user-nick, etc…
|
2022-01-17 14:12:33 +00:00
|
|
|
*** New IROH-Auth CRUD Services
|
2022-01-17 14:01:08 +00:00
|
|
|
**** OrgAccessRequest
|
|
|
|
|
2022-01-17 14:12:33 +00:00
|
|
|
This new service should be mostly a CRUD service on top of TKStore with the
|
|
|
|
following schema:
|
2022-01-17 14:01:08 +00:00
|
|
|
|
|
|
|
#+begin_src clojure
|
|
|
|
(s/defschema OrgAccessRequest
|
|
|
|
(st/merge
|
|
|
|
{:id UUID
|
|
|
|
:idp-mapping IdPMapping
|
|
|
|
:user-email s/Str
|
|
|
|
:org-id s/Str
|
|
|
|
:status (s/enum :pending :accepted :rejected)
|
|
|
|
:created-at DateTime}
|
|
|
|
(st/optional-keys
|
|
|
|
{:user-name s/Str
|
|
|
|
:user-nick s/Str
|
|
|
|
:approver-id UserId
|
|
|
|
:approver-email UserEmail ;; email of the approver
|
|
|
|
:updated-at DateTime
|
|
|
|
})))
|
|
|
|
#+end_src
|
|
|
|
|
2022-01-17 14:12:33 +00:00
|
|
|
#+begin_src clojure
|
|
|
|
(defprotocol OrgAccessRequestService
|
|
|
|
(create)
|
|
|
|
)
|
|
|
|
|
|
|
|
#+end_src
|
|
|
|
|
2022-01-17 14:01:08 +00:00
|
|
|
**** UserIdentity
|
2022-01-17 10:46:39 +00:00
|
|
|
|
2022-01-17 14:02:37 +00:00
|
|
|
Should look a lot like a user but instead of a =user-id= it should have a
|
|
|
|
=user-identity-id= and should not have any =org-id= value.
|
|
|
|
|
|
|
|
It should also contain a field containing a set of hidden org-ids that will
|
|
|
|
be the orgs not to display on the registration webpages.
|
|
|
|
|
2022-01-17 14:04:00 +00:00
|
|
|
#+begin_src clojure
|
|
|
|
(s/defschema UserIdentity
|
|
|
|
(ist/open-schema-any-keys
|
2022-01-17 14:05:09 +00:00
|
|
|
{:id s/Str
|
|
|
|
:email
|
|
|
|
:name
|
|
|
|
:nickname
|
|
|
|
:last-logged-in [,,,]
|
2022-01-17 14:04:00 +00:00
|
|
|
}))
|
2022-01-17 14:02:37 +00:00
|
|
|
#+end_src
|
|
|
|
|
2022-01-17 10:54:23 +00:00
|
|
|
*** New IROH-Auth API
|
2022-01-17 10:46:39 +00:00
|
|
|
|
2022-01-17 11:15:11 +00:00
|
|
|
/Estimate: 3 release cycle/
|
|
|
|
|
2022-01-17 10:55:32 +00:00
|
|
|
This new API should only work with UserIdentity JWT.
|
2022-01-17 10:46:39 +00:00
|
|
|
|
2022-01-17 10:55:32 +00:00
|
|
|
#+begin_src
|
2022-01-17 11:13:58 +00:00
|
|
|
POST /iroh/registration/org-access/:org-id ;; request access to a matching org
|
2022-01-17 11:07:38 +00:00
|
|
|
POST /iroh/registration/hide-org/:org-id ;; ability to hide an org-access
|
2022-01-17 11:13:58 +00:00
|
|
|
GET /iroh/registration/matching-accounts ;; list all the matching accounts
|
|
|
|
GET /iroh/registration/matching-orgs ;; list all the matching orgs
|
2022-01-17 11:11:54 +00:00
|
|
|
GET /iroh/registration/pending-invites ;; list all the pending invites
|
2022-01-17 13:37:07 +00:00
|
|
|
GET /iroh/registration/registration-view ;; helper to make a single http call
|
2022-01-17 10:54:23 +00:00
|
|
|
#+end_src
|
|
|
|
|
|
|
|
**** Request Org Access
|
2022-01-17 10:33:46 +00:00
|
|
|
|
2022-01-17 13:54:08 +00:00
|
|
|
We need to create another store with another Entity for access request to an Org.
|
|
|
|
|
|
|
|
#+begin_src clojure
|
|
|
|
(s/defschema OrgAccessRequest
|
|
|
|
(st/merge
|
|
|
|
{:id UUID
|
|
|
|
:idp-mapping IdPMapping
|
|
|
|
:user-email s/Str
|
|
|
|
:org-id s/Str
|
|
|
|
:status (s/enum :pending :accepted :rejected)
|
|
|
|
:created-at DateTime}
|
|
|
|
(st/optional-keys
|
|
|
|
{:user-name s/Str
|
|
|
|
:user-nick s/Str
|
|
|
|
:approver-id UserId
|
|
|
|
:approver-email UserEmail ;; email of the approver
|
|
|
|
:updated-at DateTime
|
|
|
|
})))
|
|
|
|
#+end_src
|
|
|
|
|
|
|
|
When a user request access to an organization.
|
|
|
|
We should create this object in DB.
|
|
|
|
|
|
|
|
|
2022-01-17 11:00:21 +00:00
|
|
|
#+begin_src
|
|
|
|
POST /iroh/registration/org-access/:org-id ;; request access to a matching org
|
|
|
|
#+end_src
|
|
|
|
|
2022-01-17 10:33:46 +00:00
|
|
|
#+begin_src http
|
2022-01-17 13:34:47 +00:00
|
|
|
POST /iroh/registration/org-access/:org-id
|
2022-01-17 10:33:46 +00:00
|
|
|
|
|
|
|
Accept: application/json
|
|
|
|
Content-Type: application/json
|
|
|
|
User-Agent: ob-http
|
|
|
|
Authorization: Bearer ${user-identity-jwt}
|
|
|
|
#+end_src
|
|
|
|
|
|
|
|
With this, and if every check matches:
|
|
|
|
|
|
|
|
1. There is a known active admin of this org with an email with the same domain name
|
|
|
|
2. The org is active
|
|
|
|
|
|
|
|
We should:
|
|
|
|
|
|
|
|
1. create a new =OrgAccessRequest= object in DB.
|
2022-01-17 13:58:26 +00:00
|
|
|
2. Send emails (see the [[*Email Notification of Org Request Accesses]] section)
|
2022-01-17 11:17:03 +00:00
|
|
|
|
|
|
|
**** Hide Org
|
|
|
|
|
2022-01-17 11:18:21 +00:00
|
|
|
#+begin_src http
|
|
|
|
POST /iroh/registration/hide-org/:org-id
|
|
|
|
|
|
|
|
Accept: application/json
|
|
|
|
Content-Type: application/json
|
|
|
|
User-Agent: ob-http
|
|
|
|
Authorization: Bearer ${user-identity-jwt}
|
2022-01-17 11:17:03 +00:00
|
|
|
#+end_src
|
|
|
|
|
|
|
|
Should save in the user identity store a new org-id to hide.
|
|
|
|
This impacts the call to `matching-orgs` such that orgs marked as hidden
|
|
|
|
should not be displayed when calling the `matching-org` route.
|
|
|
|
|
2022-01-17 13:35:54 +00:00
|
|
|
**** List Matching Accounts
|
2022-01-17 13:37:07 +00:00
|
|
|
|
2022-01-17 13:38:28 +00:00
|
|
|
#+begin_src http
|
|
|
|
GET /iroh/registration/matching-accounts
|
2022-01-17 13:40:16 +00:00
|
|
|
|
|
|
|
Accept: application/json
|
|
|
|
Content-Type: application/json
|
|
|
|
User-Agent: ob-http
|
|
|
|
Authorization: Bearer ${user-identity-jwt}
|
2022-01-17 13:38:28 +00:00
|
|
|
#+end_src
|
2022-01-17 13:40:16 +00:00
|
|
|
|
2022-01-17 13:44:35 +00:00
|
|
|
It should return a list of object with the following schema sorted by last
|
|
|
|
logged in time by the user:
|
|
|
|
|
2022-01-17 13:43:27 +00:00
|
|
|
#+begin_src clojure
|
|
|
|
{:user User
|
|
|
|
:org Org
|
|
|
|
:last-login-date DateTime
|
|
|
|
:relative-last-login s/Str
|
|
|
|
:org-created-at DateTime
|
|
|
|
:relative-org-created-at s/Str
|
|
|
|
:activated? s/Bool
|
|
|
|
:org-nb-users s/Int}
|
2022-01-17 13:40:16 +00:00
|
|
|
#+end_src
|
|
|
|
|
2022-01-17 13:35:54 +00:00
|
|
|
**** List Matching Orgs
|
2022-01-17 13:38:28 +00:00
|
|
|
#+begin_src http
|
|
|
|
GET /iroh/registration/matching-orgs
|
|
|
|
#+end_src
|
2022-01-17 13:44:35 +00:00
|
|
|
|
|
|
|
Should return a list of objects with the following schema (sort to be defined):
|
|
|
|
|
|
|
|
#+begin_src clojure
|
2022-01-17 13:46:33 +00:00
|
|
|
{:org Org
|
|
|
|
:org-nb-users s/Int}
|
2022-01-17 13:44:35 +00:00
|
|
|
#+end_src
|
|
|
|
|
2022-01-17 13:35:54 +00:00
|
|
|
**** List Pending Invites
|
2022-01-17 13:38:28 +00:00
|
|
|
#+begin_src http
|
|
|
|
GET /iroh/registration/pending-invites
|
|
|
|
#+end_src
|
2022-01-17 13:47:42 +00:00
|
|
|
|
2022-01-17 13:49:01 +00:00
|
|
|
Here is an example value:
|
|
|
|
|
|
|
|
#+begin_src clojure
|
|
|
|
{:role "admin",
|
|
|
|
:org-id "org-1",
|
|
|
|
:expires-in-nb-days 7,
|
|
|
|
:status "pending",
|
|
|
|
:invitee-email "chuck@example.org",
|
|
|
|
:inviter-user-id "org-1-admin-1"}
|
|
|
|
#+end_src
|
|
|
|
|
2022-01-17 13:37:07 +00:00
|
|
|
**** Registration View
|
|
|
|
GET /iroh/registration/registration-view
|
|
|
|
|
|
|
|
Should return the same result as the union of the calls to
|
|
|
|
=matching-accounts=, =matching-orgs= and =pending-invites=.
|
2022-01-17 11:17:03 +00:00
|
|
|
|
2022-01-17 13:38:28 +00:00
|
|
|
#+begin_src clojure
|
|
|
|
{:matching-accounts [,,,]
|
|
|
|
:matching-orgs [,,,]
|
|
|
|
:pending-invites [,,,]}
|
|
|
|
#+end_src
|
2022-01-17 14:10:08 +00:00
|
|
|
*** New IROH-Auth login process.
|
2022-01-17 13:38:28 +00:00
|
|
|
|
2022-01-17 14:10:08 +00:00
|
|
|
Every-time a users successfully login via an IdP we should synchronize the
|
|
|
|
=UserIdentity= value in our DB accordingly.
|
|
|
|
It should occurs not only during the account registration, but also for
|
|
|
|
every new login.
|
2022-01-17 10:33:46 +00:00
|
|
|
|
2021-12-07 15:16:47 +00:00
|
|
|
** Email Notification of Org Request Accesses
|
|
|
|
|
2021-12-16 14:48:40 +00:00
|
|
|
/Estimate: 4 release cycle after email+html templates/
|
2021-12-15 15:26:24 +00:00
|
|
|
|
2021-12-07 15:18:13 +00:00
|
|
|
1. List all the admins of the requested org.
|
2021-12-07 15:19:17 +00:00
|
|
|
2.a. If there is fewer admins than a number that could be configured in the
|
|
|
|
node configuration. Then we send an email to all admins.
|
|
|
|
2.b. If there are more admins than this specific number, then we randomly
|
|
|
|
chose this maximal number of admins and send them an email notification.
|
2021-12-07 15:16:47 +00:00
|
|
|
|
2021-12-15 15:28:15 +00:00
|
|
|
|
|
|
|
|
2021-12-07 15:21:46 +00:00
|
|
|
*TODO* Have an email template (both HTML and Text)
|
2021-12-15 15:28:15 +00:00
|
|
|
*** Notes
|
|
|
|
|
|
|
|
Need to be able to trigger a new request to join after 7 days.
|
2021-12-07 15:21:46 +00:00
|
|
|
|
2021-12-07 15:19:17 +00:00
|
|
|
** Org Requests CRUD API for Admins of the Orgs
|
2021-12-07 14:30:29 +00:00
|
|
|
|
2021-12-16 14:49:49 +00:00
|
|
|
/Estimate: 3 release cycle after mail templates + text/
|
2021-12-16 14:48:40 +00:00
|
|
|
|
2021-12-07 14:38:46 +00:00
|
|
|
There should be a CRUD API restricted to the ~admin/user-mgmt/org-requests~ scope:
|
|
|
|
|
|
|
|
- ~GET /iroh/user-mgmt/org-requests~ list pending org access requests
|
|
|
|
- ~GET /iroh/user-mgmt/org-requests/<id>~ read a single org access request
|
|
|
|
- ~POST /iroh/user-mgmt/org-requests/<id>/accept~ Grant the access
|
|
|
|
- ~POST /iroh/user-mgmt/org-requests/<id>/reject~ Reject the access
|
2021-12-07 14:30:29 +00:00
|
|
|
|
2021-12-07 14:42:50 +00:00
|
|
|
*** List
|
|
|
|
|
2021-12-07 14:44:24 +00:00
|
|
|
~GET /iroh/user-mgmt/org-requests~
|
|
|
|
|
2021-12-07 14:56:39 +00:00
|
|
|
If no parameter is provided, only list pending =OrgAccessRequests= of the org
|
|
|
|
of the caller.
|
|
|
|
Otherwise we could pass the query-parameter =status= with the following
|
|
|
|
value(s):
|
2021-12-07 14:45:38 +00:00
|
|
|
|
|
|
|
- =pending=
|
|
|
|
- =accepted=
|
|
|
|
- =rejected=
|
2021-12-07 14:44:24 +00:00
|
|
|
|
2021-12-07 14:47:09 +00:00
|
|
|
Note we should probably support duplicate statuses.
|
|
|
|
Ex:
|
|
|
|
|
2021-12-07 14:48:14 +00:00
|
|
|
~GET /iroh/user-mgmt/org-requests?status=accepted&status=pending~
|
|
|
|
|
|
|
|
*** Read
|
|
|
|
|
|
|
|
~GET /iroh/user-mgmt/org-requests/org-request-id~
|
|
|
|
|
|
|
|
Should returns a 404 if not found or the single Org Access Request object.
|
2021-12-07 14:47:09 +00:00
|
|
|
|
2021-12-07 14:52:03 +00:00
|
|
|
*** Accept the Org Access
|
|
|
|
|
|
|
|
~POST /iroh/user-mgmt/org-requests/<id>/accept~ Grant the access
|
|
|
|
|
2021-12-07 14:53:58 +00:00
|
|
|
The body should contain the role (either =admin= or =user=) with the following schema:
|
|
|
|
|
|
|
|
#+begin_src js
|
|
|
|
{"role":"admin"}
|
|
|
|
#+end_src
|
|
|
|
|
2021-12-07 14:52:03 +00:00
|
|
|
During the call, should:
|
|
|
|
|
|
|
|
1. Create a new user with:
|
|
|
|
|
|
|
|
#+begin_src clojure
|
|
|
|
{:user-id (gen-uuid)
|
2021-12-07 14:56:39 +00:00
|
|
|
:org-id (:org-id org-access-request)
|
2021-12-07 14:52:03 +00:00
|
|
|
:user-email (:user-email org-access-request)
|
|
|
|
:idp-mappings [(:idp-mapping org-access-request)]
|
|
|
|
:user-name (:user-name org-access-request)
|
|
|
|
:user-nick (:user-nick org-access-request)
|
2021-12-07 14:53:58 +00:00
|
|
|
:role (get-in request [:body :role])
|
|
|
|
:enabled? true
|
2021-12-07 14:52:03 +00:00
|
|
|
}
|
|
|
|
#+end_src
|
|
|
|
|
2021-12-07 15:20:31 +00:00
|
|
|
2. Send an email to user confirming his access was granted.
|
|
|
|
|
2021-12-07 15:35:21 +00:00
|
|
|
*TODO* have an email template + text.
|
2021-12-07 15:21:46 +00:00
|
|
|
|
2021-12-07 15:25:50 +00:00
|
|
|
*** Reject the Org Access
|
|
|
|
|
|
|
|
~POST /iroh/user-mgmt/org-requests/<id>/reject~ Reject the access
|
|
|
|
|
2021-12-07 15:33:02 +00:00
|
|
|
This call should update the =OrgAccessRequest= object by patching with:
|
2021-12-07 15:25:50 +00:00
|
|
|
|
2021-12-07 15:34:15 +00:00
|
|
|
#+begin_src clojure
|
|
|
|
{:udpated-at (now)
|
|
|
|
:approver-id (get-in req [:identity :user :id])
|
|
|
|
:approver-email (get-in req [:identity :user :email])
|
2021-12-07 15:35:21 +00:00
|
|
|
:status :rejected}
|
2021-12-07 15:34:15 +00:00
|
|
|
#+end_src
|
|
|
|
|
2021-12-07 15:33:02 +00:00
|
|
|
Then send an email to user confirming his access was denied.
|
2021-12-07 15:25:50 +00:00
|
|
|
|
2021-12-07 15:35:21 +00:00
|
|
|
*TODO* have an email template + text.
|