[keycloak-dev] relationship between application and realm

[Bill Burke]

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