[keycloak-user] Keycloak as ID provider for large amount of devices

Tue May 17 09:53:55 EDT 2016

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> 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> 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
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>> _________________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> --
>>> Aikeaguinea
>>> 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
>>> 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
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _________________________________________________
> keycloak-user mailing list
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/df850d14/attachment.html 