This is disappointing news, as when I asked this same question back in
January the answer was that the intention is to have Keycloak scale to
hundreds if not thousands of clients, and if there were issues you'd
work with us on that.
There's more to this issue than having a custom authenticator; the
client interface allows you to click one button and generate the jks
file containing the client's private key. We would need this not only
for the first time a device is set up, but for key rotation on an
ongoing basis.
Are there ways to plug into the user management interface to allow
generation of non-username/password credentials for a user?
On Fri, May 13, 2016, at 02:11 AM, Stian Thorgersen wrote:
Hi,
That's a very interesting use-case. One which we have wanted to look
into ourselves, but haven't had the resources. Ideally I'd say we'd
have a device concept in Keycloak as they're not strictly clients or
users. They'd most likely be backed by users, but would have different
screens for configuration and would have separate authentication
flows. That would require a fair bit of work to add though.
In the mean time I don't think clients are a good fit as Keycloak is
not currently designed to have large amounts of clients, both for
manageability and performance. Both of the issues can be overcome
fairly easily, but that would require some work.
The best solution in my opinion is to use users and implement your own
custom authenticator to handle IOT devices. It's fairly simply to do
and gives you the ability to handle authentication of the devices
exactly how you want to. See
http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html
for more details.
I'd appreciate if you kept me updated on your progress as I'm very
interested :)
On 12 May 2016 at 10:29, Matuszak, Eduard
<eduard.matuszak(a)atos.net> wrote:
>
> Hello
>
> We are planning to get a lot of devices, identifyable by individual
> certificates, into an IOT-system being designed and developed at the
> moment. We choosed to authenticate all actors (users, software
> components and devices as well) by OIDC-tokens and (pre)decided to
> use Keycloak as ID provider. User and software components are quite
> straightforward to handle with Keycloak (as Keycloak users with the
> help of a user federation provider & id brokerage and for
> applications as Keycloak clients respectively). But I am not sure of
> how to represent our devices (we want to support hundreds of
> thousands of them later on!) by Keycloak means.
>
> It seems that we essentially have 2 possiblities to register a device
> in Keycloak
> * As a user
> * As a client
>
> By representing devices as Keycloak clients we might take advantage
> of the ServiceAccount (Oauth-Client Credential) flow and become able
> to implement it via (dynamic!) registration and it and seems, that we
> will even be able to authenticate our device by their certificates by
> choosing "Signed Jwt" as authenticator option.
>
> My question is, if it would be a good idea to register a very big
> amount of devices as Keycloak clients with regards to performance and
> manageability. In principle I would prefer a user-representation
> (faciliting usage of user federation provider & id brokerage for
> instance), but as far as I understood, the appropriate flow would be
> Direct Access (ResourceOwnerPassword Credentials) and here we can
> only deal with username/password instead of certificates.
>
> Do you have any suggestions or hints (even the conclusion, that
> Keycloak is not the suitable ID-provider-implementation for large-
> scale IOT-systems)?
>
> Best regards, Eduard Matuszak
>
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_________________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Aikeaguinea
aikeaguinea(a)xsmail.com
--
http://www.fastmail.com - Access your email from home and the web