We're pleased to announce the release of Keycloak 1.6.0.Final. * *SAML SP* - in the past we only had client libraries for OpenID Connect, now we also have client libraries for SAML * *Offline Tokens* - if your applications need long term access outside of the users session you should take a look at the new offline tokens support we've added * *Client Registration* - we introduced a new rest api that can be used to automate the registration of clients, this includes a java client library. This feature will be further polished in a future release, including documentation and examples * *Import Clients in Admin Console* - it's now possible to import clients through the admin console using the Keycloak JSON client representation or OpenID Connect descriptions * *Added Root URL to Clients* - we've added a root url to clients. For clients that have a root url defined you can use relative urls for redirect uris and other urls * *Internationalization support in Admin Console* - we've added support for internationalization of the Admin Console. Around half the pages now support translation and the rest will be added in the next release For the full list of issues resolved check out JIRA <https://issues.jboss.org/issues/?jql=project%20%3D%2012313920%20AND%20fix... and to download the release go to the Keycloak homepage <http://keycloak.org/downloads>;. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Thank you for the release! The new features sound really useful. One question regarding client registration: Can you see any problems if the number of clients grow, for example to thousands or tens of thousands? Best regards, Thomas On Oct 20, 2015 17:53, "Stian Thorgersen" <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: We're pleased to announce the release of Keycloak 1.6.0.Final. * *SAML SP* - in the past we only had client libraries for OpenID Connect, now we also have client libraries for SAML * *Offline Tokens* - if your applications need long term access outside of the users session you should take a look at the new offline tokens support we've added * *Client Registration* - we introduced a new rest api that can be used to automate the registration of clients, this includes a java client library. This feature will be further polished in a future release, including documentation and examples * *Import Clients in Admin Console* - it's now possible to import clients through the admin console using the Keycloak JSON client representation or OpenID Connect descriptions * *Added Root URL to Clients* - we've added a root url to clients. For clients that have a root url defined you can use relative urls for redirect uris and other urls * *Internationalization support in Admin Console* - we've added support for internationalization of the Admin Console. Around half the pages now support translation and the rest will be added in the next release For the full list of issues resolved check out JIRA <https://issues.jboss.org/issues/?jql=project%20%3D%2012313920%20AND%20fix... and to download the release go to the Keycloak homepage <http://keycloak.org/downloads>;. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

On Tue, Oct 20, 2015 at 8:20 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > Thousands should be no problem at all. Tens of thousands should be ok, > but we'd have to test that. I guess you're building a public api or > something since you're expecting that many clients? > I have been thinking of various ways to utilize Keycloak in a SaaS application. A separate realm per tenant is probably the most natural option, but how about using a single realm with individual clients for each tenant, would that make any sense? I think it would have its advantages (eg. the SaaS service provider could use a single account to access any tenant, and tenants could register themselves as clients when being deployed?). Best regards, Thomas

On Wed, Oct 21, 2015 at 3:46 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > I think the first question to ask is do you want to share users and > config between tenants? If you do you should have a single realm, if not > you should have separate realms. > Sharing users and config between tenants sure could be useful, but I'm wondering how to enable tenants to manage access to their instance. I wonder if the new group management would provide support for this? Best regards, Thomas

Here i have a similar requirement for a saas application. Need to have a single login form for all users and when the user logs in, i have to descide to which tenant (and server) a user belongs. Then i do a redirect to the right server / tenant. It's the same way most saas applications works (one login screen, then you get redirected to the right server / application). If we want to have one single login form for all tenants, then we can only have the users in the same realm i think, because you must be sure that all the users are unique. But we also need a way to let a user log in into several tenants with the same user. For that i plan to add a role for every tenant. If a user has several such roles, he must choose to which tenant he wants to connect. The application makes sure only a user with the correct role can use a tenant. Maybe there is a better way to solve that? The best way to solve it would be to allow a user to be in more than one realm and support a way to test in which realms a user is. Then we can login the user and test the realm(s). But i think that wouldn't be possible because the hole design is different. Maybe a "super realm" is possible that is a container for such users?