[keycloak-user] Keycloak as ID provider for large amount of devices
Bill Burke
bburke at redhat.com
Tue May 17 10:23:45 EDT 2016
I don't know how much performance would be hurt on logout with a large
number of clients.
Sounds like you have a way to handle things. Maybe blog about it? :)
On 5/17/16 9:53 AM, Aikeaguinea wrote:
> Would only the logout request experience significant delay, or would
> logging out significantly slow down the entire system when there is a
> large number of clients? We can probably work with a long logout time
> per device.
> With regard to key rotation, we're initially planning on using the UI
> to generate new credentials when we need new keys. But couldn't we
> automate this by
> calling /admin/realms/{realm}/clients/{id}/certificates/{attr}/generate-and-download
> ?
> On Mon, May 16, 2016, at 05:19 PM, Bill Burke wrote:
>>
>> I think the only thing that doesn't scale very well as it pertains to
>> number of clients is logout. Logout for OIDC requires a redirect
>> uri. We validate this uri by iterating over every client's register
>> register uri patterns.
>>
>> We don't have any services on key rotation. That's all something
>> you'd have to implement yourself.
>>
>> On 5/16/16 3:37 PM, Henryk Konsek wrote:
>>> IMHO mapping device per use should be fine. KeyCloak scales well
>>> even for hundred of thousands of users, so it will handle gazillion
>>> of devices as well.
>>> Cheers!
>>> pon., 16.05.2016 o 16:29 użytkownik Aikeaguinea
>>> <aikeaguinea at xsmail.com <mailto:aikeaguinea at xsmail.com>> napisał:
>>>
>>> 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 at atos.net <mailto:eduard.matuszak at 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 at lists.jboss.org
>>>> <mailto:keycloak-user at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>> _________________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> <mailto:keycloak-user at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> --
>>> Aikeaguinea
>>> aikeaguinea at xsmail.com <mailto:aikeaguinea at xsmail.com>
>>>
>>>
>>> --
>>> http://www.fastmail.com - Access your email from home and the web
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> --
>>> Henryk Konsek
>>> https://linkedin.com/in/hekonsek
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> _________________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> --
> Aikeaguinea
> aikeaguinea at xsmail.com
> --
> http://www.fastmail.com - Or how I learned to stop worrying and
> love email again
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/c55be82d/attachment-0001.html
More information about the keycloak-user
mailing list