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

Wed May 18 15:20:44 EDT 2016

Hoping to get us into production first... which is more an institutional
issue than a technical one right now.

On Tue, May 17, 2016, at 10:23 AM, Bill Burke wrote:
> 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> 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
>>
>>
>>
>> _______________________________________________ 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 - The professional email service

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160518/196f113d/attachment-0001.html 