Re: [keycloak-dev] Service accounts - version 1 commited

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Wednesday, 22 July, 2015 3:56:18 PM > Subject: Re: [keycloak-dev] Service accounts - version 1 commited > > On 22.7.2015 13:32, Stian Thorgersen wrote: >> A few comments: >> >> * Do we need the ''Service Account' tab? It seems the enable/disable option >> should be on the 'Settings' tab in either case. We already have tab for >> 'Credentials' which is where alternative auth methods should be configured >> (all confidential clients should be able to use alternative auth methods, >> not just those that use service accounts). > Yeah, that seems to be better. I will delete 'Service Account' tab and > put the option to the 'Settings' . The credentials tab won't be changed > for now as there are no more supported authentication mechanisms. >> * I assume currently to set role mappings for the client you'd have to >> somehow find the associated user? That seems a bit cumbersome to me. We >> should at the very least add a link, but even better as it's only role >> mappings we want to configure I think 'service account users' should be >> hidden from regular users lists and instead we should have a role mappings >> tab on the client. > I can add the tab for role mappings, which will point to role mappings > of the linked user. I agree that will be much better regarding usability. > > But for hiding the 'service account user' from the user list, it will > require changes in the search model methods (like > UserProvider.searchForUser + maybe > UserProvider.searchForUserByAttributes ). Do you want me to go that way? Rather than adding an attribute would it be better to add a flag directly on UserModel/Entity?

> One additional question, does it makes sense to save the 'service > account user' into federation when it's enabled for the realm? For me, > rather not, so I can use "session.userStorage()" directly to save this > user. Thinking if someone may want to have service account saved in LDAP > including his role mappings, but it's probably just hypothetical usecase... I'd lean towards not saving in federation at first, then we consider adding if requested. > Marek >> ----- Original Message ----- >>> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Wednesday, 22 July, 2015 11:41:34 AM >>> Subject: [keycloak-dev] Service accounts - version 1 commited >>> >>> Few points to how it works now: >>> >>> - There is new boolean flag setServiceAccountsEnabled on ClientModel. >>> That's the only model change >>> >>> - There is new tab "Service accounts" for confidential clients in admin >>> console . Right now, service account authentication is available just >>> for confidential clients, not bearer-only or public clients. The tab >>> contains just one on/off switch for enable/disable service account >>> authentication support. It's disabled by default. I think for the next >>> release we can add the table with Authentication mechanisms for clients, >>> so admin can choose for example that Client Credentials Grant is >>> "DISABLED" and Certificate authentication is "ALTERNATIVE" etc. Right >>> now, the client authentication is available just through OAuth2 Client >>> Credentials Grant (authentication with clientId + client secret) >>> >>> - When service account enabled for client "foo", new user >>> "service-account-foo" is created . I've added the "service-account-" >>> prefix just to make more visible that this is not normal user, but user >>> dedicated to service account. The user has also attribute with client DB >>> ID (It's really DB ID, not clientId) and the binding between client and >>> user is through this attribute. Hence when admin renames clientId of >>> this client or renames the username of service account user, the binding >>> still works. The roles available to this user are used in the token >>> dedicated to service account. >>> >>> - The existing TokenEndpoint is reused for service account >>> authentication. Just new grantType "client_credentials" is added as per >>> OAuth2 specs. >>> >>> - The token retrieved through service account has few additional >>> attributes available in otherClaims(). Those are added by protocol >>> mappers, which are created when service account authentication is >>> enabled. Right now, it's just clientID, clientHost and client address >>> (host and address are retrieved dynamically from ClientConnection used >>> during auth request to TokenEndpoint). Should we have more info >>> available in service account access token? >>> >>> - Sample app "service-account-example" added to the demo >>> >>> - Only missing piece for the 1.4 release seems to be docs unless you >>> have additional feedback. >>> >>> WDYT? >>> >>> Marek >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >