-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, As part of a task for another project that could benefit from having multi tenancy support in Keycloak, I scratched a proposal for this feature and sent it as a PR (it's now on the 'multi-tenant-adapter' branch). In my view, multi tenancy is defined as "a way to determine the realm of an application based on the incoming request". So, a single application is deployed to a single application server, but the users could belong to different realms, depending on the hostname, or an HTTP header, or path, ... This is a typical SaaS scenario. There's already a good "multi tenant" support at the server level, in the form of a realm, so, I haven't bothered much in checking if it would make sense to add this kind of support on the server (ie: a "tenants" property in a realm). The commit [1] adds a new abstract class, KeycloakConfigResolver, that is meant to be extended by an application developer and builds a KeycloakDeployment. If an application (war) contains the context parameter "keycloak.config.resolver" and points to a class existing on the deployed WAR, it uses that on the AdapterDeploymentContext. On each incoming request, this resolver is used to build a KeycloakDeployment, used during the actual authentication/authorization, not changed by this commit except for adding the HttpFacade.Request in some places. When doing a rebase this morning to send the PR, I got a few conflicts due to the clustering support. I don't know the implications of that yet, as I'm not familiar with the clustering support, but I think a proper final solution is to split KeycloakDeployment , so that information about the target Keycloak server is stored in a different place than the realm information. I have tested this with a custom application, available at [2]. It was tested with a Keycloak 1.0.1.Final server and with the custom adapters deployed on Wildfly 8.1.0.Final and seem to work fine. What I'm particularly interested in knowing is: - - Is this the right direction to implement this feature? I have mixed feelings about doing this at the "AdapterDeploymentContext" level (mixed, but more on the positive side). - - Should I refactor KeycloakDeployment , to split the server from the realm information? 1 - https://github.com/keycloak/keycloak/commit/37a48d49e10798d10f4509848c04e... 2 - https://github.com/jpkrohling/keycloak-tenants-poc Best, Juca. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/21/2014 02:45 PM, Stan Silvert wrote: > I don't know if this helps your use case, but you will soon be able > to deploy more than one Keycloak Auth Server in the same WildFly > instance. Each server will have a different web context and be > completely independent. > > So you would have something like: > http://localhost:8080/authserverone/admin/index.html > http://localhost:8080/authservertwo/admin/index.html > > In standalone.xml, you will have: <subsystem > xmlns="urn:jboss:domain:keycloak:1.0"> <auth-server > name="authserverone"> <enabled>true</enabled> > <web-context>authserverone</web-context> </auth-server> > <auth-server name="authservertwo"> <enabled>true</enabled> > <web-context>authservertwo</web-context> </auth-server> > </subsystem> > > You will also need to associate each one with a different > datasource using keycloak-server.json. That sounds like an interesting scenario, but won't help on this case, as the users would register an account themselves. So, either we would need to provision Keycloak servers on demand, or we would use one realm per account, which is the approach I was thinking. - - Juca. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 10/21/2014 5:26 PM, Bill Burke wrote: > Would be cool if you added a unit test and documentation for this > feature. If you need some help with that, let me know. I'll definitely be writing doco for this and the rest of the subsystem changes. I will let you know if I need help with unit tests. > > On 10/21/2014 9:43 AM, Juraci Paixão Kröhling wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 10/21/2014 02:45 PM, Stan Silvert wrote: >>> I don't know if this helps your use case, but you will soon be able >>> to deploy more than one Keycloak Auth Server in the same WildFly >>> instance. Each server will have a different web context and be >>> completely independent. >>> >>> So you would have something like: >>> http://localhost:8080/authserverone/admin/index.html >>> http://localhost:8080/authservertwo/admin/index.html >>> >>> In standalone.xml, you will have: <subsystem >>> xmlns="urn:jboss:domain:keycloak:1.0"> <auth-server >>> name="authserverone"> <enabled>true</enabled> >>> <web-context>authserverone</web-context> </auth-server> >>> <auth-server name="authservertwo"> <enabled>true</enabled> >>> <web-context>authservertwo</web-context> </auth-server> >>> </subsystem> >>> >>> You will also need to associate each one with a different >>> datasource using keycloak-server.json. >> That sounds like an interesting scenario, but won't help on this case, >> as the users would register an account themselves. So, either we would >> need to provision Keycloak servers on demand, or we would use one >> realm per account, which is the approach I was thinking. >> >> - - Juca. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Would be cool if you added a unit test and documentation for this feature. If you need some help with that, let me know.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUR+mJAAoJEDnJtskdmzLM2IkIAKn/My0zyKTCe6aElFRXER83 T+vCsEHEgNUN+emPp7LigvOU3l/V1jInEbSVnQwQKDoDQm4R79SXGSQBiFa4DLFJ 1lHN/kIQI3DG+B0+CyUlq3pyHOTcpLc+FqFfV5RyBYuhH+JYH82v0FZia98wCMLF XVBbw3jesMTOiQvHnWXq4qYCDh1zKVs+rv6BpKLp8s3ikC4hEtwjoPrm5/KYQoJI LagFEhq/kQ1KQH/aQDn3qrVwPcvel4vSU1KbO2z/mE9+YdH80PY/nLwykZK4QX7J wi76NjpZjB2+b3GhnxE3mfxRgeHwEpe04jUYxF8aPY3zsM4auGB958wQJ9W6Dus= =s4Lp -----END PGP SIGNATURE-----

> Actually isn't problem in scopes? The client application, which > you are using to access KC should be in scopes for those > "view-applications" or "manage-applications" roles. Admin console > is using application "Security-admin-console", which has scope to > realm role "admin" so it has defacto scope to everything. Maybe > you can also use this scope or use "Full scope allowed" switch > for your app.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUSL9uAAoJEDnJtskdmzLM04MIAJ2eMtlKJ471hlx78aEC21eh z36j8xbwlC9QjNnlA505vIg5L8ZGNui9r+itH661rdR4GdVEdGepCWLiXdVlkHBf gzdboMvlNeocW+PxyBIm2FMS2c3tJ25S2kQ+8bOcQcoshs0QMpyeZ8ydgvXysXsG t696OoSEJ1B97R3d6Wos565ardVcoDDiPq32dpcsEDIV2vK7P3S98OEB/xr6kIja kNqc3b0YpLCV//CuId9hKYVSmv/sxZXHmnvi1ICIdyjb4jiQ4lixUZf7KCIf0O9P Y+PLHqZqPV1Qqj6H+gH2MNxYRGEyCsJeGsgEyXHv8g22e5dj0PQblTiDL2OdWFg= =jSg0 -----END PGP SIGNATURE-----