8:56 a.m.
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(a)redhat.com>
> 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
>