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