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

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(a)xsmail.com&gt; 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(a)atos.net&gt; 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

>>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> -- >>> Henryk Konsek >>> https://linkedin.com/in/hekonsek >>> >>> >>> _______________________________________________ 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 - Or how I learned to stop worrying and > love email again > > > > _______________________________________________ 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