[almighty] User/Login model refactoring

[Pete Muir]

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;
    url?: string;
    emails?: string[];
    primaryEmail?: string;
    notificationEmail?: string;
    publicEmail?: string;
    primaryEmailPrivate?: boolean;
    emailPreference?: string;
    notificationMethods?: string[];
}

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

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/
> 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 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/20170127/96424711/attachment.htm>