[keycloak-user] Different theme for each client

[Travis De Silva]

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 at redhat.com> 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 at gmail.com> wrote:
>
>>
>>
>> On Wed, 6 Jan 2016 at 01:52 Scott Rossillo <srossillo at smartling.com>
>> 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 at smartling.com
>>>
>>> [image: Powered by Sigstr] <http://www.sigstr.com/>
>>>
>>> On Jan 5, 2016, at 6:22 AM, Travis De Silva <traviskds at gmail.com> 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 at redhat.com>
>>> wrote:
>>>
>>>> On 4 January 2016 at 14:25, Travis De Silva <traviskds at 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 at 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 at 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
>>>>>>>
>>>>>>> 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160106/1348f1b9/attachment-0001.html