[almighty] User/Login model refactoring

[Alexey Kazakov]

On Fri, Jan 27, 2017 at 12:06 AM Shoubhik Bose <shbose at redhat.com> wrote:

> On Fri, Jan 27, 2017 at 1:06 PM, Alexey Kazakov <alkazako at redhat.com>
> wrote:
>
> Hi all,
>
> After some discussion with Aslak and Max I would lit to share proposal of
> User/login model update in almighty-core as part of our move to Keycloak
> auth. I'm copying this from
> https://github.com/almighty/almighty-core/issues/672 (Use keycloak tokens
> instead of generating our own ones when serving client auth requests).
>
> *What we currently have in our model:*
>
> *Identity* (represents a user)
>
>     - uuid (generated automatically) - This uuid is used as "creator" and
> "assignee" in our payloads and it's also stored in the JWT token we
> generate after authentication.
>     - fullName (human name - string)
>     - avatarImage (URL string)
>     - users []User (list of associated users, each user just represents a
> email)
>
> *User*
>
>     - uuid (generated automatically)
>     - email (just a string)
>     - identity-uuid (Identity association)
>
> *Proposed model:*
>
> *User* (represents a user account in our system)
>
>     - uuid (generated automatically) - Our internal user ID. Used for
> associations with Logins
>     - fullName (human name - string)
>     - avatarImage (URL string)
>     - logins []Login (list of associated logins)
>
> *Login* I actually don't like this name. Can we call it *Identity
> Provider User* or somewhat else to avoid confusions? This is a
> representation of user provided by some particular Identity Provider such
> as: a) Our Keycloak; b) GitHub (for remote WI's); c) JIRA (for remote
> WI's), etc.
>
>     - uuid - Generated automatically for remote WI but in case of KC the
> uuid from the KC user is used. This uuid is used as "creator" and
> "assignee" in our payloads and it's also represented in the KC token we
> retrieve from KC during authentication. So, our token is always associated
> with a Login.
>     - username (string) - Username used by corresponding IDP. It's not
> unique in our system (it's supposed to be unique for the particular IDP
> though).
>     - email (string)
>     - idp (string) - Some IDP key/ID which will indicate from what IDP we
> got this Login. Possible values: "keycloak", "github", "jira", etc.
>
>
> I see a deviation from the previous model where we stored *identity-uuid *in
> the (old)*User* model.I guess the deviation is because for remote
> workitems , we only have the "Login" and not the (new model) User.
>

Oops, I forgot to add a user-uuid field to Login. We will need this field
for User-Login associations. But this field is optional. Keycloak logins
are always associated with a User. Remote WIs may not.



>
>
>
> When a user is logging in we authenticate in our Keycloak (which uses
> developers.redhat.com as the default IDP). A new Login is created. We use
> uuid of the Keycloak user. idp="keycloak". We also create a User and
> associate these User - Login. We return the retrieved Keycloak token which
> will be used by UI for authentication. So there is a strong assassination
> between a token and a keyclaok Login.
>
>
> This sounds good.
>
>
> When we import a remote WI (from JIRA, github, etc) we create a Login
> which is not associated with any User yet. Open question: how we associate
> remote WI's (imported from github, etc) with User. We would need some
> manual workflow for that.
>
>
>
> When we import remote workitems from github, are we going to leave the
> 'email' field blank/null in *Login* ?
>
> One complex way to get user email information in case of github is that
> the API response for a GH issue
>
> - https://api.github.com/repos/almighty/almighty-core/issues/133
> has the user endpoints.
>
> - the creator/assignee api url is found in the response as
> https://api.github.com/users/aslakknutsen which further provides the
> email address,full name,etc
>
> - use this email address to associate a *Login *with a *User . *Drawback
> of this is that github allows addition of multiple email addresses which
> the GH API wouldn't expose.
>
>
>
> *Another way *is to use the github user url to uniquely identify a *Login*
>  So the combo of an [ idp "github" + gh user url ] is always going to be
> unique in the *Login *table. This could lead to using user urls instead
> of email for all IDPs ?
>
>
>
> This update will requre a massive refactoring in almighty-core (and ui
> probably too) :-(
>
> Any thoughts?
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20170127/f9a41cbb/attachment.htm>