[keycloak-dev] Service accounts - version 1 commited

[Marek Posolda]

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?

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...

Marek
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>