From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)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.

On 2/26/2014 7:43 PM, Bill Burke wrote: > I'm refactoring ApplicationModel and OAuthClientModel to inherit from > the same interface, ClientModel. I'm moving all the app/client specific > attributes out of UserModel and into ClientModel. > > I also want the TokenService to be dealing with ClientModel instead of > putzing around with UserModels and figuring out if they are apps or not. > right now, if you change an application name it can screw up > everything when generating a token. > > So, expect some changes in this area this week. > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)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(a)redhat.com&gt; >> To: keycloak-dev(a)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.

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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)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(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>> To: keycloak-dev(a)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.

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