[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 4:30:17 PM
> Subject: Re: [keycloak-dev] Service accounts - version 1 commited
> 
> 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?

+1

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