[keycloak-dev] Shortening URLs

[Marek Posolda]

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.


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.
>>