[keycloak-dev] Service accounts - version 1 commited

[Stian Thorgersen]

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

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