[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: Friday, 28 February, 2014 2:15:53 PM
> Subject: Re: [keycloak-dev] Refactoring Model
> 
> 
> 
> On 2/27/2014 11:45 AM, Stian Thorgersen wrote:
> >
> >
> > ----- 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.
> >
> 
> Currently, the database service doesn't need any registration in the
> admin console (and isn't registered in the admin console).  All it is
> doing is verifying tokens so all it needs is the public key of the
> realm.  In the future, the only reason to register it with the admin
> console is to provide an admin URL so the keycloak server can push
> revocation policies or get access stats.

Yes, but that's because it uses realm roles instead of roles associated with the database service. If you want to have roles specific to a service you need to create an app to represent it so you can setup role/scope mappings

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>