[keycloak-dev] changes to admin ui login/bootstrap

[Stian Thorgersen]

----- 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, 18 October, 2013 8:02:52 PM
> Subject: Re: [keycloak-dev] changes to admin ui login/bootstrap
> 
> Commit the work, I'll ditch what I have and work on finishing it up so
> that it can be used as a core service.  This means populating the
> SkeletonKeyToken with origins and adding the apppropriate decorators and
> OPTIONS support in the application adapter.
> 
> 
> 
> BTW, it doesn't look like you are setting and checking the STATE cookie
> in keycloak.js.  But I'm not exactly sure yet how you're using
> keycloak.js yet in the application.

Neither am I ;)

State variable is saved in sessionStorage and validated in callback. sessionStorage is fine as long as we're only targeting modern browsers. Just to clarify keycloak.js is in the experimentation stage atm!

> 
> On 10/18/2013 1:20 PM, Stian Thorgersen wrote:
> > I've been focused on what's needed to get keycloak.js to work..
> >
> > * I've added a list of web origins to the client (UserModel)
> > * Alexandre has added this to the admin console (application page)
> > * I've added support for CORS to TokenService.accessCodeToToken
> > * Tested basic JS example to work with CORS
> >
> > Been considering what to do for authorized requests (bearer token). And
> > came to same conclusion as you. However, I was going to send the value of
> > the Origin header, not '*'. Then verify when the actual header comes in. I
> > was actually thinking about doing returning a 400/403 or something like
> > that if the Origin does match one specified on the client. The first thing
> > I was thinking about adding to use this was a method to allow retrieving
> > the user profile for the currently logged in user. Then I was going to
> > talk to you about what we could do to add it to SaasService.
> >
> > I've not looked at it from the perspective of adding it to adapters, only
> > to support it for the Keycloak server itself.
> >
> > I was in the process of cleaning this up, then the plan was to let you have
> > a look at it before merging it upstream.
> >
> > I've also had a look at what others are doing at it seems like Google for
> > example just returns an allowed origins that matches whatever the origin
> > was. It seems to completely disregard the values you specify through the
> > console itself (of which I can't quite figure out what their purpose is).
> >
> > ----- 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, 18 October, 2013 5:49:51 PM
> >> Subject: Re: [keycloak-dev] changes to admin ui login/bootstrap
> >>
> >>
> >>
> >> On 10/18/2013 12:15 PM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 17 October, 2013 11:30:08 PM
> >>>> Subject: Re: [keycloak-dev] changes to admin ui login/bootstrap
> >>>>
> >>>>
> >>>>
> >>>> On 10/17/2013 4:42 AM, Stian Thorgersen wrote:
> >>>>> I strongly feel this is a mistake. We need to find a way to make the
> >>>>> admin
> >>>>> console use Keycloak without any hacks. In my opinion the admin console
> >>>>> should use keycloak.js as it's a client-side application. For
> >>>>> client-side
> >>>>> applications the credentials should be public so can just be
> >>>>> pre-configured to a well-known string.
> >>>>>
> >>>>> Safety of client-side applications are provided by two things: firstly
> >>>>> the
> >>>>> application credentials themselves don't give you any privileges,
> >>>>> secondly
> >>>>> the redirect uri should be verified by Keycloak preventing unauthorized
> >>>>> use of the credentials.
> >>>>>
> >>>>> If we can't come up with a good and safe approach to using Keycloak
> >>>>> with
> >>>>> HTML5 and mobile applications the project is a huge fail! If we're not
> >>>>> using it directly ourselves for our HTML5 console that doesn't sound
> >>>>> right
> >>>>> to me.
> >>>>>
> >>>>
> >>>> #1  I want Keycloak ready to use out of the box and be as secure and
> >>>> locked down as possible.  This requirement may or may not effect the
> >>>> implementation of the admin ui or admin REST interfaces.
> >>>>
> >>>> #2 We don't support CORS yet so doing keycloak.js approach is not an
> >>>> option at the moment.  I'm going to tackle that now as I don't think its
> >>>> that much work and this would be a really cool core feature.
> >>>
> >>> I've already started work on keycloak.js + CORS support. As I mentioned
> >>> on
> >>> our Hangout having a good way to support HTML5 applications is a strong
> >>> requirement for MBaaS so that is something I'm look at now
> >>>
> >>
> >> Would be good to know what you're doing for this.  This requires support
> >> at multiple layers to support it as a core keycloak feature.  I've done
> >> most of the work, just have the admin UI left.
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>