Re: [keycloak-user] Different theme for each client

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