On Dec 31, 2015, at 3:49 AM, Thomas Raehalme <thomas.raehalme(a)aitiofinland.com&gt; wrote: +1 as I have a similar use-case from a customer. > On Thu, Dec 31, 2015 at 10:46 AM, Travis De Silva <traviskds(a)gmail.com&gt; wrote: > Hi, > > My vote is to provide this feature at a client level as per the original request. > > I think realms should be used for completely different domains when we want to isolate users etc. Should not try and use it for something that it was not intended in the design. > > The reason why you might need theming at client level is iif you really think that clients which are essentially different applications most of the time and each of these applications might have different look and feel themes (either due to different development teams or vendors building different applications). > > So when someone logins via KeyCloak, its true that we are logging into a realm but for an end user, it is really logging into a application and there is a need for the login page theme to look similar to the application look and feel. > > Also I have a use case where I have a back office application that requires login for admin users and then I have the front office of this application where in addition to the admin users, you also can have other users as well who can self register and login to the front end which is a consumer facing site. > > How I handle this is by having two clients in the same realm. This works fine if you are happy with the same backend login theme to be there for the consumer facing frontend. But we cannot do that as the front end is a consumer facing SaaS site, so each front end needs to have the client's website theme. This becomes very hard to do if we don't have theming at a client level. > > I came across this post from Bill a few months ago > http://lists.jboss.org/pipermail/keycloak-user/2015-July/002537.html > > I am thinking to make use of the client variable that is available in login.ftl and load different freemarker fragments that will then theme it differently for each client. As mentioned by Bill, having many if conditions might not be ideal but it might meet the requirement. > > Cheers > Travis > > > > > > _______________________________________________ > 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

I strongly disagree. With Keycloak you are logging in to a SSO realm, not an individual application. With that in mind it's important that the login screen reflects that. Users need to know the difference as it's an important distinction. It just doesn't make any sense that I'm logged-in to the SSO with a login screen that is themed to look like the login screen for an individual application. Adding an option on clients to set the theme just doesn't make any sense. If we added the option to create SSO "zones" or disable SSO for individual applications then it would make sense to be able to set theme on a per-zone or apps that doesn't have SSO enabled. On 31 December 2015 at 09:46, Travis De Silva <traviskds(a)gmail.com&gt; wrote: > Hi, > > My vote is to provide this feature at a client level as per the original > request. > > I think realms should be used for completely different domains when we > want to isolate users etc. Should not try and use it for something that it > was not intended in the design. > > The reason why you might need theming at client level is iif you really > think that clients which are essentially different applications most of the > time and each of these applications might have different look and feel > themes (either due to different development teams or vendors building > different applications). > > So when someone logins via KeyCloak, its true that we are logging into a > realm but for an end user, it is really logging into a application and > there is a need for the login page theme to look similar to the application > look and feel. > > Also I have a use case where I have a back office application that > requires login for admin users and then I have the front office of this > application where in addition to the admin users, you also can have other > users as well who can self register and login to the front end which is a > consumer facing site. > > How I handle this is by having two clients in the same realm. This works > fine if you are happy with the same backend login theme to be there for the > consumer facing frontend. But we cannot do that as the front end is a > consumer facing SaaS site, so each front end needs to have the client's > website theme. This becomes very hard to do if we don't have theming at a > client level. > > I came across this post from Bill a few months ago > http://lists.jboss.org/pipermail/keycloak-user/2015-July/002537.html > > I am thinking to make use of the client variable that is available in > login.ftl and load different freemarker fragments that will then theme it > differently for each client. As mentioned by Bill, having many if > conditions might not be ideal but it might meet the requirement. > > Cheers > Travis > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >

HI Stian, Adding SSO zones just to address the theming issue looks a bit overkill to me as it will eventually come down to doing some theming at a level below the realm. I was going on the basis that if theming is not set at a client level, then it will default to the realm level theming which is basically your SSO enabled zone.

Also my other point was with regard to SaaS based applications where we have a backoffice system which is themed as per our SaaS product but the consumer facing front end needs to be themed to be aligned with the customer's web site. In this case, we cannot go with what KeyCloak has at present. What I am doing is as suggested by Bill sometime back, adding "if/else" statements into the freemarker templates and based on the client id loading different freemarker templates which is not ideal but does the job. In any case, since what we are discussing is in general edge cases, Therefore instead of complicating the core KeyCloak platform, why don't you just expose the various links/flows that is currently available in the login process (forgot password/reset credentials, required actions (update password, verify email, configure OTP, etc.), user account mgmt, registration, social login etc. Then we are still using the core of keycloak but for the frontend themes/UI, we use our own. I also haven't explored the Login SPI which as per the KeyCloak docs which says "The Login SPI allows implementing the login forms using whatever web framework or templating engine you want". Wonder if this will give us what we are after.

Cheers Travis On Mon, 4 Jan 2016 at 22:27 Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > I strongly disagree. With Keycloak you are logging in to a SSO realm, not > an individual application. With that in mind it's important that the login > screen reflects that. Users need to know the difference as it's an > important distinction. It just doesn't make any sense that I'm logged-in to > the SSO with a login screen that is themed to look like the login screen > for an individual application. > > Adding an option on clients to set the theme just doesn't make any sense. > If we added the option to create SSO "zones" or disable SSO for individual > applications then it would make sense to be able to set theme on a per-zone > or apps that doesn't have SSO enabled. > > On 31 December 2015 at 09:46, Travis De Silva <traviskds(a)gmail.com&gt; > wrote: > >> Hi, >> >> My vote is to provide this feature at a client level as per the original >> request. >> >> I think realms should be used for completely different domains when we >> want to isolate users etc. Should not try and use it for something that it >> was not intended in the design. >> >> The reason why you might need theming at client level is iif you really >> think that clients which are essentially different applications most of the >> time and each of these applications might have different look and feel >> themes (either due to different development teams or vendors building >> different applications). >> >> So when someone logins via KeyCloak, its true that we are logging into a >> realm but for an end user, it is really logging into a application and >> there is a need for the login page theme to look similar to the application >> look and feel. >> > >> Also I have a use case where I have a back office application that >> requires login for admin users and then I have the front office of this >> application where in addition to the admin users, you also can have other >> users as well who can self register and login to the front end which is a >> consumer facing site. >> >> How I handle this is by having two clients in the same realm. This works >> fine if you are happy with the same backend login theme to be there for the >> consumer facing frontend. But we cannot do that as the front end is a >> consumer facing SaaS site, so each front end needs to have the client's >> website theme. This becomes very hard to do if we don't have theming at a >> client level. >> >> I came across this post from Bill a few months ago >> http://lists.jboss.org/pipermail/keycloak-user/2015-July/002537.html >> >> I am thinking to make use of the client variable that is available in >> login.ftl and load different freemarker fragments that will then theme it >> differently for each client. As mentioned by Bill, having many if >> conditions might not be ideal but it might meet the requirement. >> >> Cheers >> Travis >> >> >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >

On Jan 5, 2016, at 6:22 AM, Travis De Silva <traviskds(a)gmail.com&gt; wrote: Hi Stian, SSO zones will not help in my use case because I actually want SSO between clients. For example lets say I have following clients Client1 Client2 and have following users User1 User2 User3 and I want User1 to be able to login to Client1 using its own application theme, User2 to login to Client2 using its own application theme and User3 can login to either Client1 or Client2 and they get SSO across the two clients. How can we do this with your proposed SSO zones? The more I think of this, its would be better to just give access to various end points in the login process. (e.g. forgot password, social login, register user etc) This I believe will be more flexible as we can then use it for these edge cases. Any thoughts on this? Cheers Travis On Tue, 5 Jan 2016 at 18:29 Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: On 4 January 2016 at 14:25, Travis De Silva <traviskds(a)gmail.com <mailto:traviskds@gmail.com>> wrote: HI Stian, Adding SSO zones just to address the theming issue looks a bit overkill to me as it will eventually come down to doing some theming at a level below the realm. I was going on the basis that if theming is not set at a client level, then it will default to the realm level theming which is basically your SSO enabled zone. Also my other point was with regard to SaaS based applications where we have a backoffice system which is themed as per our SaaS product but the consumer facing front end needs to be themed to be aligned with the customer's web site. In this case, we cannot go with what KeyCloak has at present. What I am doing is as suggested by Bill sometime back, adding "if/else" statements into the freemarker templates and based on the client id loading different freemarker templates which is not ideal but does the job. In any case, since what we are discussing is in general edge cases, Therefore instead of complicating the core KeyCloak platform, why don't you just expose the various links/flows that is currently available in the login process (forgot password/reset credentials, required actions (update password, verify email, configure OTP, etc.), user account mgmt, registration, social login etc. Then we are still using the core of keycloak but for the frontend themes/UI, we use our own. I also haven't explored the Login SPI which as per the KeyCloak docs which says "The Login SPI allows implementing the login forms using whatever web framework or templating engine you want". Wonder if this will give us what we are after. Sounds like an SSO zone is exactly what you'd want, so I'm not sure why you are so against that. I really don't want to have a theme option on a client, as I've said it just doesn't make any sense. I'd be happy with introducing an SPI or adding to the Theme SPI to let you choose yourself what theme is selected. The Login SPI is rather low-level so it would be better to do something else. Cheers Travis On Mon, 4 Jan 2016 at 22:27 Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: I strongly disagree. With Keycloak you are logging in to a SSO realm, not an individual application. With that in mind it's important that the login screen reflects that. Users need to know the difference as it's an important distinction. It just doesn't make any sense that I'm logged-in to the SSO with a login screen that is themed to look like the login screen for an individual application. Adding an option on clients to set the theme just doesn't make any sense. If we added the option to create SSO "zones" or disable SSO for individual applications then it would make sense to be able to set theme on a per-zone or apps that doesn't have SSO enabled. On 31 December 2015 at 09:46, Travis De Silva <traviskds(a)gmail.com <mailto:traviskds@gmail.com>> wrote: Hi, My vote is to provide this feature at a client level as per the original request. I think realms should be used for completely different domains when we want to isolate users etc. Should not try and use it for something that it was not intended in the design. The reason why you might need theming at client level is iif you really think that clients which are essentially different applications most of the time and each of these applications might have different look and feel themes (either due to different development teams or vendors building different applications). So when someone logins via KeyCloak, its true that we are logging into a realm but for an end user, it is really logging into a application and there is a need for the login page theme to look similar to the application look and feel. Also I have a use case where I have a back office application that requires login for admin users and then I have the front office of this application where in addition to the admin users, you also can have other users as well who can self register and login to the front end which is a consumer facing site. How I handle this is by having two clients in the same realm. This works fine if you are happy with the same backend login theme to be there for the consumer facing frontend. But we cannot do that as the front end is a consumer facing SaaS site, so each front end needs to have the client's website theme. This becomes very hard to do if we don't have theming at a client level. I came across this post from Bill a few months ago http://lists.jboss.org/pipermail/keycloak-user/2015-July/002537.html <http://lists.jboss.org/pipermail/keycloak-user/2015-July/002537.html> I am thinking to make use of the client variable that is available in login.ftl and load different freemarker fragments that will then theme it differently for each client. As mentioned by Bill, having many if conditions might not be ideal but it might meet the requirement. Cheers Travis _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <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

On Wed, 6 Jan 2016 at 01:52 Scott Rossillo <srossillo(a)smartling.com&gt; wrote: > Isn’t this whole idea of client specific themes just going to confuse > users? Think about logging into Google. Mail, calendar, drive, etc., all > share the same login screen and are all SSO clients. Wouldn’t you be > confused if it looked different for each app? Either way you’re > authenticating with Google. If you want to customize the consent screen > for external clients, that makes a bit more sense but it should be done in > a very standard way, like allowing a custom logo per external client you’re > authorizing. If you completely re-theme the consent screen even, you’re > going to confuse users IMO. > > If the suite of applications/products as per your Google example is provided from one vendor/development group, then yes. In that case we can use what KeyCloak has at present. But in corporate environments, you have hundreds and sometimes thousands of applications built by different groups/teams/vendors and they all don't look the same. In these environments, users most of the time use one or two as their primary application and occasionally might want to access another one in which case SSO will kick in and they don't need to login again. So there is really no confusion as they will always login to their primary application which is themed as per their application and when they go across to another application, it just automagically logs them in due to SSO. Another point is that when new application projects are kicked off in the corporate world, they will want to style/theme UI's as per the latest design standards or features. In such cases, if we go and theme it using the new standard, that will also change the existing applications that are running on KeyCloak and anyone who has worked in a corporate world knows how much of a pain point that is as you need to then engage various business owners of the exiting applications, come up with end user communication plans and so on. If we have theming at a client level, then we can progressively or to use the current buzz word "in an Agile" manner, ensure that new applications look new with new UI standards and not have to worry about existing applications at least until those applications are migrated. Apart from the above "corporate world" example, there are examples where this can be useful in consumer facing SaaS type of applications as well. It just gives more flexibility to end developers of applications that utilise KeyCloak. > Scott Rossillo > Smartling | Senior Software Engineer > srossillo(a)smartling.com > > [image: Powered by Sigstr] <http://www.sigstr.com/> > > On Jan 5, 2016, at 6:22 AM, Travis De Silva <traviskds(a)gmail.com&gt; wrote: > > Hi Stian, > > SSO zones will not help in my use case because I actually want SSO > between clients. For example lets say I have following clients > > Client1 > Client2 > > and have following users > > User1 > User2 > User3 > > and I want User1 to be able to login to Client1 using its own application > theme, User2 to login to Client2 using its own application theme and User3 > can login to either Client1 or Client2 and they get SSO across the two > clients. > > How can we do this with your proposed SSO zones? > > The more I think of this, its would be better to just give access to > various end points in the login process. (e.g. forgot password, social > login, register user etc) This I believe will be more flexible as we can > then use it for these edge cases. Any thoughts on this? > > Cheers > Travis > > On Tue, 5 Jan 2016 at 18:29 Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > >> On 4 January 2016 at 14:25, Travis De Silva <traviskds(a)gmail.com&gt; wrote: >> >>> HI Stian, >>> >>> Adding SSO zones just to address the theming issue looks a bit overkill >>> to me as it will eventually come down to doing some theming at a level >>> below the realm. I was going on the basis that if theming is not set at a >>> client level, then it will default to the realm level theming which is >>> basically your SSO enabled zone. >>> >> >>> Also my other point was with regard to SaaS based applications where we >>> have a backoffice system which is themed as per our SaaS product but the >>> consumer facing front end needs to be themed to be aligned with the >>> customer's web site. In this case, we cannot go with what KeyCloak has at >>> present. What I am doing is as suggested by Bill sometime back, adding >>> "if/else" statements into the freemarker templates and based on the client >>> id loading different freemarker templates which is not ideal but does the >>> job. >>> >>> In any case, since what we are discussing is in general edge cases, >>> Therefore instead of complicating the core KeyCloak platform, why don't you >>> just expose the various links/flows that is currently available in the >>> login process (forgot password/reset credentials, required actions >>> (update password, verify email, configure OTP, etc.), user account >>> mgmt, registration, social login etc. Then we are still using the core of >>> keycloak but for the frontend themes/UI, we use our own. >>> >>> I also haven't explored the Login SPI which as per the KeyCloak docs >>> which says "The Login SPI allows implementing the login forms using >>> whatever web framework or templating engine you want". Wonder if this will >>> give us what we are after. >>> >> >> Sounds like an SSO zone is exactly what you'd want, so I'm not sure why >> you are so against that. >> >> I really don't want to have a theme option on a client, as I've said it >> just doesn't make any sense. I'd be happy with introducing an SPI or adding >> to the Theme SPI to let you choose yourself what theme is selected. The >> Login SPI is rather low-level so it would be better to do something else. >> >> >>> >>> Cheers >>> Travis >>> >>> >>> >>> >>> >>> >>> >>> On Mon, 4 Jan 2016 at 22:27 Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> I strongly disagree. With Keycloak you are logging in to a SSO realm, >>>> not an individual application. With that in mind it's important that the >>>> login screen reflects that. Users need to know the difference as it's an >>>> important distinction. It just doesn't make any sense that I'm logged-in to >>>> the SSO with a login screen that is themed to look like the login screen >>>> for an individual application. >>>> >>>> Adding an option on clients to set the theme just doesn't make any >>>> sense. If we added the option to create SSO "zones" or disable SSO for >>>> individual applications then it would make sense to be able to set theme on >>>> a per-zone or apps that doesn't have SSO enabled. >>>> >>>> On 31 December 2015 at 09:46, Travis De Silva <traviskds(a)gmail.com&gt; >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> My vote is to provide this feature at a client level as per the >>>>> original request. >>>>> >>>>> I think realms should be used for completely different domains when >>>>> we want to isolate users etc. Should not try and use it for something that >>>>> it was not intended in the design. >>>>> >>>>> The reason why you might need theming at client level is iif you >>>>> really think that clients which are essentially different applications most >>>>> of the time and each of these applications might have different look and >>>>> feel themes (either due to different development teams or vendors building >>>>> different applications). >>>>> >>>>> So when someone logins via KeyCloak, its true that we are logging >>>>> into a realm but for an end user, it is really logging into a application >>>>> and there is a need for the login page theme to look similar to the >>>>> application look and feel. >>>>> >>>> >>>>> Also I have a use case where I have a back office application that >>>>> requires login for admin users and then I have the front office of this >>>>> application where in addition to the admin users, you also can have other >>>>> users as well who can self register and login to the front end which is a >>>>> consumer facing site. >>>>> >>>>> How I handle this is by having two clients in the same realm. This >>>>> works fine if you are happy with the same backend login theme to be there >>>>> for the consumer facing frontend. But we cannot do that as the front end is >>>>> a consumer facing SaaS site, so each front end needs to have the client's >>>>> website theme. This becomes very hard to do if we don't have theming at a >>>>> client level. >>>>> >>>>> I came across this post from Bill a few months ago >>>>> http://lists.jboss.org/pipermail/keycloak-user/2015-July/002537.html >>>>> >>>>> I am thinking to make use of the client variable that is available in >>>>> login.ftl and load different freemarker fragments that will then theme it >>>>> differently for each client. As mentioned by Bill, having many if >>>>> conditions might not be ideal but it might meet the requirement. >>>>> >>>>> Cheers >>>>> Travis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > >

Yes I understand. Let me check out the Login SPI. Also thank you for not getting mad with this prolonged conversation :) As always you guys have been very responsive and willing to listen to the community and that is a great sign for the future of KeyCloak. On Thu, 7 Jan 2016 at 01:04 Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > In theory you should be able to create your own screens using the Login > SPI, but you will have to do a fair bit of development as you'll pretty > much have to replace the whole login frontend. You can't host the login > pages from your apps either as you'll then loose the ability to do SSO, so > it will still have to be redirect based login as it is now. > > As you say your use-case is not quite the common-case so it's not > something that I want to support directly in Keycloak. However, we do > strive to make Keycloak customizable for corner-cases so if you can achieve > what you want with our current SPIs that would be great. Otherwise we could > discuss what's needed. At the moment we're pretty swamped though so changes > to Keycloak would most likely have to be contributions from you. > > On 6 January 2016 at 03:25, Travis De Silva <traviskds(a)gmail.com&gt; wrote: > >> >> >> On Wed, 6 Jan 2016 at 01:52 Scott Rossillo <srossillo(a)smartling.com&gt; >> wrote: >> >>> Isn’t this whole idea of client specific themes just going to confuse >>> users? Think about logging into Google. Mail, calendar, drive, etc., all >>> share the same login screen and are all SSO clients. Wouldn’t you be >>> confused if it looked different for each app? Either way you’re >>> authenticating with Google. If you want to customize the consent screen >>> for external clients, that makes a bit more sense but it should be done in >>> a very standard way, like allowing a custom logo per external client you’re >>> authorizing. If you completely re-theme the consent screen even, you’re >>> going to confuse users IMO. >>> >>> >> If the suite of applications/products as per your Google example is >> provided from one vendor/development group, then yes. In that case we can >> use what KeyCloak has at present. >> >> But in corporate environments, you have hundreds and sometimes thousands >> of applications built by different groups/teams/vendors and they all don't >> look the same. In these environments, users most of the time use one or two >> as their primary application and occasionally might want to access another >> one in which case SSO will kick in and they don't need to login again. So >> there is really no confusion as they will always login to their primary >> application which is themed as per their application and when they go >> across to another application, it just automagically logs them in due to >> SSO. >> >> Another point is that when new application projects are kicked off in >> the corporate world, they will want to style/theme UI's as per the latest >> design standards or features. In such cases, if we go and theme it using >> the new standard, that will also change the existing applications that are >> running on KeyCloak and anyone who has worked in a corporate world knows >> how much of a pain point that is as you need to then engage various >> business owners of the exiting applications, come up with end user >> communication plans and so on. If we have theming at a client level, then >> we can progressively or to use the current buzz word "in an Agile" manner, >> ensure that new applications look new with new UI standards and not have to >> worry about existing applications at least until those applications are >> migrated. >> >> Apart from the above "corporate world" example, there are examples where >> this can be useful in consumer facing SaaS type of applications as well. It >> just gives more flexibility to end developers of applications that utilise >> KeyCloak. >> >> >> >>> Scott Rossillo >>> Smartling | Senior Software Engineer >>> srossillo(a)smartling.com >>> >>> [image: Powered by Sigstr] <http://www.sigstr.com/> >>> >>> On Jan 5, 2016, at 6:22 AM, Travis De Silva <traviskds(a)gmail.com&gt; >>> wrote: >>> >>> Hi Stian, >>> >>> SSO zones will not help in my use case because I actually want SSO >>> between clients. For example lets say I have following clients >>> >>> Client1 >>> Client2 >>> >>> and have following users >>> >>> User1 >>> User2 >>> User3 >>> >>> and I want User1 to be able to login to Client1 using its own >>> application theme, User2 to login to Client2 using its own application >>> theme and User3 can login to either Client1 or Client2 and they get SSO >>> across the two clients. >>> >>> How can we do this with your proposed SSO zones? >>> >>> The more I think of this, its would be better to just give access to >>> various end points in the login process. (e.g. forgot password, social >>> login, register user etc) This I believe will be more flexible as we can >>> then use it for these edge cases. Any thoughts on this? >>> >>> Cheers >>> Travis >>> >>> On Tue, 5 Jan 2016 at 18:29 Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> On 4 January 2016 at 14:25, Travis De Silva <traviskds(a)gmail.com&gt; >>>> wrote: >>>> >>>>> HI Stian, >>>>> >>>>> Adding SSO zones just to address the theming issue looks a bit >>>>> overkill to me as it will eventually come down to doing some theming at a >>>>> level below the realm. I was going on the basis that if theming is not set >>>>> at a client level, then it will default to the realm level theming which is >>>>> basically your SSO enabled zone. >>>>> >>>> >>>>> Also my other point was with regard to SaaS based applications where >>>>> we have a backoffice system which is themed as per our SaaS product but the >>>>> consumer facing front end needs to be themed to be aligned with the >>>>> customer's web site. In this case, we cannot go with what KeyCloak has at >>>>> present. What I am doing is as suggested by Bill sometime back, adding >>>>> "if/else" statements into the freemarker templates and based on the client >>>>> id loading different freemarker templates which is not ideal but does the >>>>> job. >>>>> >>>>> In any case, since what we are discussing is in general edge cases, >>>>> Therefore instead of complicating the core KeyCloak platform, why don't you >>>>> just expose the various links/flows that is currently available in the >>>>> login process (forgot password/reset credentials, required actions >>>>> (update password, verify email, configure OTP, etc.), user account >>>>> mgmt, registration, social login etc. Then we are still using the core of >>>>> keycloak but for the frontend themes/UI, we use our own. >>>>> >>>>> I also haven't explored the Login SPI which as per the KeyCloak docs >>>>> which says "The Login SPI allows implementing the login forms using >>>>> whatever web framework or templating engine you want". Wonder if this will >>>>> give us what we are after. >>>>> >>>> >>>> Sounds like an SSO zone is exactly what you'd want, so I'm not sure >>>> why you are so against that. >>>> >>>> I really don't want to have a theme option on a client, as I've said >>>> it just doesn't make any sense. I'd be happy with introducing an SPI or >>>> adding to the Theme SPI to let you choose yourself what theme is selected. >>>> The Login SPI is rather low-level so it would be better to do something >>>> else. >>>> >>>> >>>>> >>>>> Cheers >>>>> Travis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, 4 Jan 2016 at 22:27 Stian Thorgersen <sthorger(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> I strongly disagree. With Keycloak you are logging in to a SSO >>>>>> realm, not an individual application. With that in mind it's important that >>>>>> the login screen reflects that. Users need to know the difference as it's >>>>>> an important distinction. It just doesn't make any sense that I'm logged-in >>>>>> to the SSO with a login screen that is themed to look like the login screen >>>>>> for an individual application. >>>>>> >>>>>> Adding an option on clients to set the theme just doesn't make any >>>>>> sense. If we added the option to create SSO "zones" or disable SSO for >>>>>> individual applications then it would make sense to be able to set theme on >>>>>> a per-zone or apps that doesn't have SSO enabled. >>>>>> >>>>>> On 31 December 2015 at 09:46, Travis De Silva <traviskds(a)gmail.com&gt; >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> My vote is to provide this feature at a client level as per the >>>>>>> original request. >>>>>>> >>>>>>> I think realms should be used for completely different domains when >>>>>>> we want to isolate users etc. Should not try and use it for something that >>>>>>> it was not intended in the design. >>>>>>> >>>>>>> The reason why you might need theming at client level is iif you >>>>>>> really think that clients which are essentially different applications most >>>>>>> of the time and each of these applications might have different look and >>>>>>> feel themes (either due to different development teams or vendors building >>>>>>> different applications). >>>>>>> >>>>>>> So when someone logins via KeyCloak, its true that we are logging >>>>>>> into a realm but for an end user, it is really logging into a application >>>>>>> and there is a need for the login page theme to look similar to the >>>>>>> application look and feel. >>>>>>> >>>>>> >>>>>>> Also I have a use case where I have a back office application that >>>>>>> requires login for admin users and then I have the front office of this >>>>>>> application where in addition to the admin users, you also can have other >>>>>>> users as well who can self register and login to the front end which is a >>>>>>> consumer facing site. >>>>>>> >>>>>>> How I handle this is by having two clients in the same realm. This >>>>>>> works fine if you are happy with the same backend login theme to be there >>>>>>> for the consumer facing frontend. But we cannot do that as the front end is >>>>>>> a consumer facing SaaS site, so each front end needs to have the client's >>>>>>> website theme. This becomes very hard to do if we don't have theming at a >>>>>>> client level. >>>>>>> >>>>>>> I came across this post from Bill a few months ago >>>>>>> http://lists.jboss.org/pipermail/keycloak-user/2015-July/002537.html >>>>>>> >>>>>>> I am thinking to make use of the client variable that is available >>>>>>> in login.ftl and load different freemarker fragments that will then theme >>>>>>> it differently for each client. As mentioned by Bill, having many if >>>>>>> conditions might not be ideal but it might meet the requirement. >>>>>>> >>>>>>> Cheers >>>>>>> Travis >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >>> > _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user