[keycloak-dev] relationship between application and realm

[Bolesław Dawidowicz]

On 09/16/2013 02:39 PM, Bill Burke wrote:
>
>
> On 9/15/2013 9:21 AM, Stian Thorgersen wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com> To: "Stian Thorgersen"
>>> <stian at redhat.com> Cc: keycloak-dev at lists.jboss.org Sent: Friday,
>>> 13 September, 2013 3:14:42 PM Subject: Re: [keycloak-dev]
>>> relationship between application and realm
>>>
>>>
>>>
>>> On 9/13/2013 9:41 AM, Stian Thorgersen wrote:
>>>> You convinced me with poppycock...
>>>
>>> I should have expanded on "poppycock", apologies...I get too
>>> excited sometimes...
>>
>> No need, I understood what you meant ;)
>>
>>>
>>>> I'll try to get out of the idea of a console that is more
>>>> general purpose (this is probably where most of our
>>>> disagreements on the console comes from)!
>>>>
>>>
>>> Every effort I've seen to do portlet-like like exchanges/sharing
>>> hasn't worked out too well.  This goes all the way back to my
>>> Visual Basic/Visual C++/OLE days and then, to watching how the
>>> portlet specification failed to garner a component exchange.  Its
>>> why I'm so skeptical of it.  We *MIGHT* be able to accomplish it
>>> with Red Hat only projects, but as you already know, each project
>>> has their own favorite (or legacy) UI framework and things are
>>> already an integration nightmare for Uberfire.
>>>
>>> Personally I'd prefer us to focus on company-wide UI
>>> standards/templates and getting Red Hat projects to conform to
>>> them.  That in and of itself is a lot of work for a engineering
>>> team that is already stretched pretty thin...
>>>
>>> For us, I think if we write some well designed and focused REST
>>> APIs we'll be able to resolve most requirements for Red Hat
>>> projects.
>>>
>>>> With that in mind, I'm happy with what you're proposing. Only
>>>> one question though. If a developer wants to configure the
>>>> settings for a specific application, for example add a role to
>>>> the application, and doesn't know what realm the application
>>>> belongs to (and there are many realms), will he have to just
>>>> browse through all realms to find the application? TBH not sure
>>>> how "common" this case would be, so is probably a non-issue.
>>>>
>>>
>>> They have to know what the realm is when they configure their
>>> application to use Keycloak.   The realm is the "auth-server".
>>>
>>> We'll have to see how people use Keycloak.  But don't you think
>>> the norm would be 1 realm?  At most a small handful of realms?
>>> Also, minus the fact they have to know the realm anyways to
>>> configure their app, don't you think they'd know this information
>>> anyways?  Or, even they'd be the keycloak admin?
>>
>> I think collaboration when configuring applications and realms is
>> important - I'd think there would be some people responsible for
>> configuring the realm itself, while there could be others that only
>> can configure independent applications. In some situations you may
>> for example want to let one developer edit "Acme Android App", but
>> not touch "Acme Realm" or "Acme iOS App".
>>
>
> Well, that's actually a good point...That you may only want to give
> a developer permission to edit the roles of their realm.
>
>> But, let's leave it the way you want it - if we find a strong
>> enough reason to add an application tab as well, that can always be
>> done in the future.
>>
>
> BTW, don't you guys (portal) have experience with Identity
> deployments? Thomas was telling me that customers often bought Portal
> for its identity management.

We have some. Which aspect are you interested in? Majority of 
deployments are around integrating MSAD - as majority of organizations 
just inherit it as part of Windows Domain.





-- 
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead