[keycloak-dev] Refactoring Model

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 27 February, 2014 2:34:41 PM
> Subject: Re: [keycloak-dev] Refactoring Model
> 
> 
> 
> On 2/27/2014 4:45 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 27 February, 2014 3:08:13 AM
> >> Subject: Re: [keycloak-dev] Refactoring Model
> >>
> >> Ok, I did the first phase of this.  Most code is now dealing with
> >> ClientModel rather than UserModel in the TokenService, et. al.
> >>
> >> I hope nobody is working on anything major :) I'm just trying to avoid
> >> duplicating a lot of code.  I"d also like to eventually not use a User
> >> to model any type of client as I'm worried about username clashes and
> >> such.
> >
> > +1 Assuming you're talking about getting rid of ClientModel.get/setAgent
> > and just pulling all required fields from UserModel into ClientModel. It
> > would also be nice to remove the "special" roles we have
> > (KEYCLOAK_APPLICATION and KEYCLOAK_IDENTITY_REQUESTER).
> >
> 
> I'll do a 2nd rev of this refactoring today and get rid of the
> ClientModel.agent and special roles too.
> 
> > One idea I had was to rename ApplicationModel to ResourceModel. A resource
> > would only have name and roles. No web-origins, redirect-uris, secret or
> > scope mapping. Then we'd add an option to ClientModel to automatically
> > grant access instead. I think that makes the distinction clearer.
> > Basically if your modelling something that is accessed through roles, you
> > create a resource. If you're modelling something that wants to login users
> > you create a client. And as some clients would be "internal" they have the
> > option of automatically being granted permissions.
> >
> 
> I like that for an implementation detail at least.  Not sure about
> propagating that idea to the admin console though.
> 
> Applications have always been special in that they don't require an
> oauth grant page, can be administered, you can log out of them, and
> eventually we'll have screens for session management and stuff and
> things like that for them.  For clustering, at least for Wildfly/JBoss,
> I don't even think it makes sense to have the idea of a "deployment" as
> I believe cluster nodes would get the same configuration from the domain
> controller (client_id, secret, etc.).  What we can do for a cluster is
> make Admin URl a Set<URI> maybe even the same with Redirect URI.

Didn't think of all that. Needs some rethinking. I still think it would be nice to have something to represent resources. For example the database service from the example, and the realm-admin apps. It doesn't make sense that they have credentials, redirect-uris and scopes. They will never request a login, only parse bearer tokens.

> 
> I do think I want to rename OAuth Client to Client though.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>