[keycloak-dev] Shortening URLs

[Stian Thorgersen]

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, January 26, 2015 10:45:03 AM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> On 26.1.2015 10:04, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Monday, January 26, 2015 9:51:24 AM
> >> Subject: Re: [keycloak-dev] Shortening URLs
> >>
> >> The main issue to address are shorter URL for services directly
> >> accessible by users, which is account mgmt and admin console, right? How
> >> about introduce aliases and add cookie scoped to '/auth' context, which
> >> will handle the name of the realm user is logged in?
> >>
> >> Some details:
> >>
> >> * User will log into realm "foo" . Keycloak will add KEYCLOAK_REALM
> >> cookie with content "foo" scoped to path "/auth" (or whatever context is
> >> auth-server deployed on)
> >>
> >> * User goes to "/auth/account" . Keycloak will read cookie and redirect
> >> user to "/auth/realms/foo/account"
> >>
> >> * User goes to "/auth/admin" . Keycloak will read cookie and redirect
> >> user to "/auth/admin/foo/console"
> >>
> >> * If user's browser is logged into 2 realms, Keycloak can display the UI
> >> page with radio buttons where user can choose his realm (Something like
> >> Google is doing for choosing your account)
> >>
> >> * If user is not logged into any realm, Keycloak can display list of all
> >> realms and user can choose? Or directly redirect user if there is just
> >> one realm available.
> > I don't like that. It will be common for a user that goes directly to
> > 'account' to not be logged-in and the user would have no clue of what
> > realm to select.
> >
> > Also, how would that work if user logs in to multiple realms?
> Also allow him to choose from UI as I mentioned above (paragraph with
> 4th star)

What if user is logged-in to one realm, but was expecting account for another? Besides, my other point still stands I don't expect a user to have any clue what a realm is.

> >
> > It's also very much against the whole resign of URLs to have dynamic URLs
> > in such a way.
> Maybe, I am not sure. Cookie could be one alternative and another could
> be virtual hosts. We can maybe have possibility for admins to specify
> "redirection policies" so admin can easily specify that access to
> "http://foo.keycloak.org/auth/account" would redirect users to
> "http://keycloak.org/auth/realms/foo/account" .
> 
> Admins can already put keycloak behind Apache, which provides
> possibilities to handle redirection based on various rules. I am just
> wondering if we should put something into Keycloak itself without need
> to rewrite our existing urls and give up on pluggable protocols etc.

A fixed alias is a better suggestion than a cookie. I really don't think it's a good idea to have a URL that redirects depending on the value of a cookie.

Still, a fixed alias seems a bit like a work-around than an actual fix

> 
> Marek
> >
> >>
> >> Maybe the behaviour could be somehow pluggable, so people can use
> >> virtual hosts instead of cookie and access to
> >> "http://foo.keycloak.org/auth/account" will use realm "foo" etc?
> >>
> >> Marek
> >>
> >> On 23.1.2015 19:00, Bill Burke wrote:
> >>> We can't remove "realms" qualifier unless the admin REST interface is
> >>> exposed under an entirely different WAR root context.
> >>>
> >>>
> >>>
> >>>
> >>> On 1/23/2015 10:28 AM, Bill Burke wrote:
> >>>> On 1/23/2015 9:36 AM, Bill Burke wrote:
> >>>>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> >>>>>> Our URLs are quite long, examples:
> >>>>>>
> >>>>>> *
> >>>>>> http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> >>>>>> * http://localhost:8080/auth/realms/master/account
> >>>>>>
> >>>>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
> >>>>>>
> >>>>>> * http://localhost:8080/auth/master/oidc/login
> >>>>>> * http://localhost:8080/auth/master/account
> >>>>>>
> >>>>>> That would require moving everything under a realm and I guess we'd
> >>>>>> need
> >>>>>> to hard-wire the protocols, but I think that should be fine.
> >>>>>>
> >>>>> Wouldn't work for multiple reasons.
> >>>>>
> >>>>> * protocols/* exists to be able to plugin different protocols (oidc,
> >>>>> saml, etc.)
> >>>>> * Because of the crappy way JAX-RS dispatch algorithm handles wildcards
> >>>>> for both resource classes and resource locators we need both a "realms"
> >>>>> and "protocols" qualifier.
> >>>>>
> >>>>> Its really funny you bring this up now because I've renewed my argument
> >>>>> with JAX-RS JSR just 2 minutes ago!  Synchronicity!
> >>>>>
> >>>> Bah!  Scratch that...I think we might be able to remove "realms" so long
> >>>> as we don't add any other root context wildcard resource classes.  Using
> >>>> a wildcard only for "protocols" might paint us in a corner as there may
> >>>> be other wildcard resources we want to add in the future.
> >>>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
>