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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>