[almighty] User/Login model refactoring

[Pete Muir]

On 27 Jan 2017 10:23 pm, "Alexey Kazakov" <alkazako at redhat.com> wrote:

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.


It's only optional in the UI as we are currently not getting it in the
payload we get from KC and have to stub it out. If we get the username from
KC, it will change to required. Immutable is fine.



    url?: string;
    emails?: string[];
    primaryEmail?: string;


This one also shouldn't be optional, we are just missing it from KC right
now.

    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.


Yes some like notification method definitely don't need to go in the token,
so I agree with your design. When you are ready let us know the calls to
make and we can wire up the UI.

Another question. Do you expect your developers.redhat.com account
updated/changed if you edit your profile in fabric8 ui?


That was the design from Todd, but I don't feel it is MVP, so of we can
just provide a read only view and a link to d.r.c to update it, I think
that will work. Do you know the URL for this? If so, could you file a
fabric8-ui issue for the fields that will be read only and the URL, and eg
Mitch or I can update  the 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.


Sounds good. We are mocking all of this in the UI right now, so we are not
blocking on this. Username and email access is the top priority in the UI,
as those are quite fundamental, and mean we have hacks to make stuff work
(look up user account using full name ;-).


Thanks.



On 27 January 2017 at 07:36, 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/al
> mighty-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 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
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20170129/db1e0333/attachment.htm>