[keycloak-dev] Service accounts - version 1 commited

Stian Thorgersen stian at redhat.com
Wed Jul 22 07:32:06 EDT 2015

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

----- 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.
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

More information about the keycloak-dev mailing list