[keycloak-dev] relationship between application and realm

[Bill Burke]

One more thing...

With a one-app model, I really wonder if keycloak is even useful for 
JBoss applications.  In this case, I can see wanting to just do social 
integration myself using one of the plethora of libraries out there so I 
could have a more integrated and branded experience.  For non-social, 
I'd just use the existing JBoss security infrastructure.

Keycloak as an SSO solution is the more compelling reason to choose it, IMO.

On 9/13/2013 9:23 AM, Bill Burke wrote:
> TLDR
>
> THe more we discuss this, the more strongly I feel your approach to
> Application and Realm is just not the way to go.  I don't know how to
> resolve our differences at the moment, but please read further...
>
> On 9/12/2013 9:23 AM, Stian Thorgersen wrote:
>> I strongly believe that applications should be under a separate top-level menu.
>>
>
> I think you are creating more work for us and making an inconsistent UI
> for the user.
>
>> - An application is configured to use a realm, it's not a child of the realm
>
> An application deployment is configured to interact with a specific
> realm.  It needs the realm name, public key, and credentials it needs to
> interact with the realm.  It is not separate from the realm.  An
> application deployment is not going to be serviced by multiple realms.
>
> JBoss developers currently create realms when they secure their apps.
>
>> - A developer may know what application he's looking for, but not know what realm it belongs to
>>
>
> Why would a developer be "looking" for an application or for that matter
> "looking" for a realm?  What you state is just not how developers will
> interact with Keycloak.
>
> JBoss, Tomcat, and Jetty developers create a realm when they secure
> their apps.
>
>> I also believe that a first time user should be able to create an application without having to create a realm first. There are several options for this:
>>
>
> And I completely disagree.  I just don't understand your problem with a
> realm as its just one extra field:  a name.  Conversley, if you start
> with an application and have to do all the extra import stuff Gabriel
> has in his current flow it is *A LOT MORE WORK* and *A LOT MORE CONFUSING*.
>
>
>> - Create a default realm for a user when the first application is created
>
> Again, develoeprs aren't going to be creating "applications" first.
> They will already have an application they want to secure.  They will
> create a realm, set up social providers, add an application with a URL,
> etc...
>
> This is basically how developers work *ALREADY* with JBoss (and Tomcat
> and Jetty).  They create a security domain, then configure their
> application to use this security domain.
>
>> - Embed the creating realm form into the creating application form / this should require very little additional work on the UI level if Angular services and partials are done correctly
>>
>> Having applications as a separate entity is also vital if for example an MBaaS solution should consume Keycloak and reuse parts of the admin console. In this case an application doesn't only have a security realm, and security configuration, it also has data configuration, push notification configuration, etc.
>>
>
> For MBaaS, you are targeting a use case and designing a UI based on the
> needs of a handful of consumers, when the UI should be tailored to the
> needs of the most common use case.
>
> As it is, you give no details why having an application as a separate
> entity is so vital for MBaaS.  The MBaaS will be using Keycloak REST
> services in the background and have their own integrated UI for
> security.  This idea that we're going to reuse the Keycloak UI is just
> poppycock.  Even if they wanted to, it would not result in a very
> user-friendly UI.  Also, you're not going to be using the Keycloak UI to
> create Application security templates.  Why would you when a JSON file
> is 100 times simpler and quicker?
>
> I just can't agree that your approach is appropriate.  Your approach
> immediately falls apart when dealing with SSO, which will be a very
> common deployment model for Keycloak given how much feedback I've
> already gotten for the Resteasy OAuth solution.  Not only that,  but
> having a Realm as the central concept in keycloak doesn't even in the
> slightest make things more complicated and is a concept that developers
> are already deeply familiar with.
>

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