[keycloak-dev] Service accounts - version 1 commited

[Marek Posolda]

On 22.7.2015 16:21, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at 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?
I wanted to avoid that to minimize model changes :-)

But maybe it's best option... Anyway, the UserProvider.searchForUser 
will be changed to not include users with this flag (or attribute) true. 
Is it ok?

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