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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Friday, 13 September, 2013 2:41:56 PM Subject: Re: [keycloak-dev] relationship between application and realm 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 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev