[keycloak-dev] relationship between application and realm

[Stian Thorgersen]

You convinced me with poppycock... 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)!

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.

----- 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 2:23:18 PM
> Subject: Re: [keycloak-dev] relationship between application and realm
> 
> 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
>