[keycloak-dev] relationship between application and realm

Bill Burke bburke at redhat.com
Mon Sep 16 08:39:03 EDT 2013



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.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the keycloak-dev mailing list