[keycloak-dev] Shortening URLs

[Marek Posolda]

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

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