Re: [keycloak-dev] relationship between application and realm

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)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