[keycloak-user] SSO on non-protected / public urls

Pedro Igor Silva psilva at redhat.com
Wed Jan 3 13:37:42 EST 2018


I see now.

As you noticed, the adapters rely on a set of one or more paths in order to
trigger authentication and intercept requests.

I'm not sure either how we can accomplish this, but maybe we can start by
understanding how your clients look like. For instance:

* Which adapter are you using with your clients (site1 and site2) ?
* Are these clients confidential clients ?

I think that if you are using JS in your clients (e.g.: angular or
something else) it should be easier to support these requirements.

On Wed, Jan 3, 2018 at 3:07 PM, Michalis Siochos <msiochos at gmail.com> wrote:

> Greetings Pedro,
>
> We need SSO on non protected resources for a number of reasons outlined
> below:
>
> 1) We have a series of portals (company, services, products, subsidiaries,
> etc) that have both public and protected areas.
> So, we need to be able to identify a user that lands on a public url (e.g.
> by following a link) in order to show personalized content.
>
> Google offers similar functionality
> - Go to https://mail.google.com
> - Login
> - Then go to https://www.youtube.com
> - You see personalized content on a page that is obviously public
>
> In my view, this is an important added value of SSO.
>
> 2) The main website consists of a series of applications (actually
> portals) than are put together at user interface level. So, the user may
> navigate from a protected portal to a public portal e.g.
> - From: https://www.example.com/customers (protected)
> - To: https://www.example.com/services (public)
>
> As the customer navigates to public urls then the application cannot show
> logged in user information and list of available actions. This is bad from
> user experience point of view since the user will see himself/herself as
> logged in on /customers but as anonymous on /service while on the same
> website (the user cannot understand that he navigates to different apps)
>
> 3) We have been using this functionality for 10+ years so renouncing it
> would be a major regression.
>
> Best Regards,
> Michalis
>
>
> On 01/02/2018 04:33 PM, Pedro Igor Silva wrote:
>
> Why do you need to create session when accessing a public resource ?
>
> On Thu, Dec 28, 2017 at 6:01 PM, Michalis Siochos <msiochos at gmail.com>
> wrote:
>
>> Hi All,
>>
>> I'm evaluating keycloak and identifying the possibility to provide SSO
>> services on non protected (public) pages.
>>
>> Assume the following environment:
>>
>> Portal 1
>> - https://site1.example.com/public
>> - https://site1.example.com/protected
>>
>> Portal 2
>> - https://site2.example.com/public
>> - https://site2.example.com/protected
>>
>> /protected is the restricted area of the portal, that only logged in
>> users may access
>> /public is the public area where both logged in and anonymous users may
>> navigate
>>
>> I'm trying to achieve the following
>> - User logs in @ https://site1.example.com
>> - SSO session and site1 session are created
>> - User goes to public area of site2, https://site2.example.com/public
>> - User is automatically logged in (site2 session is created)
>>
>> It seems that the above is not possible with OIDC / SAML since the user
>> has to land on a protected page to initiate federation, or perform an
>> action (e.g. click a button).
>>
>> Any other thoughts, feedback?
>>
>> Thanks in advance,
>> Michalis
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>


More information about the keycloak-user mailing list