[keycloak-dev] relationship between application and realm

[Stian Thorgersen]

For social Keycloak should provide integrated and branded experiences. This is done by letting developers use their own key and secrets for social networks. It still saves users a lot of work to incorporate login with social networks. Incorporating social networks is a non-trivial thing if done correctly (I can elaborate on this if you want).

SSO is one compelling features yes, but there's loads more very nice features that we can provide:

* Audit
* User management
* User workflows - password reset, verify email, etc, etc..
* Social aspects
* Multi-factor authentication
* Link with corporate identity providers (for example LDAP)
* Ability to use the same solution for server-side, client-side and mobile applications

Of course, how useful each feature is depends on the target audience! IMO Keycloak will provide loads of value to:

* A single app
* A single logical app - but where there's different versions (desktop, mobile, etc.)
* A enterprise with loads of REST services, desktop applications, web applications, mobile applications, etc....

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>