[almighty] User/Login model refactoring

[Alexey Kazakov]

On 01/27/2017 04:07 AM, Pete Muir wrote:
> Related to this, we need some additional info that relates to the 
> users profile in the UI:
>
> This is our UI model.
>
> export class Profile {
>     fullName: string;
>     imageURL: string;
>     bio?: string;
>     username?: string;
Username is optional in UI? Username is required and immutable in 
Keycloak. So, we will have it when user sign in/up via 
developer.redhat.com. And we can't change it.

>     url?: string;
>     emails?: string[];
>     primaryEmail?: string;
>     notificationEmail?: string;
>     publicEmail?: string;
>     primaryEmailPrivate?: boolean;
>     emailPreference?: string;
>     notificationMethods?: string[];
> }
Some of these fields already exist in Keycloak. Some we can/should add 
to either our internal model/DB or directly to our Keycloak as user 
attributes. If we add them as attributes to Keycloak then they will be 
available in the token too. But we probably don't need all of this info 
in the token anyway. So, I think keeping all additional info in our DB 
will be easier.
Another question. Do you expect your developers.redhat.com account 
updated/changed if you edit your profile in fabric8 ui? Full Name or 
Email. It seems to be technically possible but we will probably need to 
communicate with the RHD Keycloak directly to do so. So, I hope this is 
something we can take care of after the summit. WDYT?

>
> Not 100% todo with this thread (as this is their profile, not their 
> login info), but may help you.

This is definitely useful information. Thanks Pete! We will take it into 
account. I would change our user/login model step by step. We can add 
more fields to the model later when we're done with the essential 
login/token changes in the model.

Thanks.

>
> On 27 January 2017 at 07:36, Alexey Kazakov <alkazako at redhat.com 
> <mailto: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
>     <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.
>
>     When a user is logging in we authenticate in our Keycloak (which
>     uses developers.redhat.com <http://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.
>
>     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.
>
>     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 <mailto:almighty-public at redhat.com>
>     https://www.redhat.com/mailman/listinfo/almighty-public
>     <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/93384e92/attachment.htm>