[keycloak-user] Different theme for each client

[Travis De Silva]

On Wed, 6 Jan 2016 at 02:08 Stian Thorgersen <sthorger at redhat.com> wrote:

> On 5 January 2016 at 12:22, 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?
>>
>
> I didn't expect a client to belong to multiple zones. That would
> complicate things quite a bit I think.
>
> However, what you're asking for with client specific themes still makes no
> sense. How is User3 going to know that he's logged in to Client1 as well if
> the login screen is themed to match Client2.
>

When User3 logs into Client2, and then they navigate to Client1, it just
automagically logs them in due to SSO. When User3 logs into Client2, he
does not need to be aware what other clients he has got auto logged in as
at that time he might not even know he needs to access other clients.

This is sort of a "poor man's" Kerberos, when you log in to the first
application it gives you login access to other applications. You may ask
why can't they then just login to the realm theme. That is because in
corporate environments, you have users who access only one primary
application and for them, the login theme should be like their own
application.

As I mentioned since these are edge cases, I think if we can address my
request below which I have explained a bit more, that might be the best
rather than focusing about client level theming or theming via 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?
>>
>
> Not sure what you mean about that. I was thinking about just exposing
> something that let you select the theme to use yourself and have everything
> else work as it is currently.
>

What would be ideal is if we can host the themes within our own
applications and use KeyCloak for the authentication flows. For example
instead of using the Freemarker theming, can we for example do the login,
forgot password, register new user, social login links etc using our
front-end framework (e.g. AngularJS) and make rest calls to KeyCloak for
the authentication flow. I am trying to avoid the direct grant but use what
KeyCloak currently has in its authentication flow.

I am aware (and use) various KeyCloak admin rest endpoints such as create
new user, change password, add social links etc but if I am to use this for
the auth flows, then I will be duplicating functionality that has already
been done just because of the theming. If there is a way we can call the
same auth flows but replace the page displayed with our own directly from
the application, in my opinion it would make KeyCloak more "embeddable" is
external applications.

Maybe this is already possible with the Login SPI which I will have a look.
But I suspect that I will end up having to do all the auth flows again. I
maybe wrong.

KeyCloak is really great and one of the best open source platforms out
there. Even the FreeMarker theming is a fantastic feature. But when it
comes to UI, you can never satisfy everyone and if we can extend the auth
flows to applications/teams outside the group that manages the KeyCloak
instance, then that opens up a lot of new possibilities. For example in its
simplest form we can offer KeyCloak as a SaaS platform where external
applications not within our control can use it for Authentication and theme
the login page etc the way they want without we having to do any theme
development.


>
>
>>
>> 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
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160106/a13b974c/attachment-0001.html