From stian at redhat.com  Thu May  1 05:23:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 05:23:40 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <5361B37A.7080203@redhat.com>
References: <5361B37A.7080203@redhat.com>
Message-ID: <410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>

What are the downsides of having a "shared" admin realm? 

We can fine-grained access control, so individual admins/users can be limited to only manage certain realms (or none at all).

Another related thing is I wonder if we could share users (and maybe even do sso) cross realms? I can imagine situations where people wants multiple realms to manage token settings, social settings, applications, etc, but still want to let users have a single account, instead of one per-realm. We already support authenticating users with a different realm, but I was wondering if we could make it a more integrated feature, as well as support sso. 

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 1 May, 2014 3:37:46 AM
> Subject: [keycloak-dev] management problems
> 
> Our current "master realm" structure/design is deficient.  Consider an
> application like UPS that wants to use Keycloak to manage users.  This
> application would also have its own management console whose security is
> also managed by keycloak.
> 
> My first thought is that you could define the application's management
> console as an application in the "master" keycloak realm.  This solution
> isn't a great one if the keycloak server is managing multiple realms.
> So, IMO not something we should recommend.
> 
> Another option is to define admin roles within the application's realm
> itself.  These roles are assignable to users within the realm.  This
> would require rethinking of the Angular JS admin console and how things
> are authenticated and how people log-in.  We should probably treat this
> as SSO and have individual applications within the application realm,
> for example:
> 
> UPS Realm registered applications:
> 
> realm-management (keycloak admin console)
> aerogear-ups-management (ups admin console)
> 
> 
> 
> 
> 
> --
> 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
> 

From stian at redhat.com  Thu May  1 05:28:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 05:28:41 -0400 (EDT)
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <53613FC1.3050006@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
	<53613FC1.3050006@redhat.com>
Message-ID: <1890253881.15538720.1398936521101.JavaMail.zimbra@redhat.com>

As long as we have a way for users to invalidate everything in accnt mngmt I agree that's sufficient.

Setting UserModel.notBefore on user logout, would that not invalidation the session on other devices/browsers as well?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 30 April, 2014 7:24:01 PM
> Subject: Re: [keycloak-dev] Account management requirements for beta1
> 
> We have most of this via a not-before policy you can set at the realm
> level, application, client, or user level.  No ability yet to view
> tokens that have been given out though and which may still be valid.
> Only an admin can set the not-before policy right now.
> 
> Tasks:
> 
> * Make sure all not before policies are checked before login or refresh
> * Set UserModel.notBefore when a user does a logout.
> * Allow user to invalidate all grants (sets a UserModel.notBefore(now)
> policy)
> 
> Not a priority:
> * Allow a user to view and invalidate specific oauth grants.  We can
> just make it all or nothing.  I just think there's higher priority
> things to do.
> 
> On 4/30/2014 12:17 PM, Stian Thorgersen wrote:
> > With regards to account management what additional requirements do we have
> > for beta1?
> >
> > Features I can think off to add now or in the future includes:
> >
> > * Manage refresh tokens - view applications and clients that have refresh
> > tokens, and the ability to invalidate specific tokens
> > * Manage devices - view browsers and devices that have access (remember me
> > cookie?), and the ability to invalidate specific cookies
> > * Manage devices that can bypass totp - it seems to be quite common that
> > it's possible to not require asking for totp again for a specific device,
> > I assume this is done by setting a cookie, if we enable this it should be
> > possible to view what devices have this option, as well as invalidate them
> > * Manage applications - view all applications, be able to navigate to an
> > application, and the ability to invalidate access to specific application
> > * Manage clients - view all clients and what grants they have, and the
> > ability to revoke access to specific client
> >
> > I think listing client grants, invalidate specific client grants, and a
> > logout everything option would be sufficient. The logout everything option
> > would invalidate any refresh tokens, remember me cookies, 'skip' totp
> > cookies and do a sso-logout.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> 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
> 

From bburke at redhat.com  Thu May  1 09:05:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 09:05:28 -0400
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <1890253881.15538720.1398936521101.JavaMail.zimbra@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
	<53613FC1.3050006@redhat.com>
	<1890253881.15538720.1398936521101.JavaMail.zimbra@redhat.com>
Message-ID: <53624698.9070807@redhat.com>



On 5/1/2014 5:28 AM, Stian Thorgersen wrote:
> As long as we have a way for users to invalidate everything in accnt mngmt I agree that's sufficient.
>
> Setting UserModel.notBefore on user logout, would that not invalidation the session on other devices/browsers as well?
>

Yes, for those apps that don't have an HTTP session that can be 
invalidated, they will eventually have to do a refresh and the refresh 
token would be invalid which would force a relog.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May  1 09:08:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 09:08:17 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>
Message-ID: <53624741.10601@redhat.com>

cross-realm user doesn't solve the problem of having an integrated admin 
experience for apps like Aerogear UPS.

On 5/1/2014 5:23 AM, Stian Thorgersen wrote:
> What are the downsides of having a "shared" admin realm?
>
> We can fine-grained access control, so individual admins/users can be limited to only manage certain realms (or none at all).
>
> Another related thing is I wonder if we could share users (and maybe even do sso) cross realms? I can imagine situations where people wants multiple realms to manage token settings, social settings, applications, etc, but still want to let users have a single account, instead of one per-realm. We already support authenticating users with a different realm, but I was wondering if we could make it a more integrated feature, as well as support sso.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 1 May, 2014 3:37:46 AM
>> Subject: [keycloak-dev] management problems
>>
>> Our current "master realm" structure/design is deficient.  Consider an
>> application like UPS that wants to use Keycloak to manage users.  This
>> application would also have its own management console whose security is
>> also managed by keycloak.
>>
>> My first thought is that you could define the application's management
>> console as an application in the "master" keycloak realm.  This solution
>> isn't a great one if the keycloak server is managing multiple realms.
>> So, IMO not something we should recommend.
>>
>> Another option is to define admin roles within the application's realm
>> itself.  These roles are assignable to users within the realm.  This
>> would require rethinking of the Angular JS admin console and how things
>> are authenticated and how people log-in.  We should probably treat this
>> as SSO and have individual applications within the application realm,
>> for example:
>>
>> UPS Realm registered applications:
>>
>> realm-management (keycloak admin console)
>> aerogear-ups-management (ups admin console)
>>
>>
>>
>>
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu May  1 09:12:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 09:12:29 -0400 (EDT)
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <53624698.9070807@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
	<53613FC1.3050006@redhat.com>
	<1890253881.15538720.1398936521101.JavaMail.zimbra@redhat.com>
	<53624698.9070807@redhat.com>
Message-ID: <939505715.15603944.1398949949389.JavaMail.zimbra@redhat.com>

That's pretty rubbish though. Say I've got a desktop, a laptop and a mobile, and they're all logged-in with a remember-me cookie. Then I use a friends or a library computer, and after I've clicked logout there I'm logged out everywhere. That's really annoying, especially for mobiles.

----- 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, 1 May, 2014 2:05:28 PM
> Subject: Re: [keycloak-dev] Account management requirements for beta1
> 
> 
> 
> On 5/1/2014 5:28 AM, Stian Thorgersen wrote:
> > As long as we have a way for users to invalidate everything in accnt mngmt
> > I agree that's sufficient.
> >
> > Setting UserModel.notBefore on user logout, would that not invalidation the
> > session on other devices/browsers as well?
> >
> 
> Yes, for those apps that don't have an HTTP session that can be
> invalidated, they will eventually have to do a refresh and the refresh
> token would be invalid which would force a relog.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu May  1 09:13:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 09:13:11 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <53624741.10601@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>
	<53624741.10601@redhat.com>
Message-ID: <582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>



----- 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, 1 May, 2014 2:08:17 PM
> Subject: Re: [keycloak-dev] management problems
> 
> cross-realm user doesn't solve the problem of having an integrated admin
> experience for apps like Aerogear UPS.

I know - not really related, just popped into my head while reading your mail

> 
> On 5/1/2014 5:23 AM, Stian Thorgersen wrote:
> > What are the downsides of having a "shared" admin realm?
> >
> > We can fine-grained access control, so individual admins/users can be
> > limited to only manage certain realms (or none at all).
> >
> > Another related thing is I wonder if we could share users (and maybe even
> > do sso) cross realms? I can imagine situations where people wants multiple
> > realms to manage token settings, social settings, applications, etc, but
> > still want to let users have a single account, instead of one per-realm.
> > We already support authenticating users with a different realm, but I was
> > wondering if we could make it a more integrated feature, as well as
> > support sso.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 1 May, 2014 3:37:46 AM
> >> Subject: [keycloak-dev] management problems
> >>
> >> Our current "master realm" structure/design is deficient.  Consider an
> >> application like UPS that wants to use Keycloak to manage users.  This
> >> application would also have its own management console whose security is
> >> also managed by keycloak.
> >>
> >> My first thought is that you could define the application's management
> >> console as an application in the "master" keycloak realm.  This solution
> >> isn't a great one if the keycloak server is managing multiple realms.
> >> So, IMO not something we should recommend.
> >>
> >> Another option is to define admin roles within the application's realm
> >> itself.  These roles are assignable to users within the realm.  This
> >> would require rethinking of the Angular JS admin console and how things
> >> are authenticated and how people log-in.  We should probably treat this
> >> as SSO and have individual applications within the application realm,
> >> for example:
> >>
> >> UPS Realm registered applications:
> >>
> >> realm-management (keycloak admin console)
> >> aerogear-ups-management (ups admin console)
> >>
> >>
> >>
> >>
> >>
> >> --
> >> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu May  1 09:30:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 09:30:06 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>
	<53624741.10601@redhat.com>
	<582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>
Message-ID: <50138451.15616257.1398951006761.JavaMail.zimbra@redhat.com>

I'm wondering about what issues there are with having a single shared admin realm though. That seems the optional solution to me.

Thinking about the unified console project that Thomas is in charge off it should be possible to login to have SSO to all admin consoles. For example SSO across EAP, Keycloak, AeroGear, consoles.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 1 May, 2014 2:13:11 PM
> Subject: Re: [keycloak-dev] management problems
> 
> 
> 
> ----- 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, 1 May, 2014 2:08:17 PM
> > Subject: Re: [keycloak-dev] management problems
> > 
> > cross-realm user doesn't solve the problem of having an integrated admin
> > experience for apps like Aerogear UPS.
> 
> I know - not really related, just popped into my head while reading your mail
> 
> > 
> > On 5/1/2014 5:23 AM, Stian Thorgersen wrote:
> > > What are the downsides of having a "shared" admin realm?
> > >
> > > We can fine-grained access control, so individual admins/users can be
> > > limited to only manage certain realms (or none at all).
> > >
> > > Another related thing is I wonder if we could share users (and maybe even
> > > do sso) cross realms? I can imagine situations where people wants
> > > multiple
> > > realms to manage token settings, social settings, applications, etc, but
> > > still want to let users have a single account, instead of one per-realm.
> > > We already support authenticating users with a different realm, but I was
> > > wondering if we could make it a more integrated feature, as well as
> > > support sso.
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: keycloak-dev at lists.jboss.org
> > >> Sent: Thursday, 1 May, 2014 3:37:46 AM
> > >> Subject: [keycloak-dev] management problems
> > >>
> > >> Our current "master realm" structure/design is deficient.  Consider an
> > >> application like UPS that wants to use Keycloak to manage users.  This
> > >> application would also have its own management console whose security is
> > >> also managed by keycloak.
> > >>
> > >> My first thought is that you could define the application's management
> > >> console as an application in the "master" keycloak realm.  This solution
> > >> isn't a great one if the keycloak server is managing multiple realms.
> > >> So, IMO not something we should recommend.
> > >>
> > >> Another option is to define admin roles within the application's realm
> > >> itself.  These roles are assignable to users within the realm.  This
> > >> would require rethinking of the Angular JS admin console and how things
> > >> are authenticated and how people log-in.  We should probably treat this
> > >> as SSO and have individual applications within the application realm,
> > >> for example:
> > >>
> > >> UPS Realm registered applications:
> > >>
> > >> realm-management (keycloak admin console)
> > >> aerogear-ups-management (ups admin console)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> 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
> > >>
> > 
> > --
> > 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
> 

From stian at redhat.com  Thu May  1 09:45:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 09:45:06 -0400 (EDT)
Subject: [keycloak-dev] Plan for final release
In-Reply-To: <1430647213.15617740.1398951092144.JavaMail.zimbra@redhat.com>
Message-ID: <1152903569.15631853.1398951906475.JavaMail.zimbra@redhat.com>

What are the general plans for the final release in June. I think we need to finish of the crucial features asap for beta1, then have a release cycle each for performance, testing and security. What about the following release schedule:

* 12 May Beta1 - Feature freeze 
* 19 May Beta2 - Performance
* 26 May Beta3 - Testing
* 2 June RC1 - Security
* 16 June Final

With regards to Beta1 what are the outstanding required features? Those I can think of are:

* Brute force protection - what's the status on this?
* Import/export - Marek has started work on this
* Logout everything through acct mngmt - invalidate grants, refresh tokens, cookies, etc for user
* Dependencies for EAP - including support for Resteasy 2.3.6
* Two WARs bootstrapping example for AeroGear
* LDAP integration - Marek is pretty much done with this

Lower priority features:

* Email on events - email user/admin on various events, for example if brute force protection suspects someone is trying to hack the account
* Social login remember me
* Single-sign out for JS adapter
* Add realm option to enable/disable "Resource Owner Password Credentials Grant"
* Filter what events are audited
* Expose/Embed Version information

From bburke at redhat.com  Thu May  1 09:58:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 09:58:43 -0400
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <939505715.15603944.1398949949389.JavaMail.zimbra@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
	<53613FC1.3050006@redhat.com>
	<1890253881.15538720.1398936521101.JavaMail.zimbra@redhat.com>
	<53624698.9070807@redhat.com>
	<939505715.15603944.1398949949389.JavaMail.zimbra@redhat.com>
Message-ID: <53625313.2090005@redhat.com>

How do you propose single logout works then?  You want single log out to 
be a single click, not a questionaire on which apps to log out of.

On 5/1/2014 9:12 AM, Stian Thorgersen wrote:
> That's pretty rubbish though. Say I've got a desktop, a laptop and a mobile, and they're all logged-in with a remember-me cookie. Then I use a friends or a library computer, and after I've clicked logout there I'm logged out everywhere. That's really annoying, especially for mobiles.
>
> ----- 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, 1 May, 2014 2:05:28 PM
>> Subject: Re: [keycloak-dev] Account management requirements for beta1
>>
>>
>>
>> On 5/1/2014 5:28 AM, Stian Thorgersen wrote:
>>> As long as we have a way for users to invalidate everything in accnt mngmt
>>> I agree that's sufficient.
>>>
>>> Setting UserModel.notBefore on user logout, would that not invalidation the
>>> session on other devices/browsers as well?
>>>
>>
>> Yes, for those apps that don't have an HTTP session that can be
>> invalidated, they will eventually have to do a refresh and the refresh
>> token would be invalid which would force a relog.
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May  1 10:06:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 10:06:45 -0400
Subject: [keycloak-dev] Plan for final release
In-Reply-To: <1152903569.15631853.1398951906475.JavaMail.zimbra@redhat.com>
References: <1152903569.15631853.1398951906475.JavaMail.zimbra@redhat.com>
Message-ID: <536254F5.2090806@redhat.com>



On 5/1/2014 9:45 AM, Stian Thorgersen wrote:
> What are the general plans for the final release in June. I think we need to finish of the crucial features asap for beta1, then have a release cycle each for performance, testing and security. What about the following release schedule:
>
> * 12 May Beta1 - Feature freeze
> * 19 May Beta2 - Performance
> * 26 May Beta3 - Testing
> * 2 June RC1 - Security
> * 16 June Final
>
> With regards to Beta1 what are the outstanding required features? Those I can think of are:
>
> * Brute force protection - what's the status on this?

I'm not sure brute force protection is such a high priority as long as 
we log the appropriate information to log files.  Go check out fail2ban. 
  You can set up fail2ban to change firewall rules and stuff.  But, I'm 
also not sure how scalable fail2ban is.

That said, I do have user-failure based brute-force detection.  It 
works, but i need to add some unit tests.  I still need to implement IP 
based filtering (like fail2ban does).

> * Import/export - Marek has started work on this
> * Logout everything through acct mngmt - invalidate grants, refresh tokens, cookies, etc for user
> * Dependencies for EAP - including support for Resteasy 2.3.6
> * Two WARs bootstrapping example for AeroGear
> * LDAP integration - Marek is pretty much done with this
>

I'm working on aerogear requirements.  This may be more work than we 
thought (see other thread).

> Lower priority features:
>
> * Email on events - email user/admin on various events, for example if brute force protection suspects someone is trying to hack the account
> * Social login remember me
> * Single-sign out for JS adapter

SSO for JS adapter can work by setting a User.notBefore on a logout with 
short access tokens.  Iframe might work (see OpenID connect spec).


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May  1 10:11:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 10:11:48 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <50138451.15616257.1398951006761.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>
	<53624741.10601@redhat.com>
	<582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>
	<50138451.15616257.1398951006761.JavaMail.zimbra@redhat.com>
Message-ID: <53625624.5060702@redhat.com>



On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
> I'm wondering about what issues there are with having a single shared admin realm though. That seems the optional solution to me.
>

Isn't the issue multi-tenancy?

> Thinking about the unified console project that Thomas is in charge off it should be possible to login to have SSO to all admin consoles. For example SSO across EAP, Keycloak, AeroGear, consoles.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 1 May, 2014 2:13:11 PM
>> Subject: Re: [keycloak-dev] management problems
>>
>>
>>
>> ----- 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, 1 May, 2014 2:08:17 PM
>>> Subject: Re: [keycloak-dev] management problems
>>>
>>> cross-realm user doesn't solve the problem of having an integrated admin
>>> experience for apps like Aerogear UPS.
>>
>> I know - not really related, just popped into my head while reading your mail
>>
>>>
>>> On 5/1/2014 5:23 AM, Stian Thorgersen wrote:
>>>> What are the downsides of having a "shared" admin realm?
>>>>
>>>> We can fine-grained access control, so individual admins/users can be
>>>> limited to only manage certain realms (or none at all).
>>>>
>>>> Another related thing is I wonder if we could share users (and maybe even
>>>> do sso) cross realms? I can imagine situations where people wants
>>>> multiple
>>>> realms to manage token settings, social settings, applications, etc, but
>>>> still want to let users have a single account, instead of one per-realm.
>>>> We already support authenticating users with a different realm, but I was
>>>> wondering if we could make it a more integrated feature, as well as
>>>> support sso.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, 1 May, 2014 3:37:46 AM
>>>>> Subject: [keycloak-dev] management problems
>>>>>
>>>>> Our current "master realm" structure/design is deficient.  Consider an
>>>>> application like UPS that wants to use Keycloak to manage users.  This
>>>>> application would also have its own management console whose security is
>>>>> also managed by keycloak.
>>>>>
>>>>> My first thought is that you could define the application's management
>>>>> console as an application in the "master" keycloak realm.  This solution
>>>>> isn't a great one if the keycloak server is managing multiple realms.
>>>>> So, IMO not something we should recommend.
>>>>>
>>>>> Another option is to define admin roles within the application's realm
>>>>> itself.  These roles are assignable to users within the realm.  This
>>>>> would require rethinking of the Angular JS admin console and how things
>>>>> are authenticated and how people log-in.  We should probably treat this
>>>>> as SSO and have individual applications within the application realm,
>>>>> for example:
>>>>>
>>>>> UPS Realm registered applications:
>>>>>
>>>>> realm-management (keycloak admin console)
>>>>> aerogear-ups-management (ups admin console)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>
>>> --
>>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu May  1 10:14:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 10:14:47 -0400 (EDT)
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <53625313.2090005@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
	<53613FC1.3050006@redhat.com>
	<1890253881.15538720.1398936521101.JavaMail.zimbra@redhat.com>
	<53624698.9070807@redhat.com>
	<939505715.15603944.1398949949389.JavaMail.zimbra@redhat.com>
	<53625313.2090005@redhat.com>
Message-ID: <1818378756.15653227.1398953687213.JavaMail.zimbra@redhat.com>

Yes, it should log out from all applications and clients, but not all devices.

To confirm, resources to invalidate includes:

* Refresh tokens
* Identity cookie
* Remember-me cookie

What about when a user logs in we create a unique "login-code" for that device that is stored in the identity cookie. All refresh tokens and remember-me cookies are then associated with this code as well. A UserModel would have a list of valid "login-codes", and on a standard logout the "login-code" from the current identity cookie would be removed from the UserModel. This would invalidate all refresh tokens and cookies created for that particular device/browser.

In account management we'd have an additional option to log out everything. Doing this would set the notBefore on the UserModel to "now", as well as remove all "login-codes". This would invalidate all current refresh tokens and cookies for all devices/browsers.

With regards to OAuth Grants, as we don't currently remember what grants a user has given to a client I don't think we need to add anything in account management for it. Once we remember grants then we should also allow users to view and revoke grants.

----- 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, 1 May, 2014 2:58:43 PM
> Subject: Re: [keycloak-dev] Account management requirements for beta1
> 
> How do you propose single logout works then?  You want single log out to
> be a single click, not a questionaire on which apps to log out of.
> 
> On 5/1/2014 9:12 AM, Stian Thorgersen wrote:
> > That's pretty rubbish though. Say I've got a desktop, a laptop and a
> > mobile, and they're all logged-in with a remember-me cookie. Then I use a
> > friends or a library computer, and after I've clicked logout there I'm
> > logged out everywhere. That's really annoying, especially for mobiles.
> >
> > ----- 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, 1 May, 2014 2:05:28 PM
> >> Subject: Re: [keycloak-dev] Account management requirements for beta1
> >>
> >>
> >>
> >> On 5/1/2014 5:28 AM, Stian Thorgersen wrote:
> >>> As long as we have a way for users to invalidate everything in accnt
> >>> mngmt
> >>> I agree that's sufficient.
> >>>
> >>> Setting UserModel.notBefore on user logout, would that not invalidation
> >>> the
> >>> session on other devices/browsers as well?
> >>>
> >>
> >> Yes, for those apps that don't have an HTTP session that can be
> >> invalidated, they will eventually have to do a refresh and the refresh
> >> token would be invalid which would force a relog.
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu May  1 10:16:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 10:16:19 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <53625624.5060702@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>
	<53624741.10601@redhat.com>
	<582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>
	<50138451.15616257.1398951006761.JavaMail.zimbra@redhat.com>
	<53625624.5060702@redhat.com>
Message-ID: <434350216.15653859.1398953779196.JavaMail.zimbra@redhat.com>



----- 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, 1 May, 2014 3:11:48 PM
> Subject: Re: [keycloak-dev] management problems
> 
> 
> 
> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
> > I'm wondering about what issues there are with having a single shared admin
> > realm though. That seems the optional solution to me.
> >
> 
> Isn't the issue multi-tenancy?

We can grant admin users access to manage only specific realms though?

Or are you thinking multi-tenancy for AeroGear?

> 
> > Thinking about the unified console project that Thomas is in charge off it
> > should be possible to login to have SSO to all admin consoles. For example
> > SSO across EAP, Keycloak, AeroGear, consoles.
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 1 May, 2014 2:13:11 PM
> >> Subject: Re: [keycloak-dev] management problems
> >>
> >>
> >>
> >> ----- 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, 1 May, 2014 2:08:17 PM
> >>> Subject: Re: [keycloak-dev] management problems
> >>>
> >>> cross-realm user doesn't solve the problem of having an integrated admin
> >>> experience for apps like Aerogear UPS.
> >>
> >> I know - not really related, just popped into my head while reading your
> >> mail
> >>
> >>>
> >>> On 5/1/2014 5:23 AM, Stian Thorgersen wrote:
> >>>> What are the downsides of having a "shared" admin realm?
> >>>>
> >>>> We can fine-grained access control, so individual admins/users can be
> >>>> limited to only manage certain realms (or none at all).
> >>>>
> >>>> Another related thing is I wonder if we could share users (and maybe
> >>>> even
> >>>> do sso) cross realms? I can imagine situations where people wants
> >>>> multiple
> >>>> realms to manage token settings, social settings, applications, etc, but
> >>>> still want to let users have a single account, instead of one per-realm.
> >>>> We already support authenticating users with a different realm, but I
> >>>> was
> >>>> wondering if we could make it a more integrated feature, as well as
> >>>> support sso.
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: keycloak-dev at lists.jboss.org
> >>>>> Sent: Thursday, 1 May, 2014 3:37:46 AM
> >>>>> Subject: [keycloak-dev] management problems
> >>>>>
> >>>>> Our current "master realm" structure/design is deficient.  Consider an
> >>>>> application like UPS that wants to use Keycloak to manage users.  This
> >>>>> application would also have its own management console whose security
> >>>>> is
> >>>>> also managed by keycloak.
> >>>>>
> >>>>> My first thought is that you could define the application's management
> >>>>> console as an application in the "master" keycloak realm.  This
> >>>>> solution
> >>>>> isn't a great one if the keycloak server is managing multiple realms.
> >>>>> So, IMO not something we should recommend.
> >>>>>
> >>>>> Another option is to define admin roles within the application's realm
> >>>>> itself.  These roles are assignable to users within the realm.  This
> >>>>> would require rethinking of the Angular JS admin console and how things
> >>>>> are authenticated and how people log-in.  We should probably treat this
> >>>>> as SSO and have individual applications within the application realm,
> >>>>> for example:
> >>>>>
> >>>>> UPS Realm registered applications:
> >>>>>
> >>>>> realm-management (keycloak admin console)
> >>>>> aerogear-ups-management (ups admin console)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> 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
> >>>>>
> >>>
> >>> --
> >>> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu May  1 11:19:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 11:19:26 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <434350216.15653859.1398953779196.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>
	<53624741.10601@redhat.com>
	<582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>
	<50138451.15616257.1398951006761.JavaMail.zimbra@redhat.com>
	<53625624.5060702@redhat.com>
	<434350216.15653859.1398953779196.JavaMail.zimbra@redhat.com>
Message-ID: <536265FE.7010503@redhat.com>



On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
>> Subject: Re: [keycloak-dev] management problems
>>
>>
>>
>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
>>> I'm wondering about what issues there are with having a single shared admin
>>> realm though. That seems the optional solution to me.
>>>
>>
>> Isn't the issue multi-tenancy?
>
> We can grant admin users access to manage only specific realms though?
>
> Or are you thinking multi-tenancy for AeroGear?

What I mean is that you want to manage Aerogear in a realm on a server 
that is multi-tenant (1 server managing multiple realms).  Can't really 
have a single shared admin realm in that case.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu May  1 11:24:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 11:24:40 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <536265FE.7010503@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>
	<53624741.10601@redhat.com>
	<582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>
	<50138451.15616257.1398951006761.JavaMail.zimbra@redhat.com>
	<53625624.5060702@redhat.com>
	<434350216.15653859.1398953779196.JavaMail.zimbra@redhat.com>
	<536265FE.7010503@redhat.com>
Message-ID: <1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>



----- 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, 1 May, 2014 4:19:26 PM
> Subject: Re: [keycloak-dev] management problems
> 
> 
> 
> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
> >> Subject: Re: [keycloak-dev] management problems
> >>
> >>
> >>
> >> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
> >>> I'm wondering about what issues there are with having a single shared
> >>> admin
> >>> realm though. That seems the optional solution to me.
> >>>
> >>
> >> Isn't the issue multi-tenancy?
> >
> > We can grant admin users access to manage only specific realms though?
> >
> > Or are you thinking multi-tenancy for AeroGear?
> 
> What I mean is that you want to manage Aerogear in a realm on a server
> that is multi-tenant (1 server managing multiple realms).  Can't really
> have a single shared admin realm in that case.

I'm still not following :/

Can you spoon-feed me an example?

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu May  1 11:37:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 11:37:39 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<410057464.15537994.1398936220965.JavaMail.zimbra@redhat.com>
	<53624741.10601@redhat.com>
	<582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>
	<50138451.15616257.1398951006761.JavaMail.zimbra@redhat.com>
	<53625624.5060702@redhat.com>
	<434350216.15653859.1398953779196.JavaMail.zimbra@redhat.com>
	<536265FE.7010503@redhat.com>
	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>
Message-ID: <53626A43.3060208@redhat.com>



On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
>> Subject: Re: [keycloak-dev] management problems
>>
>>
>>
>> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
>>>> Subject: Re: [keycloak-dev] management problems
>>>>
>>>>
>>>>
>>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
>>>>> I'm wondering about what issues there are with having a single shared
>>>>> admin
>>>>> realm though. That seems the optional solution to me.
>>>>>
>>>>
>>>> Isn't the issue multi-tenancy?
>>>
>>> We can grant admin users access to manage only specific realms though?
>>>
>>> Or are you thinking multi-tenancy for AeroGear?
>>
>> What I mean is that you want to manage Aerogear in a realm on a server
>> that is multi-tenant (1 server managing multiple realms).  Can't really
>> have a single shared admin realm in that case.
>
> I'm still not following :/
>
> Can you spoon-feed me an example?
>

Aerogear UPS admin needs to:

* manage users
* manage role mappings
* manage oauth clients
* Manage aerogear specific things

You want to have one login to do all those things.  This means there 
needs to be one realm to do all these things.  You could re-use the 
"keycloak-admin" realm, but re-using the "keycloak-admin" realm doesn't 
work if you're dealing with a Keycloak deployment that is managing 
multiple realms.  A.K.A.  Multi-tenancy.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu May  1 11:41:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 11:41:30 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <53626A43.3060208@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>
	<50138451.15616257.1398951006761.JavaMail.zimbra@redhat.com>
	<53625624.5060702@redhat.com>
	<434350216.15653859.1398953779196.JavaMail.zimbra@redhat.com>
	<536265FE.7010503@redhat.com>
	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>
	<53626A43.3060208@redhat.com>
Message-ID: <1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>



----- 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, 1 May, 2014 4:37:39 PM
> Subject: Re: [keycloak-dev] management problems
> 
> 
> 
> On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
> >> Subject: Re: [keycloak-dev] management problems
> >>
> >>
> >>
> >> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
> >>>> Subject: Re: [keycloak-dev] management problems
> >>>>
> >>>>
> >>>>
> >>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
> >>>>> I'm wondering about what issues there are with having a single shared
> >>>>> admin
> >>>>> realm though. That seems the optional solution to me.
> >>>>>
> >>>>
> >>>> Isn't the issue multi-tenancy?
> >>>
> >>> We can grant admin users access to manage only specific realms though?
> >>>
> >>> Or are you thinking multi-tenancy for AeroGear?
> >>
> >> What I mean is that you want to manage Aerogear in a realm on a server
> >> that is multi-tenant (1 server managing multiple realms).  Can't really
> >> have a single shared admin realm in that case.
> >
> > I'm still not following :/
> >
> > Can you spoon-feed me an example?
> >
> 
> Aerogear UPS admin needs to:
> 
> * manage users
> * manage role mappings
> * manage oauth clients
> * Manage aerogear specific things
> 
> You want to have one login to do all those things.  This means there
> needs to be one realm to do all these things.  You could re-use the
> "keycloak-admin" realm, but re-using the "keycloak-admin" realm doesn't
> work if you're dealing with a Keycloak deployment that is managing
> multiple realms.  A.K.A.  Multi-tenancy.

The part I'm not understanding is why it doesn't work with a Keycloak deployment with multiple realms?

> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu May  1 11:47:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 11:47:24 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<582220329.15604310.1398949991111.JavaMail.zimbra@redhat.com>
	<50138451.15616257.1398951006761.JavaMail.zimbra@redhat.com>
	<53625624.5060702@redhat.com>
	<434350216.15653859.1398953779196.JavaMail.zimbra@redhat.com>
	<536265FE.7010503@redhat.com>
	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>
	<53626A43.3060208@redhat.com>
	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>
Message-ID: <53626C8C.4070605@redhat.com>



On 5/1/2014 11:41 AM, 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, 1 May, 2014 4:37:39 PM
>> Subject: Re: [keycloak-dev] management problems
>>
>>
>>
>> On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
>>>> Subject: Re: [keycloak-dev] management problems
>>>>
>>>>
>>>>
>>>> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
>>>>>>> I'm wondering about what issues there are with having a single shared
>>>>>>> admin
>>>>>>> realm though. That seems the optional solution to me.
>>>>>>>
>>>>>>
>>>>>> Isn't the issue multi-tenancy?
>>>>>
>>>>> We can grant admin users access to manage only specific realms though?
>>>>>
>>>>> Or are you thinking multi-tenancy for AeroGear?
>>>>
>>>> What I mean is that you want to manage Aerogear in a realm on a server
>>>> that is multi-tenant (1 server managing multiple realms).  Can't really
>>>> have a single shared admin realm in that case.
>>>
>>> I'm still not following :/
>>>
>>> Can you spoon-feed me an example?
>>>
>>
>> Aerogear UPS admin needs to:
>>
>> * manage users
>> * manage role mappings
>> * manage oauth clients
>> * Manage aerogear specific things
>>
>> You want to have one login to do all those things.  This means there
>> needs to be one realm to do all these things.  You could re-use the
>> "keycloak-admin" realm, but re-using the "keycloak-admin" realm doesn't
>> work if you're dealing with a Keycloak deployment that is managing
>> multiple realms.  A.K.A.  Multi-tenancy.
>
> The part I'm not understanding is why it doesn't work with a Keycloak deployment with multiple realms?
>

Because you're polluting the "keycloak-admin" realm with Aerogear 
specific things: users, roles, applications, etc.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu May  1 11:49:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 11:49:50 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <53626C8C.4070605@redhat.com>
References: <5361B37A.7080203@redhat.com> <53625624.5060702@redhat.com>
	<434350216.15653859.1398953779196.JavaMail.zimbra@redhat.com>
	<536265FE.7010503@redhat.com>
	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>
	<53626A43.3060208@redhat.com>
	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>
	<53626C8C.4070605@redhat.com>
Message-ID: <27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>

Is that really an issue?

Users would just be admin users, there would be a separate realm for AeroGear users.

And there'd probably be a single AeroGear console application, with a few associated roles.

----- 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, 1 May, 2014 4:47:24 PM
> Subject: Re: [keycloak-dev] management problems
> 
> 
> 
> On 5/1/2014 11:41 AM, 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, 1 May, 2014 4:37:39 PM
> >> Subject: Re: [keycloak-dev] management problems
> >>
> >>
> >>
> >> On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
> >>>> Subject: Re: [keycloak-dev] management problems
> >>>>
> >>>>
> >>>>
> >>>> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
> >>>>>> Subject: Re: [keycloak-dev] management problems
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
> >>>>>>> I'm wondering about what issues there are with having a single shared
> >>>>>>> admin
> >>>>>>> realm though. That seems the optional solution to me.
> >>>>>>>
> >>>>>>
> >>>>>> Isn't the issue multi-tenancy?
> >>>>>
> >>>>> We can grant admin users access to manage only specific realms though?
> >>>>>
> >>>>> Or are you thinking multi-tenancy for AeroGear?
> >>>>
> >>>> What I mean is that you want to manage Aerogear in a realm on a server
> >>>> that is multi-tenant (1 server managing multiple realms).  Can't really
> >>>> have a single shared admin realm in that case.
> >>>
> >>> I'm still not following :/
> >>>
> >>> Can you spoon-feed me an example?
> >>>
> >>
> >> Aerogear UPS admin needs to:
> >>
> >> * manage users
> >> * manage role mappings
> >> * manage oauth clients
> >> * Manage aerogear specific things
> >>
> >> You want to have one login to do all those things.  This means there
> >> needs to be one realm to do all these things.  You could re-use the
> >> "keycloak-admin" realm, but re-using the "keycloak-admin" realm doesn't
> >> work if you're dealing with a Keycloak deployment that is managing
> >> multiple realms.  A.K.A.  Multi-tenancy.
> >
> > The part I'm not understanding is why it doesn't work with a Keycloak
> > deployment with multiple realms?
> >
> 
> Because you're polluting the "keycloak-admin" realm with Aerogear
> specific things: users, roles, applications, etc.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu May  1 11:57:36 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 11:57:36 -0400 (EDT)
Subject: [keycloak-dev] Plan for final release
In-Reply-To: <536254F5.2090806@redhat.com>
References: <1152903569.15631853.1398951906475.JavaMail.zimbra@redhat.com>
	<536254F5.2090806@redhat.com>
Message-ID: <919977608.15708638.1398959856335.JavaMail.zimbra@redhat.com>

I agree brute force protection is probably a lower priority for beta1, especially if we can integrate with something like fail2ban. Fail2ban looks pretty cool, and I think we can easily integrate with that as we can either use the JBoss Logging Audit Listener to create the log files required, or create a custom one that generates log files more customized for fail2ban. In the future though I think it would be nicer to have built-in support for this written in Java, which should make it easier to use and more portable.

In fact that's what I had in mind initially with the audit listeners. That you'd be able to listen to events in the system and re-act accordingly. I was imagining that would be used by the brute protection to listen for failed login events. I should probably rename audit Listener to event Listener to make that clear though.

If you're happy with the other high/low priority issues, as well as the release schedule I proposed, I can update JIRA to reflect this.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 1 May, 2014 3:06:45 PM
> Subject: Re: [keycloak-dev] Plan for final release
> 
> 
> 
> On 5/1/2014 9:45 AM, Stian Thorgersen wrote:
> > What are the general plans for the final release in June. I think we need
> > to finish of the crucial features asap for beta1, then have a release
> > cycle each for performance, testing and security. What about the following
> > release schedule:
> >
> > * 12 May Beta1 - Feature freeze
> > * 19 May Beta2 - Performance
> > * 26 May Beta3 - Testing
> > * 2 June RC1 - Security
> > * 16 June Final
> >
> > With regards to Beta1 what are the outstanding required features? Those I
> > can think of are:
> >
> > * Brute force protection - what's the status on this?
> 
> I'm not sure brute force protection is such a high priority as long as
> we log the appropriate information to log files.  Go check out fail2ban.
>   You can set up fail2ban to change firewall rules and stuff.  But, I'm
> also not sure how scalable fail2ban is.
> 
> That said, I do have user-failure based brute-force detection.  It
> works, but i need to add some unit tests.  I still need to implement IP
> based filtering (like fail2ban does).
> 
> > * Import/export - Marek has started work on this
> > * Logout everything through acct mngmt - invalidate grants, refresh tokens,
> > cookies, etc for user
> > * Dependencies for EAP - including support for Resteasy 2.3.6
> > * Two WARs bootstrapping example for AeroGear
> > * LDAP integration - Marek is pretty much done with this
> >
> 
> I'm working on aerogear requirements.  This may be more work than we
> thought (see other thread).
> 
> > Lower priority features:
> >
> > * Email on events - email user/admin on various events, for example if
> > brute force protection suspects someone is trying to hack the account
> > * Social login remember me
> > * Single-sign out for JS adapter
> 
> SSO for JS adapter can work by setting a User.notBefore on a logout with
> short access tokens.  Iframe might work (see OpenID connect spec).
> 
> 
> --
> 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
> 

From bburke at redhat.com  Thu May  1 12:06:42 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 12:06:42 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com> <53625624.5060702@redhat.com>
	<434350216.15653859.1398953779196.JavaMail.zimbra@redhat.com>
	<536265FE.7010503@redhat.com>
	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>
	<53626A43.3060208@redhat.com>
	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>
	<53626C8C.4070605@redhat.com>
	<27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>
Message-ID: <53627112.8090408@redhat.com>

Yes, as you would have to know to switch between realms.  Defeats the 
idea of Aerogear looking like one product.

On 5/1/2014 11:49 AM, Stian Thorgersen wrote:
> Is that really an issue?
>
> Users would just be admin users, there would be a separate realm for AeroGear users.
>
> And there'd probably be a single AeroGear console application, with a few associated roles.
>
> ----- 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, 1 May, 2014 4:47:24 PM
>> Subject: Re: [keycloak-dev] management problems
>>
>>
>>
>> On 5/1/2014 11:41 AM, 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, 1 May, 2014 4:37:39 PM
>>>> Subject: Re: [keycloak-dev] management problems
>>>>
>>>>
>>>>
>>>> On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
>>>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
>>>>>>>>> I'm wondering about what issues there are with having a single shared
>>>>>>>>> admin
>>>>>>>>> realm though. That seems the optional solution to me.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Isn't the issue multi-tenancy?
>>>>>>>
>>>>>>> We can grant admin users access to manage only specific realms though?
>>>>>>>
>>>>>>> Or are you thinking multi-tenancy for AeroGear?
>>>>>>
>>>>>> What I mean is that you want to manage Aerogear in a realm on a server
>>>>>> that is multi-tenant (1 server managing multiple realms).  Can't really
>>>>>> have a single shared admin realm in that case.
>>>>>
>>>>> I'm still not following :/
>>>>>
>>>>> Can you spoon-feed me an example?
>>>>>
>>>>
>>>> Aerogear UPS admin needs to:
>>>>
>>>> * manage users
>>>> * manage role mappings
>>>> * manage oauth clients
>>>> * Manage aerogear specific things
>>>>
>>>> You want to have one login to do all those things.  This means there
>>>> needs to be one realm to do all these things.  You could re-use the
>>>> "keycloak-admin" realm, but re-using the "keycloak-admin" realm doesn't
>>>> work if you're dealing with a Keycloak deployment that is managing
>>>> multiple realms.  A.K.A.  Multi-tenancy.
>>>
>>> The part I'm not understanding is why it doesn't work with a Keycloak
>>> deployment with multiple realms?
>>>
>>
>> Because you're polluting the "keycloak-admin" realm with Aerogear
>> specific things: users, roles, applications, etc.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May  1 12:12:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 12:12:32 -0400
Subject: [keycloak-dev] Plan for final release
In-Reply-To: <919977608.15708638.1398959856335.JavaMail.zimbra@redhat.com>
References: <1152903569.15631853.1398951906475.JavaMail.zimbra@redhat.com>
	<536254F5.2090806@redhat.com>
	<919977608.15708638.1398959856335.JavaMail.zimbra@redhat.com>
Message-ID: <53627270.8080002@redhat.com>

Brute force needs to be integrated with code as it has to refuse before 
the login screen is even shown (by IP address) or after the user 
attempts to login (by username).

I really want the ability to redirect the user to a account management 
warning screen that says something like "You logged into your account 
from China.  Was that you?  If not, you might want to change your 
credentials".

On 5/1/2014 11:57 AM, Stian Thorgersen wrote:
> I agree brute force protection is probably a lower priority for beta1, especially if we can integrate with something like fail2ban. Fail2ban looks pretty cool, and I think we can easily integrate with that as we can either use the JBoss Logging Audit Listener to create the log files required, or create a custom one that generates log files more customized for fail2ban. In the future though I think it would be nicer to have built-in support for this written in Java, which should make it easier to use and more portable.
>
> In fact that's what I had in mind initially with the audit listeners. That you'd be able to listen to events in the system and re-act accordingly. I was imagining that would be used by the brute protection to listen for failed login events. I should probably rename audit Listener to event Listener to make that clear though.
>
> If you're happy with the other high/low priority issues, as well as the release schedule I proposed, I can update JIRA to reflect this.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 1 May, 2014 3:06:45 PM
>> Subject: Re: [keycloak-dev] Plan for final release
>>
>>
>>
>> On 5/1/2014 9:45 AM, Stian Thorgersen wrote:
>>> What are the general plans for the final release in June. I think we need
>>> to finish of the crucial features asap for beta1, then have a release
>>> cycle each for performance, testing and security. What about the following
>>> release schedule:
>>>
>>> * 12 May Beta1 - Feature freeze
>>> * 19 May Beta2 - Performance
>>> * 26 May Beta3 - Testing
>>> * 2 June RC1 - Security
>>> * 16 June Final
>>>
>>> With regards to Beta1 what are the outstanding required features? Those I
>>> can think of are:
>>>
>>> * Brute force protection - what's the status on this?
>>
>> I'm not sure brute force protection is such a high priority as long as
>> we log the appropriate information to log files.  Go check out fail2ban.
>>    You can set up fail2ban to change firewall rules and stuff.  But, I'm
>> also not sure how scalable fail2ban is.
>>
>> That said, I do have user-failure based brute-force detection.  It
>> works, but i need to add some unit tests.  I still need to implement IP
>> based filtering (like fail2ban does).
>>
>>> * Import/export - Marek has started work on this
>>> * Logout everything through acct mngmt - invalidate grants, refresh tokens,
>>> cookies, etc for user
>>> * Dependencies for EAP - including support for Resteasy 2.3.6
>>> * Two WARs bootstrapping example for AeroGear
>>> * LDAP integration - Marek is pretty much done with this
>>>
>>
>> I'm working on aerogear requirements.  This may be more work than we
>> thought (see other thread).
>>
>>> Lower priority features:
>>>
>>> * Email on events - email user/admin on various events, for example if
>>> brute force protection suspects someone is trying to hack the account
>>> * Social login remember me
>>> * Single-sign out for JS adapter
>>
>> SSO for JS adapter can work by setting a User.notBefore on a logout with
>> short access tokens.  Iframe might work (see OpenID connect spec).
>>
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May  1 11:30:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 11:30:08 -0400
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <1818378756.15653227.1398953687213.JavaMail.zimbra@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
	<53613FC1.3050006@redhat.com>
	<1890253881.15538720.1398936521101.JavaMail.zimbra@redhat.com>
	<53624698.9070807@redhat.com>
	<939505715.15603944.1398949949389.JavaMail.zimbra@redhat.com>
	<53625313.2090005@redhat.com>
	<1818378756.15653227.1398953687213.JavaMail.zimbra@redhat.com>
Message-ID: <53626880.4060703@redhat.com>



On 5/1/2014 10:14 AM, Stian Thorgersen wrote:
> Yes, it should log out from all applications and clients, but not all devices.
>

So logout is really a "device" logout.  "Device" being a mobile or 
desktop.  Logging in creates a "login session" for the device you logged 
in with.  A logout from that device logs the user of all applications 
that device has interacted with.


> To confirm, resources to invalidate includes:
>
> * Refresh tokens
> * Identity cookie
> * Remember-me cookie

Also:

* application http sessions.  Which means that we'll have to remember 
which application's HTTP sessions correspond to the "login session" of 
the device used to access the application.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu May  1 14:17:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 14:17:45 -0400 (EDT)
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <53626880.4060703@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
	<53613FC1.3050006@redhat.com>
	<1890253881.15538720.1398936521101.JavaMail.zimbra@redhat.com>
	<53624698.9070807@redhat.com>
	<939505715.15603944.1398949949389.JavaMail.zimbra@redhat.com>
	<53625313.2090005@redhat.com>
	<1818378756.15653227.1398953687213.JavaMail.zimbra@redhat.com>
	<53626880.4060703@redhat.com>
Message-ID: <830537856.15805115.1398968265893.JavaMail.zimbra@redhat.com>



----- 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, 1 May, 2014 4:30:08 PM
> Subject: Re: [keycloak-dev] Account management requirements for beta1
> 
> 
> 
> On 5/1/2014 10:14 AM, Stian Thorgersen wrote:
> > Yes, it should log out from all applications and clients, but not all
> > devices.
> >
> 
> So logout is really a "device" logout.  "Device" being a mobile or
> desktop.  Logging in creates a "login session" for the device you logged
> in with.  A logout from that device logs the user of all applications
> that device has interacted with.

Yep, if a user wants to logout from all devices they have to do so explicitly through the account management console. We could also support this as a query param to the logout url (/tokens/logout?logout_all)?

> 
> 
> > To confirm, resources to invalidate includes:
> >
> > * Refresh tokens
> > * Identity cookie
> > * Remember-me cookie
> 
> Also:
> 
> * application http sessions.  Which means that we'll have to remember
> which application's HTTP sessions correspond to the "login session" of
> the device used to access the application.

I assume this is the http sessions for the adapters, and not Keycloak itself? We could do this by adding the 'login session' id to the token?

> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu May  1 14:21:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 1 May 2014 14:21:59 -0400 (EDT)
Subject: [keycloak-dev] Plan for final release
In-Reply-To: <53627270.8080002@redhat.com>
References: <1152903569.15631853.1398951906475.JavaMail.zimbra@redhat.com>
	<536254F5.2090806@redhat.com>
	<919977608.15708638.1398959856335.JavaMail.zimbra@redhat.com>
	<53627270.8080002@redhat.com>
Message-ID: <1755336567.15809311.1398968519663.JavaMail.zimbra@redhat.com>



----- 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, 1 May, 2014 5:12:32 PM
> Subject: Re: [keycloak-dev] Plan for final release
> 
> Brute force needs to be integrated with code as it has to refuse before
> the login screen is even shown (by IP address) or after the user
> attempts to login (by username).

Could we do it by adding more events? We could have events both before/after login?

That would allow us to plug-in other things to the login-cycle, and you could also re-use the same event handlers for social and SAML logins. We could have built-in event handlers, but also let users register their own through the SPI.

> 
> I really want the ability to redirect the user to a account management
> warning screen that says something like "You logged into your account
> from China.  Was that you?  If not, you might want to change your
> credentials".

Only China? Might be worth considering North Korea as well ;)

> 
> On 5/1/2014 11:57 AM, Stian Thorgersen wrote:
> > I agree brute force protection is probably a lower priority for beta1,
> > especially if we can integrate with something like fail2ban. Fail2ban
> > looks pretty cool, and I think we can easily integrate with that as we can
> > either use the JBoss Logging Audit Listener to create the log files
> > required, or create a custom one that generates log files more customized
> > for fail2ban. In the future though I think it would be nicer to have
> > built-in support for this written in Java, which should make it easier to
> > use and more portable.
> >
> > In fact that's what I had in mind initially with the audit listeners. That
> > you'd be able to listen to events in the system and re-act accordingly. I
> > was imagining that would be used by the brute protection to listen for
> > failed login events. I should probably rename audit Listener to event
> > Listener to make that clear though.
> >
> > If you're happy with the other high/low priority issues, as well as the
> > release schedule I proposed, I can update JIRA to reflect this.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 1 May, 2014 3:06:45 PM
> >> Subject: Re: [keycloak-dev] Plan for final release
> >>
> >>
> >>
> >> On 5/1/2014 9:45 AM, Stian Thorgersen wrote:
> >>> What are the general plans for the final release in June. I think we need
> >>> to finish of the crucial features asap for beta1, then have a release
> >>> cycle each for performance, testing and security. What about the
> >>> following
> >>> release schedule:
> >>>
> >>> * 12 May Beta1 - Feature freeze
> >>> * 19 May Beta2 - Performance
> >>> * 26 May Beta3 - Testing
> >>> * 2 June RC1 - Security
> >>> * 16 June Final
> >>>
> >>> With regards to Beta1 what are the outstanding required features? Those I
> >>> can think of are:
> >>>
> >>> * Brute force protection - what's the status on this?
> >>
> >> I'm not sure brute force protection is such a high priority as long as
> >> we log the appropriate information to log files.  Go check out fail2ban.
> >>    You can set up fail2ban to change firewall rules and stuff.  But, I'm
> >> also not sure how scalable fail2ban is.
> >>
> >> That said, I do have user-failure based brute-force detection.  It
> >> works, but i need to add some unit tests.  I still need to implement IP
> >> based filtering (like fail2ban does).
> >>
> >>> * Import/export - Marek has started work on this
> >>> * Logout everything through acct mngmt - invalidate grants, refresh
> >>> tokens,
> >>> cookies, etc for user
> >>> * Dependencies for EAP - including support for Resteasy 2.3.6
> >>> * Two WARs bootstrapping example for AeroGear
> >>> * LDAP integration - Marek is pretty much done with this
> >>>
> >>
> >> I'm working on aerogear requirements.  This may be more work than we
> >> thought (see other thread).
> >>
> >>> Lower priority features:
> >>>
> >>> * Email on events - email user/admin on various events, for example if
> >>> brute force protection suspects someone is trying to hack the account
> >>> * Social login remember me
> >>> * Single-sign out for JS adapter
> >>
> >> SSO for JS adapter can work by setting a User.notBefore on a logout with
> >> short access tokens.  Iframe might work (see OpenID connect spec).
> >>
> >>
> >> --
> >> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu May  1 14:32:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 14:32:00 -0400
Subject: [keycloak-dev] Plan for final release
In-Reply-To: <1755336567.15809311.1398968519663.JavaMail.zimbra@redhat.com>
References: <1152903569.15631853.1398951906475.JavaMail.zimbra@redhat.com>
	<536254F5.2090806@redhat.com>
	<919977608.15708638.1398959856335.JavaMail.zimbra@redhat.com>
	<53627270.8080002@redhat.com>
	<1755336567.15809311.1398968519663.JavaMail.zimbra@redhat.com>
Message-ID: <53629320.7010004@redhat.com>



On 5/1/2014 2:21 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, 1 May, 2014 5:12:32 PM
>> Subject: Re: [keycloak-dev] Plan for final release
>>
>> Brute force needs to be integrated with code as it has to refuse before
>> the login screen is even shown (by IP address) or after the user
>> attempts to login (by username).
>
> Could we do it by adding more events? We could have events both before/after login?
>
> That would allow us to plug-in other things to the login-cycle, and you could also re-use the same event handlers for social and SAML logins. We could have built-in event handlers, but also let users register their own through the SPI.
>

It would have to be an SPI or something of which any of the interceptors 
could abort the login.
>>
>> I really want the ability to redirect the user to a account management
>> warning screen that says something like "You logged into your account
>> from China.  Was that you?  If not, you might want to change your
>> credentials".
>
> Only China? Might be worth considering North Korea as well ;)
>

My gmail got hacked from China once, so I'm biased against them ;)


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May  1 14:33:29 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 01 May 2014 14:33:29 -0400
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <830537856.15805115.1398968265893.JavaMail.zimbra@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
	<53613FC1.3050006@redhat.com>
	<1890253881.15538720.1398936521101.JavaMail.zimbra@redhat.com>
	<53624698.9070807@redhat.com>
	<939505715.15603944.1398949949389.JavaMail.zimbra@redhat.com>
	<53625313.2090005@redhat.com>
	<1818378756.15653227.1398953687213.JavaMail.zimbra@redhat.com>
	<53626880.4060703@redhat.com>
	<830537856.15805115.1398968265893.JavaMail.zimbra@redhat.com>
Message-ID: <53629379.3040507@redhat.com>



On 5/1/2014 2:17 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, 1 May, 2014 4:30:08 PM
>> Subject: Re: [keycloak-dev] Account management requirements for beta1
>>
>>
>>
>> On 5/1/2014 10:14 AM, Stian Thorgersen wrote:
>>> Yes, it should log out from all applications and clients, but not all
>>> devices.
>>>
>>
>> So logout is really a "device" logout.  "Device" being a mobile or
>> desktop.  Logging in creates a "login session" for the device you logged
>> in with.  A logout from that device logs the user of all applications
>> that device has interacted with.
>
> Yep, if a user wants to logout from all devices they have to do so explicitly through the account management console. We could also support this as a query param to the logout url (/tokens/logout?logout_all)?
>

Cookie should have the login-session information already.

>>
>>
>>> To confirm, resources to invalidate includes:
>>>
>>> * Refresh tokens
>>> * Identity cookie
>>> * Remember-me cookie
>>
>> Also:
>>
>> * application http sessions.  Which means that we'll have to remember
>> which application's HTTP sessions correspond to the "login session" of
>> the device used to access the application.
>
> I assume this is the http sessions for the adapters, and not Keycloak itself? We could do this by adding the 'login session' id to the token?
>

Invalidating an http session requires a callback from the auth server to 
the adapter's server.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May  2 04:23:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 2 May 2014 04:23:30 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <53627112.8090408@redhat.com>
References: <5361B37A.7080203@redhat.com> <536265FE.7010503@redhat.com>
	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>
	<53626A43.3060208@redhat.com>
	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>
	<53626C8C.4070605@redhat.com>
	<27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>
	<53627112.8090408@redhat.com>
Message-ID: <532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>

My thoughts was that admins would log in to a single "admin realm", which would let them manage any Keycloaks, AeroGears, EAPs and any other servers they have.

Then you'd have one or more application realms where end-users would login.

If we don't have AeroGear admins in the same realm as Keycloak admins, admins will have to login multiple times.

So basically I think the AeroGear admin console should be in the Keycloak admin realm, then there's one or more realms for AeroGear users.

----- 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, 1 May, 2014 5:06:42 PM
> Subject: Re: [keycloak-dev] management problems
> 
> Yes, as you would have to know to switch between realms.  Defeats the
> idea of Aerogear looking like one product.
> 
> On 5/1/2014 11:49 AM, Stian Thorgersen wrote:
> > Is that really an issue?
> >
> > Users would just be admin users, there would be a separate realm for
> > AeroGear users.
> >
> > And there'd probably be a single AeroGear console application, with a few
> > associated roles.
> >
> > ----- 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, 1 May, 2014 4:47:24 PM
> >> Subject: Re: [keycloak-dev] management problems
> >>
> >>
> >>
> >> On 5/1/2014 11:41 AM, 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, 1 May, 2014 4:37:39 PM
> >>>> Subject: Re: [keycloak-dev] management problems
> >>>>
> >>>>
> >>>>
> >>>> On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
> >>>>>> Subject: Re: [keycloak-dev] management problems
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
> >>>>>>>> Subject: Re: [keycloak-dev] management problems
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
> >>>>>>>>> I'm wondering about what issues there are with having a single
> >>>>>>>>> shared
> >>>>>>>>> admin
> >>>>>>>>> realm though. That seems the optional solution to me.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Isn't the issue multi-tenancy?
> >>>>>>>
> >>>>>>> We can grant admin users access to manage only specific realms
> >>>>>>> though?
> >>>>>>>
> >>>>>>> Or are you thinking multi-tenancy for AeroGear?
> >>>>>>
> >>>>>> What I mean is that you want to manage Aerogear in a realm on a server
> >>>>>> that is multi-tenant (1 server managing multiple realms).  Can't
> >>>>>> really
> >>>>>> have a single shared admin realm in that case.
> >>>>>
> >>>>> I'm still not following :/
> >>>>>
> >>>>> Can you spoon-feed me an example?
> >>>>>
> >>>>
> >>>> Aerogear UPS admin needs to:
> >>>>
> >>>> * manage users
> >>>> * manage role mappings
> >>>> * manage oauth clients
> >>>> * Manage aerogear specific things
> >>>>
> >>>> You want to have one login to do all those things.  This means there
> >>>> needs to be one realm to do all these things.  You could re-use the
> >>>> "keycloak-admin" realm, but re-using the "keycloak-admin" realm doesn't
> >>>> work if you're dealing with a Keycloak deployment that is managing
> >>>> multiple realms.  A.K.A.  Multi-tenancy.
> >>>
> >>> The part I'm not understanding is why it doesn't work with a Keycloak
> >>> deployment with multiple realms?
> >>>
> >>
> >> Because you're polluting the "keycloak-admin" realm with Aerogear
> >> specific things: users, roles, applications, etc.
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From ssilvert at redhat.com  Fri May  2 09:01:06 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 02 May 2014 09:01:06 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com> <536265FE.7010503@redhat.com>
	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>
	<53626A43.3060208@redhat.com>
	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>
	<53626C8C.4070605@redhat.com>
	<27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>
	<53627112.8090408@redhat.com>
	<532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
Message-ID: <53639712.6010507@redhat.com>

You might not want the same administrator for all of your different 
realms.  In other cases, you do want the same administrator for 
different realms.

It seems to me that you would first want a Keycloak admin that can do 
anything.   A Keycloak admin can create/manage a Realm administrator who 
can administer zero or more application realms. An ordinary user can 
only belong to one application realm.

So, you have three types of users:
* Keycloak administrator
* Realm administrator
* User within a single realm

Stan

On 5/2/2014 4:23 AM, Stian Thorgersen wrote:
> My thoughts was that admins would log in to a single "admin realm", which would let them manage any Keycloaks, AeroGears, EAPs and any other servers they have.
>
> Then you'd have one or more application realms where end-users would login.
>
> If we don't have AeroGear admins in the same realm as Keycloak admins, admins will have to login multiple times.
>
> So basically I think the AeroGear admin console should be in the Keycloak admin realm, then there's one or more realms for AeroGear users.
>
> ----- 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, 1 May, 2014 5:06:42 PM
>> Subject: Re: [keycloak-dev] management problems
>>
>> Yes, as you would have to know to switch between realms.  Defeats the
>> idea of Aerogear looking like one product.
>>
>> On 5/1/2014 11:49 AM, Stian Thorgersen wrote:
>>> Is that really an issue?
>>>
>>> Users would just be admin users, there would be a separate realm for
>>> AeroGear users.
>>>
>>> And there'd probably be a single AeroGear console application, with a few
>>> associated roles.
>>>
>>> ----- 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, 1 May, 2014 4:47:24 PM
>>>> Subject: Re: [keycloak-dev] management problems
>>>>
>>>>
>>>>
>>>> On 5/1/2014 11:41 AM, 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, 1 May, 2014 4:37:39 PM
>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
>>>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
>>>>>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
>>>>>>>>>>> I'm wondering about what issues there are with having a single
>>>>>>>>>>> shared
>>>>>>>>>>> admin
>>>>>>>>>>> realm though. That seems the optional solution to me.
>>>>>>>>>>>
>>>>>>>>>> Isn't the issue multi-tenancy?
>>>>>>>>> We can grant admin users access to manage only specific realms
>>>>>>>>> though?
>>>>>>>>>
>>>>>>>>> Or are you thinking multi-tenancy for AeroGear?
>>>>>>>> What I mean is that you want to manage Aerogear in a realm on a server
>>>>>>>> that is multi-tenant (1 server managing multiple realms).  Can't
>>>>>>>> really
>>>>>>>> have a single shared admin realm in that case.
>>>>>>> I'm still not following :/
>>>>>>>
>>>>>>> Can you spoon-feed me an example?
>>>>>>>
>>>>>> Aerogear UPS admin needs to:
>>>>>>
>>>>>> * manage users
>>>>>> * manage role mappings
>>>>>> * manage oauth clients
>>>>>> * Manage aerogear specific things
>>>>>>
>>>>>> You want to have one login to do all those things.  This means there
>>>>>> needs to be one realm to do all these things.  You could re-use the
>>>>>> "keycloak-admin" realm, but re-using the "keycloak-admin" realm doesn't
>>>>>> work if you're dealing with a Keycloak deployment that is managing
>>>>>> multiple realms.  A.K.A.  Multi-tenancy.
>>>>> The part I'm not understanding is why it doesn't work with a Keycloak
>>>>> deployment with multiple realms?
>>>>>
>>>> Because you're polluting the "keycloak-admin" realm with Aerogear
>>>> specific things: users, roles, applications, etc.
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>> --
>> 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


From stian at redhat.com  Fri May  2 10:01:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 2 May 2014 10:01:34 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <53639712.6010507@redhat.com>
References: <5361B37A.7080203@redhat.com> <53626A43.3060208@redhat.com>
	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>
	<53626C8C.4070605@redhat.com>
	<27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>
	<53627112.8090408@redhat.com>
	<532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
	<53639712.6010507@redhat.com>
Message-ID: <1582167444.16354322.1399039294428.JavaMail.zimbra@redhat.com>

If I understand correctly this is something we already have. A user in the Keycloak admin realm can have full control (Keycloak administrator) or can be given one or more permissions to individual realms.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 2 May, 2014 2:01:06 PM
> Subject: Re: [keycloak-dev] management problems
> 
> You might not want the same administrator for all of your different
> realms.  In other cases, you do want the same administrator for
> different realms.
> 
> It seems to me that you would first want a Keycloak admin that can do
> anything.   A Keycloak admin can create/manage a Realm administrator who
> can administer zero or more application realms. An ordinary user can
> only belong to one application realm.
> 
> So, you have three types of users:
> * Keycloak administrator
> * Realm administrator
> * User within a single realm
> 
> Stan
> 
> On 5/2/2014 4:23 AM, Stian Thorgersen wrote:
> > My thoughts was that admins would log in to a single "admin realm", which
> > would let them manage any Keycloaks, AeroGears, EAPs and any other servers
> > they have.
> >
> > Then you'd have one or more application realms where end-users would login.
> >
> > If we don't have AeroGear admins in the same realm as Keycloak admins,
> > admins will have to login multiple times.
> >
> > So basically I think the AeroGear admin console should be in the Keycloak
> > admin realm, then there's one or more realms for AeroGear users.
> >
> > ----- 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, 1 May, 2014 5:06:42 PM
> >> Subject: Re: [keycloak-dev] management problems
> >>
> >> Yes, as you would have to know to switch between realms.  Defeats the
> >> idea of Aerogear looking like one product.
> >>
> >> On 5/1/2014 11:49 AM, Stian Thorgersen wrote:
> >>> Is that really an issue?
> >>>
> >>> Users would just be admin users, there would be a separate realm for
> >>> AeroGear users.
> >>>
> >>> And there'd probably be a single AeroGear console application, with a few
> >>> associated roles.
> >>>
> >>> ----- 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, 1 May, 2014 4:47:24 PM
> >>>> Subject: Re: [keycloak-dev] management problems
> >>>>
> >>>>
> >>>>
> >>>> On 5/1/2014 11:41 AM, 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, 1 May, 2014 4:37:39 PM
> >>>>>> Subject: Re: [keycloak-dev] management problems
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
> >>>>>>>> Subject: Re: [keycloak-dev] management problems
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
> >>>>>>>>>> Subject: Re: [keycloak-dev] management problems
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
> >>>>>>>>>>> I'm wondering about what issues there are with having a single
> >>>>>>>>>>> shared
> >>>>>>>>>>> admin
> >>>>>>>>>>> realm though. That seems the optional solution to me.
> >>>>>>>>>>>
> >>>>>>>>>> Isn't the issue multi-tenancy?
> >>>>>>>>> We can grant admin users access to manage only specific realms
> >>>>>>>>> though?
> >>>>>>>>>
> >>>>>>>>> Or are you thinking multi-tenancy for AeroGear?
> >>>>>>>> What I mean is that you want to manage Aerogear in a realm on a
> >>>>>>>> server
> >>>>>>>> that is multi-tenant (1 server managing multiple realms).  Can't
> >>>>>>>> really
> >>>>>>>> have a single shared admin realm in that case.
> >>>>>>> I'm still not following :/
> >>>>>>>
> >>>>>>> Can you spoon-feed me an example?
> >>>>>>>
> >>>>>> Aerogear UPS admin needs to:
> >>>>>>
> >>>>>> * manage users
> >>>>>> * manage role mappings
> >>>>>> * manage oauth clients
> >>>>>> * Manage aerogear specific things
> >>>>>>
> >>>>>> You want to have one login to do all those things.  This means there
> >>>>>> needs to be one realm to do all these things.  You could re-use the
> >>>>>> "keycloak-admin" realm, but re-using the "keycloak-admin" realm
> >>>>>> doesn't
> >>>>>> work if you're dealing with a Keycloak deployment that is managing
> >>>>>> multiple realms.  A.K.A.  Multi-tenancy.
> >>>>> The part I'm not understanding is why it doesn't work with a Keycloak
> >>>>> deployment with multiple realms?
> >>>>>
> >>>> Because you're polluting the "keycloak-admin" realm with Aerogear
> >>>> specific things: users, roles, applications, etc.
> >>>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>>
> >> --
> >> 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
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri May  2 13:05:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 02 May 2014 13:05:05 -0400
Subject: [keycloak-dev] dynamic key look and relative uri support added
Message-ID: <5363D041.1070902@redhat.com>

* For adapter config, you can now leave out the realm's public key as 
long as you have a valid auth-server-url.  Keycloak will now ping this 
auth server to obtain the public key for the realm.

* The adapter config supports a relative URI for the auth-server-url. 
It will use the current requests scheme, host, and port to create urls. 
  A relative url examples is: "/auth"

* The auth server supports relative URLS for redirect urls, admin urls, 
and base urls.  i.e. "/customer-portal/*".  The current request is used 
to to build the redirect url to validate against,  THe scheme, host, and 
port is used.

With these changes, it makes it a bit easier to bundle preconfigured 
apps and keycloak on a single server.  Hoping this will resolve a bunch 
of Aerogear issues.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri May  2 14:48:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 02 May 2014 14:48:46 -0400
Subject: [keycloak-dev] renaming "keycloak-admin" realm
Message-ID: <5363E88E.2040908@redhat.com>

I'd like to rename it to something more generic, and not keycloak 
specific as people are going to be embedding us.

"master-realm", "master-server-realm"?
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri May  2 15:01:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 02 May 2014 15:01:36 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com> <536265FE.7010503@redhat.com>
	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>
	<53626A43.3060208@redhat.com>
	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>
	<53626C8C.4070605@redhat.com>
	<27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>
	<53627112.8090408@redhat.com>
	<532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
Message-ID: <5363EB90.9090802@redhat.com>

Can we have a hangout on this on Monday?  I need some closure on this as 
I want to get Aerogear requirements out of the way.

Comments inline:



On 5/2/2014 4:23 AM, Stian Thorgersen wrote:
> My thoughts was that admins would log in to a single "admin realm", which would let them manage any Keycloaks, AeroGears, EAPs and any other servers they have.
>

This is what I have been saying.  Keycloak admin console, keycloak REST 
API, and Aerogear UPS all need to be managed by one realm.

BTW, I don't know how we would get the EAP console managed under 
Keycloak.  Its all pretty much hard coded to JAAS/security domains. 
Domain controller doesn't run under a servlet container.

> Then you'd have one or more application realms where end-users would login.
>
> If we don't have AeroGear admins in the same realm as Keycloak admins, admins will have to login multiple times.
>
Exactly.

> So basically I think the AeroGear admin console should be in the Keycloak admin realm, then there's one or more realms for AeroGear users.
>
  We can't always use the master Keycloak admin realm as the keycloak 
server might be multi-tenant.  In other words, the keycloak server may 
be managing multiple realms for completely isolated applications and 
thus, you would not want to Aerogear UPS metadata in the "master" realm.

So, go back to Stan's summary.  You need:

* Keycloak administrator.  We have support for this already.
* Realm administrator.
* User within a single realm

We already have inquiries on how can an application interact with the 
admin REST interface.  Seems that with our current setup, the 
"master-realm" would be polluted with users, roles, and applications 
beyond what it was intended to be used for.

> ----- 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, 1 May, 2014 5:06:42 PM
>> Subject: Re: [keycloak-dev] management problems
>>
>> Yes, as you would have to know to switch between realms.  Defeats the
>> idea of Aerogear looking like one product.
>>
>> On 5/1/2014 11:49 AM, Stian Thorgersen wrote:
>>> Is that really an issue?
>>>
>>> Users would just be admin users, there would be a separate realm for
>>> AeroGear users.
>>>
>>> And there'd probably be a single AeroGear console application, with a few
>>> associated roles.
>>>
>>> ----- 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, 1 May, 2014 4:47:24 PM
>>>> Subject: Re: [keycloak-dev] management problems
>>>>
>>>>
>>>>
>>>> On 5/1/2014 11:41 AM, 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, 1 May, 2014 4:37:39 PM
>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
>>>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
>>>>>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
>>>>>>>>>>> I'm wondering about what issues there are with having a single
>>>>>>>>>>> shared
>>>>>>>>>>> admin
>>>>>>>>>>> realm though. That seems the optional solution to me.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Isn't the issue multi-tenancy?
>>>>>>>>>
>>>>>>>>> We can grant admin users access to manage only specific realms
>>>>>>>>> though?
>>>>>>>>>
>>>>>>>>> Or are you thinking multi-tenancy for AeroGear?
>>>>>>>>
>>>>>>>> What I mean is that you want to manage Aerogear in a realm on a server
>>>>>>>> that is multi-tenant (1 server managing multiple realms).  Can't
>>>>>>>> really
>>>>>>>> have a single shared admin realm in that case.
>>>>>>>
>>>>>>> I'm still not following :/
>>>>>>>
>>>>>>> Can you spoon-feed me an example?
>>>>>>>
>>>>>>
>>>>>> Aerogear UPS admin needs to:
>>>>>>
>>>>>> * manage users
>>>>>> * manage role mappings
>>>>>> * manage oauth clients
>>>>>> * Manage aerogear specific things
>>>>>>
>>>>>> You want to have one login to do all those things.  This means there
>>>>>> needs to be one realm to do all these things.  You could re-use the
>>>>>> "keycloak-admin" realm, but re-using the "keycloak-admin" realm doesn't
>>>>>> work if you're dealing with a Keycloak deployment that is managing
>>>>>> multiple realms.  A.K.A.  Multi-tenancy.
>>>>>
>>>>> The part I'm not understanding is why it doesn't work with a Keycloak
>>>>> deployment with multiple realms?
>>>>>
>>>>
>>>> Because you're polluting the "keycloak-admin" realm with Aerogear
>>>> specific things: users, roles, applications, etc.
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Mon May  5 03:33:05 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 05 May 2014 09:33:05 +0200
Subject: [keycloak-dev] management problems
In-Reply-To: <5363EB90.9090802@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<536265FE.7010503@redhat.com>	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>	<53626A43.3060208@redhat.com>	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>	<53626C8C.4070605@redhat.com>	<27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>	<53627112.8090408@redhat.com>	<532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
	<5363EB90.9090802@redhat.com>
Message-ID: <53673EB1.5000609@redhat.com>

The problem is that just admin realm (or "master realm" or whatever it 
will be called) is able to retrieve list of users, applications etc. 
with KC admin endpoints.

Maybe it's possible to expose endpoints for some users of realm itself 
(So for example users with role "admin" of realm "myRealm" will be able 
to retrieve list of users of this realm). But this won't solve the 
problem with SSO login though. If I want my administrator to have SSO 
between Keycloak admin console, Liveoak admin console and Aerogear admin 
console, then all these admin consoles must use same realm actually...


So it seems that the best is if all admin users will still use the 
"master realm" but there will be fine-grained authorization, which will 
allow to properly isolate various admin users.

Example:
- I want my "master realm" to manage Keycloak, Liveoak and Aerogear 
admin consoles.

- So "admin" user, which can do anything, will create roles 
"aerogear-admin" and "liveoak-admin" and he will assign role 
"aerogear-admin" to user "joe".

- Now "joe" is Aerogear administrator and he wants to grant admin rights 
to more users, so he is not alone for all administration tasks. So he 
must be able to create new users in "master realm" and grant them role 
"aerogear-admin" and also see all other "aerogear-admin" users, but he 
shouldn't be able to see any other users from "master realm" . He 
shouldn't be even able to see that "master realm" itself is also used 
for liveoak administration...

Marek

On 2.5.2014 21:01, Bill Burke wrote:
> Can we have a hangout on this on Monday?  I need some closure on this as
> I want to get Aerogear requirements out of the way.
>
> Comments inline:
>
>
>
> On 5/2/2014 4:23 AM, Stian Thorgersen wrote:
>> My thoughts was that admins would log in to a single "admin realm", which would let them manage any Keycloaks, AeroGears, EAPs and any other servers they have.
>>
> This is what I have been saying.  Keycloak admin console, keycloak REST
> API, and Aerogear UPS all need to be managed by one realm.
>
> BTW, I don't know how we would get the EAP console managed under
> Keycloak.  Its all pretty much hard coded to JAAS/security domains.
> Domain controller doesn't run under a servlet container.
>
>> Then you'd have one or more application realms where end-users would login.
>>
>> If we don't have AeroGear admins in the same realm as Keycloak admins, admins will have to login multiple times.
>>
> Exactly.
>
>> So basically I think the AeroGear admin console should be in the Keycloak admin realm, then there's one or more realms for AeroGear users.
>>
>    We can't always use the master Keycloak admin realm as the keycloak
> server might be multi-tenant.  In other words, the keycloak server may
> be managing multiple realms for completely isolated applications and
> thus, you would not want to Aerogear UPS metadata in the "master" realm.
>
> So, go back to Stan's summary.  You need:
>
> * Keycloak administrator.  We have support for this already.
> * Realm administrator.
> * User within a single realm
>
> We already have inquiries on how can an application interact with the
> admin REST interface.  Seems that with our current setup, the
> "master-realm" would be polluted with users, roles, and applications
> beyond what it was intended to be used for.
>
>> ----- 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, 1 May, 2014 5:06:42 PM
>>> Subject: Re: [keycloak-dev] management problems
>>>
>>> Yes, as you would have to know to switch between realms.  Defeats the
>>> idea of Aerogear looking like one product.
>>>
>>> On 5/1/2014 11:49 AM, Stian Thorgersen wrote:
>>>> Is that really an issue?
>>>>
>>>> Users would just be admin users, there would be a separate realm for
>>>> AeroGear users.
>>>>
>>>> And there'd probably be a single AeroGear console application, with a few
>>>> associated roles.
>>>>
>>>> ----- 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, 1 May, 2014 4:47:24 PM
>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>
>>>>>
>>>>>
>>>>> On 5/1/2014 11:41 AM, 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, 1 May, 2014 4:37:39 PM
>>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 5/1/2014 11:24 AM, 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, 1 May, 2014 4:19:26 PM
>>>>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/1/2014 10:16 AM, 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, 1 May, 2014 3:11:48 PM
>>>>>>>>>>> Subject: Re: [keycloak-dev] management problems
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 5/1/2014 9:30 AM, Stian Thorgersen wrote:
>>>>>>>>>>>> I'm wondering about what issues there are with having a single
>>>>>>>>>>>> shared
>>>>>>>>>>>> admin
>>>>>>>>>>>> realm though. That seems the optional solution to me.
>>>>>>>>>>>>
>>>>>>>>>>> Isn't the issue multi-tenancy?
>>>>>>>>>> We can grant admin users access to manage only specific realms
>>>>>>>>>> though?
>>>>>>>>>>
>>>>>>>>>> Or are you thinking multi-tenancy for AeroGear?
>>>>>>>>> What I mean is that you want to manage Aerogear in a realm on a server
>>>>>>>>> that is multi-tenant (1 server managing multiple realms).  Can't
>>>>>>>>> really
>>>>>>>>> have a single shared admin realm in that case.
>>>>>>>> I'm still not following :/
>>>>>>>>
>>>>>>>> Can you spoon-feed me an example?
>>>>>>>>
>>>>>>> Aerogear UPS admin needs to:
>>>>>>>
>>>>>>> * manage users
>>>>>>> * manage role mappings
>>>>>>> * manage oauth clients
>>>>>>> * Manage aerogear specific things
>>>>>>>
>>>>>>> You want to have one login to do all those things.  This means there
>>>>>>> needs to be one realm to do all these things.  You could re-use the
>>>>>>> "keycloak-admin" realm, but re-using the "keycloak-admin" realm doesn't
>>>>>>> work if you're dealing with a Keycloak deployment that is managing
>>>>>>> multiple realms.  A.K.A.  Multi-tenancy.
>>>>>> The part I'm not understanding is why it doesn't work with a Keycloak
>>>>>> deployment with multiple realms?
>>>>>>
>>>>> Because you're polluting the "keycloak-admin" realm with Aerogear
>>>>> specific things: users, roles, applications, etc.
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>


From mposolda at redhat.com  Mon May  5 03:42:23 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 05 May 2014 09:42:23 +0200
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
Message-ID: <536740DF.2020704@redhat.com>

There is also the thing, that currently user registered through social 
can't change his password - https://issues.jboss.org/browse/KEYCLOAK-334 
. Not sure if this is priority for beta1, but it should be at least in 
1.0-Final IMO.

We discussed the possibility to remove the options 
"updateProfileOnInitialSocialLogin", "verifyEmail" and instead use list 
of requiredActions after normal registration and social registration.

Currently it's assigned to me and planned for Beta1, but I don't think 
that I can do it though as I am on PTO from Thursday and then whole next 
week...

Marek

On 30.4.2014 18:17, Stian Thorgersen wrote:
> With regards to account management what additional requirements do we have for beta1?
>
> Features I can think off to add now or in the future includes:
>
> * Manage refresh tokens - view applications and clients that have refresh tokens, and the ability to invalidate specific tokens
> * Manage devices - view browsers and devices that have access (remember me cookie?), and the ability to invalidate specific cookies
> * Manage devices that can bypass totp - it seems to be quite common that it's possible to not require asking for totp again for a specific device, I assume this is done by setting a cookie, if we enable this it should be possible to view what devices have this option, as well as invalidate them
> * Manage applications - view all applications, be able to navigate to an application, and the ability to invalidate access to specific application
> * Manage clients - view all clients and what grants they have, and the ability to revoke access to specific client
>
> I think listing client grants, invalidate specific client grants, and a logout everything option would be sufficient. The logout everything option would invalidate any refresh tokens, remember me cookies, 'skip' totp cookies and do a sso-logout.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Mon May  5 12:22:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 05 May 2014 12:22:08 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <53673EB1.5000609@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<536265FE.7010503@redhat.com>	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>	<53626A43.3060208@redhat.com>	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>	<53626C8C.4070605@redhat.com>	<27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>	<53627112.8090408@redhat.com>	<532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
	<5363EB90.9090802@redhat.com> <53673EB1.5000609@redhat.com>
Message-ID: <5367BAB0.3010004@redhat.com>



On 5/5/2014 3:33 AM, Marek Posolda wrote:
> The problem is that just admin realm (or "master realm" or whatever it
> will be called) is able to retrieve list of users, applications etc.
> with KC admin endpoints.
>
> Maybe it's possible to expose endpoints for some users of realm itself
> (So for example users with role "admin" of realm "myRealm" will be able
> to retrieve list of users of this realm). But this won't solve the
> problem with SSO login though. If I want my administrator to have SSO
> between Keycloak admin console, Liveoak admin console and Aerogear admin
> console, then all these admin consoles must use same realm actually...
>

Yes.  LIveoak, Aerogear, keycloak admin console will have to e the same 
realm.  The problem is that this realm has to be the "master" realm, 
otherwise keycloak can't be part of SSO.  Which is unworkable in a 
multi-tenant server that is managing different realms for different 
organizations.

>
> So it seems that the best is if all admin users will still use the
> "master realm" but there will be fine-grained authorization, which will
> allow to properly isolate various admin users.
>
> Example:
> - I want my "master realm" to manage Keycloak, Liveoak and Aerogear
> admin consoles.
>
> - So "admin" user, which can do anything, will create roles
> "aerogear-admin" and "liveoak-admin" and he will assign role
> "aerogear-admin" to user "joe".
>
> - Now "joe" is Aerogear administrator and he wants to grant admin rights
> to more users, so he is not alone for all administration tasks. So he
> must be able to create new users in "master realm" and grant them role
> "aerogear-admin" and also see all other "aerogear-admin" users, but he
> shouldn't be able to see any other users from "master realm" . He
> shouldn't be even able to see that "master realm" itself is also used
> for liveoak administration...
>

Why not have a special "realm admin" role that can be assigned in each 
realm to a realm user?



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Mon May  5 13:56:24 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 05 May 2014 19:56:24 +0200
Subject: [keycloak-dev] management problems
In-Reply-To: <5367BAB0.3010004@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<536265FE.7010503@redhat.com>	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>	<53626A43.3060208@redhat.com>	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>	<53626C8C.4070605@redhat.com>	<27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>	<53627112.8090408@redhat.com>	<532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
	<5363EB90.9090802@redhat.com> <53673EB1.5000609@redhat.com>
	<5367BAB0.3010004@redhat.com>
Message-ID: <5367D0C8.5050808@redhat.com>

On 5.5.2014 18:22, Bill Burke wrote:
>
>
> On 5/5/2014 3:33 AM, Marek Posolda wrote:
>> The problem is that just admin realm (or "master realm" or whatever it
>> will be called) is able to retrieve list of users, applications etc.
>> with KC admin endpoints.
>>
>> Maybe it's possible to expose endpoints for some users of realm itself
>> (So for example users with role "admin" of realm "myRealm" will be able
>> to retrieve list of users of this realm). But this won't solve the
>> problem with SSO login though. If I want my administrator to have SSO
>> between Keycloak admin console, Liveoak admin console and Aerogear admin
>> console, then all these admin consoles must use same realm actually...
>>
>
> Yes.  LIveoak, Aerogear, keycloak admin console will have to e the 
> same realm.  The problem is that this realm has to be the "master" 
> realm, otherwise keycloak can't be part of SSO.  Which is unworkable 
> in a multi-tenant server that is managing different realms for 
> different organizations.
>
>>
>> So it seems that the best is if all admin users will still use the
>> "master realm" but there will be fine-grained authorization, which will
>> allow to properly isolate various admin users.
>>
>> Example:
>> - I want my "master realm" to manage Keycloak, Liveoak and Aerogear
>> admin consoles.
>>
>> - So "admin" user, which can do anything, will create roles
>> "aerogear-admin" and "liveoak-admin" and he will assign role
>> "aerogear-admin" to user "joe".
>>
>> - Now "joe" is Aerogear administrator and he wants to grant admin rights
>> to more users, so he is not alone for all administration tasks. So he
>> must be able to create new users in "master realm" and grant them role
>> "aerogear-admin" and also see all other "aerogear-admin" users, but he
>> shouldn't be able to see any other users from "master realm" . He
>> shouldn't be even able to see that "master realm" itself is also used
>> for liveoak administration...
>>
>
> Why not have a special "realm admin" role that can be assigned in each 
> realm to a realm user
That's something what I was thinking about as well . So members of role 
"realm admin" will be able to perform various administration tasks on 
the realm, right? For example members of role "realm admin" in realm 
"myRealm" will be able to retrieve the list of users, roles or 
applications of realm "myRealm"etc .

But is this the way to go? As you already mentioned, this won't solve 
the problem of SSO between various admin consoles if I understand 
correctly. Also it seems to be a bit strange that KC admin console can 
be used by users from various realms. This will require quite big 
refactoring of existing admin console and admin endpoints.

It seems much easier to keep all admin tasks in "master realm" and have 
very fine-grained authorization as I mentioned earlier. So for example 
member of role "aerogear-admin" will be able to create new users in 
"master realm" and assign them role "aerogear-admin" or 
"aerogear-admin-with-lower-privileges-to-perform-just-subset-of-admin-tasks" 
but he won't be able to see other users in "master realm" (for example 
members of "eap-admins") .

However it's possible that I am missing all the requirements though...

Marek

From bburke at redhat.com  Mon May  5 18:25:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 05 May 2014 18:25:58 -0400
Subject: [keycloak-dev] can we ditch org.json?
Message-ID: <53680FF6.6090302@redhat.com>

Would it be possible to ditch org.json and use Jackson instead? 
Specifically the JsonSerialization class?

It will just be one less library that needs to go through productization.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon May  5 18:46:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 05 May 2014 18:46:54 -0400
Subject: [keycloak-dev] management problems
In-Reply-To: <5367D0C8.5050808@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<536265FE.7010503@redhat.com>	<1118252656.15694304.1398957880197.JavaMail.zimbra@redhat.com>	<53626A43.3060208@redhat.com>	<1375733547.15701250.1398958890375.JavaMail.zimbra@redhat.com>	<53626C8C.4070605@redhat.com>	<27870774.15705283.1398959390110.JavaMail.zimbra@redhat.com>	<53627112.8090408@redhat.com>	<532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
	<5363EB90.9090802@redhat.com> <53673EB1.5000609@redhat.com>
	<5367BAB0.3010004@redhat.com> <5367D0C8.5050808@redhat.com>
Message-ID: <536814DE.3010107@redhat.com>



On 5/5/2014 1:56 PM, Marek Posolda wrote:
> On 5.5.2014 18:22, Bill Burke wrote:
>>
>>
>> On 5/5/2014 3:33 AM, Marek Posolda wrote:
>>> The problem is that just admin realm (or "master realm" or whatever it
>>> will be called) is able to retrieve list of users, applications etc.
>>> with KC admin endpoints.
>>>
>>> Maybe it's possible to expose endpoints for some users of realm itself
>>> (So for example users with role "admin" of realm "myRealm" will be able
>>> to retrieve list of users of this realm). But this won't solve the
>>> problem with SSO login though. If I want my administrator to have SSO
>>> between Keycloak admin console, Liveoak admin console and Aerogear admin
>>> console, then all these admin consoles must use same realm actually...
>>>
>>
>> Yes.  LIveoak, Aerogear, keycloak admin console will have to e the
>> same realm.  The problem is that this realm has to be the "master"
>> realm, otherwise keycloak can't be part of SSO.  Which is unworkable
>> in a multi-tenant server that is managing different realms for
>> different organizations.
>>
>>>
>>> So it seems that the best is if all admin users will still use the
>>> "master realm" but there will be fine-grained authorization, which will
>>> allow to properly isolate various admin users.
>>>
>>> Example:
>>> - I want my "master realm" to manage Keycloak, Liveoak and Aerogear
>>> admin consoles.
>>>
>>> - So "admin" user, which can do anything, will create roles
>>> "aerogear-admin" and "liveoak-admin" and he will assign role
>>> "aerogear-admin" to user "joe".
>>>
>>> - Now "joe" is Aerogear administrator and he wants to grant admin rights
>>> to more users, so he is not alone for all administration tasks. So he
>>> must be able to create new users in "master realm" and grant them role
>>> "aerogear-admin" and also see all other "aerogear-admin" users, but he
>>> shouldn't be able to see any other users from "master realm" . He
>>> shouldn't be even able to see that "master realm" itself is also used
>>> for liveoak administration...
>>>
>>
>> Why not have a special "realm admin" role that can be assigned in each
>> realm to a realm user
> That's something what I was thinking about as well . So members of role
> "realm admin" will be able to perform various administration tasks on
> the realm, right? For example members of role "realm admin" in realm
> "myRealm" will be able to retrieve the list of users, roles or
> applications of realm "myRealm"etc .
>
> But is this the way to go? As you already mentioned, this won't solve
> the problem of SSO between various admin consoles if I understand
> correctly.

This would solve SSO problems.  You'd create your own realm.  Add 
"ups-admin", "LiveOak admin" applications to this realm.  There would be 
a built in "security admin" application for managing access to the 
manage console solely for the realm.

> Also it seems to be a bit strange that KC admin console can
> be used by users from various realms. This will require quite big
> refactoring of existing admin console and admin endpoints.
>

Users will only be able to manage the realm they are within.  I don't 
think this would be that big of a refactor.  The auth code is in one 
place.  I just want to make sure it is the right solution which is why 
I'm asking to have a hangout to discuss.

> It seems much easier to keep all admin tasks in "master realm" and have
> very fine-grained authorization as I mentioned earlier. So for example
> member of role "aerogear-admin" will be able to create new users in
> "master realm" and assign them role "aerogear-admin" or
> "aerogear-admin-with-lower-privileges-to-perform-just-subset-of-admin-tasks"
> but he won't be able to see other users in "master realm" (for example
> members of "eap-admins") .
>

Isn't this solution kind of hacky?  Seems to me it would be a more 
disruptive change than what I suggested earlier.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Mon May  5 18:47:04 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 05 May 2014 15:47:04 -0700 (PDT)
Subject: [keycloak-dev] can we ditch org.json?
In-Reply-To: <53680FF6.6090302@redhat.com>
References: <53680FF6.6090302@redhat.com>
Message-ID: <1399330024021.8a6fd706@Nodemailer>

Go for it!?
abstractj

On Mon, May 5, 2014 at 7:26 PM, Bill Burke <bburke at redhat.com> wrote:

> Would it be possible to ditch org.json and use Jackson instead? 
> Specifically the JsonSerialization class?
> It will just be one less library that needs to go through productization.
> -- 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140505/8160683c/attachment.html 

From stian at redhat.com  Tue May  6 04:40:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 04:40:39 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <536814DE.3010107@redhat.com>
References: <5361B37A.7080203@redhat.com> <53627112.8090408@redhat.com>
	<532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
	<5363EB90.9090802@redhat.com> <53673EB1.5000609@redhat.com>
	<5367BAB0.3010004@redhat.com> <5367D0C8.5050808@redhat.com>
	<536814DE.3010107@redhat.com>
Message-ID: <672804532.1336716.1399365639278.JavaMail.zimbra@redhat.com>

+1 To a Hangout - today would be good for me

There was a public holiday in the UK yesterday, hence I was out for a bike ride with the kids instead of thinking about realms ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 5 May, 2014 11:46:54 PM
> Subject: Re: [keycloak-dev] management problems
> 
> 
> 
> On 5/5/2014 1:56 PM, Marek Posolda wrote:
> > On 5.5.2014 18:22, Bill Burke wrote:
> >>
> >>
> >> On 5/5/2014 3:33 AM, Marek Posolda wrote:
> >>> The problem is that just admin realm (or "master realm" or whatever it
> >>> will be called) is able to retrieve list of users, applications etc.
> >>> with KC admin endpoints.
> >>>
> >>> Maybe it's possible to expose endpoints for some users of realm itself
> >>> (So for example users with role "admin" of realm "myRealm" will be able
> >>> to retrieve list of users of this realm). But this won't solve the
> >>> problem with SSO login though. If I want my administrator to have SSO
> >>> between Keycloak admin console, Liveoak admin console and Aerogear admin
> >>> console, then all these admin consoles must use same realm actually...
> >>>
> >>
> >> Yes.  LIveoak, Aerogear, keycloak admin console will have to e the
> >> same realm.  The problem is that this realm has to be the "master"
> >> realm, otherwise keycloak can't be part of SSO.  Which is unworkable
> >> in a multi-tenant server that is managing different realms for
> >> different organizations.
> >>
> >>>
> >>> So it seems that the best is if all admin users will still use the
> >>> "master realm" but there will be fine-grained authorization, which will
> >>> allow to properly isolate various admin users.
> >>>
> >>> Example:
> >>> - I want my "master realm" to manage Keycloak, Liveoak and Aerogear
> >>> admin consoles.
> >>>
> >>> - So "admin" user, which can do anything, will create roles
> >>> "aerogear-admin" and "liveoak-admin" and he will assign role
> >>> "aerogear-admin" to user "joe".
> >>>
> >>> - Now "joe" is Aerogear administrator and he wants to grant admin rights
> >>> to more users, so he is not alone for all administration tasks. So he
> >>> must be able to create new users in "master realm" and grant them role
> >>> "aerogear-admin" and also see all other "aerogear-admin" users, but he
> >>> shouldn't be able to see any other users from "master realm" . He
> >>> shouldn't be even able to see that "master realm" itself is also used
> >>> for liveoak administration...
> >>>
> >>
> >> Why not have a special "realm admin" role that can be assigned in each
> >> realm to a realm user
> > That's something what I was thinking about as well . So members of role
> > "realm admin" will be able to perform various administration tasks on
> > the realm, right? For example members of role "realm admin" in realm
> > "myRealm" will be able to retrieve the list of users, roles or
> > applications of realm "myRealm"etc .
> >
> > But is this the way to go? As you already mentioned, this won't solve
> > the problem of SSO between various admin consoles if I understand
> > correctly.
> 
> This would solve SSO problems.  You'd create your own realm.  Add
> "ups-admin", "LiveOak admin" applications to this realm.  There would be
> a built in "security admin" application for managing access to the
> manage console solely for the realm.
> 
> > Also it seems to be a bit strange that KC admin console can
> > be used by users from various realms. This will require quite big
> > refactoring of existing admin console and admin endpoints.
> >
> 
> Users will only be able to manage the realm they are within.  I don't
> think this would be that big of a refactor.  The auth code is in one
> place.  I just want to make sure it is the right solution which is why
> I'm asking to have a hangout to discuss.
> 
> > It seems much easier to keep all admin tasks in "master realm" and have
> > very fine-grained authorization as I mentioned earlier. So for example
> > member of role "aerogear-admin" will be able to create new users in
> > "master realm" and assign them role "aerogear-admin" or
> > "aerogear-admin-with-lower-privileges-to-perform-just-subset-of-admin-tasks"
> > but he won't be able to see other users in "master realm" (for example
> > members of "eap-admins") .
> >
> 
> Isn't this solution kind of hacky?  Seems to me it would be a more
> disruptive change than what I suggested earlier.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Tue May  6 04:43:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 04:43:40 -0400 (EDT)
Subject: [keycloak-dev] Account management requirements for beta1
In-Reply-To: <536740DF.2020704@redhat.com>
References: <556989743.15195729.1398874667210.JavaMail.zimbra@redhat.com>
	<536740DF.2020704@redhat.com>
Message-ID: <848811073.1339498.1399365820831.JavaMail.zimbra@redhat.com>

I've set those issues as low priority for beta1 - I can do them if I get the chance, otherwise we'll have to push them

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 5 May, 2014 8:42:23 AM
> Subject: Re: [keycloak-dev] Account management requirements for beta1
> 
> There is also the thing, that currently user registered through social
> can't change his password - https://issues.jboss.org/browse/KEYCLOAK-334
> . Not sure if this is priority for beta1, but it should be at least in
> 1.0-Final IMO.
> 
> We discussed the possibility to remove the options
> "updateProfileOnInitialSocialLogin", "verifyEmail" and instead use list
> of requiredActions after normal registration and social registration.
> 
> Currently it's assigned to me and planned for Beta1, but I don't think
> that I can do it though as I am on PTO from Thursday and then whole next
> week...
> 
> Marek
> 
> On 30.4.2014 18:17, Stian Thorgersen wrote:
> > With regards to account management what additional requirements do we have
> > for beta1?
> >
> > Features I can think off to add now or in the future includes:
> >
> > * Manage refresh tokens - view applications and clients that have refresh
> > tokens, and the ability to invalidate specific tokens
> > * Manage devices - view browsers and devices that have access (remember me
> > cookie?), and the ability to invalidate specific cookies
> > * Manage devices that can bypass totp - it seems to be quite common that
> > it's possible to not require asking for totp again for a specific device,
> > I assume this is done by setting a cookie, if we enable this it should be
> > possible to view what devices have this option, as well as invalidate them
> > * Manage applications - view all applications, be able to navigate to an
> > application, and the ability to invalidate access to specific application
> > * Manage clients - view all clients and what grants they have, and the
> > ability to revoke access to specific client
> >
> > I think listing client grants, invalidate specific client grants, and a
> > logout everything option would be sufficient. The logout everything option
> > would invalidate any refresh tokens, remember me cookies, 'skip' totp
> > cookies and do a sso-logout.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue May  6 04:45:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 04:45:17 -0400 (EDT)
Subject: [keycloak-dev] can we ditch org.json?
In-Reply-To: <53680FF6.6090302@redhat.com>
References: <53680FF6.6090302@redhat.com>
Message-ID: <1002643607.1340148.1399365917150.JavaMail.zimbra@redhat.com>

AFAIK it's only the social stuff that uses org.json, and it should be quick to switch to Jackons.

I can sort it out

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 5 May, 2014 11:25:58 PM
> Subject: [keycloak-dev] can we ditch org.json?
> 
> Would it be possible to ditch org.json and use Jackson instead?
> Specifically the JsonSerialization class?
> 
> It will just be one less library that needs to go through productization.
> 
> --
> 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
> 

From stian at redhat.com  Tue May  6 04:48:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 04:48:20 -0400 (EDT)
Subject: [keycloak-dev] renaming "keycloak-admin" realm
In-Reply-To: <5363E88E.2040908@redhat.com>
References: <5363E88E.2040908@redhat.com>
Message-ID: <1973069406.1341441.1399366100300.JavaMail.zimbra@redhat.com>

How about just master or default?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 2 May, 2014 7:48:46 PM
> Subject: [keycloak-dev] renaming "keycloak-admin" realm
> 
> I'd like to rename it to something more generic, and not keycloak
> specific as people are going to be embedding us.
> 
> "master-realm", "master-server-realm"?
> --
> 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
> 

From stian at redhat.com  Tue May  6 04:48:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 04:48:31 -0400 (EDT)
Subject: [keycloak-dev] renaming "keycloak-admin" realm
In-Reply-To: <5363E88E.2040908@redhat.com>
References: <5363E88E.2040908@redhat.com>
Message-ID: <307083170.1341513.1399366111448.JavaMail.zimbra@redhat.com>

Or admin

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 2 May, 2014 7:48:46 PM
> Subject: [keycloak-dev] renaming "keycloak-admin" realm
> 
> I'd like to rename it to something more generic, and not keycloak
> specific as people are going to be embedding us.
> 
> "master-realm", "master-server-realm"?
> --
> 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
> 

From stian at redhat.com  Tue May  6 04:56:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 04:56:38 -0400 (EDT)
Subject: [keycloak-dev] dynamic key look and relative uri support added
In-Reply-To: <5363D041.1070902@redhat.com>
References: <5363D041.1070902@redhat.com>
Message-ID: <928853558.1347716.1399366598670.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 2 May, 2014 6:05:05 PM
> Subject: [keycloak-dev] dynamic key look and relative uri support added
> 
> * For adapter config, you can now leave out the realm's public key as
> long as you have a valid auth-server-url.  Keycloak will now ping this
> auth server to obtain the public key for the realm.
> 
> * The adapter config supports a relative URI for the auth-server-url.
> It will use the current requests scheme, host, and port to create urls.
>   A relative url examples is: "/auth"
> 
> * The auth server supports relative URLS for redirect urls, admin urls,
> and base urls.  i.e. "/customer-portal/*".  The current request is used
> to to build the redirect url to validate against,  THe scheme, host, and
> port is used.
> 
> With these changes, it makes it a bit easier to bundle preconfigured
> apps and keycloak on a single server.  Hoping this will resolve a bunch
> of Aerogear issues.

Sounds good - but I wonder if this could be used to redirect to a custom domain?

> --
> 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
> 

From bburke at redhat.com  Tue May  6 07:36:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 06 May 2014 07:36:06 -0400
Subject: [keycloak-dev] dynamic key look and relative uri support added
In-Reply-To: <928853558.1347716.1399366598670.JavaMail.zimbra@redhat.com>
References: <5363D041.1070902@redhat.com>
	<928853558.1347716.1399366598670.JavaMail.zimbra@redhat.com>
Message-ID: <5368C926.3090505@redhat.com>



On 5/6/2014 4:56 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 2 May, 2014 6:05:05 PM
>> Subject: [keycloak-dev] dynamic key look and relative uri support added
>>
>> * For adapter config, you can now leave out the realm's public key as
>> long as you have a valid auth-server-url.  Keycloak will now ping this
>> auth server to obtain the public key for the realm.
>>
>> * The adapter config supports a relative URI for the auth-server-url.
>> It will use the current requests scheme, host, and port to create urls.
>>    A relative url examples is: "/auth"
>>
>> * The auth server supports relative URLS for redirect urls, admin urls,
>> and base urls.  i.e. "/customer-portal/*".  The current request is used
>> to to build the redirect url to validate against,  THe scheme, host, and
>> port is used.
>>
>> With these changes, it makes it a bit easier to bundle preconfigured
>> apps and keycloak on a single server.  Hoping this will resolve a bunch
>> of Aerogear issues.
>
> Sounds good - but I wonder if this could be used to redirect to a custom domain?

What do you mean?

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue May  6 07:36:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 07:36:45 -0400 (EDT)
Subject: [keycloak-dev] management problems
In-Reply-To: <672804532.1336716.1399365639278.JavaMail.zimbra@redhat.com>
References: <5361B37A.7080203@redhat.com>
	<532272917.16164489.1399019010453.JavaMail.zimbra@redhat.com>
	<5363EB90.9090802@redhat.com> <53673EB1.5000609@redhat.com>
	<5367BAB0.3010004@redhat.com> <5367D0C8.5050808@redhat.com>
	<536814DE.3010107@redhat.com>
	<672804532.1336716.1399365639278.JavaMail.zimbra@redhat.com>
Message-ID: <585850408.1436062.1399376205029.JavaMail.zimbra@redhat.com>

Just adding my latest thoughts:

I think we should allow login to admin console either through the "master" realm, or through any realm. If login to an individual realm we use an app in the realm itself to represents the admin of the realm, which would be the equivalent of the "realm app" in the master realm. Obviously to manage multiple realms you'd have to login to the "master" realm, or to login to each realm separately.

Shouldn't be to hard to do, I can sort this out in a day or two, and I think this would give us the most flexibility.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 6 May, 2014 9:40:39 AM
> Subject: Re: [keycloak-dev] management problems
> 
> +1 To a Hangout - today would be good for me
> 
> There was a public holiday in the UK yesterday, hence I was out for a bike
> ride with the kids instead of thinking about realms ;)
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
> > <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Monday, 5 May, 2014 11:46:54 PM
> > Subject: Re: [keycloak-dev] management problems
> > 
> > 
> > 
> > On 5/5/2014 1:56 PM, Marek Posolda wrote:
> > > On 5.5.2014 18:22, Bill Burke wrote:
> > >>
> > >>
> > >> On 5/5/2014 3:33 AM, Marek Posolda wrote:
> > >>> The problem is that just admin realm (or "master realm" or whatever it
> > >>> will be called) is able to retrieve list of users, applications etc.
> > >>> with KC admin endpoints.
> > >>>
> > >>> Maybe it's possible to expose endpoints for some users of realm itself
> > >>> (So for example users with role "admin" of realm "myRealm" will be able
> > >>> to retrieve list of users of this realm). But this won't solve the
> > >>> problem with SSO login though. If I want my administrator to have SSO
> > >>> between Keycloak admin console, Liveoak admin console and Aerogear
> > >>> admin
> > >>> console, then all these admin consoles must use same realm actually...
> > >>>
> > >>
> > >> Yes.  LIveoak, Aerogear, keycloak admin console will have to e the
> > >> same realm.  The problem is that this realm has to be the "master"
> > >> realm, otherwise keycloak can't be part of SSO.  Which is unworkable
> > >> in a multi-tenant server that is managing different realms for
> > >> different organizations.
> > >>
> > >>>
> > >>> So it seems that the best is if all admin users will still use the
> > >>> "master realm" but there will be fine-grained authorization, which will
> > >>> allow to properly isolate various admin users.
> > >>>
> > >>> Example:
> > >>> - I want my "master realm" to manage Keycloak, Liveoak and Aerogear
> > >>> admin consoles.
> > >>>
> > >>> - So "admin" user, which can do anything, will create roles
> > >>> "aerogear-admin" and "liveoak-admin" and he will assign role
> > >>> "aerogear-admin" to user "joe".
> > >>>
> > >>> - Now "joe" is Aerogear administrator and he wants to grant admin
> > >>> rights
> > >>> to more users, so he is not alone for all administration tasks. So he
> > >>> must be able to create new users in "master realm" and grant them role
> > >>> "aerogear-admin" and also see all other "aerogear-admin" users, but he
> > >>> shouldn't be able to see any other users from "master realm" . He
> > >>> shouldn't be even able to see that "master realm" itself is also used
> > >>> for liveoak administration...
> > >>>
> > >>
> > >> Why not have a special "realm admin" role that can be assigned in each
> > >> realm to a realm user
> > > That's something what I was thinking about as well . So members of role
> > > "realm admin" will be able to perform various administration tasks on
> > > the realm, right? For example members of role "realm admin" in realm
> > > "myRealm" will be able to retrieve the list of users, roles or
> > > applications of realm "myRealm"etc .
> > >
> > > But is this the way to go? As you already mentioned, this won't solve
> > > the problem of SSO between various admin consoles if I understand
> > > correctly.
> > 
> > This would solve SSO problems.  You'd create your own realm.  Add
> > "ups-admin", "LiveOak admin" applications to this realm.  There would be
> > a built in "security admin" application for managing access to the
> > manage console solely for the realm.
> > 
> > > Also it seems to be a bit strange that KC admin console can
> > > be used by users from various realms. This will require quite big
> > > refactoring of existing admin console and admin endpoints.
> > >
> > 
> > Users will only be able to manage the realm they are within.  I don't
> > think this would be that big of a refactor.  The auth code is in one
> > place.  I just want to make sure it is the right solution which is why
> > I'm asking to have a hangout to discuss.
> > 
> > > It seems much easier to keep all admin tasks in "master realm" and have
> > > very fine-grained authorization as I mentioned earlier. So for example
> > > member of role "aerogear-admin" will be able to create new users in
> > > "master realm" and assign them role "aerogear-admin" or
> > > "aerogear-admin-with-lower-privileges-to-perform-just-subset-of-admin-tasks"
> > > but he won't be able to see other users in "master realm" (for example
> > > members of "eap-admins") .
> > >
> > 
> > Isn't this solution kind of hacky?  Seems to me it would be a more
> > disruptive change than what I suggested earlier.
> > 
> > 
> > --
> > 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
> 

From stian at redhat.com  Tue May  6 10:12:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 10:12:33 -0400 (EDT)
Subject: [keycloak-dev] Unassigned by default
In-Reply-To: <562637136.1559929.1399385427352.JavaMail.zimbra@redhat.com>
Message-ID: <462737367.1561492.1399385553272.JavaMail.zimbra@redhat.com>

I've now set all existing issues (except for a few) to unassigned. I may have set some issues that you where working on or planning to work to unassigned, if so just grab them straight away.

Basic rule should be before you plan to work on an issue assign it to yourself. If someone else has an issue you'd like to work on, but it's assigned to them, talk to them directly prior to working on it.

Also, for larger issues (+2 days sort of things) it could be an idea to fire an email first on how you plan to attack it.

From Anil.Saldhana at redhat.com  Tue May  6 11:30:25 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 06 May 2014 10:30:25 -0500
Subject: [keycloak-dev] can we ditch org.json?
In-Reply-To: <53680FF6.6090302@redhat.com>
References: <53680FF6.6090302@redhat.com>
Message-ID: <53690011.50508@redhat.com>

Should we start looking at JSONP libraries?

My personal preference is Jackson too.  But I see a lot of usage of
Jackson,Jettison,org.json, g-json in various OSS projects.

I wonder if the time to standardize on the json-p library has come.

On 05/05/2014 05:25 PM, Bill Burke wrote:
> Would it be possible to ditch org.json and use Jackson instead?
> Specifically the JsonSerialization class?
>
> It will just be one less library that needs to go through productization.
>


From stian at redhat.com  Tue May  6 11:36:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 11:36:18 -0400 (EDT)
Subject: [keycloak-dev] can we ditch org.json?
In-Reply-To: <53690011.50508@redhat.com>
References: <53680FF6.6090302@redhat.com> <53690011.50508@redhat.com>
Message-ID: <1849516566.1644421.1399390578830.JavaMail.zimbra@redhat.com>

Do we need JSONP? 

My assumption was that browsers we need to support (at least with the js adapter) have CORS support.

----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 6 May, 2014 4:30:25 PM
> Subject: Re: [keycloak-dev] can we ditch org.json?
> 
> Should we start looking at JSONP libraries?
> 
> My personal preference is Jackson too.  But I see a lot of usage of
> Jackson,Jettison,org.json, g-json in various OSS projects.
> 
> I wonder if the time to standardize on the json-p library has come.
> 
> On 05/05/2014 05:25 PM, Bill Burke wrote:
> > Would it be possible to ditch org.json and use Jackson instead?
> > Specifically the JsonSerialization class?
> >
> > It will just be one less library that needs to go through productization.
> >
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From Anil.Saldhana at redhat.com  Tue May  6 11:45:22 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 06 May 2014 10:45:22 -0500
Subject: [keycloak-dev] can we ditch org.json?
In-Reply-To: <1849516566.1644421.1399390578830.JavaMail.zimbra@redhat.com>
References: <53680FF6.6090302@redhat.com> <53690011.50508@redhat.com>
	<1849516566.1644421.1399390578830.JavaMail.zimbra@redhat.com>
Message-ID: <53690392.9060300@redhat.com>

Sorry for being cryptic.

I was referring to https://jcp.org/en/jsr/detail?id=353   (part of JavaEE 7)

I think this JSR was heavily influenced by Jackson.

JSONP as in JAXP. :)


On 05/06/2014 10:36 AM, Stian Thorgersen wrote:
> Do we need JSONP?
>
> My assumption was that browsers we need to support (at least with the js adapter) have CORS support.
>
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 6 May, 2014 4:30:25 PM
>> Subject: Re: [keycloak-dev] can we ditch org.json?
>>
>> Should we start looking at JSONP libraries?
>>
>> My personal preference is Jackson too.  But I see a lot of usage of
>> Jackson,Jettison,org.json, g-json in various OSS projects.
>>
>> I wonder if the time to standardize on the json-p library has come.
>>
>> On 05/05/2014 05:25 PM, Bill Burke wrote:
>>> Would it be possible to ditch org.json and use Jackson instead?
>>> Specifically the JsonSerialization class?
>>>
>>> It will just be one less library that needs to go through productization.
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Tue May  6 12:10:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 May 2014 12:10:50 -0400 (EDT)
Subject: [keycloak-dev] can we ditch org.json?
In-Reply-To: <53690392.9060300@redhat.com>
References: <53680FF6.6090302@redhat.com> <53690011.50508@redhat.com>
	<1849516566.1644421.1399390578830.JavaMail.zimbra@redhat.com>
	<53690392.9060300@redhat.com>
Message-ID: <157849159.1674610.1399392650031.JavaMail.zimbra@redhat.com>

That makes more sense ;)

"JSON-P" is an incredibly bad abbreviation considering JSONP is something completely different. 

----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 6 May, 2014 4:45:22 PM
> Subject: Re: [keycloak-dev] can we ditch org.json?
> 
> Sorry for being cryptic.
> 
> I was referring to https://jcp.org/en/jsr/detail?id=353   (part of JavaEE 7)
> 
> I think this JSR was heavily influenced by Jackson.
> 
> JSONP as in JAXP. :)
> 
> 
> On 05/06/2014 10:36 AM, Stian Thorgersen wrote:
> > Do we need JSONP?
> >
> > My assumption was that browsers we need to support (at least with the js
> > adapter) have CORS support.
> >
> > ----- Original Message -----
> >> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 6 May, 2014 4:30:25 PM
> >> Subject: Re: [keycloak-dev] can we ditch org.json?
> >>
> >> Should we start looking at JSONP libraries?
> >>
> >> My personal preference is Jackson too.  But I see a lot of usage of
> >> Jackson,Jettison,org.json, g-json in various OSS projects.
> >>
> >> I wonder if the time to standardize on the json-p library has come.
> >>
> >> On 05/05/2014 05:25 PM, Bill Burke wrote:
> >>> Would it be possible to ditch org.json and use Jackson instead?
> >>> Specifically the JsonSerialization class?
> >>>
> >>> It will just be one less library that needs to go through productization.
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue May  6 13:02:29 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 06 May 2014 13:02:29 -0400
Subject: [keycloak-dev] can we ditch org.json?
In-Reply-To: <157849159.1674610.1399392650031.JavaMail.zimbra@redhat.com>
References: <53680FF6.6090302@redhat.com>
	<53690011.50508@redhat.com>	<1849516566.1644421.1399390578830.JavaMail.zimbra@redhat.com>	<53690392.9060300@redhat.com>
	<157849159.1674610.1399392650031.JavaMail.zimbra@redhat.com>
Message-ID: <536915A5.3080109@redhat.com>

Sticking with Jackson 1.9.x solely.  Mainly because it's available in 
AS7, EAP 6, and Wildfly.  :)  As you also probably already painfully 
experienced Anil, org.json is now one less JAR that has to go through 
productization.

On 5/6/2014 12:10 PM, Stian Thorgersen wrote:
> That makes more sense ;)
>
> "JSON-P" is an incredibly bad abbreviation considering JSONP is something completely different.
>
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 6 May, 2014 4:45:22 PM
>> Subject: Re: [keycloak-dev] can we ditch org.json?
>>
>> Sorry for being cryptic.
>>
>> I was referring to https://jcp.org/en/jsr/detail?id=353   (part of JavaEE 7)
>>
>> I think this JSR was heavily influenced by Jackson.
>>
>> JSONP as in JAXP. :)
>>
>>
>> On 05/06/2014 10:36 AM, Stian Thorgersen wrote:
>>> Do we need JSONP?
>>>
>>> My assumption was that browsers we need to support (at least with the js
>>> adapter) have CORS support.
>>>
>>> ----- Original Message -----
>>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 6 May, 2014 4:30:25 PM
>>>> Subject: Re: [keycloak-dev] can we ditch org.json?
>>>>
>>>> Should we start looking at JSONP libraries?
>>>>
>>>> My personal preference is Jackson too.  But I see a lot of usage of
>>>> Jackson,Jettison,org.json, g-json in various OSS projects.
>>>>
>>>> I wonder if the time to standardize on the json-p library has come.
>>>>
>>>> On 05/05/2014 05:25 PM, Bill Burke wrote:
>>>>> Would it be possible to ditch org.json and use Jackson instead?
>>>>> Specifically the JsonSerialization class?
>>>>>
>>>>> It will just be one less library that needs to go through productization.
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Anil.Saldhana at redhat.com  Tue May  6 13:17:31 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 06 May 2014 12:17:31 -0500
Subject: [keycloak-dev] can we ditch org.json?
In-Reply-To: <536915A5.3080109@redhat.com>
References: <53680FF6.6090302@redhat.com>	<53690011.50508@redhat.com>	<1849516566.1644421.1399390578830.JavaMail.zimbra@redhat.com>	<53690392.9060300@redhat.com>	<157849159.1674610.1399392650031.JavaMail.zimbra@redhat.com>
	<536915A5.3080109@redhat.com>
Message-ID: <5369192B.30100@redhat.com>

Bill - it makes perfect sense to use Jackson 1.9.x

Personally I am not a fan of using Jackson annotations in the JSON model 
objects.
I try to keep my usage to the ObjectMapper level. But that is me. :)

On 05/06/2014 12:02 PM, Bill Burke wrote:
> Sticking with Jackson 1.9.x solely.  Mainly because it's available in
> AS7, EAP 6, and Wildfly.  :)  As you also probably already painfully
> experienced Anil, org.json is now one less JAR that has to go through
> productization.
>
> On 5/6/2014 12:10 PM, Stian Thorgersen wrote:
>> That makes more sense ;)
>>
>> "JSON-P" is an incredibly bad abbreviation considering JSONP is something completely different.
>>
>> ----- Original Message -----
>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 6 May, 2014 4:45:22 PM
>>> Subject: Re: [keycloak-dev] can we ditch org.json?
>>>
>>> Sorry for being cryptic.
>>>
>>> I was referring to https://jcp.org/en/jsr/detail?id=353   (part of JavaEE 7)
>>>
>>> I think this JSR was heavily influenced by Jackson.
>>>
>>> JSONP as in JAXP. :)
>>>
>>>
>>> On 05/06/2014 10:36 AM, Stian Thorgersen wrote:
>>>> Do we need JSONP?
>>>>
>>>> My assumption was that browsers we need to support (at least with the js
>>>> adapter) have CORS support.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Tuesday, 6 May, 2014 4:30:25 PM
>>>>> Subject: Re: [keycloak-dev] can we ditch org.json?
>>>>>
>>>>> Should we start looking at JSONP libraries?
>>>>>
>>>>> My personal preference is Jackson too.  But I see a lot of usage of
>>>>> Jackson,Jettison,org.json, g-json in various OSS projects.
>>>>>
>>>>> I wonder if the time to standardize on the json-p library has come.
>>>>>
>>>>> On 05/05/2014 05:25 PM, Bill Burke wrote:
>>>>>> Would it be possible to ditch org.json and use Jackson instead?
>>>>>> Specifically the JsonSerialization class?
>>>>>>
>>>>>> It will just be one less library that needs to go through productization.
>>>>>>
>>>>>>

From mposolda at redhat.com  Tue May  6 16:50:51 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 06 May 2014 22:50:51 +0200
Subject: [keycloak-dev] Export/import implementation
In-Reply-To: <535E771C.1040309@redhat.com>
References: <535E02F1.4090107@redhat.com> <535E4F00.7020506@redhat.com>
	<535E771C.1040309@redhat.com>
Message-ID: <53694B2B.5040602@redhat.com>

I've sent PR with export/import (migration) implementation. 
https://github.com/keycloak/keycloak/pull/366

Some notes:

* It's possible to trigger export/import during startup with usage of 
system properties. It's triggered from KeycloakApplication constructor 
similarly like all other initialization tasks (ApplianceBootstrap etc). 
Hence there was no need to create any "pause" filter as export/import is 
done before KC can serve requests

* 2 IO providers for export/import data. You can either choose from:
** "dir" provider (data are exported into JSON files in some directory 
in your filesystem. All data including password hashes are in 
plain-text, so this provider is useful mainly for testing)
** "zip" provider (data are exported into ZIP file encrypted by provided 
password. Data are exported directly from Java OutputStream into ZIP, 
nothing is written to disk unencrypted. Usage of small 3rd party library 
winzipaes). Zip provider is the default one. The ID of provider, 
location of ZIP file and password for ZIP encryption are configurable 
with system properties.

* I've used model approach as we agreed, so I needed to add few methods 
into model API. Main additions are 2 new methods 
"getCredentialsDirectly" and "updateCredentialsDirectly" for save and 
load user passwords with knowing of their hash+salt . Also I've added 
new methods, which allow to create objects by their name and ID. For 
example:
addApplication(String id, String name);
addRole(String id, String name);
...

The previous form with creating new objects just by name is indeed kept, 
so methods like:
addApplication(String name);
addRole(String name);
...
are still available. In this case ID is autogenerated like before.

* As a consequence, I did some refactoring of mongo module and removed 
dependency on picketlink-common from it. I've forked some helper 
reflection classes from it into model-api as those classes are used by 
both mongo-model and export-import. I still need to do more work related 
to picketlink isolation, so will likely continue tomorrow.

For now, I did not anything related to versions and migration 
converters. I believe that this can be postponed after Beta1 and maybe 
also after 1.0-Final? I think we can develop support for version updates 
later once we need it (so somewhere between 1.0-Final and 1.1-Final 
releases)

Marek


On 28.4.2014 17:43, Marek Posolda wrote:
> On 28.4.2014 14:52, Bill Burke wrote:
>> On 4/28/2014 3:27 AM, Marek Posolda wrote:
>>> I am planning to start soon on export/import. If I recall correctly, one
>>> of the requirements is to export the content of whole DB content
>>> (including IDs and password hashes) to JSON file, which can then be
>>> later imported into other DB. This will allow to migrate between
>>> environments and various DB types (For example from Mongo to MySQL and
>>> viceversa).
>>>
>> IMO, a full export (of credentials) should require a secret given by the
>> admin that will be used to encrypt the export.  The export should only
>> be saved locally to disk and not available over the network.
> Yes, so the exported JSON file will be always saved just to local
> filesystem with KC server and never sent over the network. With respect
> to this, I am not sure if securing the JSON file is big issue as the
> file is anyway available just to someone with physical access to the
> machine with KC server? However for better protection and ensuring that
> nobody can read it, I will encrypt the content of this file, likely with
> KDF as proposed by Bruno.
>>> I have some question though
>>>
>>> 1) I assume that DB should be cleared before full import from JSON file?
>>> Or do we want to update existing data without deleting the previous
>>> content? I assume that this is used for migration, so it's not about
>>> updating but completely delete and recreate existing DB, correct?
>>>
>>> 2) How to implement it. I can see two approaches
>>>
>>> a) Use model API to retrieve content of the DB into JSON file during
>>> export. Similarly during import use model API to sync objects back from
>>> JSON into model DB.
>>>
>>> b) Add some methods to KeycloakSession interface like:
>>>
>>> ObjectNode export();
>>>
>>> void import(ObjectNode node);
>>>
>>> and implement export/import separately for each model.
>>>
>>> Approach (b) might be better for performance as it allows to directly
>>> use low-level queries specific to JPA, Mongo or other model
>>> implementations to export/import stuff more effectively in batch,
>>> however it will require changes in model implementations and probably
>>> adding more stuff into dependencies. So I am more convinced to use (a).
>>> Thoughts?
>>>
>> "a", IMO.  Easier to maintain.
> oops, now thinking again that current model API doesn't allow to
> retrieve password hash or save password hash into DB? It allows to
> validate plain-text password or save plain-text password but there is no
> support for load or save directly the value of password hash. I wonder
> if it's ok to add some methods to RealmModel, which will allow to
> load/save password hashes?
>
> If you don't want this, I will maybe need to use low-level stuff and
> stick with option (b) .
>>> 3) How will be export/import triggered?
>>>
>>> I think that for security reasons, we want to always export into local
>>> file with KC server and similarly always import from local file. Is it
>>> correct? I can see approaches like:
>>>
>> You can already import a full json description from the admin console.
>>
>>> a) Use KC admin console. By default, just "admin" will be able to
>>> export/import stuff . Data will be always exported/imported into JSON
>>> file local to server. So it will be possible to trigger export/import
>>> remotely from admin console, but just use local JSON file. The import
>>> would be tricky though as import will recreate all data (including admin
>>> realm and admin user) so it would need to cancel logout sessions
>>> including the session of admin user who triggered import.
>>>
>>> b) Use some script, which will trigger JVM process for export/import
>>> data. Script can be executed locally from CMD. I can imagine something
>>> like this (executed from the directory with AS7/wildfly server):
>>>
>>> ./bin/keycloak-import -Dkeycloak.model=jpa
>>> -Ddata-to-import=/tmp/file-with-full-kc-data-to-import-which-were-previously-exported.json
>>>
>>> Assumption is that distribution contains deployed KC inside
>>> standalone/deployments/auth-server.war. Script will be able to run JVM
>>> which will have access to needed KC jars on classpath and access to
>>> persistence.xml . In AS7/Wildfly environment the persistence.xml bundled
>>> inside auth-server.war is using datasource though, so this JVM process
>>> would also need to parse datasource from
>>> standalone/configuration/standalone.xml as it won't be executed in
>>> managed AS7/Wildfly environment.
>>>
>>> c) Use something similar to approach (b) but execute export/import from
>>> AS7/Wildfly CLI or admin console. The advantage is that it is triggered
>>> from the managed (AS7 or Wildfly) so has access to server resources like
>>> datasource referenced from persistence.xml
>>>
>> I don't see any reason you couldn't trigger an import from the admin
>> console.  Especially if we require a secret used to encrypt the export.
>>
>>
> Sure, I can. However as already mentioned, all the KC data (including
> admin realm and current admin user who is triggering import) are going
> to be deleted and re-imported from JSON file, so there are many things,
> which need to be addressed if we want to support it on the "online"
> system like:
> - Filter, which will pause all requests until export/import is done
> - All existing states in memory (TokenManager, SocialRequestManager)
> needs to be cleared after import
> - All existing sessions should be logged out (including the session of
> current admin user) after import
>
> There might be more issues related to this and user experience might not
> be good. So it seems to be much easier to support importing data either
> on KC startup as proposed by Stian or at "offline" time when KC server
> is not running at all, which can be done with script?
>
> Exporting data from KC DB into JSON file seems to be safer, but there is
> still a need to pause the server with HTTP or JAX-RS filter, as if users
> are allowed to change data during export (like changing password or
> changing their emails etc), it might result in broken exported data.
>
> I don't know exactly how are production systems deal with
> backup/migration of data, don't have much experience with this. But I
> assume that administrators are usually not doing it on the "online" data.
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Tue May  6 21:13:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 06 May 2014 21:13:17 -0400
Subject: [keycloak-dev] merged: started /rest remove and pom fixes
Message-ID: <536988AD.3060200@redhat.com>

Some of the poms were broken.  Also removed "/rest" from RealmsResource. 
  Finally, I refactored a lot of the tests so that they aren't so 
sensitive to url schema changes anymore.

So, you might want to merge!  I'll be doing a lot more of these URI 
schema change and removing /rest entirely.  This goes along with the 
realm admin work, btw.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue May  6 21:20:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 06 May 2014 21:20:31 -0400
Subject: [keycloak-dev] Export/import implementation
In-Reply-To: <53694B2B.5040602@redhat.com>
References: <535E02F1.4090107@redhat.com> <535E4F00.7020506@redhat.com>
	<535E771C.1040309@redhat.com> <53694B2B.5040602@redhat.com>
Message-ID: <53698A5F.4070001@redhat.com>

Great work Marek!

On 5/6/2014 4:50 PM, Marek Posolda wrote:
> I've sent PR with export/import (migration) implementation.
> https://github.com/keycloak/keycloak/pull/366
>
> Some notes:
>
> * It's possible to trigger export/import during startup with usage of
> system properties. It's triggered from KeycloakApplication constructor
> similarly like all other initialization tasks (ApplianceBootstrap etc).
> Hence there was no need to create any "pause" filter as export/import is
> done before KC can serve requests
>
> * 2 IO providers for export/import data. You can either choose from:
> ** "dir" provider (data are exported into JSON files in some directory
> in your filesystem. All data including password hashes are in
> plain-text, so this provider is useful mainly for testing)
> ** "zip" provider (data are exported into ZIP file encrypted by provided
> password. Data are exported directly from Java OutputStream into ZIP,
> nothing is written to disk unencrypted. Usage of small 3rd party library
> winzipaes). Zip provider is the default one. The ID of provider,
> location of ZIP file and password for ZIP encryption are configurable
> with system properties.
>
> * I've used model approach as we agreed, so I needed to add few methods
> into model API. Main additions are 2 new methods
> "getCredentialsDirectly" and "updateCredentialsDirectly" for save and
> load user passwords with knowing of their hash+salt . Also I've added
> new methods, which allow to create objects by their name and ID. For
> example:
> addApplication(String id, String name);
> addRole(String id, String name);
> ...
>
> The previous form with creating new objects just by name is indeed kept,
> so methods like:
> addApplication(String name);
> addRole(String name);
> ...
> are still available. In this case ID is autogenerated like before.
>
> * As a consequence, I did some refactoring of mongo module and removed
> dependency on picketlink-common from it. I've forked some helper
> reflection classes from it into model-api as those classes are used by
> both mongo-model and export-import. I still need to do more work related
> to picketlink isolation, so will likely continue tomorrow.
>
> For now, I did not anything related to versions and migration
> converters. I believe that this can be postponed after Beta1 and maybe
> also after 1.0-Final? I think we can develop support for version updates
> later once we need it (so somewhere between 1.0-Final and 1.1-Final
> releases)
>
> Marek
>
>
> On 28.4.2014 17:43, Marek Posolda wrote:
>> On 28.4.2014 14:52, Bill Burke wrote:
>>> On 4/28/2014 3:27 AM, Marek Posolda wrote:
>>>> I am planning to start soon on export/import. If I recall correctly,
>>>> one
>>>> of the requirements is to export the content of whole DB content
>>>> (including IDs and password hashes) to JSON file, which can then be
>>>> later imported into other DB. This will allow to migrate between
>>>> environments and various DB types (For example from Mongo to MySQL and
>>>> viceversa).
>>>>
>>> IMO, a full export (of credentials) should require a secret given by the
>>> admin that will be used to encrypt the export.  The export should only
>>> be saved locally to disk and not available over the network.
>> Yes, so the exported JSON file will be always saved just to local
>> filesystem with KC server and never sent over the network. With respect
>> to this, I am not sure if securing the JSON file is big issue as the
>> file is anyway available just to someone with physical access to the
>> machine with KC server? However for better protection and ensuring that
>> nobody can read it, I will encrypt the content of this file, likely with
>> KDF as proposed by Bruno.
>>>> I have some question though
>>>>
>>>> 1) I assume that DB should be cleared before full import from JSON
>>>> file?
>>>> Or do we want to update existing data without deleting the previous
>>>> content? I assume that this is used for migration, so it's not about
>>>> updating but completely delete and recreate existing DB, correct?
>>>>
>>>> 2) How to implement it. I can see two approaches
>>>>
>>>> a) Use model API to retrieve content of the DB into JSON file during
>>>> export. Similarly during import use model API to sync objects back from
>>>> JSON into model DB.
>>>>
>>>> b) Add some methods to KeycloakSession interface like:
>>>>
>>>> ObjectNode export();
>>>>
>>>> void import(ObjectNode node);
>>>>
>>>> and implement export/import separately for each model.
>>>>
>>>> Approach (b) might be better for performance as it allows to directly
>>>> use low-level queries specific to JPA, Mongo or other model
>>>> implementations to export/import stuff more effectively in batch,
>>>> however it will require changes in model implementations and probably
>>>> adding more stuff into dependencies. So I am more convinced to use (a).
>>>> Thoughts?
>>>>
>>> "a", IMO.  Easier to maintain.
>> oops, now thinking again that current model API doesn't allow to
>> retrieve password hash or save password hash into DB? It allows to
>> validate plain-text password or save plain-text password but there is no
>> support for load or save directly the value of password hash. I wonder
>> if it's ok to add some methods to RealmModel, which will allow to
>> load/save password hashes?
>>
>> If you don't want this, I will maybe need to use low-level stuff and
>> stick with option (b) .
>>>> 3) How will be export/import triggered?
>>>>
>>>> I think that for security reasons, we want to always export into local
>>>> file with KC server and similarly always import from local file. Is it
>>>> correct? I can see approaches like:
>>>>
>>> You can already import a full json description from the admin console.
>>>
>>>> a) Use KC admin console. By default, just "admin" will be able to
>>>> export/import stuff . Data will be always exported/imported into JSON
>>>> file local to server. So it will be possible to trigger export/import
>>>> remotely from admin console, but just use local JSON file. The import
>>>> would be tricky though as import will recreate all data (including
>>>> admin
>>>> realm and admin user) so it would need to cancel logout sessions
>>>> including the session of admin user who triggered import.
>>>>
>>>> b) Use some script, which will trigger JVM process for export/import
>>>> data. Script can be executed locally from CMD. I can imagine something
>>>> like this (executed from the directory with AS7/wildfly server):
>>>>
>>>> ./bin/keycloak-import -Dkeycloak.model=jpa
>>>> -Ddata-to-import=/tmp/file-with-full-kc-data-to-import-which-were-previously-exported.json
>>>>
>>>>
>>>> Assumption is that distribution contains deployed KC inside
>>>> standalone/deployments/auth-server.war. Script will be able to run JVM
>>>> which will have access to needed KC jars on classpath and access to
>>>> persistence.xml . In AS7/Wildfly environment the persistence.xml
>>>> bundled
>>>> inside auth-server.war is using datasource though, so this JVM process
>>>> would also need to parse datasource from
>>>> standalone/configuration/standalone.xml as it won't be executed in
>>>> managed AS7/Wildfly environment.
>>>>
>>>> c) Use something similar to approach (b) but execute export/import from
>>>> AS7/Wildfly CLI or admin console. The advantage is that it is triggered
>>>> from the managed (AS7 or Wildfly) so has access to server resources
>>>> like
>>>> datasource referenced from persistence.xml
>>>>
>>> I don't see any reason you couldn't trigger an import from the admin
>>> console.  Especially if we require a secret used to encrypt the export.
>>>
>>>
>> Sure, I can. However as already mentioned, all the KC data (including
>> admin realm and current admin user who is triggering import) are going
>> to be deleted and re-imported from JSON file, so there are many things,
>> which need to be addressed if we want to support it on the "online"
>> system like:
>> - Filter, which will pause all requests until export/import is done
>> - All existing states in memory (TokenManager, SocialRequestManager)
>> needs to be cleared after import
>> - All existing sessions should be logged out (including the session of
>> current admin user) after import
>>
>> There might be more issues related to this and user experience might not
>> be good. So it seems to be much easier to support importing data either
>> on KC startup as proposed by Stian or at "offline" time when KC server
>> is not running at all, which can be done with script?
>>
>> Exporting data from KC DB into JSON file seems to be safer, but there is
>> still a need to pause the server with HTTP or JAX-RS filter, as if users
>> are allowed to change data during export (like changing password or
>> changing their emails etc), it might result in broken exported data.
>>
>> I don't know exactly how are production systems deal with
>> backup/migration of data, don't have much experience with this. But I
>> assume that administrators are usually not doing it on the "online" data.
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed May  7 04:14:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 7 May 2014 04:14:08 -0400 (EDT)
Subject: [keycloak-dev] Export/import implementation
In-Reply-To: <53694B2B.5040602@redhat.com>
References: <535E02F1.4090107@redhat.com> <535E4F00.7020506@redhat.com>
	<535E771C.1040309@redhat.com> <53694B2B.5040602@redhat.com>
Message-ID: <765272093.2192009.1399450448547.JavaMail.zimbra@redhat.com>

Nice :)

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 6 May, 2014 9:50:51 PM
> Subject: Re: [keycloak-dev] Export/import implementation
> 
> I've sent PR with export/import (migration) implementation.
> https://github.com/keycloak/keycloak/pull/366
> 
> Some notes:
> 
> * It's possible to trigger export/import during startup with usage of
> system properties. It's triggered from KeycloakApplication constructor
> similarly like all other initialization tasks (ApplianceBootstrap etc).
> Hence there was no need to create any "pause" filter as export/import is
> done before KC can serve requests
> 
> * 2 IO providers for export/import data. You can either choose from:
> ** "dir" provider (data are exported into JSON files in some directory
> in your filesystem. All data including password hashes are in
> plain-text, so this provider is useful mainly for testing)
> ** "zip" provider (data are exported into ZIP file encrypted by provided
> password. Data are exported directly from Java OutputStream into ZIP,
> nothing is written to disk unencrypted. Usage of small 3rd party library
> winzipaes). Zip provider is the default one. The ID of provider,
> location of ZIP file and password for ZIP encryption are configurable
> with system properties.
> 
> * I've used model approach as we agreed, so I needed to add few methods
> into model API. Main additions are 2 new methods
> "getCredentialsDirectly" and "updateCredentialsDirectly" for save and
> load user passwords with knowing of their hash+salt . Also I've added
> new methods, which allow to create objects by their name and ID. For
> example:
> addApplication(String id, String name);
> addRole(String id, String name);
> ...
> 
> The previous form with creating new objects just by name is indeed kept,
> so methods like:
> addApplication(String name);
> addRole(String name);
> ...
> are still available. In this case ID is autogenerated like before.
> 
> * As a consequence, I did some refactoring of mongo module and removed
> dependency on picketlink-common from it. I've forked some helper
> reflection classes from it into model-api as those classes are used by
> both mongo-model and export-import. I still need to do more work related
> to picketlink isolation, so will likely continue tomorrow.
> 
> For now, I did not anything related to versions and migration
> converters. I believe that this can be postponed after Beta1 and maybe
> also after 1.0-Final? I think we can develop support for version updates
> later once we need it (so somewhere between 1.0-Final and 1.1-Final
> releases)

Yes, that's fine

> 
> Marek
> 
> 
> On 28.4.2014 17:43, Marek Posolda wrote:
> > On 28.4.2014 14:52, Bill Burke wrote:
> >> On 4/28/2014 3:27 AM, Marek Posolda wrote:
> >>> I am planning to start soon on export/import. If I recall correctly, one
> >>> of the requirements is to export the content of whole DB content
> >>> (including IDs and password hashes) to JSON file, which can then be
> >>> later imported into other DB. This will allow to migrate between
> >>> environments and various DB types (For example from Mongo to MySQL and
> >>> viceversa).
> >>>
> >> IMO, a full export (of credentials) should require a secret given by the
> >> admin that will be used to encrypt the export.  The export should only
> >> be saved locally to disk and not available over the network.
> > Yes, so the exported JSON file will be always saved just to local
> > filesystem with KC server and never sent over the network. With respect
> > to this, I am not sure if securing the JSON file is big issue as the
> > file is anyway available just to someone with physical access to the
> > machine with KC server? However for better protection and ensuring that
> > nobody can read it, I will encrypt the content of this file, likely with
> > KDF as proposed by Bruno.
> >>> I have some question though
> >>>
> >>> 1) I assume that DB should be cleared before full import from JSON file?
> >>> Or do we want to update existing data without deleting the previous
> >>> content? I assume that this is used for migration, so it's not about
> >>> updating but completely delete and recreate existing DB, correct?
> >>>
> >>> 2) How to implement it. I can see two approaches
> >>>
> >>> a) Use model API to retrieve content of the DB into JSON file during
> >>> export. Similarly during import use model API to sync objects back from
> >>> JSON into model DB.
> >>>
> >>> b) Add some methods to KeycloakSession interface like:
> >>>
> >>> ObjectNode export();
> >>>
> >>> void import(ObjectNode node);
> >>>
> >>> and implement export/import separately for each model.
> >>>
> >>> Approach (b) might be better for performance as it allows to directly
> >>> use low-level queries specific to JPA, Mongo or other model
> >>> implementations to export/import stuff more effectively in batch,
> >>> however it will require changes in model implementations and probably
> >>> adding more stuff into dependencies. So I am more convinced to use (a).
> >>> Thoughts?
> >>>
> >> "a", IMO.  Easier to maintain.
> > oops, now thinking again that current model API doesn't allow to
> > retrieve password hash or save password hash into DB? It allows to
> > validate plain-text password or save plain-text password but there is no
> > support for load or save directly the value of password hash. I wonder
> > if it's ok to add some methods to RealmModel, which will allow to
> > load/save password hashes?
> >
> > If you don't want this, I will maybe need to use low-level stuff and
> > stick with option (b) .
> >>> 3) How will be export/import triggered?
> >>>
> >>> I think that for security reasons, we want to always export into local
> >>> file with KC server and similarly always import from local file. Is it
> >>> correct? I can see approaches like:
> >>>
> >> You can already import a full json description from the admin console.
> >>
> >>> a) Use KC admin console. By default, just "admin" will be able to
> >>> export/import stuff . Data will be always exported/imported into JSON
> >>> file local to server. So it will be possible to trigger export/import
> >>> remotely from admin console, but just use local JSON file. The import
> >>> would be tricky though as import will recreate all data (including admin
> >>> realm and admin user) so it would need to cancel logout sessions
> >>> including the session of admin user who triggered import.
> >>>
> >>> b) Use some script, which will trigger JVM process for export/import
> >>> data. Script can be executed locally from CMD. I can imagine something
> >>> like this (executed from the directory with AS7/wildfly server):
> >>>
> >>> ./bin/keycloak-import -Dkeycloak.model=jpa
> >>> -Ddata-to-import=/tmp/file-with-full-kc-data-to-import-which-were-previously-exported.json
> >>>
> >>> Assumption is that distribution contains deployed KC inside
> >>> standalone/deployments/auth-server.war. Script will be able to run JVM
> >>> which will have access to needed KC jars on classpath and access to
> >>> persistence.xml . In AS7/Wildfly environment the persistence.xml bundled
> >>> inside auth-server.war is using datasource though, so this JVM process
> >>> would also need to parse datasource from
> >>> standalone/configuration/standalone.xml as it won't be executed in
> >>> managed AS7/Wildfly environment.
> >>>
> >>> c) Use something similar to approach (b) but execute export/import from
> >>> AS7/Wildfly CLI or admin console. The advantage is that it is triggered
> >>> from the managed (AS7 or Wildfly) so has access to server resources like
> >>> datasource referenced from persistence.xml
> >>>
> >> I don't see any reason you couldn't trigger an import from the admin
> >> console.  Especially if we require a secret used to encrypt the export.
> >>
> >>
> > Sure, I can. However as already mentioned, all the KC data (including
> > admin realm and current admin user who is triggering import) are going
> > to be deleted and re-imported from JSON file, so there are many things,
> > which need to be addressed if we want to support it on the "online"
> > system like:
> > - Filter, which will pause all requests until export/import is done
> > - All existing states in memory (TokenManager, SocialRequestManager)
> > needs to be cleared after import
> > - All existing sessions should be logged out (including the session of
> > current admin user) after import
> >
> > There might be more issues related to this and user experience might not
> > be good. So it seems to be much easier to support importing data either
> > on KC startup as proposed by Stian or at "offline" time when KC server
> > is not running at all, which can be done with script?
> >
> > Exporting data from KC DB into JSON file seems to be safer, but there is
> > still a need to pause the server with HTTP or JAX-RS filter, as if users
> > are allowed to change data during export (like changing password or
> > changing their emails etc), it might result in broken exported data.
> >
> > I don't know exactly how are production systems deal with
> > backup/migration of data, don't have much experience with this. But I
> > assume that administrators are usually not doing it on the "online" data.
> >
> > Marek
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu May  8 20:13:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 08 May 2014 20:13:40 -0400
Subject: [keycloak-dev] account/admin services don't have their own cookie
Message-ID: <536C1DB4.9070703@redhat.com>

The account service and admin console UI no longer have their own 
identity cookie.  The account service validates via the realm cookie (or 
token).  The admin console APIs are now only available via a token.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May  8 20:18:30 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 08 May 2014 20:18:30 -0400
Subject: [keycloak-dev] admin uses keycloak.js login
Message-ID: <536C1ED6.1080907@redhat.com>

Admin console now uses keycloak.js login.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May  8 20:40:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 08 May 2014 20:40:46 -0400
Subject: [keycloak-dev] Signle sign off doens't work for admin console
Message-ID: <536C240E.5070200@redhat.com>

I think I can solve this by moving the admin console and its REST api 
under /realms/{realm}.

URL would be:

/realms/{realm}/console/index.html
/realms/{realm}/console/{.js, .html, .img}
/realms/{realm}/console/realms/{realm}/... admin REST api

To protect against CSRF (not sure its applicable to JSON services 
anyways), we can do double authentication with the realm's Identity 
cookie and an access-token for REST calls.

When a user does a single-sign-off, this will expire the realm's global 
identity cookie, and thus, the admin console would then also 
automatically be logged out.

BTW, this single-sign-off problem exists for all javascript apps secured 
by keycloak.js or that don't have a server-side session we can callback. 
  We might be able to use:

http://openid.net/specs/openid-connect-session-1_0.html

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May  8 22:05:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 08 May 2014 22:05:26 -0400
Subject: [keycloak-dev] openid connect iframe logout
Message-ID: <536C37E6.9090307@redhat.com>

I'm looking at:

http://openid.net/specs/openid-connect-session-1_0.html

I don't think using iframes for single log out is any better than what 
we're currently doing and planning on doing for keycloak.js.

For the OpenID Iframe technique, if our global login cookies are 
HttpOnly, then the OP Iframe will have to do a periodic "ping" request 
to the server to test the cookie.  This is really no different than the 
current plan to expire login sessions and invalidate refresh token 
requests based on on a login-session id.  I say this because there is 
still a time element involved where there is a window from when the user 
logs out and either the periodic "ping" hasn't been executed yet (openid 
connect iframe technique), or the access token hasn't expired yet.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May  9 06:52:28 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 May 2014 06:52:28 -0400 (EDT)
Subject: [keycloak-dev] openid connect iframe logout
In-Reply-To: <536C37E6.9090307@redhat.com>
References: <536C37E6.9090307@redhat.com>
Message-ID: <1953885551.3963732.1399632748564.JavaMail.zimbra@redhat.com>

Added issues:
* https://issues.jboss.org/browse/KEYCLOAK-450
* https://issues.jboss.org/browse/KEYCLOAK-451

I don't get the OpenID technique. Would it not be simpler to have a periodic XMLHttpRequest (or even better an async WebSocket) to retrieve the status of a session? The whole concept of iframes seems very hacky to me.

I think what we have at the moment is good enough (at least for beta1), and we can look at this later.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 9 May, 2014 3:05:26 AM
> Subject: [keycloak-dev] openid connect iframe logout
> 
> I'm looking at:
> 
> http://openid.net/specs/openid-connect-session-1_0.html
> 
> I don't think using iframes for single log out is any better than what
> we're currently doing and planning on doing for keycloak.js.
> 
> For the OpenID Iframe technique, if our global login cookies are
> HttpOnly, then the OP Iframe will have to do a periodic "ping" request
> to the server to test the cookie.  This is really no different than the
> current plan to expire login sessions and invalidate refresh token
> requests based on on a login-session id.  I say this because there is
> still a time element involved where there is a window from when the user
> logs out and either the periodic "ping" hasn't been executed yet (openid
> connect iframe technique), or the access token hasn't expired yet.
> 
> 
> --
> 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
> 

From stian at redhat.com  Fri May  9 06:59:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 May 2014 06:59:59 -0400 (EDT)
Subject: [keycloak-dev] User sessions added
In-Reply-To: <273785370.3965457.1399632934834.JavaMail.zimbra@redhat.com>
Message-ID: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>

User sessions have been added. In summary when a user logs in a new session is created (and persisted in the model). The identity cookie as well as all tokens/refresh-tokens are associated with a session. When a user logs out the session is invalidated (removed from the model), which invalidates the identity cookie and all tokens/refresh-tokens.

There's two related issues left to do:

* Make sure adapters only log out a specific session (if LoginAction contains a session id)
* Allow a user to log out all sessions through the account management console

Also, we may want some mechanism to retrieve the status of a session from applications. This could be a REST endpoint, or the crazy iframe technique from OpenID Connect. I think this can be postponed to after 1.0 though.

From bburke at redhat.com  Fri May  9 08:41:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 09 May 2014 08:41:02 -0400
Subject: [keycloak-dev] User sessions added
In-Reply-To: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
References: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
Message-ID: <536CCCDE.10105@redhat.com>



On 5/9/2014 6:59 AM, Stian Thorgersen wrote:
> User sessions have been added. In summary when a user logs in a new session is created (and persisted in the model). The identity cookie as well as all tokens/refresh-tokens are associated with a session. When a user logs out the session is invalidated (removed from the model), which invalidates the identity cookie and all tokens/refresh-tokens.
>
> There's two related issues left to do:
>
> * Make sure adapters only log out a specific session (if LoginAction contains a session id)
> * Allow a user to log out all sessions through the account management console
>
> Also, we may want some mechanism to retrieve the status of a session from applications. This could be a REST endpoint, or the crazy iframe technique from OpenID Connect. I think this can be postponed to after 1.0 though.
>

The crazy IFrame techique would require this REST "ping".  At least for 
us, as our cookies would be http-only.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May  9 09:10:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 May 2014 09:10:30 -0400 (EDT)
Subject: [keycloak-dev] User sessions added
In-Reply-To: <536CCCDE.10105@redhat.com>
References: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
	<536CCCDE.10105@redhat.com>
Message-ID: <489786583.4066152.1399641030290.JavaMail.zimbra@redhat.com>

What then is the benefit of having this iframe compared to just adding something like the following to keycloak.js:

setTimeout(function() {
  var req = new XMLHttpRequest();
  req.open('GET', 'http://localhost:8080/auth/rest/realms/realm/tokens/session-status?session_state=...', true);
  req.onreadystatechange = function () {
    if (req.readyState == 4 && req.status == 200) {
      var status = JSON.parse(req.responseText);
      if (!status.active) {
        clearToken();
      }
    }
  }
  req.send();
}, 3000);


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 9 May, 2014 1:41:02 PM
> Subject: Re: [keycloak-dev] User sessions added
> 
> 
> 
> On 5/9/2014 6:59 AM, Stian Thorgersen wrote:
> > User sessions have been added. In summary when a user logs in a new session
> > is created (and persisted in the model). The identity cookie as well as
> > all tokens/refresh-tokens are associated with a session. When a user logs
> > out the session is invalidated (removed from the model), which invalidates
> > the identity cookie and all tokens/refresh-tokens.
> >
> > There's two related issues left to do:
> >
> > * Make sure adapters only log out a specific session (if LoginAction
> > contains a session id)
> > * Allow a user to log out all sessions through the account management
> > console
> >
> > Also, we may want some mechanism to retrieve the status of a session from
> > applications. This could be a REST endpoint, or the crazy iframe technique
> > from OpenID Connect. I think this can be postponed to after 1.0 though.
> >
> 
> The crazy IFrame techique would require this REST "ping".  At least for
> us, as our cookies would be http-only.
> 
> 
> --
> 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
> 

From bburke at redhat.com  Fri May  9 09:16:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 09 May 2014 09:16:50 -0400
Subject: [keycloak-dev] openid connect iframe logout
In-Reply-To: <1953885551.3963732.1399632748564.JavaMail.zimbra@redhat.com>
References: <536C37E6.9090307@redhat.com>
	<1953885551.3963732.1399632748564.JavaMail.zimbra@redhat.com>
Message-ID: <536CD542.6060408@redhat.com>

Ok, I think I know why the ipframe technique exists:

Specifically to avoid network traffic.  From spec: " it is desirable to 
be able to check the login status at the OP without causing network 
traffic".

This could only work if our cookies were viewable in Javascript. (not 
HttpOnly).  But just Google "steal cross domain cookies" and you'll see 
why this just isn't a great idea.

On 5/9/2014 6:52 AM, Stian Thorgersen wrote:
> Added issues:
> * https://issues.jboss.org/browse/KEYCLOAK-450
> * https://issues.jboss.org/browse/KEYCLOAK-451
>
> I don't get the OpenID technique. Would it not be simpler to have a periodic XMLHttpRequest (or even better an async WebSocket) to retrieve the status of a session? The whole concept of iframes seems very hacky to me.
>
> I think what we have at the moment is good enough (at least for beta1), and we can look at this later.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 9 May, 2014 3:05:26 AM
>> Subject: [keycloak-dev] openid connect iframe logout
>>
>> I'm looking at:
>>
>> http://openid.net/specs/openid-connect-session-1_0.html
>>
>> I don't think using iframes for single log out is any better than what
>> we're currently doing and planning on doing for keycloak.js.
>>
>> For the OpenID Iframe technique, if our global login cookies are
>> HttpOnly, then the OP Iframe will have to do a periodic "ping" request
>> to the server to test the cookie.  This is really no different than the
>> current plan to expire login sessions and invalidate refresh token
>> requests based on on a login-session id.  I say this because there is
>> still a time element involved where there is a window from when the user
>> logs out and either the periodic "ping" hasn't been executed yet (openid
>> connect iframe technique), or the access token hasn't expired yet.
>>
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May  9 09:18:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 May 2014 09:18:41 -0400 (EDT)
Subject: [keycloak-dev] openid connect iframe logout
In-Reply-To: <536CD542.6060408@redhat.com>
References: <536C37E6.9090307@redhat.com>
	<1953885551.3963732.1399632748564.JavaMail.zimbra@redhat.com>
	<536CD542.6060408@redhat.com>
Message-ID: <447246278.4072945.1399641521520.JavaMail.zimbra@redhat.com>

Surely you still need to do regular requests to the identity provider to get the cookie updated though?

----- 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, 9 May, 2014 2:16:50 PM
> Subject: Re: [keycloak-dev] openid connect iframe logout
> 
> Ok, I think I know why the ipframe technique exists:
> 
> Specifically to avoid network traffic.  From spec: " it is desirable to
> be able to check the login status at the OP without causing network
> traffic".
> 
> This could only work if our cookies were viewable in Javascript. (not
> HttpOnly).  But just Google "steal cross domain cookies" and you'll see
> why this just isn't a great idea.
> 
> On 5/9/2014 6:52 AM, Stian Thorgersen wrote:
> > Added issues:
> > * https://issues.jboss.org/browse/KEYCLOAK-450
> > * https://issues.jboss.org/browse/KEYCLOAK-451
> >
> > I don't get the OpenID technique. Would it not be simpler to have a
> > periodic XMLHttpRequest (or even better an async WebSocket) to retrieve
> > the status of a session? The whole concept of iframes seems very hacky to
> > me.
> >
> > I think what we have at the moment is good enough (at least for beta1), and
> > we can look at this later.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 9 May, 2014 3:05:26 AM
> >> Subject: [keycloak-dev] openid connect iframe logout
> >>
> >> I'm looking at:
> >>
> >> http://openid.net/specs/openid-connect-session-1_0.html
> >>
> >> I don't think using iframes for single log out is any better than what
> >> we're currently doing and planning on doing for keycloak.js.
> >>
> >> For the OpenID Iframe technique, if our global login cookies are
> >> HttpOnly, then the OP Iframe will have to do a periodic "ping" request
> >> to the server to test the cookie.  This is really no different than the
> >> current plan to expire login sessions and invalidate refresh token
> >> requests based on on a login-session id.  I say this because there is
> >> still a time element involved where there is a window from when the user
> >> logs out and either the periodic "ping" hasn't been executed yet (openid
> >> connect iframe technique), or the access token hasn't expired yet.
> >>
> >>
> >> --
> >> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri May  9 09:36:09 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 09 May 2014 09:36:09 -0400
Subject: [keycloak-dev] User sessions added
In-Reply-To: <489786583.4066152.1399641030290.JavaMail.zimbra@redhat.com>
References: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
	<536CCCDE.10105@redhat.com>
	<489786583.4066152.1399641030290.JavaMail.zimbra@redhat.com>
Message-ID: <536CD9C9.7010900@redhat.com>

That's what I was saying before.  There is no benefit in using Iframes 
if your login cookies are HttpOnly.  Your set timeout is *already* 
happening indirectly via refresh tokens.

The only other benefit might be in that you'd have to enable CORS for 
that "ping" request which might be a pain.

On 5/9/2014 9:10 AM, Stian Thorgersen wrote:
> What then is the benefit of having this iframe compared to just adding something like the following to keycloak.js:
>
> setTimeout(function() {
>    var req = new XMLHttpRequest();
>    req.open('GET', 'http://localhost:8080/auth/rest/realms/realm/tokens/session-status?session_state=...', true);
>    req.onreadystatechange = function () {
>      if (req.readyState == 4 && req.status == 200) {
>        var status = JSON.parse(req.responseText);
>        if (!status.active) {
>          clearToken();
>        }
>      }
>    }
>    req.send();
> }, 3000);
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 9 May, 2014 1:41:02 PM
>> Subject: Re: [keycloak-dev] User sessions added
>>
>>
>>
>> On 5/9/2014 6:59 AM, Stian Thorgersen wrote:
>>> User sessions have been added. In summary when a user logs in a new session
>>> is created (and persisted in the model). The identity cookie as well as
>>> all tokens/refresh-tokens are associated with a session. When a user logs
>>> out the session is invalidated (removed from the model), which invalidates
>>> the identity cookie and all tokens/refresh-tokens.
>>>
>>> There's two related issues left to do:
>>>
>>> * Make sure adapters only log out a specific session (if LoginAction
>>> contains a session id)
>>> * Allow a user to log out all sessions through the account management
>>> console
>>>
>>> Also, we may want some mechanism to retrieve the status of a session from
>>> applications. This could be a REST endpoint, or the crazy iframe technique
>>> from OpenID Connect. I think this can be postponed to after 1.0 though.
>>>
>>
>> The crazy IFrame techique would require this REST "ping".  At least for
>> us, as our cookies would be http-only.
>>
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May  9 09:38:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 May 2014 09:38:39 -0400 (EDT)
Subject: [keycloak-dev] User sessions added
In-Reply-To: <536CD9C9.7010900@redhat.com>
References: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
	<536CCCDE.10105@redhat.com>
	<489786583.4066152.1399641030290.JavaMail.zimbra@redhat.com>
	<536CD9C9.7010900@redhat.com>
Message-ID: <853930281.4089365.1399642719938.JavaMail.zimbra@redhat.com>

Could we not have a separate session state cookie that is not HttpOnly?

----- 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, 9 May, 2014 2:36:09 PM
> Subject: Re: [keycloak-dev] User sessions added
> 
> That's what I was saying before.  There is no benefit in using Iframes
> if your login cookies are HttpOnly.  Your set timeout is *already*
> happening indirectly via refresh tokens.
> 
> The only other benefit might be in that you'd have to enable CORS for
> that "ping" request which might be a pain.
> 
> On 5/9/2014 9:10 AM, Stian Thorgersen wrote:
> > What then is the benefit of having this iframe compared to just adding
> > something like the following to keycloak.js:
> >
> > setTimeout(function() {
> >    var req = new XMLHttpRequest();
> >    req.open('GET',
> >    'http://localhost:8080/auth/rest/realms/realm/tokens/session-status?session_state=...',
> >    true);
> >    req.onreadystatechange = function () {
> >      if (req.readyState == 4 && req.status == 200) {
> >        var status = JSON.parse(req.responseText);
> >        if (!status.active) {
> >          clearToken();
> >        }
> >      }
> >    }
> >    req.send();
> > }, 3000);
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 9 May, 2014 1:41:02 PM
> >> Subject: Re: [keycloak-dev] User sessions added
> >>
> >>
> >>
> >> On 5/9/2014 6:59 AM, Stian Thorgersen wrote:
> >>> User sessions have been added. In summary when a user logs in a new
> >>> session
> >>> is created (and persisted in the model). The identity cookie as well as
> >>> all tokens/refresh-tokens are associated with a session. When a user logs
> >>> out the session is invalidated (removed from the model), which
> >>> invalidates
> >>> the identity cookie and all tokens/refresh-tokens.
> >>>
> >>> There's two related issues left to do:
> >>>
> >>> * Make sure adapters only log out a specific session (if LoginAction
> >>> contains a session id)
> >>> * Allow a user to log out all sessions through the account management
> >>> console
> >>>
> >>> Also, we may want some mechanism to retrieve the status of a session from
> >>> applications. This could be a REST endpoint, or the crazy iframe
> >>> technique
> >>> from OpenID Connect. I think this can be postponed to after 1.0 though.
> >>>
> >>
> >> The crazy IFrame techique would require this REST "ping".  At least for
> >> us, as our cookies would be http-only.
> >>
> >>
> >> --
> >> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri May  9 09:52:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 09 May 2014 09:52:20 -0400
Subject: [keycloak-dev] User sessions added
In-Reply-To: <853930281.4089365.1399642719938.JavaMail.zimbra@redhat.com>
References: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
	<536CCCDE.10105@redhat.com>
	<489786583.4066152.1399641030290.JavaMail.zimbra@redhat.com>
	<536CD9C9.7010900@redhat.com>
	<853930281.4089365.1399642719938.JavaMail.zimbra@redhat.com>
Message-ID: <536CDD94.9070508@redhat.com>

Duh... :)  Now its my turn to be slow...

So the iframe solution is a good one :)  I'll add it to keycloak.js


On 5/9/2014 9:38 AM, Stian Thorgersen wrote:
> Could we not have a separate session state cookie that is not HttpOnly?
>
> ----- 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, 9 May, 2014 2:36:09 PM
>> Subject: Re: [keycloak-dev] User sessions added
>>
>> That's what I was saying before.  There is no benefit in using Iframes
>> if your login cookies are HttpOnly.  Your set timeout is *already*
>> happening indirectly via refresh tokens.
>>
>> The only other benefit might be in that you'd have to enable CORS for
>> that "ping" request which might be a pain.
>>
>> On 5/9/2014 9:10 AM, Stian Thorgersen wrote:
>>> What then is the benefit of having this iframe compared to just adding
>>> something like the following to keycloak.js:
>>>
>>> setTimeout(function() {
>>>     var req = new XMLHttpRequest();
>>>     req.open('GET',
>>>     'http://localhost:8080/auth/rest/realms/realm/tokens/session-status?session_state=...',
>>>     true);
>>>     req.onreadystatechange = function () {
>>>       if (req.readyState == 4 && req.status == 200) {
>>>         var status = JSON.parse(req.responseText);
>>>         if (!status.active) {
>>>           clearToken();
>>>         }
>>>       }
>>>     }
>>>     req.send();
>>> }, 3000);
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 9 May, 2014 1:41:02 PM
>>>> Subject: Re: [keycloak-dev] User sessions added
>>>>
>>>>
>>>>
>>>> On 5/9/2014 6:59 AM, Stian Thorgersen wrote:
>>>>> User sessions have been added. In summary when a user logs in a new
>>>>> session
>>>>> is created (and persisted in the model). The identity cookie as well as
>>>>> all tokens/refresh-tokens are associated with a session. When a user logs
>>>>> out the session is invalidated (removed from the model), which
>>>>> invalidates
>>>>> the identity cookie and all tokens/refresh-tokens.
>>>>>
>>>>> There's two related issues left to do:
>>>>>
>>>>> * Make sure adapters only log out a specific session (if LoginAction
>>>>> contains a session id)
>>>>> * Allow a user to log out all sessions through the account management
>>>>> console
>>>>>
>>>>> Also, we may want some mechanism to retrieve the status of a session from
>>>>> applications. This could be a REST endpoint, or the crazy iframe
>>>>> technique
>>>>> from OpenID Connect. I think this can be postponed to after 1.0 though.
>>>>>
>>>>
>>>> The crazy IFrame techique would require this REST "ping".  At least for
>>>> us, as our cookies would be http-only.
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May  9 09:57:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 May 2014 09:57:40 -0400 (EDT)
Subject: [keycloak-dev] User sessions added
In-Reply-To: <536CDD94.9070508@redhat.com>
References: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
	<536CCCDE.10105@redhat.com>
	<489786583.4066152.1399641030290.JavaMail.zimbra@redhat.com>
	<536CD9C9.7010900@redhat.com>
	<853930281.4089365.1399642719938.JavaMail.zimbra@redhat.com>
	<536CDD94.9070508@redhat.com>
Message-ID: <1778280327.4103827.1399643860095.JavaMail.zimbra@redhat.com>

Good thing we are slow about different things, otherwise we'd not manage to do anything ;)

----- 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, 9 May, 2014 2:52:20 PM
> Subject: Re: [keycloak-dev] User sessions added
> 
> Duh... :)  Now its my turn to be slow...
> 
> So the iframe solution is a good one :)  I'll add it to keycloak.js
> 
> 
> On 5/9/2014 9:38 AM, Stian Thorgersen wrote:
> > Could we not have a separate session state cookie that is not HttpOnly?
> >
> > ----- 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, 9 May, 2014 2:36:09 PM
> >> Subject: Re: [keycloak-dev] User sessions added
> >>
> >> That's what I was saying before.  There is no benefit in using Iframes
> >> if your login cookies are HttpOnly.  Your set timeout is *already*
> >> happening indirectly via refresh tokens.
> >>
> >> The only other benefit might be in that you'd have to enable CORS for
> >> that "ping" request which might be a pain.
> >>
> >> On 5/9/2014 9:10 AM, Stian Thorgersen wrote:
> >>> What then is the benefit of having this iframe compared to just adding
> >>> something like the following to keycloak.js:
> >>>
> >>> setTimeout(function() {
> >>>     var req = new XMLHttpRequest();
> >>>     req.open('GET',
> >>>     'http://localhost:8080/auth/rest/realms/realm/tokens/session-status?session_state=...',
> >>>     true);
> >>>     req.onreadystatechange = function () {
> >>>       if (req.readyState == 4 && req.status == 200) {
> >>>         var status = JSON.parse(req.responseText);
> >>>         if (!status.active) {
> >>>           clearToken();
> >>>         }
> >>>       }
> >>>     }
> >>>     req.send();
> >>> }, 3000);
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, 9 May, 2014 1:41:02 PM
> >>>> Subject: Re: [keycloak-dev] User sessions added
> >>>>
> >>>>
> >>>>
> >>>> On 5/9/2014 6:59 AM, Stian Thorgersen wrote:
> >>>>> User sessions have been added. In summary when a user logs in a new
> >>>>> session
> >>>>> is created (and persisted in the model). The identity cookie as well as
> >>>>> all tokens/refresh-tokens are associated with a session. When a user
> >>>>> logs
> >>>>> out the session is invalidated (removed from the model), which
> >>>>> invalidates
> >>>>> the identity cookie and all tokens/refresh-tokens.
> >>>>>
> >>>>> There's two related issues left to do:
> >>>>>
> >>>>> * Make sure adapters only log out a specific session (if LoginAction
> >>>>> contains a session id)
> >>>>> * Allow a user to log out all sessions through the account management
> >>>>> console
> >>>>>
> >>>>> Also, we may want some mechanism to retrieve the status of a session
> >>>>> from
> >>>>> applications. This could be a REST endpoint, or the crazy iframe
> >>>>> technique
> >>>>> from OpenID Connect. I think this can be postponed to after 1.0 though.
> >>>>>
> >>>>
> >>>> The crazy IFrame techique would require this REST "ping".  At least for
> >>>> us, as our cookies would be http-only.
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri May  9 10:03:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 09 May 2014 10:03:49 -0400
Subject: [keycloak-dev] User sessions added
In-Reply-To: <1778280327.4103827.1399643860095.JavaMail.zimbra@redhat.com>
References: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
	<536CCCDE.10105@redhat.com>
	<489786583.4066152.1399641030290.JavaMail.zimbra@redhat.com>
	<536CD9C9.7010900@redhat.com>
	<853930281.4089365.1399642719938.JavaMail.zimbra@redhat.com>
	<536CDD94.9070508@redhat.com>
	<1778280327.4103827.1399643860095.JavaMail.zimbra@redhat.com>
Message-ID: <536CE045.1070201@redhat.com>

This actually helps alot with single log out and the admin console!

On 5/9/2014 9:57 AM, Stian Thorgersen wrote:
> Good thing we are slow about different things, otherwise we'd not manage to do anything ;)
>
> ----- 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, 9 May, 2014 2:52:20 PM
>> Subject: Re: [keycloak-dev] User sessions added
>>
>> Duh... :)  Now its my turn to be slow...
>>
>> So the iframe solution is a good one :)  I'll add it to keycloak.js
>>
>>
>> On 5/9/2014 9:38 AM, Stian Thorgersen wrote:
>>> Could we not have a separate session state cookie that is not HttpOnly?
>>>
>>> ----- 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, 9 May, 2014 2:36:09 PM
>>>> Subject: Re: [keycloak-dev] User sessions added
>>>>
>>>> That's what I was saying before.  There is no benefit in using Iframes
>>>> if your login cookies are HttpOnly.  Your set timeout is *already*
>>>> happening indirectly via refresh tokens.
>>>>
>>>> The only other benefit might be in that you'd have to enable CORS for
>>>> that "ping" request which might be a pain.
>>>>
>>>> On 5/9/2014 9:10 AM, Stian Thorgersen wrote:
>>>>> What then is the benefit of having this iframe compared to just adding
>>>>> something like the following to keycloak.js:
>>>>>
>>>>> setTimeout(function() {
>>>>>      var req = new XMLHttpRequest();
>>>>>      req.open('GET',
>>>>>      'http://localhost:8080/auth/rest/realms/realm/tokens/session-status?session_state=...',
>>>>>      true);
>>>>>      req.onreadystatechange = function () {
>>>>>        if (req.readyState == 4 && req.status == 200) {
>>>>>          var status = JSON.parse(req.responseText);
>>>>>          if (!status.active) {
>>>>>            clearToken();
>>>>>          }
>>>>>        }
>>>>>      }
>>>>>      req.send();
>>>>> }, 3000);
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Friday, 9 May, 2014 1:41:02 PM
>>>>>> Subject: Re: [keycloak-dev] User sessions added
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/9/2014 6:59 AM, Stian Thorgersen wrote:
>>>>>>> User sessions have been added. In summary when a user logs in a new
>>>>>>> session
>>>>>>> is created (and persisted in the model). The identity cookie as well as
>>>>>>> all tokens/refresh-tokens are associated with a session. When a user
>>>>>>> logs
>>>>>>> out the session is invalidated (removed from the model), which
>>>>>>> invalidates
>>>>>>> the identity cookie and all tokens/refresh-tokens.
>>>>>>>
>>>>>>> There's two related issues left to do:
>>>>>>>
>>>>>>> * Make sure adapters only log out a specific session (if LoginAction
>>>>>>> contains a session id)
>>>>>>> * Allow a user to log out all sessions through the account management
>>>>>>> console
>>>>>>>
>>>>>>> Also, we may want some mechanism to retrieve the status of a session
>>>>>>> from
>>>>>>> applications. This could be a REST endpoint, or the crazy iframe
>>>>>>> technique
>>>>>>> from OpenID Connect. I think this can be postponed to after 1.0 though.
>>>>>>>
>>>>>>
>>>>>> The crazy IFrame techique would require this REST "ping".  At least for
>>>>>> us, as our cookies would be http-only.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri May  9 18:35:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 09 May 2014 18:35:15 -0400
Subject: [keycloak-dev] User sessions added
In-Reply-To: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
References: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
Message-ID: <536D5823.4000607@redhat.com>

BTW, my only problem with this approach is that it requires a database 
update/insert on every login and a update/delete on every logout, making 
the database a big source of contention.  Especially since we can pretty 
much cache everything else.

On 5/9/2014 6:59 AM, Stian Thorgersen wrote:
> User sessions have been added. In summary when a user logs in a new session is created (and persisted in the model). The identity cookie as well as all tokens/refresh-tokens are associated with a session. When a user logs out the session is invalidated (removed from the model), which invalidates the identity cookie and all tokens/refresh-tokens.
>
> There's two related issues left to do:
>
> * Make sure adapters only log out a specific session (if LoginAction contains a session id)
> * Allow a user to log out all sessions through the account management console
>
> Also, we may want some mechanism to retrieve the status of a session from applications. This could be a REST endpoint, or the crazy iframe technique from OpenID Connect. I think this can be postponed to after 1.0 though.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon May 12 04:33:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 May 2014 04:33:18 -0400 (EDT)
Subject: [keycloak-dev] User sessions added
In-Reply-To: <536D5823.4000607@redhat.com>
References: <1469072201.3967544.1399633199758.JavaMail.zimbra@redhat.com>
	<536D5823.4000607@redhat.com>
Message-ID: <1748986815.4901814.1399883598757.JavaMail.zimbra@redhat.com>

Yep, one option I consider would be that once we introduce a cache we can keep the sessions in-memory and replicate with Infinispan.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 9 May, 2014 11:35:15 PM
> Subject: Re: [keycloak-dev] User sessions added
> 
> BTW, my only problem with this approach is that it requires a database
> update/insert on every login and a update/delete on every logout, making
> the database a big source of contention.  Especially since we can pretty
> much cache everything else.
> 
> On 5/9/2014 6:59 AM, Stian Thorgersen wrote:
> > User sessions have been added. In summary when a user logs in a new session
> > is created (and persisted in the model). The identity cookie as well as
> > all tokens/refresh-tokens are associated with a session. When a user logs
> > out the session is invalidated (removed from the model), which invalidates
> > the identity cookie and all tokens/refresh-tokens.
> >
> > There's two related issues left to do:
> >
> > * Make sure adapters only log out a specific session (if LoginAction
> > contains a session id)
> > * Allow a user to log out all sessions through the account management
> > console
> >
> > Also, we may want some mechanism to retrieve the status of a session from
> > applications. This could be a REST endpoint, or the crazy iframe technique
> > from OpenID Connect. I think this can be postponed to after 1.0 though.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> 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
> 

From bburke at redhat.com  Mon May 12 10:44:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 May 2014 10:44:46 -0400
Subject: [keycloak-dev] per realm admin console implemented
Message-ID: <5370DE5E.40708@redhat.com>

Within each realm, you can now add permissions to any user of that realm 
so that they can access the keycloak admin console (but only for that 
realm).  This will allow SSO between keycloak admin console and an 
application's admin console.  Will probably make it easier to use admin 
REST API too in many scenarios.

To access realm-specific admin console go to:

/context-root/admin/{realm}/console/index.html

Finally, you can now set the admin console theme for each realm-specific 
admin console within the realm's theme settings too.

Each realm now has 2 new applications added:

{realmName}-realm
security-admin-console


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon May 12 10:47:18 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 May 2014 10:47:18 -0400
Subject: [keycloak-dev] iframe logout check now implemented
Message-ID: <5370DEF6.9070202@redhat.com>

The OpenID Connection session status IFRAME trick is now implemented. 
keycloak.js has been extend.  The customer-portal-js demo has been 
extended to who how to use it.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon May 12 12:46:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 May 2014 12:46:46 -0400 (EDT)
Subject: [keycloak-dev] iframe logout check now implemented
In-Reply-To: <5370DEF6.9070202@redhat.com>
References: <5370DEF6.9070202@redhat.com>
Message-ID: <1179935122.5766063.1399913206577.JavaMail.zimbra@redhat.com>

Nice :)

Could we make it simpler to use? For example:

  var keycloak = new Keycloak();

  keycloak.onAuthSuccess = function() {
    alert('User logged in');
  }

  keycloak.onAuthLogout = function() {
    alert('User has logged out');
  }

  keycloak.init({ 
    onLoad: 'login-required',
    autoRefreshToken: true,
    logoutIframe: true
  });


We already have the onAuthSuccess and onAuthLogout events. The user would just have to configure if they want to use the 'logoutIframe' feature or not (by default we could even have it enabled?). Also, we could add another optional feature to automatically refresh the token.

In the future it would also be nice to enable support for using pop-up windows for login.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 12 May, 2014 3:47:18 PM
> Subject: [keycloak-dev] iframe logout check now implemented
> 
> The OpenID Connection session status IFRAME trick is now implemented.
> keycloak.js has been extend.  The customer-portal-js demo has been
> extended to who how to use it.
> 
> --
> 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
> 

From bburke at redhat.com  Mon May 12 13:15:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 May 2014 13:15:25 -0400
Subject: [keycloak-dev] iframe logout check now implemented
In-Reply-To: <1179935122.5766063.1399913206577.JavaMail.zimbra@redhat.com>
References: <5370DEF6.9070202@redhat.com>
	<1179935122.5766063.1399913206577.JavaMail.zimbra@redhat.com>
Message-ID: <537101AD.3070705@redhat.com>

I think you may be confused on what this is.  It is only to determine 
the current login-status.  Not to login or logout.

The example wraps the reloadData function to make sure that the user is 
still logged in before executing.  Alternatively, somebody could make a 
timer that checked the log-in status via this method too.

On 5/12/2014 12:46 PM, Stian Thorgersen wrote:
> Nice :)
>
> Could we make it simpler to use? For example:
>
>    var keycloak = new Keycloak();
>
>    keycloak.onAuthSuccess = function() {
>      alert('User logged in');
>    }
>
>    keycloak.onAuthLogout = function() {
>      alert('User has logged out');
>    }
>
>    keycloak.init({
>      onLoad: 'login-required',
>      autoRefreshToken: true,
>      logoutIframe: true
>    });
>
>
> We already have the onAuthSuccess and onAuthLogout events. The user would just have to configure if they want to use the 'logoutIframe' feature or not (by default we could even have it enabled?). Also, we could add another optional feature to automatically refresh the token.
>
> In the future it would also be nice to enable support for using pop-up windows for login.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 12 May, 2014 3:47:18 PM
>> Subject: [keycloak-dev] iframe logout check now implemented
>>
>> The OpenID Connection session status IFRAME trick is now implemented.
>> keycloak.js has been extend.  The customer-portal-js demo has been
>> extended to who how to use it.
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon May 12 19:29:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 May 2014 19:29:32 -0400
Subject: [keycloak-dev] "built-in" apps special attention
Message-ID: <5371595C.3010704@redhat.com>

We have a bunch of built-in apps (security-admin-console, *-realm, 
account, etc...) now that would be very problematic if the user edited 
anything in them.  I was thinking that:

- All "built-in" applications would be marked with a '*' in the listing
- All "built-in" apps would only be viewable, but not editable

I don't think any of our built in applications need to be editable, 
right?  I'll just add a "built-in" attribute to the application model to 
implement this and a little tweak in the console.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue May 13 04:33:10 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 13 May 2014 04:33:10 -0400 (EDT)
Subject: [keycloak-dev] iframe logout check now implemented
In-Reply-To: <537101AD.3070705@redhat.com>
References: <5370DEF6.9070202@redhat.com>
	<1179935122.5766063.1399913206577.JavaMail.zimbra@redhat.com>
	<537101AD.3070705@redhat.com>
Message-ID: <1012297996.6076809.1399969990372.JavaMail.zimbra@redhat.com>

Nopes, I finally get what it is and how it works ;)

My idea was that if 'logoutIframe' is enabled we create the iframe, and start a timer to ping it. We should also make the ping configurable as well. If the status changes to logged out, we invoke the onAuthLogout callback to let the application deal with the logout.

We should also update the updateToken method to also check the iframe status if it's configured.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 12 May, 2014 6:15:25 PM
> Subject: Re: [keycloak-dev] iframe logout check now implemented
> 
> I think you may be confused on what this is.  It is only to determine
> the current login-status.  Not to login or logout.
> 
> The example wraps the reloadData function to make sure that the user is
> still logged in before executing.  Alternatively, somebody could make a
> timer that checked the log-in status via this method too.
> 
> On 5/12/2014 12:46 PM, Stian Thorgersen wrote:
> > Nice :)
> >
> > Could we make it simpler to use? For example:
> >
> >    var keycloak = new Keycloak();
> >
> >    keycloak.onAuthSuccess = function() {
> >      alert('User logged in');
> >    }
> >
> >    keycloak.onAuthLogout = function() {
> >      alert('User has logged out');
> >    }
> >
> >    keycloak.init({
> >      onLoad: 'login-required',
> >      autoRefreshToken: true,
> >      logoutIframe: true
> >    });
> >
> >
> > We already have the onAuthSuccess and onAuthLogout events. The user would
> > just have to configure if they want to use the 'logoutIframe' feature or
> > not (by default we could even have it enabled?). Also, we could add
> > another optional feature to automatically refresh the token.
> >
> > In the future it would also be nice to enable support for using pop-up
> > windows for login.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 12 May, 2014 3:47:18 PM
> >> Subject: [keycloak-dev] iframe logout check now implemented
> >>
> >> The OpenID Connection session status IFRAME trick is now implemented.
> >> keycloak.js has been extend.  The customer-portal-js demo has been
> >> extended to who how to use it.
> >>
> >> --
> >> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Tue May 13 08:57:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 13 May 2014 08:57:08 -0400
Subject: [keycloak-dev] iframe logout check now implemented
In-Reply-To: <1012297996.6076809.1399969990372.JavaMail.zimbra@redhat.com>
References: <5370DEF6.9070202@redhat.com>
	<1179935122.5766063.1399913206577.JavaMail.zimbra@redhat.com>
	<537101AD.3070705@redhat.com>
	<1012297996.6076809.1399969990372.JavaMail.zimbra@redhat.com>
Message-ID: <537216A4.7030400@redhat.com>

Sounds like a good idea.  But it should be built on top of what we 
already have for the iframe stuff.

On 5/13/2014 4:33 AM, Stian Thorgersen wrote:
> Nopes, I finally get what it is and how it works ;)
>
> My idea was that if 'logoutIframe' is enabled we create the iframe, and start a timer to ping it. We should also make the ping configurable as well. If the status changes to logged out, we invoke the onAuthLogout callback to let the application deal with the logout.
>
> We should also update the updateToken method to also check the iframe status if it's configured.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 12 May, 2014 6:15:25 PM
>> Subject: Re: [keycloak-dev] iframe logout check now implemented
>>
>> I think you may be confused on what this is.  It is only to determine
>> the current login-status.  Not to login or logout.
>>
>> The example wraps the reloadData function to make sure that the user is
>> still logged in before executing.  Alternatively, somebody could make a
>> timer that checked the log-in status via this method too.
>>
>> On 5/12/2014 12:46 PM, Stian Thorgersen wrote:
>>> Nice :)
>>>
>>> Could we make it simpler to use? For example:
>>>
>>>     var keycloak = new Keycloak();
>>>
>>>     keycloak.onAuthSuccess = function() {
>>>       alert('User logged in');
>>>     }
>>>
>>>     keycloak.onAuthLogout = function() {
>>>       alert('User has logged out');
>>>     }
>>>
>>>     keycloak.init({
>>>       onLoad: 'login-required',
>>>       autoRefreshToken: true,
>>>       logoutIframe: true
>>>     });
>>>
>>>
>>> We already have the onAuthSuccess and onAuthLogout events. The user would
>>> just have to configure if they want to use the 'logoutIframe' feature or
>>> not (by default we could even have it enabled?). Also, we could add
>>> another optional feature to automatically refresh the token.
>>>
>>> In the future it would also be nice to enable support for using pop-up
>>> windows for login.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, 12 May, 2014 3:47:18 PM
>>>> Subject: [keycloak-dev] iframe logout check now implemented
>>>>
>>>> The OpenID Connection session status IFRAME trick is now implemented.
>>>> keycloak.js has been extend.  The customer-portal-js demo has been
>>>> extended to who how to use it.
>>>>
>>>> --
>>>> 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
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed May 14 04:31:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 May 2014 04:31:42 -0400 (EDT)
Subject: [keycloak-dev] "built-in" apps special attention
In-Reply-To: <5371595C.3010704@redhat.com>
References: <5371595C.3010704@redhat.com>
Message-ID: <1376939144.6991217.1400056302086.JavaMail.zimbra@redhat.com>

I don't see any issues with that. 

Actually, I think it may be better to just hide them altogether?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 13 May, 2014 12:29:32 AM
> Subject: [keycloak-dev] "built-in" apps special attention
> 
> We have a bunch of built-in apps (security-admin-console, *-realm,
> account, etc...) now that would be very problematic if the user edited
> anything in them.  I was thinking that:
> 
> - All "built-in" applications would be marked with a '*' in the listing
> - All "built-in" apps would only be viewable, but not editable
> 
> I don't think any of our built in applications need to be editable,
> right?  I'll just add a "built-in" attribute to the application model to
> implement this and a little tweak in the console.
> 
> 
> --
> 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
> 

From bburke at redhat.com  Wed May 14 08:14:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 14 May 2014 08:14:39 -0400
Subject: [keycloak-dev] "built-in" apps special attention
In-Reply-To: <1376939144.6991217.1400056302086.JavaMail.zimbra@redhat.com>
References: <5371595C.3010704@redhat.com>
	<1376939144.6991217.1400056302086.JavaMail.zimbra@redhat.com>
Message-ID: <53735E2F.8070808@redhat.com>

Hidden only from the application list in the admin console.  Should 
still show up everywhere else (session mgmt, role mappings, etc.)

On 5/14/2014 4:31 AM, Stian Thorgersen wrote:
> I don't see any issues with that.
>
> Actually, I think it may be better to just hide them altogether?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 13 May, 2014 12:29:32 AM
>> Subject: [keycloak-dev] "built-in" apps special attention
>>
>> We have a bunch of built-in apps (security-admin-console, *-realm,
>> account, etc...) now that would be very problematic if the user edited
>> anything in them.  I was thinking that:
>>
>> - All "built-in" applications would be marked with a '*' in the listing
>> - All "built-in" apps would only be viewable, but not editable
>>
>> I don't think any of our built in applications need to be editable,
>> right?  I'll just add a "built-in" attribute to the application model to
>> implement this and a little tweak in the console.
>>
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed May 14 12:54:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 May 2014 12:54:30 -0400 (EDT)
Subject: [keycloak-dev] Updated keycloak.js for session state iframe
In-Reply-To: <483395997.7339446.1400086256821.JavaMail.zimbra@redhat.com>
Message-ID: <38534041.7340468.1400086470870.JavaMail.zimbra@redhat.com>

I've update keycloak.js to now create the session state iframe by default. By default it runs 'checkLoginIframe' every 5 seconds. It also runs checkLoginIframe in updateToken.

If the session is logged out clearToken is called, this will delete subject, token, etc and also invoke the onAuthLogout callback (if one is set).

The iframe can be disabled with "init({ checkLoginIframe: false })" and the interval can be set with "init({ checkLoginIframeInterval: 10 })".

I've also update the js-console and the customer-portal-js examples, and the JS documentation.

From stian at redhat.com  Wed May 14 12:55:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 May 2014 12:55:51 -0400 (EDT)
Subject: [keycloak-dev] Logout all sessions from account management
Message-ID: <709353734.7341061.1400086551616.JavaMail.zimbra@redhat.com>

I've added a new section to the account management that lists all the active sessions the users has, it also has an option to log out all sessions.

From theute at redhat.com  Wed May 14 16:06:05 2014
From: theute at redhat.com (Thomas Heute)
Date: Wed, 14 May 2014 22:06:05 +0200
Subject: [keycloak-dev] 1.0 Alpha 4
Message-ID: <5373CCAD.2090403@redhat.com>

Apparently the tag 1.0-alpha-4 is missing from GitHub, known issue ?


From gcardoso at redhat.com  Thu May 15 14:30:58 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 15 May 2014 15:30:58 -0300
Subject: [keycloak-dev] UI Polishing
Message-ID: <D8E9AF58-522F-48D5-92E6-F41717E7F497@redhat.com>

I?ve just sent a pull request with changes in lots of pages, basically UI refinements.

These changes comprehend:

- Updated PatternFly to the last version
- A bunch of adjustments to make it look good with the patternfly update
- Adjusted tables to use only the patternfly code
- Update the roles selector to use patternfly buttons
- Adjusted some content (breadcrumbs, page headings)
- Adjusted the style of ?required fields? and borders in many pages
- Account management area: make it look better  and more like the console

I?ve tried to change the selector to use the same style as patternfly, but I didn?t manage to deal with the javascript: https://www.patternfly.org/widgets/#bootstrap-select

In my inspection, I see some usability problems:

- In the registration page, inform the required fields. In the message, inform what fields have problem instead of giving a single message ?Please specify first name? each time the user hits enter.
- Modal boxes in the console don?t have explanation text.
- In the pages to define roles, when I move a role from a list to another, there is no feedback of Saved or buttons to Save / Clear. User is unaware if it was saved or not.
- In Applications > Revocation, the ?not before? input is disabled and the three buttons appear: ?Clear?, ?Set To Now?, ?Push?. Is this correct? It doesn?t make sense to me.
- In the Audit Log page, remove the links ?first page?, ?previous page? and ?next page? when the table is empty.
- In the Add Realm page, when adding a realm, I got an error, but the realm was created.

My pull request changed lots of files, but there were no conflicts and I tested every page, so I hope to not break anything.

Thanks,
Gabriel

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140515/44c37bbd/attachment.html 

From Anil.Saldhana at redhat.com  Thu May 15 18:21:29 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 15 May 2014 17:21:29 -0500
Subject: [keycloak-dev] LiveOak and JavaEE libraries
Message-ID: <53753DE9.6060606@redhat.com>

Hi Stian,
   do you know what parts of JavaEE Web libraries, LiveOak does not want 
to use?

Right now, I know LiveOak uses Jax-RS and WebSockets.

Does it use CDI, Servlets?

Regards,
Anil

From stian at redhat.com  Fri May 16 03:41:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 May 2014 03:41:55 -0400 (EDT)
Subject: [keycloak-dev] LiveOak and JavaEE libraries
In-Reply-To: <53753DE9.6060606@redhat.com>
References: <53753DE9.6060606@redhat.com>
Message-ID: <1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>

That's an open question at the moment, but I would be surprised if LiveOak itself starts using any JavaEE libraries. Currently, Keycloak and AeroGear UPS are deployed separately (as WARs) on the same WildFly instance. 

In the future I would like to see both of those deployed as WildFly extensions. I've in the past done WildFly extensions with JAX-RS and Servlets, which worked quite well, but I don't think CDI would.

----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 15 May, 2014 11:21:29 PM
> Subject: [keycloak-dev] LiveOak and JavaEE libraries
> 
> Hi Stian,
>    do you know what parts of JavaEE Web libraries, LiveOak does not want
> to use?
> 
> Right now, I know LiveOak uses Jax-RS and WebSockets.
> 
> Does it use CDI, Servlets?
> 
> Regards,
> Anil
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bdawidow at redhat.com  Fri May 16 04:04:45 2014
From: bdawidow at redhat.com (=?UTF-8?B?Qm9sZXPFgmF3IERhd2lkb3dpY3o=?=)
Date: Fri, 16 May 2014 10:04:45 +0200
Subject: [keycloak-dev] LiveOak and JavaEE libraries
In-Reply-To: <1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>
References: <53753DE9.6060606@redhat.com>
	<1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>
Message-ID: <5375C69D.2090508@redhat.com>

Yes, the intention is that LiveOak doesn't require JEE container. We 
started with pure netty container. Currently we deploy on WildFly for 
several reasons, also because of KeyCloak. However we want to start 
stripping it down as soon as WildFly Core is available.

Btw. LiveOak has a mailing list: http://liveoak.io/community/

On 05/16/2014 09:41 AM, Stian Thorgersen wrote:
> That's an open question at the moment, but I would be surprised if
> LiveOak itself starts using any JavaEE libraries. Currently, Keycloak
> and AeroGear UPS are deployed separately (as WARs) on the same
> WildFly instance.
>
> In the future I would like to see both of those deployed as WildFly
> extensions. I've in the past done WildFly extensions with JAX-RS and
> Servlets, which worked quite well, but I don't think CDI would.
>
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com> To:
>> keycloak-dev at lists.jboss.org Sent: Thursday, 15 May, 2014 11:21:29
>> PM Subject: [keycloak-dev] LiveOak and JavaEE libraries
>>
>> Hi Stian, do you know what parts of JavaEE Web libraries, LiveOak
>> does not want to use?
>>
>> Right now, I know LiveOak uses Jax-RS and WebSockets.
>>
>> Does it use CDI, Servlets?
>>
>> Regards, Anil _______________________________________________
>> keycloak-dev mailing list keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________ keycloak-dev mailing
> list keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Boles?aw Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead

From ssilvert at redhat.com  Fri May 16 08:23:28 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 May 2014 08:23:28 -0400
Subject: [keycloak-dev] LiveOak and JavaEE libraries
In-Reply-To: <5375C69D.2090508@redhat.com>
References: <53753DE9.6060606@redhat.com>
	<1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>
	<5375C69D.2090508@redhat.com>
Message-ID: <53760340.1030008@redhat.com>

On 5/16/2014 4:04 AM, Boles?aw Dawidowicz wrote:
> Yes, the intention is that LiveOak doesn't require JEE container. We
> started with pure netty container. Currently we deploy on WildFly for
> several reasons, also because of KeyCloak. However we want to start
> stripping it down as soon as WildFly Core is available.
I'm working on "Keycloak without servlets" right now.  The goal is to be 
able to use Keycloak for the EAP console where servlets are verboten.  
So far so good.

But it begs the question, "Since the Servlet API is mostly just a facade 
on top of the Undertow API, why do we care if Keycloak is using the 
Servlet API?"
>
> Btw. LiveOak has a mailing list: http://liveoak.io/community/
>
> On 05/16/2014 09:41 AM, Stian Thorgersen wrote:
>> That's an open question at the moment, but I would be surprised if
>> LiveOak itself starts using any JavaEE libraries. Currently, Keycloak
>> and AeroGear UPS are deployed separately (as WARs) on the same
>> WildFly instance.
>>
>> In the future I would like to see both of those deployed as WildFly
>> extensions. I've in the past done WildFly extensions with JAX-RS and
>> Servlets, which worked quite well, but I don't think CDI would.
>>
>> ----- Original Message -----
>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com> To:
>>> keycloak-dev at lists.jboss.org Sent: Thursday, 15 May, 2014 11:21:29
>>> PM Subject: [keycloak-dev] LiveOak and JavaEE libraries
>>>
>>> Hi Stian, do you know what parts of JavaEE Web libraries, LiveOak
>>> does not want to use?
>>>
>>> Right now, I know LiveOak uses Jax-RS and WebSockets.
>>>
>>> Does it use CDI, Servlets?
>>>
>>> Regards, Anil _______________________________________________
>>> keycloak-dev mailing list keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________ keycloak-dev mailing
>> list keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>


From bburke at redhat.com  Fri May 16 08:47:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 May 2014 08:47:19 -0400
Subject: [keycloak-dev] LiveOak and JavaEE libraries
In-Reply-To: <53760340.1030008@redhat.com>
References: <53753DE9.6060606@redhat.com>	<1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>	<5375C69D.2090508@redhat.com>
	<53760340.1030008@redhat.com>
Message-ID: <537608D7.2030504@redhat.com>



On 5/16/2014 8:23 AM, Stan Silvert wrote:
> On 5/16/2014 4:04 AM, Boles?aw Dawidowicz wrote:
>> Yes, the intention is that LiveOak doesn't require JEE container. We
>> started with pure netty container. Currently we deploy on WildFly for
>> several reasons, also because of KeyCloak. However we want to start
>> stripping it down as soon as WildFly Core is available.
> I'm working on "Keycloak without servlets" right now.  The goal is to be
> able to use Keycloak for the EAP console where servlets are verboten.
> So far so good.
>
> But it begs the question, "Since the Servlet API is mostly just a facade
> on top of the Undertow API, why do we care if Keycloak is using the
> Servlet API?"

There's two places we use the servlet API.  In KeycloakApplication and 
in CookieHelper.  The former is to get the context path of the 
deployment, the latter is because JAX-RS 1.1 API (required because of 
EAP 6.x) doesn't support HttpOnly Cookies.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri May 16 08:55:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 May 2014 08:55:17 -0400
Subject: [keycloak-dev] session idle timeout implemented
Message-ID: <53760AB5.5030302@redhat.com>

There is no more:

centralLoginLifespan
refreshTokenLifespan

Instead there is:

ssoSessionIdleTimeout
ssoSessionMaxLifespan

UserSessionModel has removed:

expires

Replaced it with:

lastSessionRefresh


The way it works is as follows.  At every cookie validation or 
refreshToken, the session is invalidated if the session has been idle 
for a period of time, or the session has reached it's max age.

lastSessionRefresh is a timestamp which is updated at every cookie 
authentication or refreshToken.  For refreshToken, it is only updated if 
accessCodeLifespan + lastSessionRefresh time will happen after the next 
idle timeout.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From ssilvert at redhat.com  Fri May 16 09:08:42 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 May 2014 09:08:42 -0400
Subject: [keycloak-dev] LiveOak and JavaEE libraries
In-Reply-To: <537608D7.2030504@redhat.com>
References: <53753DE9.6060606@redhat.com>	<1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>	<5375C69D.2090508@redhat.com>
	<53760340.1030008@redhat.com> <537608D7.2030504@redhat.com>
Message-ID: <53760DDA.1030204@redhat.com>

On 5/16/2014 8:47 AM, Bill Burke wrote:
>
> On 5/16/2014 8:23 AM, Stan Silvert wrote:
>> On 5/16/2014 4:04 AM, Boles?aw Dawidowicz wrote:
>>> Yes, the intention is that LiveOak doesn't require JEE container. We
>>> started with pure netty container. Currently we deploy on WildFly for
>>> several reasons, also because of KeyCloak. However we want to start
>>> stripping it down as soon as WildFly Core is available.
>> I'm working on "Keycloak without servlets" right now.  The goal is to be
>> able to use Keycloak for the EAP console where servlets are verboten.
>> So far so good.
>>
>> But it begs the question, "Since the Servlet API is mostly just a facade
>> on top of the Undertow API, why do we care if Keycloak is using the
>> Servlet API?"
> There's two places we use the servlet API.  In KeycloakApplication and
> in CookieHelper.  The former is to get the context path of the
> deployment, the latter is because JAX-RS 1.1 API (required because of
> EAP 6.x) doesn't support HttpOnly Cookies.
>
>
Also, I see that UndertowUserSessionManagement is using the servlet's 
HttpSession class.  But it probably should be using Undertow's Session 
class instead.

My main point was to ask Boleslaw why it matters.  I think the technical 
arguments against using the Servlet API have gotten much weaker.

From bburke at redhat.com  Fri May 16 09:34:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 May 2014 09:34:14 -0400
Subject: [keycloak-dev] associate client with session
Message-ID: <537613D6.4000304@redhat.com>

I'm going to implement an associate between clients and UserSessions. 
This is needed to know what apps and oauth clients are associated with a 
session.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 16 09:42:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 May 2014 09:42:49 -0400 (EDT)
Subject: [keycloak-dev] associate client with session
In-Reply-To: <537613D6.4000304@redhat.com>
References: <537613D6.4000304@redhat.com>
Message-ID: <2065790390.8944423.1400247769405.JavaMail.zimbra@redhat.com>

Cool - It would be nice to show what apps/clients are using an user session in the accnt mngmt as well, but that can wait until after 1.0

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 16 May, 2014 2:34:14 PM
> Subject: [keycloak-dev] associate client with session
> 
> I'm going to implement an associate between clients and UserSessions.
> This is needed to know what apps and oauth clients are associated with a
> session.
> --
> 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
> 

From bburke at redhat.com  Fri May 16 09:43:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 May 2014 09:43:36 -0400
Subject: [keycloak-dev] LiveOak and JavaEE libraries
In-Reply-To: <53760DDA.1030204@redhat.com>
References: <53753DE9.6060606@redhat.com>	<1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>	<5375C69D.2090508@redhat.com>	<53760340.1030008@redhat.com>
	<537608D7.2030504@redhat.com> <53760DDA.1030204@redhat.com>
Message-ID: <53761608.2030601@redhat.com>



On 5/16/2014 9:08 AM, Stan Silvert wrote:
> On 5/16/2014 8:47 AM, Bill Burke wrote:
>>
>> On 5/16/2014 8:23 AM, Stan Silvert wrote:
>>> On 5/16/2014 4:04 AM, Boles?aw Dawidowicz wrote:
>>>> Yes, the intention is that LiveOak doesn't require JEE container. We
>>>> started with pure netty container. Currently we deploy on WildFly for
>>>> several reasons, also because of KeyCloak. However we want to start
>>>> stripping it down as soon as WildFly Core is available.
>>> I'm working on "Keycloak without servlets" right now.  The goal is to be
>>> able to use Keycloak for the EAP console where servlets are verboten.
>>> So far so good.
>>>
>>> But it begs the question, "Since the Servlet API is mostly just a facade
>>> on top of the Undertow API, why do we care if Keycloak is using the
>>> Servlet API?"
>> There's two places we use the servlet API.  In KeycloakApplication and
>> in CookieHelper.  The former is to get the context path of the
>> deployment, the latter is because JAX-RS 1.1 API (required because of
>> EAP 6.x) doesn't support HttpOnly Cookies.
>>
>>
> Also, I see that UndertowUserSessionManagement is using the servlet's
> HttpSession class.  But it probably should be using Undertow's Session
> class instead.
>
> My main point was to ask Boleslaw why it matters.  I think the technical
> arguments against using the Servlet API have gotten much weaker.

I haven't implemented a pure Undertow adapter yet.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri May 16 09:48:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 May 2014 09:48:06 -0400
Subject: [keycloak-dev] oauth clients and session problems
Message-ID: <53761716.4000004@redhat.com>

I think oauth grants are a different animal than application logins. 
Applications are part of an SSO session, while oauth grants will 
probably not want to be part of an SSO session.  Why? If an Oauth grant 
requires entering in user credentials, right now, Keycloak will create a 
identity cookie.  The user might not know in this situation that they 
need to logout.

I was thinking that:

1. OAuth Client grant requests should always have a new session created 
for them.
2. OAuth client grant requests should not ever set any cookies.  Its ok 
to use existing cookies for authentication though.
3. ssoSessionIdleTimeout and ssoSessionMaxLifespan should be overridable 
for each oauth client and application.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 16 09:55:28 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 May 2014 09:55:28 -0400 (EDT)
Subject: [keycloak-dev] oauth clients and session problems
In-Reply-To: <53761716.4000004@redhat.com>
References: <53761716.4000004@redhat.com>
Message-ID: <1109944605.8957952.1400248528328.JavaMail.zimbra@redhat.com>

Are you talking about 'tokens/grants/access'?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 16 May, 2014 2:48:06 PM
> Subject: [keycloak-dev] oauth clients and session problems
> 
> I think oauth grants are a different animal than application logins.
> Applications are part of an SSO session, while oauth grants will
> probably not want to be part of an SSO session.  Why? If an Oauth grant
> requires entering in user credentials, right now, Keycloak will create a
> identity cookie.  The user might not know in this situation that they
> need to logout.
> 
> I was thinking that:
> 
> 1. OAuth Client grant requests should always have a new session created
> for them.
> 2. OAuth client grant requests should not ever set any cookies.  Its ok
> to use existing cookies for authentication though.
> 3. ssoSessionIdleTimeout and ssoSessionMaxLifespan should be overridable
> for each oauth client and application.
> 
> --
> 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
> 

From ssilvert at redhat.com  Fri May 16 10:03:39 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 May 2014 10:03:39 -0400
Subject: [keycloak-dev] LiveOak and JavaEE libraries
In-Reply-To: <53761608.2030601@redhat.com>
References: <53753DE9.6060606@redhat.com>	<1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>	<5375C69D.2090508@redhat.com>	<53760340.1030008@redhat.com>
	<537608D7.2030504@redhat.com> <53760DDA.1030204@redhat.com>
	<53761608.2030601@redhat.com>
Message-ID: <53761ABB.5090009@redhat.com>

On 5/16/2014 9:43 AM, Bill Burke wrote:
>
> On 5/16/2014 9:08 AM, Stan Silvert wrote:
>> On 5/16/2014 8:47 AM, Bill Burke wrote:
>>> On 5/16/2014 8:23 AM, Stan Silvert wrote:
>>>> On 5/16/2014 4:04 AM, Boles?aw Dawidowicz wrote:
>>>>> Yes, the intention is that LiveOak doesn't require JEE container. We
>>>>> started with pure netty container. Currently we deploy on WildFly for
>>>>> several reasons, also because of KeyCloak. However we want to start
>>>>> stripping it down as soon as WildFly Core is available.
>>>> I'm working on "Keycloak without servlets" right now.  The goal is to be
>>>> able to use Keycloak for the EAP console where servlets are verboten.
>>>> So far so good.
>>>>
>>>> But it begs the question, "Since the Servlet API is mostly just a facade
>>>> on top of the Undertow API, why do we care if Keycloak is using the
>>>> Servlet API?"
>>> There's two places we use the servlet API.  In KeycloakApplication and
>>> in CookieHelper.  The former is to get the context path of the
>>> deployment, the latter is because JAX-RS 1.1 API (required because of
>>> EAP 6.x) doesn't support HttpOnly Cookies.
>>>
>>>
>> Also, I see that UndertowUserSessionManagement is using the servlet's
>> HttpSession class.  But it probably should be using Undertow's Session
>> class instead.
>>
>> My main point was to ask Boleslaw why it matters.  I think the technical
>> arguments against using the Servlet API have gotten much weaker.
> I haven't implemented a pure Undertow adapter yet.
>
I'm hacking on one right now, but I'm questioning if it will every 
really be needed.

From bburke at redhat.com  Fri May 16 11:09:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 May 2014 11:09:00 -0400
Subject: [keycloak-dev] oauth clients and session problems
In-Reply-To: <1109944605.8957952.1400248528328.JavaMail.zimbra@redhat.com>
References: <53761716.4000004@redhat.com>
	<1109944605.8957952.1400248528328.JavaMail.zimbra@redhat.com>
Message-ID: <53762A0C.6090600@redhat.com>

No, I'm talking about browser-based oauth grant.  Where the client 
initiating the token request is an oauth client and the user has to 
login and go to the oauth grant page.

On 5/16/2014 9:55 AM, Stian Thorgersen wrote:
> Are you talking about 'tokens/grants/access'?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 16 May, 2014 2:48:06 PM
>> Subject: [keycloak-dev] oauth clients and session problems
>>
>> I think oauth grants are a different animal than application logins.
>> Applications are part of an SSO session, while oauth grants will
>> probably not want to be part of an SSO session.  Why? If an Oauth grant
>> requires entering in user credentials, right now, Keycloak will create a
>> identity cookie.  The user might not know in this situation that they
>> need to logout.
>>
>> I was thinking that:
>>
>> 1. OAuth Client grant requests should always have a new session created
>> for them.
>> 2. OAuth client grant requests should not ever set any cookies.  Its ok
>> to use existing cookies for authentication though.
>> 3. ssoSessionIdleTimeout and ssoSessionMaxLifespan should be overridable
>> for each oauth client and application.
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 16 11:30:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 May 2014 11:30:31 -0400 (EDT)
Subject: [keycloak-dev] oauth clients and session problems
In-Reply-To: <53762A0C.6090600@redhat.com>
References: <53761716.4000004@redhat.com>
	<1109944605.8957952.1400248528328.JavaMail.zimbra@redhat.com>
	<53762A0C.6090600@redhat.com>
Message-ID: <645248224.9071075.1400254231789.JavaMail.zimbra@redhat.com>

In that case I'm not convinced. I'd expect all 'clients' to be logged out when I logout of the SSO realm. Unless I've explicitly granted the client offline access (something we don't really support atm).

----- 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, 16 May, 2014 4:09:00 PM
> Subject: Re: [keycloak-dev] oauth clients and session problems
> 
> No, I'm talking about browser-based oauth grant.  Where the client
> initiating the token request is an oauth client and the user has to
> login and go to the oauth grant page.
> 
> On 5/16/2014 9:55 AM, Stian Thorgersen wrote:
> > Are you talking about 'tokens/grants/access'?
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 16 May, 2014 2:48:06 PM
> >> Subject: [keycloak-dev] oauth clients and session problems
> >>
> >> I think oauth grants are a different animal than application logins.
> >> Applications are part of an SSO session, while oauth grants will
> >> probably not want to be part of an SSO session.  Why? If an Oauth grant
> >> requires entering in user credentials, right now, Keycloak will create a
> >> identity cookie.  The user might not know in this situation that they
> >> need to logout.
> >>
> >> I was thinking that:
> >>
> >> 1. OAuth Client grant requests should always have a new session created
> >> for them.
> >> 2. OAuth client grant requests should not ever set any cookies.  Its ok
> >> to use existing cookies for authentication though.
> >> 3. ssoSessionIdleTimeout and ssoSessionMaxLifespan should be overridable
> >> for each oauth client and application.
> >>
> >> --
> >> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri May 16 11:38:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 May 2014 11:38:59 -0400
Subject: [keycloak-dev] oauth clients and session problems
In-Reply-To: <645248224.9071075.1400254231789.JavaMail.zimbra@redhat.com>
References: <53761716.4000004@redhat.com>
	<1109944605.8957952.1400248528328.JavaMail.zimbra@redhat.com>
	<53762A0C.6090600@redhat.com>
	<645248224.9071075.1400254231789.JavaMail.zimbra@redhat.com>
Message-ID: <53763113.7050009@redhat.com>

OAuth clients shouldn't create an identity cookie at least.  Again, 
because the user might not know they are logged in.  Meaning, if the 
user isn't already logged in, then the oauth grant page will not 
set/refresh the KEYCLOAK_IDENTITY cookie.

I'm most worried about doing a oauth client grant and the user not 
knowing they are logged in.  They step away from the browser, and still 
have their SSO session active.

On 5/16/2014 11:30 AM, Stian Thorgersen wrote:
> In that case I'm not convinced. I'd expect all 'clients' to be logged out when I logout of the SSO realm. Unless I've explicitly granted the client offline access (something we don't really support atm).
>
> ----- 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, 16 May, 2014 4:09:00 PM
>> Subject: Re: [keycloak-dev] oauth clients and session problems
>>
>> No, I'm talking about browser-based oauth grant.  Where the client
>> initiating the token request is an oauth client and the user has to
>> login and go to the oauth grant page.
>>
>> On 5/16/2014 9:55 AM, Stian Thorgersen wrote:
>>> Are you talking about 'tokens/grants/access'?
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 16 May, 2014 2:48:06 PM
>>>> Subject: [keycloak-dev] oauth clients and session problems
>>>>
>>>> I think oauth grants are a different animal than application logins.
>>>> Applications are part of an SSO session, while oauth grants will
>>>> probably not want to be part of an SSO session.  Why? If an Oauth grant
>>>> requires entering in user credentials, right now, Keycloak will create a
>>>> identity cookie.  The user might not know in this situation that they
>>>> need to logout.
>>>>
>>>> I was thinking that:
>>>>
>>>> 1. OAuth Client grant requests should always have a new session created
>>>> for them.
>>>> 2. OAuth client grant requests should not ever set any cookies.  Its ok
>>>> to use existing cookies for authentication though.
>>>> 3. ssoSessionIdleTimeout and ssoSessionMaxLifespan should be overridable
>>>> for each oauth client and application.
>>>>
>>>> --
>>>> 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
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 16 11:47:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 May 2014 11:47:52 -0400 (EDT)
Subject: [keycloak-dev] oauth clients and session problems
In-Reply-To: <53763113.7050009@redhat.com>
References: <53761716.4000004@redhat.com>
	<1109944605.8957952.1400248528328.JavaMail.zimbra@redhat.com>
	<53762A0C.6090600@redhat.com>
	<645248224.9071075.1400254231789.JavaMail.zimbra@redhat.com>
	<53763113.7050009@redhat.com>
Message-ID: <797736324.9133157.1400255272129.JavaMail.zimbra@redhat.com>

Surely the user has to login first though, before the oauth grant page is displayed?

Google, Facebook, Twitter, etc. all requires that you are logged in with them prior to displaying a grant page.

----- 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, 16 May, 2014 4:38:59 PM
> Subject: Re: [keycloak-dev] oauth clients and session problems
> 
> OAuth clients shouldn't create an identity cookie at least.  Again,
> because the user might not know they are logged in.  Meaning, if the
> user isn't already logged in, then the oauth grant page will not
> set/refresh the KEYCLOAK_IDENTITY cookie.
> 
> I'm most worried about doing a oauth client grant and the user not
> knowing they are logged in.  They step away from the browser, and still
> have their SSO session active.
> 
> On 5/16/2014 11:30 AM, Stian Thorgersen wrote:
> > In that case I'm not convinced. I'd expect all 'clients' to be logged out
> > when I logout of the SSO realm. Unless I've explicitly granted the client
> > offline access (something we don't really support atm).
> >
> > ----- 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, 16 May, 2014 4:09:00 PM
> >> Subject: Re: [keycloak-dev] oauth clients and session problems
> >>
> >> No, I'm talking about browser-based oauth grant.  Where the client
> >> initiating the token request is an oauth client and the user has to
> >> login and go to the oauth grant page.
> >>
> >> On 5/16/2014 9:55 AM, Stian Thorgersen wrote:
> >>> Are you talking about 'tokens/grants/access'?
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, 16 May, 2014 2:48:06 PM
> >>>> Subject: [keycloak-dev] oauth clients and session problems
> >>>>
> >>>> I think oauth grants are a different animal than application logins.
> >>>> Applications are part of an SSO session, while oauth grants will
> >>>> probably not want to be part of an SSO session.  Why? If an Oauth grant
> >>>> requires entering in user credentials, right now, Keycloak will create a
> >>>> identity cookie.  The user might not know in this situation that they
> >>>> need to logout.
> >>>>
> >>>> I was thinking that:
> >>>>
> >>>> 1. OAuth Client grant requests should always have a new session created
> >>>> for them.
> >>>> 2. OAuth client grant requests should not ever set any cookies.  Its ok
> >>>> to use existing cookies for authentication though.
> >>>> 3. ssoSessionIdleTimeout and ssoSessionMaxLifespan should be overridable
> >>>> for each oauth client and application.
> >>>>
> >>>> --
> >>>> 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
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Fri May 16 12:40:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 May 2014 12:40:34 -0400 (EDT)
Subject: [keycloak-dev] Added 'keycloak-server.json' to configure server
In-Reply-To: <1370401766.9197978.1400258101472.JavaMail.zimbra@redhat.com>
Message-ID: <375789014.9200502.1400258434444.JavaMail.zimbra@redhat.com>

Keycloak is now configured through keycloak-server.json (standalone/deployments/auth-server.war/WEB-INF/classes/META-INF/keycloak-server.json).

This file let's you configure:

* Model provider - including hostname/port/etc for Mongo
* Audit provider - including hostname/port/etc for Mongo
* Theme - default theme name and dir
* Scheduled - interval to run scheduled tasks

I've also added an SPI interface, which is used to detect and load SPI's. Currently the following SPI's are registered:

* ModelSpi
* AuditProviderSpi
* AuditListenerSpi
* AuthenticationSpi
* IdentityManagerSpi
* TimerSpi

There's a few 'providers' that needs to still be updated, these are themes, import/export and social.

From gcardoso at redhat.com  Fri May 16 13:56:01 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Fri, 16 May 2014 14:56:01 -0300
Subject: [keycloak-dev] Issues with the first login flow
Message-ID: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>

When the user first installs LiveOak, he is asked to enter a username / password: https://dl.dropboxusercontent.com/u/2730435/login.png

After entering admin/admin, the page slightly changes and a message is displayed: https://dl.dropboxusercontent.com/u/2730435/password.png

Since the changes on the page are very subtile, the user might not realize that he needs to update the password and might try to log in again. This happened with me and Thomas, who stated:

"for some reason, I didn't see that the form has changed and not asking for my username/password anymore but new password/confirmation of password
I lost a bit of time as I was wondering where to change the password (it was just in front of me really?)? 

I don?t see a reason for having the login page for the first login. Instead, we could have only the page to update the password, like suggested in this wireframe: https://issues.jboss.org/secure/attachment/12379916/1%20Update%20Password.png

Is this something managed by Keycloak? Is it possible to make this change?

Gabriel

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140516/24b50c75/attachment.html 

From bburke at redhat.com  Sat May 17 14:33:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 17 May 2014 14:33:44 -0400
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
Message-ID: <5377AB88.9020704@redhat.com>



On 5/16/2014 1:56 PM, Gabriel Cardoso wrote:
>
> "for some reason, I didn't see that the form has changed and not asking
> for my username/password anymore but new password/confirmation of password
> I lost a bit of time as I was wondering where to change the password (it
> was just in front of me really?)?
>

I have hit this a few time myself!  I think the update password page 
needs to look different than the login page.



> I don?t see a reason for having the login page for the first login.
> Instead, we could have only the page to update the password, like
> suggested in this wireframe:
> https://issues.jboss.org/secure/attachment/12379916/1%20Update%20Password.png
> <https://issues.jboss.org/secure/attachment/12379916/1 Update Password.png>
>
> Is this something managed by Keycloak? Is it possible to make this change?
>

Welll, you would get this update password page if your account status 
was changed too.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Sat May 17 14:37:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 17 May 2014 14:37:41 -0400
Subject: [keycloak-dev] user session client association
Message-ID: <5377AC75.5050203@redhat.com>

clients are now associated with the user session in the database.  The 
admin console session pages have changed too to reflect this 
association.  Application session lists users logged in and when they 
logged in.  User session lists user sessions as well as the 
applications/clients associated with that session. Logouts and user 
logouts also use this session association whenever possible.

Apps that don't have Http Sessions (i.e. Javascript apps like th admin 
console) will now show up in the session listings!

Unfortunately though, the account service does not show up in session 
listings.  This is because it never receives an access token/refresh 
token like other apps do.  I still need to change the account service so 
that it shows up.

Finally, I need to update the account service session page to display 
associated clients/apps.  I'll do that monday.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon May 19 04:25:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 May 2014 04:25:00 -0400 (EDT)
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <5377AB88.9020704@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5377AB88.9020704@redhat.com>
Message-ID: <1086948787.9705386.1400487900986.JavaMail.zimbra@redhat.com>

I don't think we should have a separate update password page, but instead make the generic "you need to update your password" page more obvious.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, 17 May, 2014 7:33:44 PM
> Subject: Re: [keycloak-dev] Issues with the first login flow
> 
> 
> 
> On 5/16/2014 1:56 PM, Gabriel Cardoso wrote:
> >
> > "for some reason, I didn't see that the form has changed and not asking
> > for my username/password anymore but new password/confirmation of password
> > I lost a bit of time as I was wondering where to change the password (it
> > was just in front of me really?)?
> >
> 
> I have hit this a few time myself!  I think the update password page
> needs to look different than the login page.
> 
> 
> 
> > I don?t see a reason for having the login page for the first login.
> > Instead, we could have only the page to update the password, like
> > suggested in this wireframe:
> > https://issues.jboss.org/secure/attachment/12379916/1%20Update%20Password.png
> > <https://issues.jboss.org/secure/attachment/12379916/1 Update Password.png>
> >
> > Is this something managed by Keycloak? Is it possible to make this change?
> >
> 
> Welll, you would get this update password page if your account status
> was changed too.
> 
> --
> 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
> 


From stian at redhat.com  Mon May 19 04:33:23 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 May 2014 04:33:23 -0400 (EDT)
Subject: [keycloak-dev] user session client association
In-Reply-To: <5377AC75.5050203@redhat.com>
References: <5377AC75.5050203@redhat.com>
Message-ID: <1099923515.9714275.1400488403494.JavaMail.zimbra@redhat.com>

Nice

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, 17 May, 2014 7:37:41 PM
> Subject: [keycloak-dev] user session client association
> 
> clients are now associated with the user session in the database.  The
> admin console session pages have changed too to reflect this
> association.  Application session lists users logged in and when they
> logged in.  User session lists user sessions as well as the
> applications/clients associated with that session. Logouts and user
> logouts also use this session association whenever possible.
> 
> Apps that don't have Http Sessions (i.e. Javascript apps like th admin
> console) will now show up in the session listings!
> 
> Unfortunately though, the account service does not show up in session
> listings.  This is because it never receives an access token/refresh
> token like other apps do.  I still need to change the account service so
> that it shows up.
> 
> Finally, I need to update the account service session page to display
> associated clients/apps.  I'll do that monday.
> 
> 
> 
> --
> 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
> 

From stian at redhat.com  Mon May 19 04:35:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 May 2014 04:35:21 -0400 (EDT)
Subject: [keycloak-dev] oauth clients and session problems
In-Reply-To: <797736324.9133157.1400255272129.JavaMail.zimbra@redhat.com>
References: <53761716.4000004@redhat.com>
	<1109944605.8957952.1400248528328.JavaMail.zimbra@redhat.com>
	<53762A0C.6090600@redhat.com>
	<645248224.9071075.1400254231789.JavaMail.zimbra@redhat.com>
	<53763113.7050009@redhat.com>
	<797736324.9133157.1400255272129.JavaMail.zimbra@redhat.com>
Message-ID: <673099042.9715986.1400488521325.JavaMail.zimbra@redhat.com>

Can we have a hangout to this discuss this?

Another thing I thought about was that I think the session cookie should be persisted permanently even without remember-me enabled. That way instead of creating a new session after restarting the user can re-attach to the same session by a new login. The benefit here is that we are more likely to invalidate any refresh tokens created for that particular device/browser.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 16 May, 2014 4:47:52 PM
> Subject: Re: [keycloak-dev] oauth clients and session problems
> 
> Surely the user has to login first though, before the oauth grant page is
> displayed?
> 
> Google, Facebook, Twitter, etc. all requires that you are logged in with them
> prior to displaying a grant page.
> 
> ----- 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, 16 May, 2014 4:38:59 PM
> > Subject: Re: [keycloak-dev] oauth clients and session problems
> > 
> > OAuth clients shouldn't create an identity cookie at least.  Again,
> > because the user might not know they are logged in.  Meaning, if the
> > user isn't already logged in, then the oauth grant page will not
> > set/refresh the KEYCLOAK_IDENTITY cookie.
> > 
> > I'm most worried about doing a oauth client grant and the user not
> > knowing they are logged in.  They step away from the browser, and still
> > have their SSO session active.
> > 
> > On 5/16/2014 11:30 AM, Stian Thorgersen wrote:
> > > In that case I'm not convinced. I'd expect all 'clients' to be logged out
> > > when I logout of the SSO realm. Unless I've explicitly granted the client
> > > offline access (something we don't really support atm).
> > >
> > > ----- 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, 16 May, 2014 4:09:00 PM
> > >> Subject: Re: [keycloak-dev] oauth clients and session problems
> > >>
> > >> No, I'm talking about browser-based oauth grant.  Where the client
> > >> initiating the token request is an oauth client and the user has to
> > >> login and go to the oauth grant page.
> > >>
> > >> On 5/16/2014 9:55 AM, Stian Thorgersen wrote:
> > >>> Are you talking about 'tokens/grants/access'?
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: keycloak-dev at lists.jboss.org
> > >>>> Sent: Friday, 16 May, 2014 2:48:06 PM
> > >>>> Subject: [keycloak-dev] oauth clients and session problems
> > >>>>
> > >>>> I think oauth grants are a different animal than application logins.
> > >>>> Applications are part of an SSO session, while oauth grants will
> > >>>> probably not want to be part of an SSO session.  Why? If an Oauth
> > >>>> grant
> > >>>> requires entering in user credentials, right now, Keycloak will create
> > >>>> a
> > >>>> identity cookie.  The user might not know in this situation that they
> > >>>> need to logout.
> > >>>>
> > >>>> I was thinking that:
> > >>>>
> > >>>> 1. OAuth Client grant requests should always have a new session
> > >>>> created
> > >>>> for them.
> > >>>> 2. OAuth client grant requests should not ever set any cookies.  Its
> > >>>> ok
> > >>>> to use existing cookies for authentication though.
> > >>>> 3. ssoSessionIdleTimeout and ssoSessionMaxLifespan should be
> > >>>> overridable
> > >>>> for each oauth client and application.
> > >>>>
> > >>>> --
> > >>>> 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
> > >>>>
> > >>
> > >> --
> > >> Bill Burke
> > >> JBoss, a division of Red Hat
> > >> http://bill.burkecentral.com
> > >>
> > 
> > --
> > 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
> 

From stian at redhat.com  Mon May 19 08:58:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 May 2014 08:58:31 -0400 (EDT)
Subject: [keycloak-dev] Email notifications on events and theme support for
	emails
In-Reply-To: <40082862.10074653.1400504237667.JavaMail.zimbra@redhat.com>
Message-ID: <1859459710.10075160.1400504311347.JavaMail.zimbra@redhat.com>

I'm working on adding email notifications for events. The events I think we need to support are:

* Suspected malicious login
* Password changed

Also at the same time I'm adding theme support for emails. Folks are just not going to want their emails to be signed 'Thanks, The Keycloak Team' ;)

From gcardoso at redhat.com  Mon May 19 11:24:33 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Mon, 19 May 2014 12:24:33 -0300
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <1086948787.9705386.1400487900986.JavaMail.zimbra@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5377AB88.9020704@redhat.com>
	<1086948787.9705386.1400487900986.JavaMail.zimbra@redhat.com>
Message-ID: <5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>

In my proposal it would have the same style as the login page, but the paragraph + inputs would create this visual differentiation to call the user?s attention.

Can?t we have something like the wireframe, Stian?


On May 19, 2014, at 5:25 AM, Stian Thorgersen <stian at redhat.com> wrote:

> I don't think we should have a separate update password page, but instead make the generic "you need to update your password" page more obvious.
> 
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Saturday, 17 May, 2014 7:33:44 PM
>> Subject: Re: [keycloak-dev] Issues with the first login flow
>> 
>> 
>> 
>> On 5/16/2014 1:56 PM, Gabriel Cardoso wrote:
>>> 
>>> "for some reason, I didn't see that the form has changed and not asking
>>> for my username/password anymore but new password/confirmation of password
>>> I lost a bit of time as I was wondering where to change the password (it
>>> was just in front of me really?)?
>>> 
>> 
>> I have hit this a few time myself!  I think the update password page
>> needs to look different than the login page.
>> 
>> 
>> 
>>> I don?t see a reason for having the login page for the first login.
>>> Instead, we could have only the page to update the password, like
>>> suggested in this wireframe:
>>> https://issues.jboss.org/secure/attachment/12379916/1%20Update%20Password.png
>>> <https://issues.jboss.org/secure/attachment/12379916/1 Update Password.png>
>>> 
>>> Is this something managed by Keycloak? Is it possible to make this change?
>>> 
>> 
>> Welll, you would get this update password page if your account status
>> was changed too.
>> 
>> --
>> 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
>> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140519/9002e471/attachment.html 

From stian at redhat.com  Mon May 19 11:30:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 May 2014 11:30:19 -0400 (EDT)
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5377AB88.9020704@redhat.com>
	<1086948787.9705386.1400487900986.JavaMail.zimbra@redhat.com>
	<5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>
Message-ID: <239798468.10192628.1400513419346.JavaMail.zimbra@redhat.com>

I don't like that solution as it requires special logic in the server to handle the first login.

I would much rather we improve the screen where a user is required to reset the password.

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, 19 May, 2014 4:24:33 PM
> Subject: Re: [keycloak-dev] Issues with the first login flow
> 
> In my proposal it would have the same style as the login page, but the
> paragraph + inputs would create this visual differentiation to call the
> user?s attention.
> 
> Can?t we have something like the wireframe, Stian?
> 
> 
> On May 19, 2014, at 5:25 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > I don't think we should have a separate update password page, but instead
> > make the generic "you need to update your password" page more obvious.
> > 
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Saturday, 17 May, 2014 7:33:44 PM
> >> Subject: Re: [keycloak-dev] Issues with the first login flow
> >> 
> >> 
> >> 
> >> On 5/16/2014 1:56 PM, Gabriel Cardoso wrote:
> >>> 
> >>> "for some reason, I didn't see that the form has changed and not asking
> >>> for my username/password anymore but new password/confirmation of
> >>> password
> >>> I lost a bit of time as I was wondering where to change the password (it
> >>> was just in front of me really?)?
> >>> 
> >> 
> >> I have hit this a few time myself!  I think the update password page
> >> needs to look different than the login page.
> >> 
> >> 
> >> 
> >>> I don?t see a reason for having the login page for the first login.
> >>> Instead, we could have only the page to update the password, like
> >>> suggested in this wireframe:
> >>> https://issues.jboss.org/secure/attachment/12379916/1%20Update%20Password.png
> >>> <https://issues.jboss.org/secure/attachment/12379916/1 Update
> >>> Password.png>
> >>> 
> >>> Is this something managed by Keycloak? Is it possible to make this
> >>> change?
> >>> 
> >> 
> >> Welll, you would get this update password page if your account status
> >> was changed too.
> >> 
> >> --
> >> 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
> >> 
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 


From bburke at redhat.com  Mon May 19 11:48:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 19 May 2014 11:48:38 -0400
Subject: [keycloak-dev] user session client association
In-Reply-To: <1099923515.9714275.1400488403494.JavaMail.zimbra@redhat.com>
References: <5377AC75.5050203@redhat.com>
	<1099923515.9714275.1400488403494.JavaMail.zimbra@redhat.com>
Message-ID: <537A27D6.2080607@redhat.com>

acct service session page now lists apps/clients.  Both this page and 
the admin console equivalent might need a tiny bit of web page designer 
love.

On 5/19/2014 4:33 AM, Stian Thorgersen wrote:
> Nice
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Saturday, 17 May, 2014 7:37:41 PM
>> Subject: [keycloak-dev] user session client association
>>
>> clients are now associated with the user session in the database.  The
>> admin console session pages have changed too to reflect this
>> association.  Application session lists users logged in and when they
>> logged in.  User session lists user sessions as well as the
>> applications/clients associated with that session. Logouts and user
>> logouts also use this session association whenever possible.
>>
>> Apps that don't have Http Sessions (i.e. Javascript apps like th admin
>> console) will now show up in the session listings!
>>
>> Unfortunately though, the account service does not show up in session
>> listings.  This is because it never receives an access token/refresh
>> token like other apps do.  I still need to change the account service so
>> that it shows up.
>>
>> Finally, I need to update the account service session page to display
>> associated clients/apps.  I'll do that monday.
>>
>>
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon May 19 11:51:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 19 May 2014 11:51:28 -0400
Subject: [keycloak-dev] Email notifications on events and theme support
 for emails
In-Reply-To: <1859459710.10075160.1400504311347.JavaMail.zimbra@redhat.com>
References: <1859459710.10075160.1400504311347.JavaMail.zimbra@redhat.com>
Message-ID: <537A2880.8070203@redhat.com>

FYI, I'm thinking of disabling Brute force detection for now.  It really 
should be dealing with IP addresses.  We have a good fallback with 
fail2ban until we get this feature properly implemented with keycloak.

On 5/19/2014 8:58 AM, Stian Thorgersen wrote:
> I'm working on adding email notifications for events. The events I think we need to support are:
>
> * Suspected malicious login
> * Password changed
>
> Also at the same time I'm adding theme support for emails. Folks are just not going to want their emails to be signed 'Thanks, The Keycloak Team' ;)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Mon May 19 11:59:38 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 19 May 2014 12:59:38 -0300
Subject: [keycloak-dev] Email notifications on events and theme support
 for emails
In-Reply-To: <1859459710.10075160.1400504311347.JavaMail.zimbra@redhat.com>
References: <40082862.10074653.1400504237667.JavaMail.zimbra@redhat.com>
	<1859459710.10075160.1400504311347.JavaMail.zimbra@redhat.com>
Message-ID: <20140519155938.GB9711@abstractj.org>

Hi Stian, I think is a good idea. But what would you consider a
malicious login? Are you talking about something like brute forcing or
attempts of code injection?

On 2014-05-19, Stian Thorgersen wrote:
> I'm working on adding email notifications for events. The events I think we need to support are:
>
> * Suspected malicious login
> * Password changed
>
> Also at the same time I'm adding theme support for emails. Folks are just not going to want their emails to be signed 'Thanks, The Keycloak Team' ;)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

JBoss, a division of Red Hat

From bburke at redhat.com  Mon May 19 12:12:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 19 May 2014 12:12:56 -0400
Subject: [keycloak-dev] Email notifications on events and theme support
 for emails
In-Reply-To: <20140519155938.GB9711@abstractj.org>
References: <40082862.10074653.1400504237667.JavaMail.zimbra@redhat.com>	<1859459710.10075160.1400504311347.JavaMail.zimbra@redhat.com>
	<20140519155938.GB9711@abstractj.org>
Message-ID: <537A2D88.4020504@redhat.com>

Not sure how code injection could happen with Keycloak?  But, he's 
talking about Brute force.

On 5/19/2014 11:59 AM, Bruno Oliveira wrote:
> Hi Stian, I think is a good idea. But what would you consider a
> malicious login? Are you talking about something like brute forcing or
> attempts of code injection?
>
> On 2014-05-19, Stian Thorgersen wrote:
>> I'm working on adding email notifications for events. The events I think we need to support are:
>>
>> * Suspected malicious login
>> * Password changed
>>
>> Also at the same time I'm adding theme support for emails. Folks are just not going to want their emails to be signed 'Thanks, The Keycloak Team' ;)
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
>
> abstractj
>
> JBoss, a division of Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon May 19 12:14:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 May 2014 12:14:24 -0400 (EDT)
Subject: [keycloak-dev] Email notifications on events and theme support
 for emails
In-Reply-To: <537A2880.8070203@redhat.com>
References: <1859459710.10075160.1400504311347.JavaMail.zimbra@redhat.com>
	<537A2880.8070203@redhat.com>
Message-ID: <858169858.10234475.1400516064472.JavaMail.zimbra@redhat.com>

In that case I'm not sure if we can send emails for suspected malicious logins. Unless we just add something that sends an email after 3? failed login attempts?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 19 May, 2014 4:51:28 PM
> Subject: Re: [keycloak-dev] Email notifications on events and theme support for emails
> 
> FYI, I'm thinking of disabling Brute force detection for now.  It really
> should be dealing with IP addresses.  We have a good fallback with
> fail2ban until we get this feature properly implemented with keycloak.
> 
> On 5/19/2014 8:58 AM, Stian Thorgersen wrote:
> > I'm working on adding email notifications for events. The events I think we
> > need to support are:
> >
> > * Suspected malicious login
> > * Password changed
> >
> > Also at the same time I'm adding theme support for emails. Folks are just
> > not going to want their emails to be signed 'Thanks, The Keycloak Team' ;)
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> 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
> 

From stian at redhat.com  Mon May 19 12:43:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 May 2014 12:43:55 -0400 (EDT)
Subject: [keycloak-dev] Added theme support to emails
In-Reply-To: <1388747595.10270090.1400517780253.JavaMail.zimbra@redhat.com>
Message-ID: <949597586.10270348.1400517835872.JavaMail.zimbra@redhat.com>

I've just added theme support to emails. There are now FreeMarker templates for the email body, and the subject is set in message bundles. Currently there's no way to set the email theme for a Realm, but that'll be added tomorrow.

There's a fair few changes in this commit as I had to do some updates/refactoring to the existing Theme/FreeMarker code.

From bruno at abstractj.org  Mon May 19 13:34:54 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 19 May 2014 14:34:54 -0300
Subject: [keycloak-dev] Email notifications on events and theme support
 for emails
In-Reply-To: <537A2D88.4020504@redhat.com>
References: <40082862.10074653.1400504237667.JavaMail.zimbra@redhat.com>
	<1859459710.10075160.1400504311347.JavaMail.zimbra@redhat.com>
	<20140519155938.GB9711@abstractj.org> <537A2D88.4020504@redhat.com>
Message-ID: <20140519173454.GA12350@abstractj.org>

Not sure if you guys have something in mind. But what if we had an SPI
for notifications about malicious activities? For example: We could write
an adapter to notify users via push server about a malicious attempt.

Into this way even if their e-mail account get hacked, they still get
the notification on device.

On 2014-05-19, Bill Burke wrote:
> Not sure how code injection could happen with Keycloak?  But, he's
> talking about Brute force.
>
> On 5/19/2014 11:59 AM, Bruno Oliveira wrote:
> > Hi Stian, I think is a good idea. But what would you consider a
> > malicious login? Are you talking about something like brute forcing or
> > attempts of code injection?
> >
> > On 2014-05-19, Stian Thorgersen wrote:
> >> I'm working on adding email notifications for events. The events I think we need to support are:
> >>
> >> * Suspected malicious login
> >> * Password changed
> >>
> >> Also at the same time I'm adding theme support for emails. Folks are just not going to want their emails to be signed 'Thanks, The Keycloak Team' ;)
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > --
> >
> > abstractj
> >
> > JBoss, a division of Red Hat
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> 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

--

abstractj

From gcardoso at redhat.com  Mon May 19 13:58:18 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Mon, 19 May 2014 14:58:18 -0300
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <239798468.10192628.1400513419346.JavaMail.zimbra@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5377AB88.9020704@redhat.com>
	<1086948787.9705386.1400487900986.JavaMail.zimbra@redhat.com>
	<5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>
	<239798468.10192628.1400513419346.JavaMail.zimbra@redhat.com>
Message-ID: <B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>

From the technical side, it requires a special logic. For the user, the login screen in the first access is a useless step. But I understand that you might want to prioritise other things that must be done.

That said, how about a page like this to update the password? It is easier to recognise and it would work both in the first login and when the account status is changed.

https://dl.dropboxusercontent.com/u/2730435/password2.png


On May 19, 2014, at 12:30 PM, Stian Thorgersen <stian at redhat.com> wrote:

> I don't like that solution as it requires special logic in the server to handle the first login.
> 
> I would much rather we improve the screen where a user is required to reset the password.
> 
> ----- Original Message -----
>> From: "Gabriel Cardoso" <gcardoso at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Monday, 19 May, 2014 4:24:33 PM
>> Subject: Re: [keycloak-dev] Issues with the first login flow
>> 
>> In my proposal it would have the same style as the login page, but the
>> paragraph + inputs would create this visual differentiation to call the
>> user?s attention.
>> 
>> Can?t we have something like the wireframe, Stian?
>> 
>> 
>> On May 19, 2014, at 5:25 AM, Stian Thorgersen <stian at redhat.com> wrote:
>> 
>>> I don't think we should have a separate update password page, but instead
>>> make the generic "you need to update your password" page more obvious.
>>> 
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Saturday, 17 May, 2014 7:33:44 PM
>>>> Subject: Re: [keycloak-dev] Issues with the first login flow
>>>> 
>>>> 
>>>> 
>>>> On 5/16/2014 1:56 PM, Gabriel Cardoso wrote:
>>>>> 
>>>>> "for some reason, I didn't see that the form has changed and not asking
>>>>> for my username/password anymore but new password/confirmation of
>>>>> password
>>>>> I lost a bit of time as I was wondering where to change the password (it
>>>>> was just in front of me really?)?
>>>>> 
>>>> 
>>>> I have hit this a few time myself!  I think the update password page
>>>> needs to look different than the login page.
>>>> 
>>>> 
>>>> 
>>>>> I don?t see a reason for having the login page for the first login.
>>>>> Instead, we could have only the page to update the password, like
>>>>> suggested in this wireframe:
>>>>> https://issues.jboss.org/secure/attachment/12379916/1%20Update%20Password.png
>>>>> <https://issues.jboss.org/secure/attachment/12379916/1 Update
>>>>> Password.png>
>>>>> 
>>>>> Is this something managed by Keycloak? Is it possible to make this
>>>>> change?
>>>>> 
>>>> 
>>>> Welll, you would get this update password page if your account status
>>>> was changed too.
>>>> 
>>>> --
>>>> 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
>>>> 
>>> 
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>> 
>> 

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140519/6ebfea72/attachment.html 

From stian at redhat.com  Mon May 19 15:28:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 May 2014 15:28:55 -0400 (EDT)
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5377AB88.9020704@redhat.com>
	<1086948787.9705386.1400487900986.JavaMail.zimbra@redhat.com>
	<5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>
	<239798468.10192628.1400513419346.JavaMail.zimbra@redhat.com>
	<B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>
Message-ID: <1927459791.10461510.1400527734997.JavaMail.zimbra@redhat.com>

>From the technical point of view I don't like the idea of adding a special case that lets you set the admin password. Not just because of the additional work, but also as it adds a possible security hole. There are also situations where someone may set a more secure admin password on an initial installation prior to handing over to an admin, in which case there will be a password set, but the admin will be required to set the password. What we have covers both those use cases, as well as the use cases for when a password is required to be changed (suspected attack, expired password, etc).

On the other side, with regards to usability, I believe any user or admin of Keycloak are likely to experience the "update password" page, and may so several times while using Keycloak. This page will be displayed after the user has logged in with username/password (and optionally totp). I agree that this can be confusing, especially as it has the exact same layout as the login screen and only text changes. If we can find a solution to making this page more obvious to users that would also sufficiently solve the first login case in my opinion.

By the way the last attachment doesn't work as the screen should be displayed after the user has logged in, and hence not require the user to enter a username.

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, 19 May, 2014 6:58:18 PM
> Subject: Re: [keycloak-dev] Issues with the first login flow
> 
> From the technical side, it requires a special logic. For the user, the login
> screen in the first access is a useless step. But I understand that you
> might want to prioritise other things that must be done.
> 
> That said, how about a page like this to update the password? It is easier to
> recognise and it would work both in the first login and when the account
> status is changed.
> 
> https://dl.dropboxusercontent.com/u/2730435/password2.png
> 
> 
> On May 19, 2014, at 12:30 PM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > I don't like that solution as it requires special logic in the server to
> > handle the first login.
> > 
> > I would much rather we improve the screen where a user is required to reset
> > the password.
> > 
> > ----- Original Message -----
> >> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Monday, 19 May, 2014 4:24:33 PM
> >> Subject: Re: [keycloak-dev] Issues with the first login flow
> >> 
> >> In my proposal it would have the same style as the login page, but the
> >> paragraph + inputs would create this visual differentiation to call the
> >> user?s attention.
> >> 
> >> Can?t we have something like the wireframe, Stian?
> >> 
> >> 
> >> On May 19, 2014, at 5:25 AM, Stian Thorgersen <stian at redhat.com> wrote:
> >> 
> >>> I don't think we should have a separate update password page, but instead
> >>> make the generic "you need to update your password" page more obvious.
> >>> 
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Saturday, 17 May, 2014 7:33:44 PM
> >>>> Subject: Re: [keycloak-dev] Issues with the first login flow
> >>>> 
> >>>> 
> >>>> 
> >>>> On 5/16/2014 1:56 PM, Gabriel Cardoso wrote:
> >>>>> 
> >>>>> "for some reason, I didn't see that the form has changed and not asking
> >>>>> for my username/password anymore but new password/confirmation of
> >>>>> password
> >>>>> I lost a bit of time as I was wondering where to change the password
> >>>>> (it
> >>>>> was just in front of me really?)?
> >>>>> 
> >>>> 
> >>>> I have hit this a few time myself!  I think the update password page
> >>>> needs to look different than the login page.
> >>>> 
> >>>> 
> >>>> 
> >>>>> I don?t see a reason for having the login page for the first login.
> >>>>> Instead, we could have only the page to update the password, like
> >>>>> suggested in this wireframe:
> >>>>> https://issues.jboss.org/secure/attachment/12379916/1%20Update%20Password.png
> >>>>> <https://issues.jboss.org/secure/attachment/12379916/1 Update
> >>>>> Password.png>
> >>>>> 
> >>>>> Is this something managed by Keycloak? Is it possible to make this
> >>>>> change?
> >>>>> 
> >>>> 
> >>>> Welll, you would get this update password page if your account status
> >>>> was changed too.
> >>>> 
> >>>> --
> >>>> 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
> >>>> 
> >>> 
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> 
> >> ---
> >> Gabriel Cardoso
> >> User Experience Designer @ Red Hat
> >> 
> >> 
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 


From stian at redhat.com  Mon May 19 15:32:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 May 2014 15:32:34 -0400 (EDT)
Subject: [keycloak-dev] Email notifications on events and theme support
 for emails
In-Reply-To: <20140519173454.GA12350@abstractj.org>
References: <40082862.10074653.1400504237667.JavaMail.zimbra@redhat.com>
	<1859459710.10075160.1400504311347.JavaMail.zimbra@redhat.com>
	<20140519155938.GB9711@abstractj.org> <537A2D88.4020504@redhat.com>
	<20140519173454.GA12350@abstractj.org>
Message-ID: <1755613452.10463124.1400527954094.JavaMail.zimbra@redhat.com>

We already have an SPI ;). It's rather poorly named AuditListenerProvider. It lets you create a listener for any account related events, such as logins, failed logins, password updates, etc.. The plan is to add a email implementation for this that will send both users and admin(s) an email on certain (configurable) events.

What's lacking atm is events for suspected malicious activities, the only event available now is failed login.

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 19 May, 2014 6:34:54 PM
> Subject: Re: [keycloak-dev] Email notifications on events and theme support for emails
> 
> Not sure if you guys have something in mind. But what if we had an SPI
> for notifications about malicious activities? For example: We could write
> an adapter to notify users via push server about a malicious attempt.
> 
> Into this way even if their e-mail account get hacked, they still get
> the notification on device.
> 
> On 2014-05-19, Bill Burke wrote:
> > Not sure how code injection could happen with Keycloak?  But, he's
> > talking about Brute force.
> >
> > On 5/19/2014 11:59 AM, Bruno Oliveira wrote:
> > > Hi Stian, I think is a good idea. But what would you consider a
> > > malicious login? Are you talking about something like brute forcing or
> > > attempts of code injection?
> > >
> > > On 2014-05-19, Stian Thorgersen wrote:
> > >> I'm working on adding email notifications for events. The events I think
> > >> we need to support are:
> > >>
> > >> * Suspected malicious login
> > >> * Password changed
> > >>
> > >> Also at the same time I'm adding theme support for emails. Folks are
> > >> just not going to want their emails to be signed 'Thanks, The Keycloak
> > >> Team' ;)
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > > --
> > >
> > > abstractj
> > >
> > > JBoss, a division of Red Hat
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> >
> > --
> > 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
> 
> --
> 
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue May 20 06:33:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 06:33:53 -0400 (EDT)
Subject: [keycloak-dev] Resource Owner Password Credentials Grant disabled
	by default
In-Reply-To: <262769608.10790484.1400582007905.JavaMail.zimbra@redhat.com>
Message-ID: <2014882591.10790580.1400582033340.JavaMail.zimbra@redhat.com>

Resource Owner Password Credentials Grant aka 'grants/access' is now disabled by default and has to be enabled for the realm through the admin console

From bburke at redhat.com  Tue May 20 09:10:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 May 2014 09:10:45 -0400
Subject: [keycloak-dev] cors setup simplification?
Message-ID: <537B5455.1060009@redhat.com>

CORS setup is confusing to people.  I'm going to remove the web-origins 
setting from the admin console.  Instead there will be a on/off switch 
that says "Cross-Origin Tokens (CORS)".  Tokens created for those types 
of clients will have the token's origins calculated by iterating over 
the redirect uri list.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue May 20 09:14:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 May 2014 09:14:32 -0400
Subject: [keycloak-dev] admin console requires reboot
Message-ID: <537B5538.7000008@redhat.com>

The admin console now requires a reboot to see changes from static 
content files when run with

mvn -pl testsuite/integration -Pkeycloak-server -Dresources exec:java

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue May 20 09:21:07 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 09:21:07 -0400 (EDT)
Subject: [keycloak-dev] admin console requires reboot
In-Reply-To: <537B5538.7000008@redhat.com>
References: <537B5538.7000008@redhat.com>
Message-ID: <749008436.10910382.1400592067283.JavaMail.zimbra@redhat.com>

Hmm... That'll be my fault, I'll look at it now.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 2:14:32 PM
> Subject: [keycloak-dev] admin console requires reboot
> 
> The admin console now requires a reboot to see changes from static
> content files when run with
> 
> mvn -pl testsuite/integration -Pkeycloak-server -Dresources exec:java
> 
> --
> 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
> 

From stian at redhat.com  Tue May 20 09:33:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 09:33:48 -0400 (EDT)
Subject: [keycloak-dev] cors setup simplification?
In-Reply-To: <537B5455.1060009@redhat.com>
References: <537B5455.1060009@redhat.com>
Message-ID: <1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>

I like the idea of not having to specify the web-origins, but I wonder if there are use-cases for having web-origins that can't be calculated from the redirect-uris.

Also, the web-origins is used by Keycloak's own endpoints. In this case "Cross-Origin Tokens" doesn't make sense.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 2:10:45 PM
> Subject: [keycloak-dev] cors setup simplification?
> 
> CORS setup is confusing to people.  I'm going to remove the web-origins
> setting from the admin console.  Instead there will be a on/off switch
> that says "Cross-Origin Tokens (CORS)".  Tokens created for those types
> of clients will have the token's origins calculated by iterating over
> the redirect uri list.
> 
> --
> 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
> 

From stian at redhat.com  Tue May 20 09:42:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 09:42:46 -0400 (EDT)
Subject: [keycloak-dev] admin console requires reboot
In-Reply-To: <749008436.10910382.1400592067283.JavaMail.zimbra@redhat.com>
References: <537B5538.7000008@redhat.com>
	<749008436.10910382.1400592067283.JavaMail.zimbra@redhat.com>
Message-ID: <1073649316.10933643.1400593366232.JavaMail.zimbra@redhat.com>

Fixed

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 2:21:07 PM
> Subject: Re: [keycloak-dev] admin console requires reboot
> 
> Hmm... That'll be my fault, I'll look at it now.
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 20 May, 2014 2:14:32 PM
> > Subject: [keycloak-dev] admin console requires reboot
> > 
> > The admin console now requires a reboot to see changes from static
> > content files when run with
> > 
> > mvn -pl testsuite/integration -Pkeycloak-server -Dresources exec:java
> > 
> > --
> > 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
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue May 20 10:07:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 May 2014 10:07:52 -0400
Subject: [keycloak-dev] cors setup simplification?
In-Reply-To: <1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>
References: <537B5455.1060009@redhat.com>
	<1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>
Message-ID: <537B61B8.1030705@redhat.com>



On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
> I like the idea of not having to specify the web-origins, but I wonder if there are use-cases for having web-origins that can't be calculated from the redirect-uris.
>

I just can't see a case for this.  Let's just let users tell us we need 
this control.  Right now, the web origin is always set to the 
protocol://hostname of the application or oauth client.

> Also, the web-origins is used by Keycloak's own endpoints. In this case "Cross-Origin Tokens" doesn't make sense.
>

You're talking about the Account Service correct?  Well, I'm changing 
that! :)  How you implemented CORS support for the Account Service is 
not how web-origins were intended to be used.

Tokens are created for a specific client (app or oauth).  The 
web-origins for that issuedFor client are stuffed into the token created 
specifically for that client.  Basically, its saying this token is 
allowed to come from this set of origins.

What Web-Origins are not origin permissions for that application/client. 
  When you specify a web origin for the Account Service (or any other 
application) in the admin console, this is not origins that are allowed 
to call the account service!  But instead, the origins allowed for token 
requests made from tokens created for the Account Service.  Am I making 
sense?




-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue May 20 10:19:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 10:19:02 -0400 (EDT)
Subject: [keycloak-dev] cors setup simplification?
In-Reply-To: <537B61B8.1030705@redhat.com>
References: <537B5455.1060009@redhat.com>
	<1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>
	<537B61B8.1030705@redhat.com>
Message-ID: <1274305422.10970438.1400595542067.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 3:07:52 PM
> Subject: Re: [keycloak-dev] cors setup simplification?
> 
> 
> 
> On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
> > I like the idea of not having to specify the web-origins, but I wonder if
> > there are use-cases for having web-origins that can't be calculated from
> > the redirect-uris.
> >
> 
> I just can't see a case for this.  Let's just let users tell us we need
> this control.  Right now, the web origin is always set to the
> protocol://hostname of the application or oauth client.
> 
> > Also, the web-origins is used by Keycloak's own endpoints. In this case
> > "Cross-Origin Tokens" doesn't make sense.
> >
> 
> You're talking about the Account Service correct?  Well, I'm changing
> that! :)  How you implemented CORS support for the Account Service is
> not how web-origins were intended to be used.
> 
> Tokens are created for a specific client (app or oauth).  The
> web-origins for that issuedFor client are stuffed into the token created
> specifically for that client.  Basically, its saying this token is
> allowed to come from this set of origins.
> 
> What Web-Origins are not origin permissions for that application/client.
>   When you specify a web origin for the Account Service (or any other
> application) in the admin console, this is not origins that are allowed
> to call the account service!  But instead, the origins allowed for token
> requests made from tokens created for the Account Service.  Am I making
> sense?

Yep, it makes more sense for the account service that way. I was thinking about token service though, both code->token and refresh-token are called from JS and need web-origins configured on them.

> 
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Tue May 20 10:19:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 May 2014 10:19:56 -0400
Subject: [keycloak-dev] cors setup simplification?
In-Reply-To: <537B61B8.1030705@redhat.com>
References: <537B5455.1060009@redhat.com>	<1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>
	<537B61B8.1030705@redhat.com>
Message-ID: <537B648C.1050901@redhat.com>



On 5/20/2014 10:07 AM, Bill Burke wrote:
>
>
> On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
>> I like the idea of not having to specify the web-origins, but I wonder if there are use-cases for having web-origins that can't be calculated from the redirect-uris.
>>
>
> I just can't see a case for this.  Let's just let users tell us we need
> this control.  Right now, the web origin is always set to the
> protocol://hostname of the application or oauth client.
>
>> Also, the web-origins is used by Keycloak's own endpoints. In this case "Cross-Origin Tokens" doesn't make sense.
>>
>
> You're talking about the Account Service correct?  Well, I'm changing
> that! :)  How you implemented CORS support for the Account Service is
> not how web-origins were intended to be used.
>
> Tokens are created for a specific client (app or oauth).  The
> web-origins for that issuedFor client are stuffed into the token created
> specifically for that client.  Basically, its saying this token is
> allowed to come from this set of origins.
>
> What Web-Origins are not origin permissions for that application/client.
>    When you specify a web origin for the Account Service (or any other
> application) in the admin console, this is not origins that are allowed
> to call the account service!  But instead, the origins allowed for token
> requests made from tokens created for the Account Service.  Am I making
> sense?
>

Ugh, let me reword last paragraph:

Web-origin setting is not a set of origin permissions for an 
applicatin/client.  For example, the account service's web-origin 
setting is not the origins that are allowed to call the account service! 
  Tokens are always created for a specific client (issuedFor).  The 
client's web origin setting is just information that is stuffed into the 
token when it is created.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue May 20 10:22:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 10:22:04 -0400 (EDT)
Subject: [keycloak-dev] cors setup simplification?
In-Reply-To: <537B648C.1050901@redhat.com>
References: <537B5455.1060009@redhat.com>
	<1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>
	<537B61B8.1030705@redhat.com> <537B648C.1050901@redhat.com>
Message-ID: <765855348.10972412.1400595724808.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 3:19:56 PM
> Subject: Re: [keycloak-dev] cors setup simplification?
> 
> 
> 
> On 5/20/2014 10:07 AM, Bill Burke wrote:
> >
> >
> > On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
> >> I like the idea of not having to specify the web-origins, but I wonder if
> >> there are use-cases for having web-origins that can't be calculated from
> >> the redirect-uris.
> >>
> >
> > I just can't see a case for this.  Let's just let users tell us we need
> > this control.  Right now, the web origin is always set to the
> > protocol://hostname of the application or oauth client.
> >
> >> Also, the web-origins is used by Keycloak's own endpoints. In this case
> >> "Cross-Origin Tokens" doesn't make sense.
> >>
> >
> > You're talking about the Account Service correct?  Well, I'm changing
> > that! :)  How you implemented CORS support for the Account Service is
> > not how web-origins were intended to be used.
> >
> > Tokens are created for a specific client (app or oauth).  The
> > web-origins for that issuedFor client are stuffed into the token created
> > specifically for that client.  Basically, its saying this token is
> > allowed to come from this set of origins.
> >
> > What Web-Origins are not origin permissions for that application/client.
> >    When you specify a web origin for the Account Service (or any other
> > application) in the admin console, this is not origins that are allowed
> > to call the account service!  But instead, the origins allowed for token
> > requests made from tokens created for the Account Service.  Am I making
> > sense?
> >
> 
> Ugh, let me reword last paragraph:
> 
> Web-origin setting is not a set of origin permissions for an
> applicatin/client.  For example, the account service's web-origin
> setting is not the origins that are allowed to call the account service!
>   Tokens are always created for a specific client (issuedFor).  The
> client's web origin setting is just information that is stuffed into the
> token when it is created.

The account service does use the clients web-origins atm, it just pulls it from the ClientModel instead of the token, or at least that was the intent ;)

> 
> --
> 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
> 

From Anil.Saldhana at redhat.com  Tue May 20 10:28:08 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 20 May 2014 09:28:08 -0500
Subject: [keycloak-dev] LiveOak and JavaEE libraries
In-Reply-To: <53761ABB.5090009@redhat.com>
References: <53753DE9.6060606@redhat.com>	<1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>	<5375C69D.2090508@redhat.com>	<53760340.1030008@redhat.com>	<537608D7.2030504@redhat.com>
	<53760DDA.1030204@redhat.com>	<53761608.2030601@redhat.com>
	<53761ABB.5090009@redhat.com>
Message-ID: <537B6678.1000509@redhat.com>

On 05/16/2014 09:03 AM, Stan Silvert wrote:
> On 5/16/2014 9:43 AM, Bill Burke wrote:
>> On 5/16/2014 9:08 AM, Stan Silvert wrote:
>>> On 5/16/2014 8:47 AM, Bill Burke wrote:
>>>> On 5/16/2014 8:23 AM, Stan Silvert wrote:
>>>>> On 5/16/2014 4:04 AM, Boles?aw Dawidowicz wrote:
>>>>>> Yes, the intention is that LiveOak doesn't require JEE container. We
>>>>>> started with pure netty container. Currently we deploy on WildFly for
>>>>>> several reasons, also because of KeyCloak. However we want to start
>>>>>> stripping it down as soon as WildFly Core is available.
>>>>> I'm working on "Keycloak without servlets" right now.  The goal is to be
>>>>> able to use Keycloak for the EAP console where servlets are verboten.
>>>>> So far so good.
>>>>>
>>>>> But it begs the question, "Since the Servlet API is mostly just a facade
>>>>> on top of the Undertow API, why do we care if Keycloak is using the
>>>>> Servlet API?"
>>>> There's two places we use the servlet API.  In KeycloakApplication and
>>>> in CookieHelper.  The former is to get the context path of the
>>>> deployment, the latter is because JAX-RS 1.1 API (required because of
>>>> EAP 6.x) doesn't support HttpOnly Cookies.
>>>>
>>>>
>>> Also, I see that UndertowUserSessionManagement is using the servlet's
>>> HttpSession class.  But it probably should be using Undertow's Session
>>> class instead.
>>>
>>> My main point was to ask Boleslaw why it matters.  I think the technical
>>> arguments against using the Servlet API have gotten much weaker.
>> I haven't implemented a pure Undertow adapter yet.
>>
> I'm hacking on one right now, but I'm questioning if it will every
> really be needed.
In a REST world, I think a pure http driven approach is better compared 
to relying on the servlet api. You see a lot of applications just 
migrating to Netty based handlers rather than web applications. So what 
you are trying to do: pure undertow adapter may be quite useful.

You can still use the web application/servlet API for Administration.  
But for your REST endpoints, I would go with Undertow + REST framework 
or Netty+REST.





From bburke at redhat.com  Tue May 20 10:31:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 May 2014 10:31:47 -0400
Subject: [keycloak-dev] cors setup simplification?
In-Reply-To: <1274305422.10970438.1400595542067.JavaMail.zimbra@redhat.com>
References: <537B5455.1060009@redhat.com>
	<1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>
	<537B61B8.1030705@redhat.com>
	<1274305422.10970438.1400595542067.JavaMail.zimbra@redhat.com>
Message-ID: <537B6753.1080208@redhat.com>



On 5/20/2014 10:19 AM, 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: Tuesday, 20 May, 2014 3:07:52 PM
>> Subject: Re: [keycloak-dev] cors setup simplification?
>>
>>
>>
>> On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
>>> I like the idea of not having to specify the web-origins, but I wonder if
>>> there are use-cases for having web-origins that can't be calculated from
>>> the redirect-uris.
>>>
>>
>> I just can't see a case for this.  Let's just let users tell us we need
>> this control.  Right now, the web origin is always set to the
>> protocol://hostname of the application or oauth client.
>>
>>> Also, the web-origins is used by Keycloak's own endpoints. In this case
>>> "Cross-Origin Tokens" doesn't make sense.
>>>
>>
>> You're talking about the Account Service correct?  Well, I'm changing
>> that! :)  How you implemented CORS support for the Account Service is
>> not how web-origins were intended to be used.
>>
>> Tokens are created for a specific client (app or oauth).  The
>> web-origins for that issuedFor client are stuffed into the token created
>> specifically for that client.  Basically, its saying this token is
>> allowed to come from this set of origins.
>>
>> What Web-Origins are not origin permissions for that application/client.
>>    When you specify a web origin for the Account Service (or any other
>> application) in the admin console, this is not origins that are allowed
>> to call the account service!  But instead, the origins allowed for token
>> requests made from tokens created for the Account Service.  Am I making
>> sense?
>
> Yep, it makes more sense for the account service that way. I was thinking about token service though, both code->token and refresh-token are called from JS and need web-origins configured on them.
>

All the token service is doing is verifying that a code->token 
refresh-token request for that client is coming from the configured 
origin of that client.

Ah, I think I have a better explanation. The Web-Origin setting for an 
application is just the Origin of the application.  Nothing else.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue May 20 10:34:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 10:34:17 -0400 (EDT)
Subject: [keycloak-dev] cors setup simplification?
In-Reply-To: <537B6753.1080208@redhat.com>
References: <537B5455.1060009@redhat.com>
	<1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>
	<537B61B8.1030705@redhat.com>
	<1274305422.10970438.1400595542067.JavaMail.zimbra@redhat.com>
	<537B6753.1080208@redhat.com>
Message-ID: <452721572.10981737.1400596457262.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 3:31:47 PM
> Subject: Re: [keycloak-dev] cors setup simplification?
> 
> 
> 
> On 5/20/2014 10:19 AM, 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: Tuesday, 20 May, 2014 3:07:52 PM
> >> Subject: Re: [keycloak-dev] cors setup simplification?
> >>
> >>
> >>
> >> On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
> >>> I like the idea of not having to specify the web-origins, but I wonder if
> >>> there are use-cases for having web-origins that can't be calculated from
> >>> the redirect-uris.
> >>>
> >>
> >> I just can't see a case for this.  Let's just let users tell us we need
> >> this control.  Right now, the web origin is always set to the
> >> protocol://hostname of the application or oauth client.
> >>
> >>> Also, the web-origins is used by Keycloak's own endpoints. In this case
> >>> "Cross-Origin Tokens" doesn't make sense.
> >>>
> >>
> >> You're talking about the Account Service correct?  Well, I'm changing
> >> that! :)  How you implemented CORS support for the Account Service is
> >> not how web-origins were intended to be used.
> >>
> >> Tokens are created for a specific client (app or oauth).  The
> >> web-origins for that issuedFor client are stuffed into the token created
> >> specifically for that client.  Basically, its saying this token is
> >> allowed to come from this set of origins.
> >>
> >> What Web-Origins are not origin permissions for that application/client.
> >>    When you specify a web origin for the Account Service (or any other
> >> application) in the admin console, this is not origins that are allowed
> >> to call the account service!  But instead, the origins allowed for token
> >> requests made from tokens created for the Account Service.  Am I making
> >> sense?
> >
> > Yep, it makes more sense for the account service that way. I was thinking
> > about token service though, both code->token and refresh-token are called
> > from JS and need web-origins configured on them.
> >
> 
> All the token service is doing is verifying that a code->token
> refresh-token request for that client is coming from the configured
> origin of that client.
> 
> Ah, I think I have a better explanation. The Web-Origin setting for an
> application is just the Origin of the application.  Nothing else.

The origin of the application making the request right? 

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Tue May 20 11:10:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 11:10:02 -0400 (EDT)
Subject: [keycloak-dev] Email notifications on events and filtering of
	persisted events
In-Reply-To: <1888531772.11098991.1400598126141.JavaMail.zimbra@redhat.com>
Message-ID: <430339465.11155957.1400598602191.JavaMail.zimbra@redhat.com>

I've added an audit listener that can send emails on events. By default it once enabled as an audit listener for a realm it will send emails on these events:

* Login error
* Update password
* Remove totp
* Update totp

It will only send events if a user has a verified email address. This is more aimed as a template for someone that wants to implement their own, as we don't have the time needed to do this properly at the moment. Especially with regards to failed login attempts, as it is a bit silly to send an email after a single failed login attempt.

Also, it's possible to configure include/exclude events in keycloak-server.json, for example:

    "audit-listener": {
        "email": {
            "include": [ "update_password" ]
        }
    }

It's also possible to configure include/exclude events that are persisted (and hence visible in the admin console) through keycloak-server.json as well:

    "audit": {
        "provider": "jpa",
        "jpa": {
            "exclude-events": [ "REFRESH_TOKEN" ]
        }
    },

Configuring include/exclude for these providers are currently limited to a server-wide config. After the 1.0 release I'd like to add a configuration mechanism for providers on a realm level, so we can configure these things without having to constantly add things to RealmModel. I'll send a separate email on this soon.

From stian at redhat.com  Tue May 20 11:17:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 11:17:27 -0400 (EDT)
Subject: [keycloak-dev] Provider config framework
In-Reply-To: <1419256222.11177963.1400598744619.JavaMail.zimbra@redhat.com>
Message-ID: <981083298.11211974.1400599047051.JavaMail.zimbra@redhat.com>

Once 1.0.final is released I'd like to work on adding a generic mechanism to configure SPI providers to keycloak-server.json, the model, and admin console.

The basic idea is to have a "providers" section on the admin console. There will be a drop-down to select the SPI you want to configure (audit, social, email, etc.). Once you've selected the SPI it will be possible to select what providers are active, and to be able to configure individual providers. Some SPIs/providers will let you specify a global configuration for the server, others a config for a realm, and maybe also a combination.

Then we should add a ProvideConfigModel to the model, which will replace a fair amount of stuff on RealmModel, such as smtp-settings and social-settings.

The benefits includes:

* Ability to config custom providers through console
* Simplified model / less crap on RealmModel
* Global provider config with realm override

From bburke at redhat.com  Tue May 20 11:32:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 May 2014 11:32:06 -0400
Subject: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
Message-ID: <537B7576.5030307@redhat.com>

If the client has a redirect uri of urn:ietf:wg:oauth:2.0:oob, this is 
always acceptable?

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue May 20 11:33:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 May 2014 11:33:28 -0400
Subject: [keycloak-dev] cors setup simplification?
In-Reply-To: <452721572.10981737.1400596457262.JavaMail.zimbra@redhat.com>
References: <537B5455.1060009@redhat.com>
	<1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>
	<537B61B8.1030705@redhat.com>
	<1274305422.10970438.1400595542067.JavaMail.zimbra@redhat.com>
	<537B6753.1080208@redhat.com>
	<452721572.10981737.1400596457262.JavaMail.zimbra@redhat.com>
Message-ID: <537B75C8.50100@redhat.com>



On 5/20/2014 10:34 AM, 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: Tuesday, 20 May, 2014 3:31:47 PM
>> Subject: Re: [keycloak-dev] cors setup simplification?
>>
>>
>>
>> On 5/20/2014 10:19 AM, 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: Tuesday, 20 May, 2014 3:07:52 PM
>>>> Subject: Re: [keycloak-dev] cors setup simplification?
>>>>
>>>>
>>>>
>>>> On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
>>>>> I like the idea of not having to specify the web-origins, but I wonder if
>>>>> there are use-cases for having web-origins that can't be calculated from
>>>>> the redirect-uris.
>>>>>
>>>>
>>>> I just can't see a case for this.  Let's just let users tell us we need
>>>> this control.  Right now, the web origin is always set to the
>>>> protocol://hostname of the application or oauth client.
>>>>
>>>>> Also, the web-origins is used by Keycloak's own endpoints. In this case
>>>>> "Cross-Origin Tokens" doesn't make sense.
>>>>>
>>>>
>>>> You're talking about the Account Service correct?  Well, I'm changing
>>>> that! :)  How you implemented CORS support for the Account Service is
>>>> not how web-origins were intended to be used.
>>>>
>>>> Tokens are created for a specific client (app or oauth).  The
>>>> web-origins for that issuedFor client are stuffed into the token created
>>>> specifically for that client.  Basically, its saying this token is
>>>> allowed to come from this set of origins.
>>>>
>>>> What Web-Origins are not origin permissions for that application/client.
>>>>     When you specify a web origin for the Account Service (or any other
>>>> application) in the admin console, this is not origins that are allowed
>>>> to call the account service!  But instead, the origins allowed for token
>>>> requests made from tokens created for the Account Service.  Am I making
>>>> sense?
>>>
>>> Yep, it makes more sense for the account service that way. I was thinking
>>> about token service though, both code->token and refresh-token are called
>>> from JS and need web-origins configured on them.
>>>
>>
>> All the token service is doing is verifying that a code->token
>> refresh-token request for that client is coming from the configured
>> origin of that client.
>>
>> Ah, I think I have a better explanation. The Web-Origin setting for an
>> application is just the Origin of the application.  Nothing else.
>
> The origin of the application making the request right?
>

Nothing to do with the request.  It is just the origin of the application.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From gcardoso at redhat.com  Tue May 20 11:33:37 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Tue, 20 May 2014 12:33:37 -0300
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <1927459791.10461510.1400527734997.JavaMail.zimbra@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5377AB88.9020704@redhat.com>
	<1086948787.9705386.1400487900986.JavaMail.zimbra@redhat.com>
	<5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>
	<239798468.10192628.1400513419346.JavaMail.zimbra@redhat.com>
	<B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>
	<1927459791.10461510.1400527734997.JavaMail.zimbra@redhat.com>
Message-ID: <3367E77C-B619-4EBB-B9F6-7A5C3AA57800@redhat.com>

> From the technical point of view I don't like the idea of adding a special case that lets you set the admin password. Not just because of the additional work, but also as it adds a possible security hole. There are also situations where someone may set a more secure admin password on an initial installation prior to handing over to an admin, in which case there will be a password set, but the admin will be required to set the password. What we have covers both those use cases, as well as the use cases for when a password is required to be changed (suspected attack, expired password, etc).
> 
> On the other side, with regards to usability, I believe any user or admin of Keycloak are likely to experience the "update password" page, and may so several times while using Keycloak. This page will be displayed after the user has logged in with username/password (and optionally totp). I agree that this can be confusing, especially as it has the exact same layout as the login screen and only text changes. If we can find a solution to making this page more obvious to users that would also sufficiently solve the first login case in my opinion.

Ok, we can keep the current flow :)

> By the way the last attachment doesn't work as the screen should be displayed after the user has logged in, and hence not require the user to enter a username.

So, when the user is asked to update his password, is he already logged in? It doesn't feel like that at all. The feeling is that you need to update the password to log in. To update the password is mandatory at that point, isn?t it? I mean, without doing so, the user cannot ?explore? the console, right?

Regarding my screen, if the matter is the text ?To have access to the console??, we can easily change it. Maybe it is hard to recognise that, but the ?username? field is already fulfilled with admin, which is a disabled field. So the autofocus would be in ?New password? and the user wouldn?t need to enter the username.

Despite your punctual appointments, don?t you think a screen like that would improve what we have? I included the text above and the field ?username? for this screen to be visible different from the login screen.

Gabriel

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140520/8ef4f532/attachment.html 

From ssilvert at redhat.com  Tue May 20 11:34:11 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 20 May 2014 11:34:11 -0400
Subject: [keycloak-dev] LiveOak and JavaEE libraries
In-Reply-To: <537B6678.1000509@redhat.com>
References: <53753DE9.6060606@redhat.com>	<1226978259.8712319.1400226115133.JavaMail.zimbra@redhat.com>	<5375C69D.2090508@redhat.com>	<53760340.1030008@redhat.com>	<537608D7.2030504@redhat.com>
	<53760DDA.1030204@redhat.com>	<53761608.2030601@redhat.com>
	<53761ABB.5090009@redhat.com> <537B6678.1000509@redhat.com>
Message-ID: <537B75F3.5050703@redhat.com>

On 5/20/2014 10:28 AM, Anil Saldhana wrote:
> On 05/16/2014 09:03 AM, Stan Silvert wrote:
>> On 5/16/2014 9:43 AM, Bill Burke wrote:
>>> On 5/16/2014 9:08 AM, Stan Silvert wrote:
>>>> On 5/16/2014 8:47 AM, Bill Burke wrote:
>>>>> On 5/16/2014 8:23 AM, Stan Silvert wrote:
>>>>>> On 5/16/2014 4:04 AM, Boles?aw Dawidowicz wrote:
>>>>>>> Yes, the intention is that LiveOak doesn't require JEE container. We
>>>>>>> started with pure netty container. Currently we deploy on WildFly for
>>>>>>> several reasons, also because of KeyCloak. However we want to start
>>>>>>> stripping it down as soon as WildFly Core is available.
>>>>>> I'm working on "Keycloak without servlets" right now.  The goal is to be
>>>>>> able to use Keycloak for the EAP console where servlets are verboten.
>>>>>> So far so good.
>>>>>>
>>>>>> But it begs the question, "Since the Servlet API is mostly just a facade
>>>>>> on top of the Undertow API, why do we care if Keycloak is using the
>>>>>> Servlet API?"
>>>>> There's two places we use the servlet API.  In KeycloakApplication and
>>>>> in CookieHelper.  The former is to get the context path of the
>>>>> deployment, the latter is because JAX-RS 1.1 API (required because of
>>>>> EAP 6.x) doesn't support HttpOnly Cookies.
>>>>>
>>>>>
>>>> Also, I see that UndertowUserSessionManagement is using the servlet's
>>>> HttpSession class.  But it probably should be using Undertow's Session
>>>> class instead.
>>>>
>>>> My main point was to ask Boleslaw why it matters.  I think the technical
>>>> arguments against using the Servlet API have gotten much weaker.
>>> I haven't implemented a pure Undertow adapter yet.
>>>
>> I'm hacking on one right now, but I'm questioning if it will every
>> really be needed.
> In a REST world, I think a pure http driven approach is better compared
> to relying on the servlet api. You see a lot of applications just
> migrating to Netty based handlers rather than web applications. So what
> you are trying to do: pure undertow adapter may be quite useful.
>
> You can still use the web application/servlet API for Administration.
> But for your REST endpoints, I would go with Undertow + REST framework
> or Netty+REST.
I do want to set expectations here.  What I am doing now is just a POC 
showing the EAP console using Keycloak.  Since this app is not deployed 
as a WAR I can not use the servlet API.  So right now I'm just filling 
in the gaps to make this work in pure Undertow.

It will be awhile before this gets refactored into a pure Undertow 
adapter.  At that point I'll need some oversight from Bill to make sure 
I'm doing it right.
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Tue May 20 11:39:57 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 11:39:57 -0400 (EDT)
Subject: [keycloak-dev] cors setup simplification?
In-Reply-To: <537B75C8.50100@redhat.com>
References: <537B5455.1060009@redhat.com>
	<1514768493.10919729.1400592828073.JavaMail.zimbra@redhat.com>
	<537B61B8.1030705@redhat.com>
	<1274305422.10970438.1400595542067.JavaMail.zimbra@redhat.com>
	<537B6753.1080208@redhat.com>
	<452721572.10981737.1400596457262.JavaMail.zimbra@redhat.com>
	<537B75C8.50100@redhat.com>
Message-ID: <892618789.11273284.1400600397770.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 4:33:28 PM
> Subject: Re: [keycloak-dev] cors setup simplification?
> 
> 
> 
> On 5/20/2014 10:34 AM, 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: Tuesday, 20 May, 2014 3:31:47 PM
> >> Subject: Re: [keycloak-dev] cors setup simplification?
> >>
> >>
> >>
> >> On 5/20/2014 10:19 AM, 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: Tuesday, 20 May, 2014 3:07:52 PM
> >>>> Subject: Re: [keycloak-dev] cors setup simplification?
> >>>>
> >>>>
> >>>>
> >>>> On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
> >>>>> I like the idea of not having to specify the web-origins, but I wonder
> >>>>> if
> >>>>> there are use-cases for having web-origins that can't be calculated
> >>>>> from
> >>>>> the redirect-uris.
> >>>>>
> >>>>
> >>>> I just can't see a case for this.  Let's just let users tell us we need
> >>>> this control.  Right now, the web origin is always set to the
> >>>> protocol://hostname of the application or oauth client.
> >>>>
> >>>>> Also, the web-origins is used by Keycloak's own endpoints. In this case
> >>>>> "Cross-Origin Tokens" doesn't make sense.
> >>>>>
> >>>>
> >>>> You're talking about the Account Service correct?  Well, I'm changing
> >>>> that! :)  How you implemented CORS support for the Account Service is
> >>>> not how web-origins were intended to be used.
> >>>>
> >>>> Tokens are created for a specific client (app or oauth).  The
> >>>> web-origins for that issuedFor client are stuffed into the token created
> >>>> specifically for that client.  Basically, its saying this token is
> >>>> allowed to come from this set of origins.
> >>>>
> >>>> What Web-Origins are not origin permissions for that application/client.
> >>>>     When you specify a web origin for the Account Service (or any other
> >>>> application) in the admin console, this is not origins that are allowed
> >>>> to call the account service!  But instead, the origins allowed for token
> >>>> requests made from tokens created for the Account Service.  Am I making
> >>>> sense?
> >>>
> >>> Yep, it makes more sense for the account service that way. I was thinking
> >>> about token service though, both code->token and refresh-token are called
> >>> from JS and need web-origins configured on them.
> >>>
> >>
> >> All the token service is doing is verifying that a code->token
> >> refresh-token request for that client is coming from the configured
> >> origin of that client.
> >>
> >> Ah, I think I have a better explanation. The Web-Origin setting for an
> >> application is just the Origin of the application.  Nothing else.
> >
> > The origin of the application making the request right?
> >
> 
> Nothing to do with the request.  It is just the origin of the application.

By application making the request I meant the JS application/client (the public application), which is the application that will be making the request correct?


> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Tue May 20 11:44:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 11:44:00 -0400 (EDT)
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <3367E77C-B619-4EBB-B9F6-7A5C3AA57800@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5377AB88.9020704@redhat.com>
	<1086948787.9705386.1400487900986.JavaMail.zimbra@redhat.com>
	<5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>
	<239798468.10192628.1400513419346.JavaMail.zimbra@redhat.com>
	<B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>
	<1927459791.10461510.1400527734997.JavaMail.zimbra@redhat.com>
	<3367E77C-B619-4EBB-B9F6-7A5C3AA57800@redhat.com>
Message-ID: <482393518.11278241.1400600640160.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 4:33:37 PM
> Subject: Re: [keycloak-dev] Issues with the first login flow
> 
> > From the technical point of view I don't like the idea of adding a special
> > case that lets you set the admin password. Not just because of the
> > additional work, but also as it adds a possible security hole. There are
> > also situations where someone may set a more secure admin password on an
> > initial installation prior to handing over to an admin, in which case
> > there will be a password set, but the admin will be required to set the
> > password. What we have covers both those use cases, as well as the use
> > cases for when a password is required to be changed (suspected attack,
> > expired password, etc).
> > 
> > On the other side, with regards to usability, I believe any user or admin
> > of Keycloak are likely to experience the "update password" page, and may
> > so several times while using Keycloak. This page will be displayed after
> > the user has logged in with username/password (and optionally totp). I
> > agree that this can be confusing, especially as it has the exact same
> > layout as the login screen and only text changes. If we can find a
> > solution to making this page more obvious to users that would also
> > sufficiently solve the first login case in my opinion.
> 
> Ok, we can keep the current flow :)
> 
> > By the way the last attachment doesn't work as the screen should be
> > displayed after the user has logged in, and hence not require the user to
> > enter a username.
> 
> So, when the user is asked to update his password, is he already logged in?
> It doesn't feel like that at all. The feeling is that you need to update the
> password to log in. To update the password is mandatory at that point, isn?t
> it? I mean, without doing so, the user cannot ?explore? the console, right?

He's not logged-in, those are actions that the user are required to do prior to be logged-in. The user will however have to identify himself with username/password (and totp if configured) prior to being permitted to do those actions. The actions a user can be asked to do as part of a login is not just limited to updating the password. These can include:

* Configure TOTO
* Update password
* Verify email
* Update profile

And, possible more to come in the future.


> 
> Regarding my screen, if the matter is the text ?To have access to the
> console??, we can easily change it. Maybe it is hard to recognise that, but
> the ?username? field is already fulfilled with admin, which is a disabled
> field. So the autofocus would be in ?New password? and the user wouldn?t
> need to enter the username.
> 
> Despite your punctual appointments, don?t you think a screen like that would
> improve what we have? I included the text above and the field ?username? for
> this screen to be visible different from the login screen.

Text above we already have in a notification thing, but I don't have a problem with moving that above the form. The username input field doesn't make sense at all, as the user is not able to change that at this stage.

> 
> Gabriel
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 


From stian at redhat.com  Tue May 20 11:51:25 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 11:51:25 -0400 (EDT)
Subject: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
In-Reply-To: <537B7576.5030307@redhat.com>
References: <537B7576.5030307@redhat.com>
Message-ID: <1732028648.11284115.1400601085634.JavaMail.zimbra@redhat.com>

Not sure what you mean, but if you're asking if a login request can have '..?redirect_uri=urn:ietf:wg:oauth:2.0:oob' without 'urn:ietf:wg:oauth:2.0:oob' listed as a valid redirect_uri on the application/client, then no.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 4:32:06 PM
> Subject: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
> 
> If the client has a redirect uri of urn:ietf:wg:oauth:2.0:oob, this is
> always acceptable?
> 
> --
> 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
> 

From corinnekrych at gmail.com  Tue May 20 11:54:12 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 20 May 2014 17:54:12 +0200
Subject: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
In-Reply-To: <1732028648.11284115.1400601085634.JavaMail.zimbra@redhat.com>
References: <537B7576.5030307@redhat.com>
	<1732028648.11284115.1400601085634.JavaMail.zimbra@redhat.com>
Message-ID: <12D385DF-5994-4541-835B-B8F1B127C75B@gmail.com>

>From what i?ve seen with oob uri seems to be mainly used by Google.
Facebook will use a redirect_uri which looks like fb<appId>://authorize/

Not sure there is a standard way of expressing out of bound uri.

++
Corinne

On 20 May 2014, at 17:51, Stian Thorgersen <stian at redhat.com> wrote:

> Not sure what you mean, but if you're asking if a login request can have '..?redirect_uri=urn:ietf:wg:oauth:2.0:oob' without 'urn:ietf:wg:oauth:2.0:oob' listed as a valid redirect_uri on the application/client, then no.
> 
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 20 May, 2014 4:32:06 PM
>> Subject: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
>> 
>> If the client has a redirect uri of urn:ietf:wg:oauth:2.0:oob, this is
>> always acceptable?
>> 
>> --
>> 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
>> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From stian at redhat.com  Tue May 20 12:15:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 May 2014 12:15:45 -0400 (EDT)
Subject: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
In-Reply-To: <12D385DF-5994-4541-835B-B8F1B127C75B@gmail.com>
References: <537B7576.5030307@redhat.com>
	<1732028648.11284115.1400601085634.JavaMail.zimbra@redhat.com>
	<12D385DF-5994-4541-835B-B8F1B127C75B@gmail.com>
Message-ID: <358823324.11299752.1400602545925.JavaMail.zimbra@redhat.com>

It's not in the RFC, but there's a few other oauth2 implementations that uses it, and it doesn't have any reference to Google directly, so seems good to me.

----- Original Message -----
> From: "Corinne Krych" <corinnekrych at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Cc: "Bill Burke" <bburke at redhat.com>
> Sent: Tuesday, 20 May, 2014 4:54:12 PM
> Subject: Re: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
> 
> From what i?ve seen with oob uri seems to be mainly used by Google.
> Facebook will use a redirect_uri which looks like fb<appId>://authorize/
> 
> Not sure there is a standard way of expressing out of bound uri.
> 
> ++
> Corinne
> 
> On 20 May 2014, at 17:51, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > Not sure what you mean, but if you're asking if a login request can have
> > '..?redirect_uri=urn:ietf:wg:oauth:2.0:oob' without
> > 'urn:ietf:wg:oauth:2.0:oob' listed as a valid redirect_uri on the
> > application/client, then no.
> > 
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 20 May, 2014 4:32:06 PM
> >> Subject: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
> >> 
> >> If the client has a redirect uri of urn:ietf:wg:oauth:2.0:oob, this is
> >> always acceptable?
> >> 
> >> --
> >> 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
> >> 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 


From bruno at abstractj.org  Tue May 20 13:03:08 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 20 May 2014 14:03:08 -0300
Subject: [keycloak-dev] Provider config framework
In-Reply-To: <981083298.11211974.1400599047051.JavaMail.zimbra@redhat.com>
References: <1419256222.11177963.1400598744619.JavaMail.zimbra@redhat.com>
	<981083298.11211974.1400599047051.JavaMail.zimbra@redhat.com>
Message-ID: <20140520170308.GA62455@abstractj.org>

Nice!

On 2014-05-20, Stian Thorgersen wrote:
> Once 1.0.final is released I'd like to work on adding a generic mechanism to configure SPI providers to keycloak-server.json, the model, and admin console.
>
> The basic idea is to have a "providers" section on the admin console. There will be a drop-down to select the SPI you want to configure (audit, social, email, etc.). Once you've selected the SPI it will be possible to select what providers are active, and to be able to configure individual providers. Some SPIs/providers will let you specify a global configuration for the server, others a config for a realm, and maybe also a combination.
>
> Then we should add a ProvideConfigModel to the model, which will replace a fair amount of stuff on RealmModel, such as smtp-settings and social-settings.
>
> The benefits includes:
>
> * Ability to config custom providers through console
> * Simplified model / less crap on RealmModel
> * Global provider config with realm override
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From bburke at redhat.com  Tue May 20 13:18:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 May 2014 13:18:39 -0400
Subject: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
In-Reply-To: <1732028648.11284115.1400601085634.JavaMail.zimbra@redhat.com>
References: <537B7576.5030307@redhat.com>
	<1732028648.11284115.1400601085634.JavaMail.zimbra@redhat.com>
Message-ID: <537B8E6F.80701@redhat.com>

Ok, then I need to fix this.

On 5/20/2014 11:51 AM, Stian Thorgersen wrote:
> Not sure what you mean, but if you're asking if a login request can have '..?redirect_uri=urn:ietf:wg:oauth:2.0:oob' without 'urn:ietf:wg:oauth:2.0:oob' listed as a valid redirect_uri on the application/client, then no.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 20 May, 2014 4:32:06 PM
>> Subject: [keycloak-dev] urn:ietf:wg:oauth:2.0:oob always valid?
>>
>> If the client has a redirect uri of urn:ietf:wg:oauth:2.0:oob, this is
>> always acceptable?
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From gcardoso at redhat.com  Tue May 20 14:11:20 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Tue, 20 May 2014 15:11:20 -0300
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <482393518.11278241.1400600640160.JavaMail.zimbra@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5377AB88.9020704@redhat.com>
	<1086948787.9705386.1400487900986.JavaMail.zimbra@redhat.com>
	<5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>
	<239798468.10192628.1400513419346.JavaMail.zimbra@redhat.com>
	<B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>
	<1927459791.10461510.1400527734997.JavaMail.zimbra@redhat.com>
	<3367E77C-B619-4EBB-B9F6-7A5C3AA57800@redhat.com>
	<482393518.11278241.1400600640160.JavaMail.zimbra@redhat.com>
Message-ID: <CB39A37B-92A4-4AC2-A506-E5D7AD0BE9A6@redhat.com>

> He's not logged-in, those are actions that the user are required to do prior to be logged-in. The user will however have to identify himself with username/password (and totp if configured) prior to being permitted to do those actions. The actions a user can be asked to do as part of a login is not just limited to updating the password. These can include:
> 
> * Configure TOTO
> * Update password
> * Verify email
> * Update profile
> 
> And, possible more to come in the future.

Thanks for the clarification.

> Text above we already have in a notification thing, but I don't have a problem with moving that above the form. The username input field doesn't make sense at all, as the user is not able to change that at this stage.

Cool, so please put the text inside a <p class=?form-info?></p>.

The username field is to differentiate more this page from the login page (3 fields are different than 2 :) I don?t see it as a problem, it is informative and the user can?t change it (no danger). So now it is up to you.

Thanks,
Gabriel

> 
>> 
>> Gabriel
>> 
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140520/80d1ad8c/attachment.html 

From bburke at redhat.com  Tue May 20 14:25:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 May 2014 14:25:40 -0400
Subject: [keycloak-dev] redirect uri now required
Message-ID: <537B9E24.9080106@redhat.com>

Admin console requires a redirect uri to be set for non-bearer-only 
clients.  Token Service will now abort any login request where a client 
redirect uri hasn't been configured.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed May 21 03:37:35 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 21 May 2014 03:37:35 -0400 (EDT)
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <CB39A37B-92A4-4AC2-A506-E5D7AD0BE9A6@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>
	<239798468.10192628.1400513419346.JavaMail.zimbra@redhat.com>
	<B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>
	<1927459791.10461510.1400527734997.JavaMail.zimbra@redhat.com>
	<3367E77C-B619-4EBB-B9F6-7A5C3AA57800@redhat.com>
	<482393518.11278241.1400600640160.JavaMail.zimbra@redhat.com>
	<CB39A37B-92A4-4AC2-A506-E5D7AD0BE9A6@redhat.com>
Message-ID: <1484525279.11630291.1400657855821.JavaMail.zimbra@redhat.com>

I added it the way you said, and to me it doesn't stand out at all. How about moving the notification bubble we already have to be in-line with the form? That would also make all other notifications, such as invalid username/password stand out more as well. See attached screenshot for how that would look like.

Adding a disabled input field for username doesn't make sense at all to me. An input field is not informative, it's an input field and hence something users expect to fill in.

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 7:11:20 PM
> Subject: Re: [keycloak-dev] Issues with the first login flow
> 
> > He's not logged-in, those are actions that the user are required to do
> > prior to be logged-in. The user will however have to identify himself with
> > username/password (and totp if configured) prior to being permitted to do
> > those actions. The actions a user can be asked to do as part of a login is
> > not just limited to updating the password. These can include:
> > 
> > * Configure TOTO
> > * Update password
> > * Verify email
> > * Update profile
> > 
> > And, possible more to come in the future.
> 
> Thanks for the clarification.
> 
> > Text above we already have in a notification thing, but I don't have a
> > problem with moving that above the form. The username input field doesn't
> > make sense at all, as the user is not able to change that at this stage.
> 
> Cool, so please put the text inside a <p class=?form-info?></p>.
> 
> The username field is to differentiate more this page from the login page (3
> fields are different than 2 :) I don?t see it as a problem, it is
> informative and the user can?t change it (no danger). So now it is up to
> you.
> 
> Thanks,
> Gabriel
> 
> > 
> >> 
> >> Gabriel
> >> 
> >> ---
> >> Gabriel Cardoso
> >> User Experience Designer @ Red Hat
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: login-notification.png
Type: image/png
Size: 64234 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140521/5c29407f/attachment-0001.png 

From stian at redhat.com  Wed May 21 09:16:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 21 May 2014 09:16:34 -0400 (EDT)
Subject: [keycloak-dev] Some issues with admin console
In-Reply-To: <425567918.11844337.1400677918453.JavaMail.zimbra@redhat.com>
Message-ID: <863015875.11847160.1400678194335.JavaMail.zimbra@redhat.com>

I've spotted a few issues with the admin console:

Roles are retrieved directly from UserModel instead of token - this will cause it to bypass scope for app/client. https://issues.jboss.org/browse/KEYCLOAK-484

Once in a while the page is empty when opening the admin console - this is caused by WhoAmI request not being completed before the page is displayed. I think the solution to this is to remove WhoAmI and use information from the token instead. When a realm is created/deleted we should redirect to login page to retrieve a new token (this will be required for the above any ways). https://issues.jboss.org/browse/KEYCLOAK-482

I can look at fixing these tomorrow

From stian at redhat.com  Wed May 21 10:19:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 21 May 2014 10:19:32 -0400 (EDT)
Subject: [keycloak-dev] Distribution artifacts in Maven
In-Reply-To: <464722328.11905991.1400681478568.JavaMail.zimbra@redhat.com>
Message-ID: <1102130256.11912655.1400681972683.JavaMail.zimbra@redhat.com>

I'd like to add the server war and also the server dist to Maven:

* org.keycloak:keycloak-server:war
* org.keycloak:keycloak-dist:zip

Also I'd like to add an additional file to sourceforge:

* keycloak-<version>.zip

keycloak-dist and keycloak-<version>.zip would contain a single folder "keycloak-<version>" equivalent of WildFly dist.

From gcardoso at redhat.com  Wed May 21 10:46:05 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Wed, 21 May 2014 11:46:05 -0300
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <1484525279.11630291.1400657855821.JavaMail.zimbra@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<5BAD868F-BCA1-4756-AA87-6F982C347A87@redhat.com>
	<239798468.10192628.1400513419346.JavaMail.zimbra@redhat.com>
	<B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>
	<1927459791.10461510.1400527734997.JavaMail.zimbra@redhat.com>
	<3367E77C-B619-4EBB-B9F6-7A5C3AA57800@redhat.com>
	<482393518.11278241.1400600640160.JavaMail.zimbra@redhat.com>
	<CB39A37B-92A4-4AC2-A506-E5D7AD0BE9A6@redhat.com>
	<1484525279.11630291.1400657855821.JavaMail.zimbra@redhat.com>
Message-ID: <4F55DCE2-88E2-4897-B79B-5745E5BEB86C@redhat.com>

The problem I see is that people don?t read these messages. They assume that it is an error or something.

I think the text above (some different from a feedback message) is more effective, and the extra field (username) helps on the differentiation. It could be plain text instead of an input.

I don?t believe this solution will solve the problem.

Gabriel 


On May 21, 2014, at 4:37 AM, Stian Thorgersen <stian at redhat.com> wrote:

> I added it the way you said, and to me it doesn't stand out at all. How about moving the notification bubble we already have to be in-line with the form? That would also make all other notifications, such as invalid username/password stand out more as well. See attached screenshot for how that would look like.
> 
> Adding a disabled input field for username doesn't make sense at all to me. An input field is not informative, it's an input field and hence something users expect to fill in.
> 
> ----- Original Message -----
>> From: "Gabriel Cardoso" <gcardoso at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 20 May, 2014 7:11:20 PM
>> Subject: Re: [keycloak-dev] Issues with the first login flow
>> 
>>> He's not logged-in, those are actions that the user are required to do
>>> prior to be logged-in. The user will however have to identify himself with
>>> username/password (and totp if configured) prior to being permitted to do
>>> those actions. The actions a user can be asked to do as part of a login is
>>> not just limited to updating the password. These can include:
>>> 
>>> * Configure TOTO
>>> * Update password
>>> * Verify email
>>> * Update profile
>>> 
>>> And, possible more to come in the future.
>> 
>> Thanks for the clarification.
>> 
>>> Text above we already have in a notification thing, but I don't have a
>>> problem with moving that above the form. The username input field doesn't
>>> make sense at all, as the user is not able to change that at this stage.
>> 
>> Cool, so please put the text inside a <p class=?form-info?></p>.
>> 
>> The username field is to differentiate more this page from the login page (3
>> fields are different than 2 :) I don?t see it as a problem, it is
>> informative and the user can?t change it (no danger). So now it is up to
>> you.
>> 
>> Thanks,
>> Gabriel
>> 
>>> 
>>>> 
>>>> Gabriel
>>>> 
>>>> ---
>>>> Gabriel Cardoso
>>>> User Experience Designer @ Red Hat
>> 
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>> 
> <login-notification.png>

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140521/b8333836/attachment.html 

From stian at redhat.com  Wed May 21 11:00:07 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 21 May 2014 11:00:07 -0400 (EDT)
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <4F55DCE2-88E2-4897-B79B-5745E5BEB86C@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>
	<1927459791.10461510.1400527734997.JavaMail.zimbra@redhat.com>
	<3367E77C-B619-4EBB-B9F6-7A5C3AA57800@redhat.com>
	<482393518.11278241.1400600640160.JavaMail.zimbra@redhat.com>
	<CB39A37B-92A4-4AC2-A506-E5D7AD0BE9A6@redhat.com>
	<1484525279.11630291.1400657855821.JavaMail.zimbra@redhat.com>
	<4F55DCE2-88E2-4897-B79B-5745E5BEB86C@redhat.com>
Message-ID: <1964354804.11951459.1400684407192.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 21 May, 2014 3:46:05 PM
> Subject: Re: [keycloak-dev] Issues with the first login flow
> 
> The problem I see is that people don?t read these messages. They assume that
> it is an error or something.
> 
> I think the text above (some different from a feedback message) is more
> effective, and the extra field (username) helps on the differentiation. It
> could be plain text instead of an input.

That doesn't make sense to me - if folks are not going to read an error message, they are certainly not going to read plain text that doesn't stand out at all.

> 
> I don?t believe this solution will solve the problem.
> 
> Gabriel
> 
> 
> On May 21, 2014, at 4:37 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > I added it the way you said, and to me it doesn't stand out at all. How
> > about moving the notification bubble we already have to be in-line with
> > the form? That would also make all other notifications, such as invalid
> > username/password stand out more as well. See attached screenshot for how
> > that would look like.
> > 
> > Adding a disabled input field for username doesn't make sense at all to me.
> > An input field is not informative, it's an input field and hence something
> > users expect to fill in.
> > 
> > ----- Original Message -----
> >> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 20 May, 2014 7:11:20 PM
> >> Subject: Re: [keycloak-dev] Issues with the first login flow
> >> 
> >>> He's not logged-in, those are actions that the user are required to do
> >>> prior to be logged-in. The user will however have to identify himself
> >>> with
> >>> username/password (and totp if configured) prior to being permitted to do
> >>> those actions. The actions a user can be asked to do as part of a login
> >>> is
> >>> not just limited to updating the password. These can include:
> >>> 
> >>> * Configure TOTO
> >>> * Update password
> >>> * Verify email
> >>> * Update profile
> >>> 
> >>> And, possible more to come in the future.
> >> 
> >> Thanks for the clarification.
> >> 
> >>> Text above we already have in a notification thing, but I don't have a
> >>> problem with moving that above the form. The username input field doesn't
> >>> make sense at all, as the user is not able to change that at this stage.
> >> 
> >> Cool, so please put the text inside a <p class=?form-info?></p>.
> >> 
> >> The username field is to differentiate more this page from the login page
> >> (3
> >> fields are different than 2 :) I don?t see it as a problem, it is
> >> informative and the user can?t change it (no danger). So now it is up to
> >> you.
> >> 
> >> Thanks,
> >> Gabriel
> >> 
> >>> 
> >>>> 
> >>>> Gabriel
> >>>> 
> >>>> ---
> >>>> Gabriel Cardoso
> >>>> User Experience Designer @ Red Hat
> >> 
> >> ---
> >> Gabriel Cardoso
> >> User Experience Designer @ Red Hat
> >> 
> > <login-notification.png>
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
>


From bburke at redhat.com  Wed May 21 11:16:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 21 May 2014 11:16:05 -0400
Subject: [keycloak-dev] Some issues with admin console
In-Reply-To: <863015875.11847160.1400678194335.JavaMail.zimbra@redhat.com>
References: <863015875.11847160.1400678194335.JavaMail.zimbra@redhat.com>
Message-ID: <537CC335.2020306@redhat.com>



On 5/21/2014 9:16 AM, Stian Thorgersen wrote:
> I've spotted a few issues with the admin console:
>
> Roles are retrieved directly from UserModel instead of token - this will cause it to bypass scope for app/client. https://issues.jboss.org/browse/KEYCLOAK-484
>

I'll do this one as I'm already in the code.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From gcardoso at redhat.com  Wed May 21 11:38:53 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Wed, 21 May 2014 12:38:53 -0300
Subject: [keycloak-dev] Issues with the first login flow
In-Reply-To: <1964354804.11951459.1400684407192.JavaMail.zimbra@redhat.com>
References: <731EACE4-F933-4469-BC39-694AFBD0112D@redhat.com>
	<B1AAB0EC-DA12-43FF-A915-353D13AFA214@redhat.com>
	<1927459791.10461510.1400527734997.JavaMail.zimbra@redhat.com>
	<3367E77C-B619-4EBB-B9F6-7A5C3AA57800@redhat.com>
	<482393518.11278241.1400600640160.JavaMail.zimbra@redhat.com>
	<CB39A37B-92A4-4AC2-A506-E5D7AD0BE9A6@redhat.com>
	<1484525279.11630291.1400657855821.JavaMail.zimbra@redhat.com>
	<4F55DCE2-88E2-4897-B79B-5745E5BEB86C@redhat.com>
	<1964354804.11951459.1400684407192.JavaMail.zimbra@redhat.com>
Message-ID: <6C9AB89C-1270-4072-9A2A-75B764222641@redhat.com>


>> The problem I see is that people don?t read these messages. They assume that
>> it is an error or something.
>> 
>> I think the text above (some different from a feedback message) is more
>> effective, and the extra field (username) helps on the differentiation. It
>> could be plain text instead of an input.
> 
> That doesn't make sense to me - if folks are not going to read an error message, they are certainly not going to read plain text that doesn't stand out at all.

Well, if the screen changes a bit they will realise that it is not the same screen and will read something. However, if they think it is an error/feedback, they might try to log in again :)

I?ve already give my suggestion, now it?s up to you to decide.

Gabriel

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140521/4f45663c/attachment.html 

From bburke at redhat.com  Wed May 21 22:53:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 21 May 2014 22:53:21 -0400
Subject: [keycloak-dev] release next wed
Message-ID: <537D66A1.9040003@redhat.com>

I'd like for us to stop submitting more JIRAs for beta-1 unless they are 
blockers.  Try to have a code freeze by Mon-Tues and focus on 
documentation, then release Beta-1 on Wed or Thurs.

Please edit the Migration docs to reflect any changes that are 
incompatible with Alpha-4.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May 22 10:33:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 22 May 2014 10:33:59 -0400
Subject: [keycloak-dev] why doesnt import/expot use reps?
Message-ID: <537E0AD7.3010101@redhat.com>

We now have two different models for dealing with imports and two 
different code paths too.  Why does import/export have its own json 
model under model/api/...entities?  Why weren't the JSON representations 
in keycloak-core/.../representations used?

We already have code that converts between 
keycloak-core/...representations and Models that is updated and 
maintained.  We now have double the work to keep the export/import stuff 
in sync too!


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu May 22 11:26:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 22 May 2014 11:26:04 -0400 (EDT)
Subject: [keycloak-dev] why doesnt import/expot use reps?
In-Reply-To: <537E0AD7.3010101@redhat.com>
References: <537E0AD7.3010101@redhat.com>
Message-ID: <223974414.12812760.1400772364410.JavaMail.zimbra@redhat.com>

I agree it would be better to use one set of JSON representations - that would also mean that we can import the exported json through the admin console as well

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 22 May, 2014 3:33:59 PM
> Subject: [keycloak-dev] why doesnt import/expot use reps?
> 
> We now have two different models for dealing with imports and two
> different code paths too.  Why does import/export have its own json
> model under model/api/...entities?  Why weren't the JSON representations
> in keycloak-core/.../representations used?
> 
> We already have code that converts between
> keycloak-core/...representations and Models that is updated and
> maintained.  We now have double the work to keep the export/import stuff
> in sync too!
> 
> 
> --
> 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
> 

From stian at redhat.com  Thu May 22 12:27:37 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 22 May 2014 12:27:37 -0400 (EDT)
Subject: [keycloak-dev] release next wed
In-Reply-To: <537D66A1.9040003@redhat.com>
References: <537D66A1.9040003@redhat.com>
Message-ID: <1911164117.12864133.1400776057176.JavaMail.zimbra@redhat.com>

Sure, I'm doing some testing at the moment and I'm finding a few issues. In general it looks pretty good though, so Mon-Tue should be fine.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 22 May, 2014 3:53:21 AM
> Subject: [keycloak-dev] release next wed
> 
> I'd like for us to stop submitting more JIRAs for beta-1 unless they are
> blockers.  Try to have a code freeze by Mon-Tues and focus on
> documentation, then release Beta-1 on Wed or Thurs.
> 
> Please edit the Migration docs to reflect any changes that are
> incompatible with Alpha-4.
> 
> 
> --
> 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
> 

From stian at redhat.com  Fri May 23 06:05:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 May 2014 06:05:39 -0400 (EDT)
Subject: [keycloak-dev] Composite roles list on mapping page
In-Reply-To: <1514705021.13202271.1400838503381.JavaMail.zimbra@redhat.com>
Message-ID: <1270640853.13211157.1400839539357.JavaMail.zimbra@redhat.com>

I like the new "composite roles list" on the user role mapping, and app scope mapping pages. I did find the title a bit confusing though, maybe we could change "Composite roles" to "Effective roles"?

From ssilvert at redhat.com  Fri May 23 07:39:01 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 23 May 2014 07:39:01 -0400
Subject: [keycloak-dev] Composite roles list on mapping page
In-Reply-To: <1270640853.13211157.1400839539357.JavaMail.zimbra@redhat.com>
References: <1270640853.13211157.1400839539357.JavaMail.zimbra@redhat.com>
Message-ID: <537F3355.5040604@redhat.com>

On 5/23/2014 6:05 AM, Stian Thorgersen wrote:
> I like the new "composite roles list" on the user role mapping, and app scope mapping pages. I did find the title a bit confusing though, maybe we could change "Composite roles" to "Effective roles"?
If I understand correctly, the type of role is a composite role, but the 
read-only list box shows the effective roles.  If that is the case then 
I think you should indeed rename the list box, but only the list box.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri May 23 10:40:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 May 2014 10:40:49 -0400
Subject: [keycloak-dev] Composite roles list on mapping page
In-Reply-To: <1270640853.13211157.1400839539357.JavaMail.zimbra@redhat.com>
References: <1270640853.13211157.1400839539357.JavaMail.zimbra@redhat.com>
Message-ID: <537F5DF1.9020003@redhat.com>

Funny that the non-native speak has suggested a better name.  I couldn't 
think of a good one.

On 5/23/2014 6:05 AM, Stian Thorgersen wrote:
> I like the new "composite roles list" on the user role mapping, and app scope mapping pages. I did find the title a bit confusing though, maybe we could change "Composite roles" to "Effective roles"?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 23 10:44:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 May 2014 10:44:51 -0400 (EDT)
Subject: [keycloak-dev] Composite roles list on mapping page
In-Reply-To: <537F5DF1.9020003@redhat.com>
References: <1270640853.13211157.1400839539357.JavaMail.zimbra@redhat.com>
	<537F5DF1.9020003@redhat.com>
Message-ID: <278488504.13417258.1400856291348.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 23 May, 2014 3:40:49 PM
> Subject: Re: [keycloak-dev] Composite roles list on mapping page
> 
> Funny that the non-native speak has suggested a better name.  I couldn't
> think of a good one.

"the non-native speaker" you mean ;)

> 
> On 5/23/2014 6:05 AM, Stian Thorgersen wrote:
> > I like the new "composite roles list" on the user role mapping, and app
> > scope mapping pages. I did find the title a bit confusing though, maybe we
> > could change "Composite roles" to "Effective roles"?
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> 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
> 

From bburke at redhat.com  Fri May 23 10:46:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 May 2014 10:46:08 -0400
Subject: [keycloak-dev] FYI: can't use token to auth admin console
Message-ID: <537F5F30.20600@redhat.com>

Too much kid stuff lately!  Sorry I haven't been productive past 2 
days...But...

FYI: We can't use role mapping information in access token to authorize 
admin console access.  This is because users may be creating new realms 
which will update their role mappings on the fly with the new admin 
roles created for that new realm.

What will happen is that the client id will be extracted from token and 
authorization based on client scope and user role mappings will be done 
dynamically.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 23 10:48:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 May 2014 10:48:08 -0400 (EDT)
Subject: [keycloak-dev] FYI: can't use token to auth admin console
In-Reply-To: <537F5F30.20600@redhat.com>
References: <537F5F30.20600@redhat.com>
Message-ID: <999654602.13418962.1400856488880.JavaMail.zimbra@redhat.com>

Why not just do a window.reload(), which will redirect to login screen and get a new token with the new roles?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 23 May, 2014 3:46:08 PM
> Subject: [keycloak-dev] FYI: can't use token to auth admin console
> 
> Too much kid stuff lately!  Sorry I haven't been productive past 2
> days...But...
> 
> FYI: We can't use role mapping information in access token to authorize
> admin console access.  This is because users may be creating new realms
> which will update their role mappings on the fly with the new admin
> roles created for that new realm.
> 
> What will happen is that the client id will be extracted from token and
> authorization based on client scope and user role mappings will be done
> dynamically.
> 
> --
> 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
> 

From bburke at redhat.com  Fri May 23 10:51:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 May 2014 10:51:31 -0400
Subject: [keycloak-dev] FYI: can't use token to auth admin console
In-Reply-To: <999654602.13418962.1400856488880.JavaMail.zimbra@redhat.com>
References: <537F5F30.20600@redhat.com>
	<999654602.13418962.1400856488880.JavaMail.zimbra@redhat.com>
Message-ID: <537F6073.50402@redhat.com>

Our user-agent might not be a browser.

On 5/23/2014 10:48 AM, Stian Thorgersen wrote:
> Why not just do a window.reload(), which will redirect to login screen and get a new token with the new roles?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 23 May, 2014 3:46:08 PM
>> Subject: [keycloak-dev] FYI: can't use token to auth admin console
>>
>> Too much kid stuff lately!  Sorry I haven't been productive past 2
>> days...But...
>>
>> FYI: We can't use role mapping information in access token to authorize
>> admin console access.  This is because users may be creating new realms
>> which will update their role mappings on the fly with the new admin
>> roles created for that new realm.
>>
>> What will happen is that the client id will be extracted from token and
>> authorization based on client scope and user role mappings will be done
>> dynamically.
>>
>> --
>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 23 11:00:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 May 2014 11:00:52 -0400 (EDT)
Subject: [keycloak-dev] FYI: can't use token to auth admin console
In-Reply-To: <537F6073.50402@redhat.com>
References: <537F5F30.20600@redhat.com>
	<999654602.13418962.1400856488880.JavaMail.zimbra@redhat.com>
	<537F6073.50402@redhat.com>
Message-ID: <1981012656.13438297.1400857252199.JavaMail.zimbra@redhat.com>

What about clients? You're then giving additional permissions to a client that the user hasn't granted.

----- 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, 23 May, 2014 3:51:31 PM
> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
> 
> Our user-agent might not be a browser.
> 
> On 5/23/2014 10:48 AM, Stian Thorgersen wrote:
> > Why not just do a window.reload(), which will redirect to login screen and
> > get a new token with the new roles?
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 23 May, 2014 3:46:08 PM
> >> Subject: [keycloak-dev] FYI: can't use token to auth admin console
> >>
> >> Too much kid stuff lately!  Sorry I haven't been productive past 2
> >> days...But...
> >>
> >> FYI: We can't use role mapping information in access token to authorize
> >> admin console access.  This is because users may be creating new realms
> >> which will update their role mappings on the fly with the new admin
> >> roles created for that new realm.
> >>
> >> What will happen is that the client id will be extracted from token and
> >> authorization based on client scope and user role mappings will be done
> >> dynamically.
> >>
> >> --
> >> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri May 23 11:03:13 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 May 2014 11:03:13 -0400
Subject: [keycloak-dev] FYI: can't use token to auth admin console
In-Reply-To: <1981012656.13438297.1400857252199.JavaMail.zimbra@redhat.com>
References: <537F5F30.20600@redhat.com>
	<999654602.13418962.1400856488880.JavaMail.zimbra@redhat.com>
	<537F6073.50402@redhat.com>
	<1981012656.13438297.1400857252199.JavaMail.zimbra@redhat.com>
Message-ID: <537F6331.7020409@redhat.com>

I will do:

boolean authorized = realm.hasRole(user, role) && realm.hasScope(client, 
role);



On 5/23/2014 11:00 AM, Stian Thorgersen wrote:
> What about clients? You're then giving additional permissions to a client that the user hasn't granted.
>
> ----- 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, 23 May, 2014 3:51:31 PM
>> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
>>
>> Our user-agent might not be a browser.
>>
>> On 5/23/2014 10:48 AM, Stian Thorgersen wrote:
>>> Why not just do a window.reload(), which will redirect to login screen and
>>> get a new token with the new roles?
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 23 May, 2014 3:46:08 PM
>>>> Subject: [keycloak-dev] FYI: can't use token to auth admin console
>>>>
>>>> Too much kid stuff lately!  Sorry I haven't been productive past 2
>>>> days...But...
>>>>
>>>> FYI: We can't use role mapping information in access token to authorize
>>>> admin console access.  This is because users may be creating new realms
>>>> which will update their role mappings on the fly with the new admin
>>>> roles created for that new realm.
>>>>
>>>> What will happen is that the client id will be extracted from token and
>>>> authorization based on client scope and user role mappings will be done
>>>> dynamically.
>>>>
>>>> --
>>>> 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
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 23 11:09:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 May 2014 11:09:01 -0400 (EDT)
Subject: [keycloak-dev] FYI: can't use token to auth admin console
In-Reply-To: <537F6331.7020409@redhat.com>
References: <537F5F30.20600@redhat.com>
	<999654602.13418962.1400856488880.JavaMail.zimbra@redhat.com>
	<537F6073.50402@redhat.com>
	<1981012656.13438297.1400857252199.JavaMail.zimbra@redhat.com>
	<537F6331.7020409@redhat.com>
Message-ID: <1261846919.13445659.1400857741352.JavaMail.zimbra@redhat.com>

That still doesn't ask the user to give the client permissions though.

Maybe it should use the roles from the token for clients, but for applications the model as you propose?

----- 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, 23 May, 2014 4:03:13 PM
> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
> 
> I will do:
> 
> boolean authorized = realm.hasRole(user, role) && realm.hasScope(client,
> role);
> 
> 
> 
> On 5/23/2014 11:00 AM, Stian Thorgersen wrote:
> > What about clients? You're then giving additional permissions to a client
> > that the user hasn't granted.
> >
> > ----- 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, 23 May, 2014 3:51:31 PM
> >> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
> >>
> >> Our user-agent might not be a browser.
> >>
> >> On 5/23/2014 10:48 AM, Stian Thorgersen wrote:
> >>> Why not just do a window.reload(), which will redirect to login screen
> >>> and
> >>> get a new token with the new roles?
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, 23 May, 2014 3:46:08 PM
> >>>> Subject: [keycloak-dev] FYI: can't use token to auth admin console
> >>>>
> >>>> Too much kid stuff lately!  Sorry I haven't been productive past 2
> >>>> days...But...
> >>>>
> >>>> FYI: We can't use role mapping information in access token to authorize
> >>>> admin console access.  This is because users may be creating new realms
> >>>> which will update their role mappings on the fly with the new admin
> >>>> roles created for that new realm.
> >>>>
> >>>> What will happen is that the client id will be extracted from token and
> >>>> authorization based on client scope and user role mappings will be done
> >>>> dynamically.
> >>>>
> >>>> --
> >>>> 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
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri May 23 11:19:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 May 2014 11:19:06 -0400
Subject: [keycloak-dev] FYI: can't use token to auth admin console
In-Reply-To: <1261846919.13445659.1400857741352.JavaMail.zimbra@redhat.com>
References: <537F5F30.20600@redhat.com>
	<999654602.13418962.1400856488880.JavaMail.zimbra@redhat.com>
	<537F6073.50402@redhat.com>
	<1981012656.13438297.1400857252199.JavaMail.zimbra@redhat.com>
	<537F6331.7020409@redhat.com>
	<1261846919.13445659.1400857741352.JavaMail.zimbra@redhat.com>
Message-ID: <537F66EA.4030302@redhat.com>

The client's scope can't be modified by the client unless the user has 
granted permission for the client to modify its scope.  In the case of 
realm creation, if the client has the "admin" scope, then because 
"admin" is a composite role, the user has already granted the client 
"admin" permission.


On 5/23/2014 11:09 AM, Stian Thorgersen wrote:
> That still doesn't ask the user to give the client permissions though.
>
> Maybe it should use the roles from the token for clients, but for applications the model as you propose?
>
> ----- 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, 23 May, 2014 4:03:13 PM
>> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
>>
>> I will do:
>>
>> boolean authorized = realm.hasRole(user, role) && realm.hasScope(client,
>> role);
>>
>>
>>
>> On 5/23/2014 11:00 AM, Stian Thorgersen wrote:
>>> What about clients? You're then giving additional permissions to a client
>>> that the user hasn't granted.
>>>
>>> ----- 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, 23 May, 2014 3:51:31 PM
>>>> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
>>>>
>>>> Our user-agent might not be a browser.
>>>>
>>>> On 5/23/2014 10:48 AM, Stian Thorgersen wrote:
>>>>> Why not just do a window.reload(), which will redirect to login screen
>>>>> and
>>>>> get a new token with the new roles?
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Friday, 23 May, 2014 3:46:08 PM
>>>>>> Subject: [keycloak-dev] FYI: can't use token to auth admin console
>>>>>>
>>>>>> Too much kid stuff lately!  Sorry I haven't been productive past 2
>>>>>> days...But...
>>>>>>
>>>>>> FYI: We can't use role mapping information in access token to authorize
>>>>>> admin console access.  This is because users may be creating new realms
>>>>>> which will update their role mappings on the fly with the new admin
>>>>>> roles created for that new realm.
>>>>>>
>>>>>> What will happen is that the client id will be extracted from token and
>>>>>> authorization based on client scope and user role mappings will be done
>>>>>> dynamically.
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 23 11:25:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 May 2014 11:25:12 -0400 (EDT)
Subject: [keycloak-dev] FYI: can't use token to auth admin console
In-Reply-To: <537F66EA.4030302@redhat.com>
References: <537F5F30.20600@redhat.com>
	<999654602.13418962.1400856488880.JavaMail.zimbra@redhat.com>
	<537F6073.50402@redhat.com>
	<1981012656.13438297.1400857252199.JavaMail.zimbra@redhat.com>
	<537F6331.7020409@redhat.com>
	<1261846919.13445659.1400857741352.JavaMail.zimbra@redhat.com>
	<537F66EA.4030302@redhat.com>
Message-ID: <1071650644.13465750.1400858712731.JavaMail.zimbra@redhat.com>



----- 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, 23 May, 2014 4:19:06 PM
> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
> 
> The client's scope can't be modified by the client unless the user has
> granted permission for the client to modify its scope.  In the case of
> realm creation, if the client has the "admin" scope, then because
> "admin" is a composite role, the user has already granted the client
> "admin" permission.

There's two things that needs to happen, first admin has to add the scope for the client. Second the user has to grant permissions to it as well, which is the step that would be bypassed.


> 
> 
> On 5/23/2014 11:09 AM, Stian Thorgersen wrote:
> > That still doesn't ask the user to give the client permissions though.
> >
> > Maybe it should use the roles from the token for clients, but for
> > applications the model as you propose?
> >
> > ----- 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, 23 May, 2014 4:03:13 PM
> >> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
> >>
> >> I will do:
> >>
> >> boolean authorized = realm.hasRole(user, role) && realm.hasScope(client,
> >> role);
> >>
> >>
> >>
> >> On 5/23/2014 11:00 AM, Stian Thorgersen wrote:
> >>> What about clients? You're then giving additional permissions to a client
> >>> that the user hasn't granted.
> >>>
> >>> ----- 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, 23 May, 2014 3:51:31 PM
> >>>> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
> >>>>
> >>>> Our user-agent might not be a browser.
> >>>>
> >>>> On 5/23/2014 10:48 AM, Stian Thorgersen wrote:
> >>>>> Why not just do a window.reload(), which will redirect to login screen
> >>>>> and
> >>>>> get a new token with the new roles?
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Friday, 23 May, 2014 3:46:08 PM
> >>>>>> Subject: [keycloak-dev] FYI: can't use token to auth admin console
> >>>>>>
> >>>>>> Too much kid stuff lately!  Sorry I haven't been productive past 2
> >>>>>> days...But...
> >>>>>>
> >>>>>> FYI: We can't use role mapping information in access token to
> >>>>>> authorize
> >>>>>> admin console access.  This is because users may be creating new
> >>>>>> realms
> >>>>>> which will update their role mappings on the fly with the new admin
> >>>>>> roles created for that new realm.
> >>>>>>
> >>>>>> What will happen is that the client id will be extracted from token
> >>>>>> and
> >>>>>> authorization based on client scope and user role mappings will be
> >>>>>> done
> >>>>>> dynamically.
> >>>>>>
> >>>>>> --
> >>>>>> 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
> >>>>>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Mon May 26 21:18:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 May 2014 21:18:04 -0400
Subject: [keycloak-dev] automated REST api docs
Message-ID: <5383E7CC.6060801@redhat.com>

I integrated jax-doclets[1] somewhat into our build.

if you do the following:

1. cd ${keycloak.project.root}
2. mvn javadoc:javadoc
3. cd services
4. mvn package

The jax-doclets are in

services/target/site/apidocs

Then if you do:

5. cd distribution
6. mvn clean install

The docs/ directory that is included will have a rest-api directory and 
those jax-doclets will be linked to the Keycloak javadocs.

The REST docs aren't the greatest.  I tried out Swagger-jaxrs-doclet, 
and swagger-ui but I couldn't get it to work offline (nor online).



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon May 26 21:18:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 May 2014 21:18:55 -0400
Subject: [keycloak-dev] automated REST api docs
In-Reply-To: <5383E7CC.6060801@redhat.com>
References: <5383E7CC.6060801@redhat.com>
Message-ID: <5383E7FF.3040804@redhat.com>

http://fromage.github.io/jax-doclets/docs/0.10.0/html/

On 5/26/2014 9:18 PM, Bill Burke wrote:
> I integrated jax-doclets[1] somewhat into our build.
>
> if you do the following:
>
> 1. cd ${keycloak.project.root}
> 2. mvn javadoc:javadoc
> 3. cd services
> 4. mvn package
>
> The jax-doclets are in
>
> services/target/site/apidocs
>
> Then if you do:
>
> 5. cd distribution
> 6. mvn clean install
>
> The docs/ directory that is included will have a rest-api directory and
> those jax-doclets will be linked to the Keycloak javadocs.
>
> The REST docs aren't the greatest.  I tried out Swagger-jaxrs-doclet,
> and swagger-ui but I couldn't get it to work offline (nor online).
>
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon May 26 21:20:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 May 2014 21:20:00 -0400
Subject: [keycloak-dev] automated REST api docs
In-Reply-To: <5383E7FF.3040804@redhat.com>
References: <5383E7CC.6060801@redhat.com> <5383E7FF.3040804@redhat.com>
Message-ID: <5383E840.8030104@redhat.com>

And the best screen is, IMO,  the overview-index.html as it lists all 
paths/HTTP methods.

On 5/26/2014 9:18 PM, Bill Burke wrote:
> http://fromage.github.io/jax-doclets/docs/0.10.0/html/
>
> On 5/26/2014 9:18 PM, Bill Burke wrote:
>> I integrated jax-doclets[1] somewhat into our build.
>>
>> if you do the following:
>>
>> 1. cd ${keycloak.project.root}
>> 2. mvn javadoc:javadoc
>> 3. cd services
>> 4. mvn package
>>
>> The jax-doclets are in
>>
>> services/target/site/apidocs
>>
>> Then if you do:
>>
>> 5. cd distribution
>> 6. mvn clean install
>>
>> The docs/ directory that is included will have a rest-api directory and
>> those jax-doclets will be linked to the Keycloak javadocs.
>>
>> The REST docs aren't the greatest.  I tried out Swagger-jaxrs-doclet,
>> and swagger-ui but I couldn't get it to work offline (nor online).
>>
>>
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue May 27 06:52:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 27 May 2014 06:52:01 -0400 (EDT)
Subject: [keycloak-dev] Proposed changes to dist bundles
In-Reply-To: <479168366.15571404.1401187332828.JavaMail.zimbra@redhat.com>
Message-ID: <749325369.15578831.1401187921781.JavaMail.zimbra@redhat.com>

I'd like to do some changes to our distribution to make it easier to automate/script installing Keycloak.

This would include:

* Deploy server-war to Maven 
* Add appliance-dist and war-dist to Maven
* Some layout changes to appliance-dist

I'd like to rename appliance-dist to just dist, and move everything in the keycloak folder up one level. So the contents of "keycloak-dist-<version>.zip" would be (not including everything):

  - adapters
  - bin
  - standalone
     - configuration
        - keycloak-server.json
        - themes
     - deployments
        - auth-server.war
  - docs (combined with WildFly docs, or replace WildFly docs, not sure which?)
  - examples

    
  

From bruno at abstractj.org  Tue May 27 07:58:05 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 27 May 2014 08:58:05 -0300
Subject: [keycloak-dev] Restricting the scope of admin
Message-ID: <20140527115805.GA11134@abstractj.org>

Good morning guys, following the requirements of Push server. We on
AeroGear would like to restrict the scope of Admin.

Following the integration samples here:
https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/java/org/aerogear/ups/security/UpsSecurityApplication.java#L32.

The downside of remove the admin is that we can't manage our users anymore (correct me if I'm wrong).
This is not a big deal if you add a new user or update the current admin with the appropriate
permissions. The odd thing is: after login I'm immediately kicked out of KC
admin, probably I'm doing something wrong for sure, but I couldn't figure
out yet.

This is the piece of code being tested:
https://github.com/abstractj/aerogear-unifiedpush-server/commit/4814e75f1e5bfc31919bb51f00623a3948829861#diff-fb1187c03792f02a16e7bb8642ad6052R67

And this is the log file:
https://gist.github.com/abstractj/eb75d6210eb29394d139. It seems like
everything goes well here:
https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L5,
but maybe I'm missing the mgmt configuration?
https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L7

Thanks in advance.

--

abstractj

From bburke at redhat.com  Tue May 27 11:16:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 27 May 2014 11:16:07 -0400
Subject: [keycloak-dev] Restricting the scope of admin
In-Reply-To: <20140527115805.GA11134@abstractj.org>
References: <20140527115805.GA11134@abstractj.org>
Message-ID: <5384AC37.6020909@redhat.com>

Please check out the project here.  IMO, this is how you'll want to set 
up aerogear:

https://github.com/keycloak/keycloak/tree/master/project-integrations/aerogear-ups

With aerogear, IMO, you'll want to remove the admin user of the master 
realm.  We added a feature that you can have a admin user directly in 
your realm within the admin console.  Please read this:

https://github.com/keycloak/keycloak/tree/master/project-integrations/aerogear-ups 


The realm import enables an admin user with permissions to modify the 
aerogear realm.

https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/webapp/WEB-INF/testrealm.json

On 5/27/2014 7:58 AM, Bruno Oliveira wrote:
> Good morning guys, following the requirements of Push server. We on
> AeroGear would like to restrict the scope of Admin.
>
> Following the integration samples here:
> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/java/org/aerogear/ups/security/UpsSecurityApplication.java#L32.
>
> The downside of remove the admin is that we can't manage our users anymore (correct me if I'm wrong).
> This is not a big deal if you add a new user or update the current admin with the appropriate
> permissions. The odd thing is: after login I'm immediately kicked out of KC
> admin, probably I'm doing something wrong for sure, but I couldn't figure
> out yet.
>
> This is the piece of code being tested:
> https://github.com/abstractj/aerogear-unifiedpush-server/commit/4814e75f1e5bfc31919bb51f00623a3948829861#diff-fb1187c03792f02a16e7bb8642ad6052R67
>
> And this is the log file:
> https://gist.github.com/abstractj/eb75d6210eb29394d139. It seems like
> everything goes well here:
> https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L5,
> but maybe I'm missing the mgmt configuration?
> https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L7
>
> Thanks in advance.
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue May 27 11:19:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 27 May 2014 11:19:05 -0400
Subject: [keycloak-dev] Proposed changes to dist bundles
In-Reply-To: <749325369.15578831.1401187921781.JavaMail.zimbra@redhat.com>
References: <749325369.15578831.1401187921781.JavaMail.zimbra@redhat.com>
Message-ID: <5384ACE9.2040609@redhat.com>

Keep the name appliance-dist please as we have a war-dist.  One is a 
Wildfly bundle, the other is a war.

Also, if you change the directory structure, you will require me to redo 
some of the screencast demos.  Which I was hoping to avoid until 1.0.Final.

On 5/27/2014 6:52 AM, Stian Thorgersen wrote:
> I'd like to do some changes to our distribution to make it easier to automate/script installing Keycloak.
>
> This would include:
>
> * Deploy server-war to Maven
> * Add appliance-dist and war-dist to Maven
> * Some layout changes to appliance-dist
>
> I'd like to rename appliance-dist to just dist, and move everything in the keycloak folder up one level. So the contents of "keycloak-dist-<version>.zip" would be (not including everything):
>
>    - adapters
>    - bin
>    - standalone
>       - configuration
>          - keycloak-server.json
>          - themes
>       - deployments
>          - auth-server.war
>    - docs (combined with WildFly docs, or replace WildFly docs, not sure which?)
>    - examples
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue May 27 11:33:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 27 May 2014 11:33:03 -0400 (EDT)
Subject: [keycloak-dev] Proposed changes to dist bundles
In-Reply-To: <5384ACE9.2040609@redhat.com>
References: <749325369.15578831.1401187921781.JavaMail.zimbra@redhat.com>
	<5384ACE9.2040609@redhat.com>
Message-ID: <1720174141.15869715.1401204783505.JavaMail.zimbra@redhat.com>

Ok - how about we put the war and zips in Maven for now, then re-visit the directory structure for 1.0.Final?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 27 May, 2014 4:19:05 PM
> Subject: Re: [keycloak-dev] Proposed changes to dist bundles
> 
> Keep the name appliance-dist please as we have a war-dist.  One is a
> Wildfly bundle, the other is a war.
> 
> Also, if you change the directory structure, you will require me to redo
> some of the screencast demos.  Which I was hoping to avoid until 1.0.Final.
> 
> On 5/27/2014 6:52 AM, Stian Thorgersen wrote:
> > I'd like to do some changes to our distribution to make it easier to
> > automate/script installing Keycloak.
> >
> > This would include:
> >
> > * Deploy server-war to Maven
> > * Add appliance-dist and war-dist to Maven
> > * Some layout changes to appliance-dist
> >
> > I'd like to rename appliance-dist to just dist, and move everything in the
> > keycloak folder up one level. So the contents of
> > "keycloak-dist-<version>.zip" would be (not including everything):
> >
> >    - adapters
> >    - bin
> >    - standalone
> >       - configuration
> >          - keycloak-server.json
> >          - themes
> >       - deployments
> >          - auth-server.war
> >    - docs (combined with WildFly docs, or replace WildFly docs, not sure
> >    which?)
> >    - examples
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> 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
> 

From bruno at abstractj.org  Tue May 27 13:19:37 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 27 May 2014 14:19:37 -0300
Subject: [keycloak-dev] Restricting the scope of admin
In-Reply-To: <5384AC37.6020909@redhat.com>
References: <20140527115805.GA11134@abstractj.org>
	<5384AC37.6020909@redhat.com>
Message-ID: <20140527171937.GA36511@abstractj.org>

Thank you Bill. If I want to restrict the access for my endpoint, for example:

- admin: can do anything: read, update, delete, create at my endpoints
  (on UPS)
- regular user: read only

Which approach would be the best with KC? Interceptors? Servlet filter?
Or there's something already implemented?

On 2014-05-27, Bill Burke wrote:
> Please check out the project here.  IMO, this is how you'll want to set
> up aerogear:
>
> https://github.com/keycloak/keycloak/tree/master/project-integrations/aerogear-ups
>
> With aerogear, IMO, you'll want to remove the admin user of the master
> realm.  We added a feature that you can have a admin user directly in
> your realm within the admin console.  Please read this:
>
> https://github.com/keycloak/keycloak/tree/master/project-integrations/aerogear-ups
>
>
> The realm import enables an admin user with permissions to modify the
> aerogear realm.
>
> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/webapp/WEB-INF/testrealm.json
>
> On 5/27/2014 7:58 AM, Bruno Oliveira wrote:
> > Good morning guys, following the requirements of Push server. We on
> > AeroGear would like to restrict the scope of Admin.
> >
> > Following the integration samples here:
> > https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/java/org/aerogear/ups/security/UpsSecurityApplication.java#L32.
> >
> > The downside of remove the admin is that we can't manage our users anymore (correct me if I'm wrong).
> > This is not a big deal if you add a new user or update the current admin with the appropriate
> > permissions. The odd thing is: after login I'm immediately kicked out of KC
> > admin, probably I'm doing something wrong for sure, but I couldn't figure
> > out yet.
> >
> > This is the piece of code being tested:
> > https://github.com/abstractj/aerogear-unifiedpush-server/commit/4814e75f1e5bfc31919bb51f00623a3948829861#diff-fb1187c03792f02a16e7bb8642ad6052R67
> >
> > And this is the log file:
> > https://gist.github.com/abstractj/eb75d6210eb29394d139. It seems like
> > everything goes well here:
> > https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L5,
> > but maybe I'm missing the mgmt configuration?
> > https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L7
> >
> > Thanks in advance.
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> 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

--

abstractj

From bburke at redhat.com  Tue May 27 13:38:18 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 27 May 2014 13:38:18 -0400
Subject: [keycloak-dev] Restricting the scope of admin
In-Reply-To: <20140527171937.GA36511@abstractj.org>
References: <20140527115805.GA11134@abstractj.org>
	<5384AC37.6020909@redhat.com>
	<20140527171937.GA36511@abstractj.org>
Message-ID: <5384CD8A.7040502@redhat.com>

You can use RoleAllowed on JAX-RS methods, but you'll need to enable the 
resteasy config for that.  If that's what you mean.  You can also use 
web.xml servlet security too, but you can't get as fine-grained.

I'll update the example we have for Aerogear, if you want to take one of 
those approaches.


On 5/27/2014 1:19 PM, Bruno Oliveira wrote:
> Thank you Bill. If I want to restrict the access for my endpoint, for example:
>
> - admin: can do anything: read, update, delete, create at my endpoints
>    (on UPS)
> - regular user: read only
>
> Which approach would be the best with KC? Interceptors? Servlet filter?
> Or there's something already implemented?
>
> On 2014-05-27, Bill Burke wrote:
>> Please check out the project here.  IMO, this is how you'll want to set
>> up aerogear:
>>
>> https://github.com/keycloak/keycloak/tree/master/project-integrations/aerogear-ups
>>
>> With aerogear, IMO, you'll want to remove the admin user of the master
>> realm.  We added a feature that you can have a admin user directly in
>> your realm within the admin console.  Please read this:
>>
>> https://github.com/keycloak/keycloak/tree/master/project-integrations/aerogear-ups
>>
>>
>> The realm import enables an admin user with permissions to modify the
>> aerogear realm.
>>
>> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/webapp/WEB-INF/testrealm.json
>>
>> On 5/27/2014 7:58 AM, Bruno Oliveira wrote:
>>> Good morning guys, following the requirements of Push server. We on
>>> AeroGear would like to restrict the scope of Admin.
>>>
>>> Following the integration samples here:
>>> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/java/org/aerogear/ups/security/UpsSecurityApplication.java#L32.
>>>
>>> The downside of remove the admin is that we can't manage our users anymore (correct me if I'm wrong).
>>> This is not a big deal if you add a new user or update the current admin with the appropriate
>>> permissions. The odd thing is: after login I'm immediately kicked out of KC
>>> admin, probably I'm doing something wrong for sure, but I couldn't figure
>>> out yet.
>>>
>>> This is the piece of code being tested:
>>> https://github.com/abstractj/aerogear-unifiedpush-server/commit/4814e75f1e5bfc31919bb51f00623a3948829861#diff-fb1187c03792f02a16e7bb8642ad6052R67
>>>
>>> And this is the log file:
>>> https://gist.github.com/abstractj/eb75d6210eb29394d139. It seems like
>>> everything goes well here:
>>> https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L5,
>>> but maybe I'm missing the mgmt configuration?
>>> https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L7
>>>
>>> Thanks in advance.
>>>
>>> --
>>>
>>> abstractj
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>> 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
>
> --
>
> abstractj
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Tue May 27 15:06:03 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 27 May 2014 16:06:03 -0300
Subject: [keycloak-dev] Restricting the scope of admin
In-Reply-To: <5384CD8A.7040502@redhat.com>
References: <20140527115805.GA11134@abstractj.org>
	<5384AC37.6020909@redhat.com>
	<20140527171937.GA36511@abstractj.org>
	<5384CD8A.7040502@redhat.com>
Message-ID: <20140527190603.GA48959@abstractj.org>

On 2014-05-27, Bill Burke wrote:
> You can use RoleAllowed on JAX-RS methods, but you'll need to enable the
> resteasy config for that.  If that's what you mean.  You can also use

Nailed it Bill, that's exactly what I mean.

> web.xml servlet security too, but you can't get as fine-grained.
>
> I'll update the example we have for Aerogear, if you want to take one of
> those approaches.

Thanks a lot, I will take a look at the documentation.

>
>
> On 5/27/2014 1:19 PM, Bruno Oliveira wrote:
> >Thank you Bill. If I want to restrict the access for my endpoint, for example:
> >
> >- admin: can do anything: read, update, delete, create at my endpoints
> >   (on UPS)
> >- regular user: read only
> >
> >Which approach would be the best with KC? Interceptors? Servlet filter?
> >Or there's something already implemented?
> >
> >On 2014-05-27, Bill Burke wrote:
> >>Please check out the project here.  IMO, this is how you'll want to set
> >>up aerogear:
> >>
> >>https://github.com/keycloak/keycloak/tree/master/project-integrations/aerogear-ups
> >>
> >>With aerogear, IMO, you'll want to remove the admin user of the master
> >>realm.  We added a feature that you can have a admin user directly in
> >>your realm within the admin console.  Please read this:
> >>
> >>https://github.com/keycloak/keycloak/tree/master/project-integrations/aerogear-ups
> >>
> >>
> >>The realm import enables an admin user with permissions to modify the
> >>aerogear realm.
> >>
> >>https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/webapp/WEB-INF/testrealm.json
> >>
> >>On 5/27/2014 7:58 AM, Bruno Oliveira wrote:
> >>>Good morning guys, following the requirements of Push server. We on
> >>>AeroGear would like to restrict the scope of Admin.
> >>>
> >>>Following the integration samples here:
> >>>https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/java/org/aerogear/ups/security/UpsSecurityApplication.java#L32.
> >>>
> >>>The downside of remove the admin is that we can't manage our users anymore (correct me if I'm wrong).
> >>>This is not a big deal if you add a new user or update the current admin with the appropriate
> >>>permissions. The odd thing is: after login I'm immediately kicked out of KC
> >>>admin, probably I'm doing something wrong for sure, but I couldn't figure
> >>>out yet.
> >>>
> >>>This is the piece of code being tested:
> >>>https://github.com/abstractj/aerogear-unifiedpush-server/commit/4814e75f1e5bfc31919bb51f00623a3948829861#diff-fb1187c03792f02a16e7bb8642ad6052R67
> >>>
> >>>And this is the log file:
> >>>https://gist.github.com/abstractj/eb75d6210eb29394d139. It seems like
> >>>everything goes well here:
> >>>https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L5,
> >>>but maybe I'm missing the mgmt configuration?
> >>>https://gist.github.com/abstractj/eb75d6210eb29394d139#file-log-txt-L7
> >>>
> >>>Thanks in advance.
> >>>
> >>>--
> >>>
> >>>abstractj
> >>>_______________________________________________
> >>>keycloak-dev mailing list
> >>>keycloak-dev at lists.jboss.org
> >>>https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >>--
> >>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
> >
> >--
> >
> >abstractj
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

--

abstractj

From mposolda at redhat.com  Wed May 28 04:18:50 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 28 May 2014 10:18:50 +0200
Subject: [keycloak-dev] why doesnt import/expot use reps?
In-Reply-To: <537E0AD7.3010101@redhat.com>
References: <537E0AD7.3010101@redhat.com>
Message-ID: <53859BEA.5070302@redhat.com>

I assume that main purpose of export/import is especially migration of 
full DB from one environment to another, so it's a bit different than 
just importing JSON file like testrealm.json with few data related to 
one realm IMO.

My main worry is especially about performance. For example if you have 
realm with million users and want to migrate it, the resulting 
realm.json file will be very big and IMO it would be impossible to 
import it with current approach used in RealmManager.importRealm, which 
is doing whole import in 1 transaction and needs whole 
RealmRepresentation to be read into memory with all the data and all 
million users.

So that's why I used a bit different approach, which is doing import in 
few steps and should scale well even with very big amount of data.

Also some data in representations can't be used as they are because it's 
impossible to retrieve them from DB. For example 
CredentialRepresentation assumes password in plain-text, but DB doesn't 
contain password in plain-text. To workaround, I will need 
CredentialRepresentation to support both plain-text password and also 
hash+salt. Similarly for privateKey (if we ever have an SPI for secure 
store of private key). Is it fine to change CredentialRepresentation 
(and possibly other places) this way? Also I will need to add support 
for "id" into representations as export/import is exporting everything 
including ID of objects, but that's not a big issue though...

Also the stuff inside model/api is not used just by export/import, but 
also by Mongo model. Mongo is storing it's data in JSON like format and 
I am reusing same format for export/import. So we not to maintain more 
things than before. If you want to add new configuration option with 
getter+setter into Realm, you still have "just" 7 places to update :) (I 
count RealmModel, 2xRealmEntity, 2xRealmAdapter, RealmRepresentation and 
ModelToRepresentation)

I have already JIRA opened for investigation of using same format - 
https://issues.jboss.org/browse/KEYCLOAK-487 . I can also investigate 
the possibility to read data in stream instead of everything into memory 
like RealmRepresentation is doing.

Marek

On 22.5.2014 16:33, Bill Burke wrote:
> We now have two different models for dealing with imports and two
> different code paths too.  Why does import/export have its own json
> model under model/api/...entities?  Why weren't the JSON representations
> in keycloak-core/.../representations used?
>
> We already have code that converts between
> keycloak-core/...representations and Models that is updated and
> maintained.  We now have double the work to keep the export/import stuff
> in sync too!
>
>


From mposolda at redhat.com  Wed May 28 04:27:04 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 28 May 2014 10:27:04 +0200
Subject: [keycloak-dev] Default admin password
Message-ID: <53859DD8.30903@redhat.com>

Currently there are many things for initialization of master realm 
hardcoded in ApplianceBootstrap including the initial password of admin 
user. Maybe it's not so big issue as user is required to change admin 
password after first login, but still it's not ideal IMO because if 
someone access admin console faster than you, he can change admin 
password and gain full admin access.

I wonder if we can improve this? At least adding initial admin password 
into keycloak-server.json may help a bit as people can change default 
value from "admin" to something else. wdyt?

Marek

From bruno at abstractj.org  Wed May 28 04:45:47 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 28 May 2014 05:45:47 -0300
Subject: [keycloak-dev] Default admin password
In-Reply-To: <53859DD8.30903@redhat.com>
References: <53859DD8.30903@redhat.com>
Message-ID: <20140528084547.GA76726@abstractj.org>

Hi Marek, not sure if I got it right. I think what we can do is to
ask for the password only once during the application startup ? but I'm not sure
about how it would be annoying to users)

Or like you mentioned add an initial password to keycloak-server.json.
But what would happen with the values on .json file when the admin
changes the password? Or the password would be exposed into this file?

On 2014-05-28, Marek Posolda wrote:
> Currently there are many things for initialization of master realm
> hardcoded in ApplianceBootstrap including the initial password of admin
> user. Maybe it's not so big issue as user is required to change admin
> password after first login, but still it's not ideal IMO because if
> someone access admin console faster than you, he can change admin
> password and gain full admin access.
>
> I wonder if we can improve this? At least adding initial admin password
> into keycloak-server.json may help a bit as people can change default
> value from "admin" to something else. wdyt?
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From stian at redhat.com  Wed May 28 04:47:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 May 2014 04:47:55 -0400 (EDT)
Subject: [keycloak-dev] Default admin password
In-Reply-To: <53859DD8.30903@redhat.com>
References: <53859DD8.30903@redhat.com>
Message-ID: <1160740997.16232706.1401266875082.JavaMail.zimbra@redhat.com>

It would be nice to extract the ApplianceBootstrap into a keycloak-boostrapping.json file. That would let AeroGear and LiveOak modify this file instead of having to extend the KeycloakApplication. It would be nice if AeroGear and LiveOak had to maintain less redundancy in the future. At the moment they both have to build their own custom WAR, maintaining all dependencies, web.xml, persistence.xml, extending KeycloakApplication, etc. I think we could make this simpler by adding the WAR to Maven, then have Maven remove whatever dependencies AeroGear doesn't use, replace the keycloak-boostrapping.json, and that's it. 

The initial password is only used on first boot, so the server config file isn't suitable.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 28 May, 2014 9:27:04 AM
> Subject: [keycloak-dev] Default admin password
> 
> Currently there are many things for initialization of master realm
> hardcoded in ApplianceBootstrap including the initial password of admin
> user. Maybe it's not so big issue as user is required to change admin
> password after first login, but still it's not ideal IMO because if
> someone access admin console faster than you, he can change admin
> password and gain full admin access.
> 
> I wonder if we can improve this? At least adding initial admin password
> into keycloak-server.json may help a bit as people can change default
> value from "admin" to something else. wdyt?
> 
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed May 28 06:06:56 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 May 2014 06:06:56 -0400 (EDT)
Subject: [keycloak-dev] Updated JBoss and WildFly maven plugins
In-Reply-To: <1990739481.16271120.1401271372754.JavaMail.zimbra@redhat.com>
Message-ID: <933135316.16272694.1401271616683.JavaMail.zimbra@redhat.com>

I've added WildFly maven plugin. Also made both JBoss and Maven plugins skipped by default in Keycloak parent. This means we only need to specify those in modules that should be deployed (see server/pom.xml for example).

As examples/demo-template are skipped as well you can't do a "mvn jboss-as:deploy" or "mvn wildfly:deploy" from the root as the examples will not deploy successfully. Instead you'll have to do "mvn -pl server jboss-as:deploy" or "mvn -pl server wildfly:deploy" to deploy the server.

Keycloak doesn't seem to be working on 8.1.0.CR2, I know they had to do some tweaks to get it working in LiveOak so I'll look at that now.

From bburke at redhat.com  Wed May 28 09:27:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 28 May 2014 09:27:06 -0400
Subject: [keycloak-dev] Default admin password
In-Reply-To: <1160740997.16232706.1401266875082.JavaMail.zimbra@redhat.com>
References: <53859DD8.30903@redhat.com>
	<1160740997.16232706.1401266875082.JavaMail.zimbra@redhat.com>
Message-ID: <5385E42A.2040000@redhat.com>

While we're on the topic of making things easier.  It would be cool if I 
could package up a theme in a jar (like web fragments) and not have to 
do any coding like I had to do to add a theme to the aerogear example.

On 5/28/2014 4:47 AM, Stian Thorgersen wrote:
> It would be nice to extract the ApplianceBootstrap into a keycloak-boostrapping.json file. That would let AeroGear and LiveOak modify this file instead of having to extend the KeycloakApplication. It would be nice if AeroGear and LiveOak had to maintain less redundancy in the future. At the moment they both have to build their own custom WAR, maintaining all dependencies, web.xml, persistence.xml, extending KeycloakApplication, etc. I think we could make this simpler by adding the WAR to Maven, then have Maven remove whatever dependencies AeroGear doesn't use, replace the keycloak-boostrapping.json, and that's it.
>
> The initial password is only used on first boot, so the server config file isn't suitable.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 28 May, 2014 9:27:04 AM
>> Subject: [keycloak-dev] Default admin password
>>
>> Currently there are many things for initialization of master realm
>> hardcoded in ApplianceBootstrap including the initial password of admin
>> user. Maybe it's not so big issue as user is required to change admin
>> password after first login, but still it's not ideal IMO because if
>> someone access admin console faster than you, he can change admin
>> password and gain full admin access.
>>
>> I wonder if we can improve this? At least adding initial admin password
>> into keycloak-server.json may help a bit as people can change default
>> value from "admin" to something else. wdyt?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed May 28 09:35:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 May 2014 09:35:19 -0400 (EDT)
Subject: [keycloak-dev] Default admin password
In-Reply-To: <5385E42A.2040000@redhat.com>
References: <53859DD8.30903@redhat.com>
	<1160740997.16232706.1401266875082.JavaMail.zimbra@redhat.com>
	<5385E42A.2040000@redhat.com>
Message-ID: <1974227118.16384599.1401284119542.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 28 May, 2014 2:27:06 PM
> Subject: Re: [keycloak-dev] Default admin password
> 
> While we're on the topic of making things easier.  It would be cool if I
> could package up a theme in a jar (like web fragments) and not have to
> do any coding like I had to do to add a theme to the aerogear example.

That'd be very nice - created https://issues.jboss.org/browse/KEYCLOAK-498

> 
> On 5/28/2014 4:47 AM, Stian Thorgersen wrote:
> > It would be nice to extract the ApplianceBootstrap into a
> > keycloak-boostrapping.json file. That would let AeroGear and LiveOak
> > modify this file instead of having to extend the KeycloakApplication. It
> > would be nice if AeroGear and LiveOak had to maintain less redundancy in
> > the future. At the moment they both have to build their own custom WAR,
> > maintaining all dependencies, web.xml, persistence.xml, extending
> > KeycloakApplication, etc. I think we could make this simpler by adding the
> > WAR to Maven, then have Maven remove whatever dependencies AeroGear
> > doesn't use, replace the keycloak-boostrapping.json, and that's it.
> >
> > The initial password is only used on first boot, so the server config file
> > isn't suitable.
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 28 May, 2014 9:27:04 AM
> >> Subject: [keycloak-dev] Default admin password
> >>
> >> Currently there are many things for initialization of master realm
> >> hardcoded in ApplianceBootstrap including the initial password of admin
> >> user. Maybe it's not so big issue as user is required to change admin
> >> password after first login, but still it's not ideal IMO because if
> >> someone access admin console faster than you, he can change admin
> >> password and gain full admin access.
> >>
> >> I wonder if we can improve this? At least adding initial admin password
> >> into keycloak-server.json may help a bit as people can change default
> >> value from "admin" to something else. wdyt?
> >>
> >> Marek
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> 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
> 

From stian at redhat.com  Wed May 28 09:37:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 May 2014 09:37:30 -0400 (EDT)
Subject: [keycloak-dev] Default admin password
In-Reply-To: <5385E42A.2040000@redhat.com>
References: <53859DD8.30903@redhat.com>
	<1160740997.16232706.1401266875082.JavaMail.zimbra@redhat.com>
	<5385E42A.2040000@redhat.com>
Message-ID: <1151236285.16386483.1401284250295.JavaMail.zimbra@redhat.com>

And https://issues.jboss.org/browse/KEYCLOAK-499 for bootstrapping

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 28 May, 2014 2:27:06 PM
> Subject: Re: [keycloak-dev] Default admin password
> 
> While we're on the topic of making things easier.  It would be cool if I
> could package up a theme in a jar (like web fragments) and not have to
> do any coding like I had to do to add a theme to the aerogear example.
> 
> On 5/28/2014 4:47 AM, Stian Thorgersen wrote:
> > It would be nice to extract the ApplianceBootstrap into a
> > keycloak-boostrapping.json file. That would let AeroGear and LiveOak
> > modify this file instead of having to extend the KeycloakApplication. It
> > would be nice if AeroGear and LiveOak had to maintain less redundancy in
> > the future. At the moment they both have to build their own custom WAR,
> > maintaining all dependencies, web.xml, persistence.xml, extending
> > KeycloakApplication, etc. I think we could make this simpler by adding the
> > WAR to Maven, then have Maven remove whatever dependencies AeroGear
> > doesn't use, replace the keycloak-boostrapping.json, and that's it.
> >
> > The initial password is only used on first boot, so the server config file
> > isn't suitable.
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 28 May, 2014 9:27:04 AM
> >> Subject: [keycloak-dev] Default admin password
> >>
> >> Currently there are many things for initialization of master realm
> >> hardcoded in ApplianceBootstrap including the initial password of admin
> >> user. Maybe it's not so big issue as user is required to change admin
> >> password after first login, but still it's not ideal IMO because if
> >> someone access admin console faster than you, he can change admin
> >> password and gain full admin access.
> >>
> >> I wonder if we can improve this? At least adding initial admin password
> >> into keycloak-server.json may help a bit as people can change default
> >> value from "admin" to something else. wdyt?
> >>
> >> Marek
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> 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
> 

From bburke at redhat.com  Wed May 28 09:55:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 28 May 2014 09:55:00 -0400
Subject: [keycloak-dev] renamed master realm to "master"
Message-ID: <5385EAB4.4010107@redhat.com>

FYI, I renamed the "keycloak-admin" realm to "master".  I did this as 
the admin console might be branded and this would be one less thing to 
configure to change the name as "master" is pretty generic.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed May 28 10:34:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 May 2014 10:34:06 -0400 (EDT)
Subject: [keycloak-dev] Added server war and dist bundles to Maven deploy
In-Reply-To: <2021667688.16435194.1401287611380.JavaMail.zimbra@redhat.com>
Message-ID: <1139444507.16435619.1401287646105.JavaMail.zimbra@redhat.com>

I've added server war and dist bundles to Maven deploy. So when doing a release please add -Pdistribution to make sure distribution bundles are included in Maven repo.

From stian at redhat.com  Wed May 28 10:45:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 May 2014 10:45:24 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <1018268595.16442324.1401288255411.JavaMail.zimbra@redhat.com>
Message-ID: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>

Where are we at with the release? From my point of view it looks like we're ready to go.

From bburke at redhat.com  Wed May 28 10:47:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 28 May 2014 10:47:12 -0400
Subject: [keycloak-dev] Release status
In-Reply-To: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
Message-ID: <5385F6F0.9030201@redhat.com>

Working on updating documentation at the moment.  We need to check that 
all the demos work as well as the aerogear demo.  We need people to 
review the docs, readme's, etc.

On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
> Where are we at with the release? From my point of view it looks like we're ready to go.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Wed May 28 10:50:11 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 28 May 2014 11:50:11 -0300
Subject: [keycloak-dev] Release status
In-Reply-To: <5385F6F0.9030201@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<5385F6F0.9030201@redhat.com>
Message-ID: <20140528145011.GA95560@abstractj.org>

I can help reviewing and reporting if I find something.

On 2014-05-28, Bill Burke wrote:
> Working on updating documentation at the moment.  We need to check that
> all the demos work as well as the aerogear demo.  We need people to
> review the docs, readme's, etc.
>
> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
> > Where are we at with the release? From my point of view it looks like we're ready to go.
> >
>
> --
> 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

--

abstractj

From stian at redhat.com  Wed May 28 11:02:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 May 2014 11:02:55 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <5385F6F0.9030201@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<5385F6F0.9030201@redhat.com>
Message-ID: <2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>

But, that's so booooooooooring ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 28 May, 2014 3:47:12 PM
> Subject: Re: Release status
> 
> Working on updating documentation at the moment.  We need to check that
> all the demos work as well as the aerogear demo.  We need people to
> review the docs, readme's, etc.
> 
> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
> > Where are we at with the release? From my point of view it looks like we're
> > ready to go.
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Wed May 28 11:13:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 28 May 2014 11:13:22 -0400
Subject: [keycloak-dev] Release status
In-Reply-To: <2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<5385F6F0.9030201@redhat.com>
	<2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>
Message-ID: <5385FD12.9010209@redhat.com>

Tell me about it!  Why do you think I haven't released yet!  My 
attention deficit disorder kicks in whenever I wrote documentation!

(Not only that, but having in-laws here this week helps kill my 
productivity!)

On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
> But, that's so booooooooooring ;)
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 28 May, 2014 3:47:12 PM
>> Subject: Re: Release status
>>
>> Working on updating documentation at the moment.  We need to check that
>> all the demos work as well as the aerogear demo.  We need people to
>> review the docs, readme's, etc.
>>
>> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
>>> Where are we at with the release? From my point of view it looks like we're
>>> ready to go.
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed May 28 11:38:22 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 May 2014 11:38:22 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <5385FD12.9010209@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<5385F6F0.9030201@redhat.com>
	<2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>
	<5385FD12.9010209@redhat.com>
Message-ID: <381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>

We need to hire some monkeys!

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 28 May, 2014 4:13:22 PM
> Subject: Re: Release status
> 
> Tell me about it!  Why do you think I haven't released yet!  My
> attention deficit disorder kicks in whenever I wrote documentation!
> 
> (Not only that, but having in-laws here this week helps kill my
> productivity!)
> 
> On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
> > But, that's so booooooooooring ;)
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 28 May, 2014 3:47:12 PM
> >> Subject: Re: Release status
> >>
> >> Working on updating documentation at the moment.  We need to check that
> >> all the demos work as well as the aerogear demo.  We need people to
> >> review the docs, readme's, etc.
> >>
> >> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
> >>> Where are we at with the release? From my point of view it looks like
> >>> we're
> >>> ready to go.
> >>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Wed May 28 12:31:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 May 2014 12:31:21 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<5385F6F0.9030201@redhat.com>
	<2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>
	<5385FD12.9010209@redhat.com>
	<381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>
Message-ID: <1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>

Quite a few issues so far:

* angular-product not working
* admin-access not found
* customer-portal/admin/admin.jsp not working
* customer-app-cli not working

Also cordova example wasn't working, but I've fixed that.

I'm calling it a day now, but I'll carry on tomorrow...

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 28 May, 2014 4:38:22 PM
> Subject: Re: [keycloak-dev] Release status
> 
> We need to hire some monkeys!
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 28 May, 2014 4:13:22 PM
> > Subject: Re: Release status
> > 
> > Tell me about it!  Why do you think I haven't released yet!  My
> > attention deficit disorder kicks in whenever I wrote documentation!
> > 
> > (Not only that, but having in-laws here this week helps kill my
> > productivity!)
> > 
> > On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
> > > But, that's so booooooooooring ;)
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> > >> Sent: Wednesday, 28 May, 2014 3:47:12 PM
> > >> Subject: Re: Release status
> > >>
> > >> Working on updating documentation at the moment.  We need to check that
> > >> all the demos work as well as the aerogear demo.  We need people to
> > >> review the docs, readme's, etc.
> > >>
> > >> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
> > >>> Where are we at with the release? From my point of view it looks like
> > >>> we're
> > >>> ready to go.
> > >>>
> > >>
> > >> --
> > >> Bill Burke
> > >> JBoss, a division of Red Hat
> > >> http://bill.burkecentral.com
> > >>
> > 
> > --
> > 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
> 

From bburke at redhat.com  Wed May 28 12:34:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 28 May 2014 12:34:55 -0400
Subject: [keycloak-dev] Release status
In-Reply-To: <1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<5385F6F0.9030201@redhat.com>
	<2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>
	<5385FD12.9010209@redhat.com>
	<381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>
	<1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>
Message-ID: <5386102F.9010103@redhat.com>

I'll look into all the demos tomorrow.  I think I finished my documentation.

On 5/28/2014 12:31 PM, Stian Thorgersen wrote:
> Quite a few issues so far:
>
> * angular-product not working
> * admin-access not found
> * customer-portal/admin/admin.jsp not working
> * customer-app-cli not working
>
> Also cordova example wasn't working, but I've fixed that.
>
> I'm calling it a day now, but I'll carry on tomorrow...
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 28 May, 2014 4:38:22 PM
>> Subject: Re: [keycloak-dev] Release status
>>
>> We need to hire some monkeys!
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 28 May, 2014 4:13:22 PM
>>> Subject: Re: Release status
>>>
>>> Tell me about it!  Why do you think I haven't released yet!  My
>>> attention deficit disorder kicks in whenever I wrote documentation!
>>>
>>> (Not only that, but having in-laws here this week helps kill my
>>> productivity!)
>>>
>>> On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
>>>> But, that's so booooooooooring ;)
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
>>>>> Sent: Wednesday, 28 May, 2014 3:47:12 PM
>>>>> Subject: Re: Release status
>>>>>
>>>>> Working on updating documentation at the moment.  We need to check that
>>>>> all the demos work as well as the aerogear demo.  We need people to
>>>>> review the docs, readme's, etc.
>>>>>
>>>>> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
>>>>>> Where are we at with the release? From my point of view it looks like
>>>>>> we're
>>>>>> ready to go.
>>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>>
>>>
>>> --
>>> 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed May 28 12:35:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 28 May 2014 12:35:39 -0400
Subject: [keycloak-dev] Missing any documentation or example?
Message-ID: <5386105B.5060600@redhat.com>

Are we missing any crucial documentation or example that already isn't 
there?  I added a few more chapters today.  I also have to improve our 
Javadoc some more for the Admin REST API.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Wed May 28 16:43:42 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 28 May 2014 22:43:42 +0200
Subject: [keycloak-dev] Default timeouts
Message-ID: <53864A7E.8070103@redhat.com>

Does it makes sense when ssoSessionIdleTimeout has bigger value than 
accessTokenLifespan? To me not, as if accessToken expires then 
refreshToken might be already outdated as lastSessionAccess is updated 
during refreshing token.

I wonder if we should update timeouts for the realm used in examples 
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/testrealm.json#L4 
? Currently accessToken timeout is 50 minutes but ssoSessionIdleTimeout 
is not specified, so it has default value 10 minutes. Also 
accessCodeLifespanUserAction has 100 minutes, which is quite big. wdyt?

I also think if we should change default value of ssoSessionIdleTimeout 
to be something like: "accessTokenLifespan + 5 minutes" instead of 10 
minutes to ensure that if people don't set it, it's bigger than 
accessTokenLifespan.

Marek



From bburke at redhat.com  Thu May 29 00:38:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 29 May 2014 00:38:35 -0400
Subject: [keycloak-dev] Default timeouts
In-Reply-To: <53864A7E.8070103@redhat.com>
References: <53864A7E.8070103@redhat.com>
Message-ID: <5386B9CB.2010808@redhat.com>



On 5/28/2014 4:43 PM, Marek Posolda wrote:
> Does it makes sense when ssoSessionIdleTimeout has bigger value than
> accessTokenLifespan?

Yes, it makes a lot of sense that ssoSessionIdleTimeout is bigger than 
accessTokenLifespan.

Access token lifespan is supposed to be short as the sso session may 
have been invalidated by the admin, a role may have been changed, an 
application or user may have been disabled, etc...  The refresh token 
request is really a check to see if any of those events happened.

> To me not, as if accessToken expires then
> refreshToken might be already outdated as lastSessionAccess is updated
> during refreshing token.
>

Access token timeout is supposed to be much less than ssoSessionIdleTimeout.

There is no more refresh token timeout.  It has been replaced with 
ssoSessionIdleTimeout and ssoSessionMaxLifespan.

> I wonder if we should update timeouts for the realm used in examples
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/testrealm.json#L4
> ? Currently accessToken timeout is 50 minutes but ssoSessionIdleTimeout
> is not specified, so it has default value 10 minutes. Also
> accessCodeLifespanUserAction has 100 minutes, which is quite big. wdyt?
>

Yes we need to change the demo code.

The large access token timeout in the demo is just legacy.  It is so 
large because we used to not have refresh token support.  Neither did we 
have any user session management.

The accessCodeLifespanUserAction is so large because I found when doing 
presentations on Keycloak (and the screen casts) I might talk so long in 
between actions, the access code would time out.  That is why it is 100 
minutes.  And the only reason why.

> I also think if we should change default value of ssoSessionIdleTimeout
> to be something like: "accessTokenLifespan + 5 minutes" instead of 10
> minutes to ensure that if people don't set it, it's bigger than
> accessTokenLifespan.
>

I think the defaults are good as they are.  But the demo.json file needs 
to change to reflect the defaults (or just be left blank).


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Thu May 29 02:59:12 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 29 May 2014 08:59:12 +0200
Subject: [keycloak-dev] Default timeouts
In-Reply-To: <5386B9CB.2010808@redhat.com>
References: <53864A7E.8070103@redhat.com> <5386B9CB.2010808@redhat.com>
Message-ID: <5386DAC0.7000507@redhat.com>

On 29.5.2014 06:38, Bill Burke wrote:
>
> On 5/28/2014 4:43 PM, Marek Posolda wrote:
>> Does it makes sense when ssoSessionIdleTimeout has bigger value than
>> accessTokenLifespan?
> Yes, it makes a lot of sense that ssoSessionIdleTimeout is bigger than
> accessTokenLifespan.
>
> Access token lifespan is supposed to be short as the sso session may
> have been invalidated by the admin, a role may have been changed, an
> application or user may have been disabled, etc...  The refresh token
> request is really a check to see if any of those events happened.
oops, I wrote it in the opposite side in first sentence:-)

I also meant that ssoSessionIdleTimeout should be bigger than 
accessTokenLifespan, which is currently not the case in examples, hence 
I wrote this mail. I will send PR for tesstrealm.json bundled in demo 
applications also with updated accessTokenLifespanUserAction. If you 
want to add more screencasts later, you can change it locally in your 
env. Is it ok?

Marek
>
>> To me not, as if accessToken expires then
>> refreshToken might be already outdated as lastSessionAccess is updated
>> during refreshing token.
>>
> Access token timeout is supposed to be much less than ssoSessionIdleTimeout.
>
> There is no more refresh token timeout.  It has been replaced with
> ssoSessionIdleTimeout and ssoSessionMaxLifespan.
>
>> I wonder if we should update timeouts for the realm used in examples
>> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/testrealm.json#L4
>> ? Currently accessToken timeout is 50 minutes but ssoSessionIdleTimeout
>> is not specified, so it has default value 10 minutes. Also
>> accessCodeLifespanUserAction has 100 minutes, which is quite big. wdyt?
>>
> Yes we need to change the demo code.
>
> The large access token timeout in the demo is just legacy.  It is so
> large because we used to not have refresh token support.  Neither did we
> have any user session management.
>
> The accessCodeLifespanUserAction is so large because I found when doing
> presentations on Keycloak (and the screen casts) I might talk so long in
> between actions, the access code would time out.  That is why it is 100
> minutes.  And the only reason why.
>
>> I also think if we should change default value of ssoSessionIdleTimeout
>> to be something like: "accessTokenLifespan + 5 minutes" instead of 10
>> minutes to ensure that if people don't set it, it's bigger than
>> accessTokenLifespan.
>>
> I think the defaults are good as they are.  But the demo.json file needs
> to change to reflect the defaults (or just be left blank).
>
>


From mposolda at redhat.com  Thu May 29 05:46:21 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 29 May 2014 11:46:21 +0200
Subject: [keycloak-dev] Release status
In-Reply-To: <5386102F.9010103@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>	<5385F6F0.9030201@redhat.com>	<2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>	<5385FD12.9010209@redhat.com>	<381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>	<1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>
	<5386102F.9010103@redhat.com>
Message-ID: <538701ED.2030600@redhat.com>

When fixing examples, I found the small bug in admin console causing 
that it's not possible to change passwordCredentialGrant configuration 
for the realm. I did a fix here 
https://github.com/mposolda/keycloak/commit/06b949980573b45502a7c2bf9fb40fb89fb1fd12 
. It's just a typo, so I hope it's ok to cover it in Beta1.

Marek

On 28.5.2014 18:34, Bill Burke wrote:
> I'll look into all the demos tomorrow.  I think I finished my documentation.
>
> On 5/28/2014 12:31 PM, Stian Thorgersen wrote:
>> Quite a few issues so far:
>>
>> * angular-product not working
>> * admin-access not found
>> * customer-portal/admin/admin.jsp not working
>> * customer-app-cli not working
>>
>> Also cordova example wasn't working, but I've fixed that.
>>
>> I'm calling it a day now, but I'll carry on tomorrow...
>>
>> ----- Original Message -----
>>> From: "Stian Thorgersen" <stian at redhat.com>
>>> To: "Bill Burke" <bburke at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 28 May, 2014 4:38:22 PM
>>> Subject: Re: [keycloak-dev] Release status
>>>
>>> We need to hire some monkeys!
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 28 May, 2014 4:13:22 PM
>>>> Subject: Re: Release status
>>>>
>>>> Tell me about it!  Why do you think I haven't released yet!  My
>>>> attention deficit disorder kicks in whenever I wrote documentation!
>>>>
>>>> (Not only that, but having in-laws here this week helps kill my
>>>> productivity!)
>>>>
>>>> On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
>>>>> But, that's so booooooooooring ;)
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
>>>>>> Sent: Wednesday, 28 May, 2014 3:47:12 PM
>>>>>> Subject: Re: Release status
>>>>>>
>>>>>> Working on updating documentation at the moment.  We need to check that
>>>>>> all the demos work as well as the aerogear demo.  We need people to
>>>>>> review the docs, readme's, etc.
>>>>>>
>>>>>> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
>>>>>>> Where are we at with the release? From my point of view it looks like
>>>>>>> we're
>>>>>>> ready to go.
>>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hat
>>>>>> http://bill.burkecentral.com
>>>>>>
>>>> --
>>>> 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
>>>


From stian at redhat.com  Thu May 29 05:51:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 29 May 2014 05:51:39 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <538701ED.2030600@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<5385F6F0.9030201@redhat.com>
	<2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>
	<5385FD12.9010209@redhat.com>
	<381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>
	<1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>
	<5386102F.9010103@redhat.com> <538701ED.2030600@redhat.com>
Message-ID: <652468466.16990707.1401357099073.JavaMail.zimbra@redhat.com>

A couple more minor fixes from me:

* Admin console listed themes twice - https://github.com/keycloak/keycloak/commit/24ac6cbbac17290654eac4501369755f07277853
* Every now and again console doesn't display anything except header - https://github.com/keycloak/keycloak/commit/0b68e52b8318bb4e1276ccfb3042aead2386116d

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 29 May, 2014 10:46:21 AM
> Subject: Re: [keycloak-dev] Release status
> 
> When fixing examples, I found the small bug in admin console causing
> that it's not possible to change passwordCredentialGrant configuration
> for the realm. I did a fix here
> https://github.com/mposolda/keycloak/commit/06b949980573b45502a7c2bf9fb40fb89fb1fd12
> . It's just a typo, so I hope it's ok to cover it in Beta1.
> 
> Marek
> 
> On 28.5.2014 18:34, Bill Burke wrote:
> > I'll look into all the demos tomorrow.  I think I finished my
> > documentation.
> >
> > On 5/28/2014 12:31 PM, Stian Thorgersen wrote:
> >> Quite a few issues so far:
> >>
> >> * angular-product not working
> >> * admin-access not found
> >> * customer-portal/admin/admin.jsp not working
> >> * customer-app-cli not working
> >>
> >> Also cordova example wasn't working, but I've fixed that.
> >>
> >> I'm calling it a day now, but I'll carry on tomorrow...
> >>
> >> ----- Original Message -----
> >>> From: "Stian Thorgersen" <stian at redhat.com>
> >>> To: "Bill Burke" <bburke at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, 28 May, 2014 4:38:22 PM
> >>> Subject: Re: [keycloak-dev] Release status
> >>>
> >>> We need to hire some monkeys!
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Wednesday, 28 May, 2014 4:13:22 PM
> >>>> Subject: Re: Release status
> >>>>
> >>>> Tell me about it!  Why do you think I haven't released yet!  My
> >>>> attention deficit disorder kicks in whenever I wrote documentation!
> >>>>
> >>>> (Not only that, but having in-laws here this week helps kill my
> >>>> productivity!)
> >>>>
> >>>> On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
> >>>>> But, that's so booooooooooring ;)
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: "Stian Thorgersen" <stian at redhat.com>,
> >>>>>> keycloak-dev at lists.jboss.org
> >>>>>> Sent: Wednesday, 28 May, 2014 3:47:12 PM
> >>>>>> Subject: Re: Release status
> >>>>>>
> >>>>>> Working on updating documentation at the moment.  We need to check
> >>>>>> that
> >>>>>> all the demos work as well as the aerogear demo.  We need people to
> >>>>>> review the docs, readme's, etc.
> >>>>>>
> >>>>>> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
> >>>>>>> Where are we at with the release? From my point of view it looks like
> >>>>>>> we're
> >>>>>>> ready to go.
> >>>>>>>
> >>>>>> --
> >>>>>> Bill Burke
> >>>>>> JBoss, a division of Red Hat
> >>>>>> http://bill.burkecentral.com
> >>>>>>
> >>>> --
> >>>> 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
> >>>
> 
> 

From stian at redhat.com  Thu May 29 11:48:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 29 May 2014 11:48:08 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <652468466.16990707.1401357099073.JavaMail.zimbra@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>
	<5385FD12.9010209@redhat.com>
	<381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>
	<1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>
	<5386102F.9010103@redhat.com> <538701ED.2030600@redhat.com>
	<652468466.16990707.1401357099073.JavaMail.zimbra@redhat.com>
Message-ID: <870899209.17186950.1401378488566.JavaMail.zimbra@redhat.com>

I've tested all examples (including js-console, themes, providers) on the appliance-dist. 

I've also tested installing the WAR dist on AS 7.1.1, EAP 6.2, EAP 6.3.beta and WF 8.1.0.CR2 + the preconfigured demo on all of those.

IMO we're ready to release ;)

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 29 May, 2014 10:51:39 AM
> Subject: Re: [keycloak-dev] Release status
> 
> A couple more minor fixes from me:
> 
> * Admin console listed themes twice -
> https://github.com/keycloak/keycloak/commit/24ac6cbbac17290654eac4501369755f07277853
> * Every now and again console doesn't display anything except header -
> https://github.com/keycloak/keycloak/commit/0b68e52b8318bb4e1276ccfb3042aead2386116d
> 
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 29 May, 2014 10:46:21 AM
> > Subject: Re: [keycloak-dev] Release status
> > 
> > When fixing examples, I found the small bug in admin console causing
> > that it's not possible to change passwordCredentialGrant configuration
> > for the realm. I did a fix here
> > https://github.com/mposolda/keycloak/commit/06b949980573b45502a7c2bf9fb40fb89fb1fd12
> > . It's just a typo, so I hope it's ok to cover it in Beta1.
> > 
> > Marek
> > 
> > On 28.5.2014 18:34, Bill Burke wrote:
> > > I'll look into all the demos tomorrow.  I think I finished my
> > > documentation.
> > >
> > > On 5/28/2014 12:31 PM, Stian Thorgersen wrote:
> > >> Quite a few issues so far:
> > >>
> > >> * angular-product not working
> > >> * admin-access not found
> > >> * customer-portal/admin/admin.jsp not working
> > >> * customer-app-cli not working
> > >>
> > >> Also cordova example wasn't working, but I've fixed that.
> > >>
> > >> I'm calling it a day now, but I'll carry on tomorrow...
> > >>
> > >> ----- Original Message -----
> > >>> From: "Stian Thorgersen" <stian at redhat.com>
> > >>> To: "Bill Burke" <bburke at redhat.com>
> > >>> Cc: keycloak-dev at lists.jboss.org
> > >>> Sent: Wednesday, 28 May, 2014 4:38:22 PM
> > >>> Subject: Re: [keycloak-dev] Release status
> > >>>
> > >>> We need to hire some monkeys!
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>> Cc: keycloak-dev at lists.jboss.org
> > >>>> Sent: Wednesday, 28 May, 2014 4:13:22 PM
> > >>>> Subject: Re: Release status
> > >>>>
> > >>>> Tell me about it!  Why do you think I haven't released yet!  My
> > >>>> attention deficit disorder kicks in whenever I wrote documentation!
> > >>>>
> > >>>> (Not only that, but having in-laws here this week helps kill my
> > >>>> productivity!)
> > >>>>
> > >>>> On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
> > >>>>> But, that's so booooooooooring ;)
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>>> To: "Stian Thorgersen" <stian at redhat.com>,
> > >>>>>> keycloak-dev at lists.jboss.org
> > >>>>>> Sent: Wednesday, 28 May, 2014 3:47:12 PM
> > >>>>>> Subject: Re: Release status
> > >>>>>>
> > >>>>>> Working on updating documentation at the moment.  We need to check
> > >>>>>> that
> > >>>>>> all the demos work as well as the aerogear demo.  We need people to
> > >>>>>> review the docs, readme's, etc.
> > >>>>>>
> > >>>>>> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
> > >>>>>>> Where are we at with the release? From my point of view it looks
> > >>>>>>> like
> > >>>>>>> we're
> > >>>>>>> ready to go.
> > >>>>>>>
> > >>>>>> --
> > >>>>>> Bill Burke
> > >>>>>> JBoss, a division of Red Hat
> > >>>>>> http://bill.burkecentral.com
> > >>>>>>
> > >>>> --
> > >>>> 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
> > >>>
> > 
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu May 29 11:53:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 29 May 2014 11:53:08 -0400
Subject: [keycloak-dev] Release status
In-Reply-To: <870899209.17186950.1401378488566.JavaMail.zimbra@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<2080828643.16463638.1401289375762.JavaMail.zimbra@redhat.com>
	<5385FD12.9010209@redhat.com>
	<381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>
	<1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>
	<5386102F.9010103@redhat.com> <538701ED.2030600@redhat.com>
	<652468466.16990707.1401357099073.JavaMail.zimbra@redhat.com>
	<870899209.17186950.1401378488566.JavaMail.zimbra@redhat.com>
Message-ID: <538757E4.4010201@redhat.com>

Ok, i'll do the release then.  I was just in the middle of testing with 
no problems so far too.

On 5/29/2014 11:48 AM, Stian Thorgersen wrote:
> I've tested all examples (including js-console, themes, providers) on the appliance-dist.
>
> I've also tested installing the WAR dist on AS 7.1.1, EAP 6.2, EAP 6.3.beta and WF 8.1.0.CR2 + the preconfigured demo on all of those.
>
> IMO we're ready to release ;)
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 29 May, 2014 10:51:39 AM
>> Subject: Re: [keycloak-dev] Release status
>>
>> A couple more minor fixes from me:
>>
>> * Admin console listed themes twice -
>> https://github.com/keycloak/keycloak/commit/24ac6cbbac17290654eac4501369755f07277853
>> * Every now and again console doesn't display anything except header -
>> https://github.com/keycloak/keycloak/commit/0b68e52b8318bb4e1276ccfb3042aead2386116d
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 29 May, 2014 10:46:21 AM
>>> Subject: Re: [keycloak-dev] Release status
>>>
>>> When fixing examples, I found the small bug in admin console causing
>>> that it's not possible to change passwordCredentialGrant configuration
>>> for the realm. I did a fix here
>>> https://github.com/mposolda/keycloak/commit/06b949980573b45502a7c2bf9fb40fb89fb1fd12
>>> . It's just a typo, so I hope it's ok to cover it in Beta1.
>>>
>>> Marek
>>>
>>> On 28.5.2014 18:34, Bill Burke wrote:
>>>> I'll look into all the demos tomorrow.  I think I finished my
>>>> documentation.
>>>>
>>>> On 5/28/2014 12:31 PM, Stian Thorgersen wrote:
>>>>> Quite a few issues so far:
>>>>>
>>>>> * angular-product not working
>>>>> * admin-access not found
>>>>> * customer-portal/admin/admin.jsp not working
>>>>> * customer-app-cli not working
>>>>>
>>>>> Also cordova example wasn't working, but I've fixed that.
>>>>>
>>>>> I'm calling it a day now, but I'll carry on tomorrow...
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Wednesday, 28 May, 2014 4:38:22 PM
>>>>>> Subject: Re: [keycloak-dev] Release status
>>>>>>
>>>>>> We need to hire some monkeys!
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Wednesday, 28 May, 2014 4:13:22 PM
>>>>>>> Subject: Re: Release status
>>>>>>>
>>>>>>> Tell me about it!  Why do you think I haven't released yet!  My
>>>>>>> attention deficit disorder kicks in whenever I wrote documentation!
>>>>>>>
>>>>>>> (Not only that, but having in-laws here this week helps kill my
>>>>>>> productivity!)
>>>>>>>
>>>>>>> On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
>>>>>>>> But, that's so booooooooooring ;)
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>,
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Wednesday, 28 May, 2014 3:47:12 PM
>>>>>>>>> Subject: Re: Release status
>>>>>>>>>
>>>>>>>>> Working on updating documentation at the moment.  We need to check
>>>>>>>>> that
>>>>>>>>> all the demos work as well as the aerogear demo.  We need people to
>>>>>>>>> review the docs, readme's, etc.
>>>>>>>>>
>>>>>>>>> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
>>>>>>>>>> Where are we at with the release? From my point of view it looks
>>>>>>>>>> like
>>>>>>>>>> we're
>>>>>>>>>> ready to go.
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu May 29 11:56:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 29 May 2014 11:56:11 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <538757E4.4010201@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>
	<381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>
	<1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>
	<5386102F.9010103@redhat.com> <538701ED.2030600@redhat.com>
	<652468466.16990707.1401357099073.JavaMail.zimbra@redhat.com>
	<870899209.17186950.1401378488566.JavaMail.zimbra@redhat.com>
	<538757E4.4010201@redhat.com>
Message-ID: <1173286637.17193191.1401378971165.JavaMail.zimbra@redhat.com>

Please add "-Pdistribution" when you're doing "mvn deploy" to make sure all the dists are deployed to maven as well :)

----- 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, 29 May, 2014 4:53:08 PM
> Subject: Re: [keycloak-dev] Release status
> 
> Ok, i'll do the release then.  I was just in the middle of testing with
> no problems so far too.
> 
> On 5/29/2014 11:48 AM, Stian Thorgersen wrote:
> > I've tested all examples (including js-console, themes, providers) on the
> > appliance-dist.
> >
> > I've also tested installing the WAR dist on AS 7.1.1, EAP 6.2, EAP 6.3.beta
> > and WF 8.1.0.CR2 + the preconfigured demo on all of those.
> >
> > IMO we're ready to release ;)
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Marek Posolda" <mposolda at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 29 May, 2014 10:51:39 AM
> >> Subject: Re: [keycloak-dev] Release status
> >>
> >> A couple more minor fixes from me:
> >>
> >> * Admin console listed themes twice -
> >> https://github.com/keycloak/keycloak/commit/24ac6cbbac17290654eac4501369755f07277853
> >> * Every now and again console doesn't display anything except header -
> >> https://github.com/keycloak/keycloak/commit/0b68e52b8318bb4e1276ccfb3042aead2386116d
> >>
> >> ----- Original Message -----
> >>> From: "Marek Posolda" <mposolda at redhat.com>
> >>> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen"
> >>> <stian at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, 29 May, 2014 10:46:21 AM
> >>> Subject: Re: [keycloak-dev] Release status
> >>>
> >>> When fixing examples, I found the small bug in admin console causing
> >>> that it's not possible to change passwordCredentialGrant configuration
> >>> for the realm. I did a fix here
> >>> https://github.com/mposolda/keycloak/commit/06b949980573b45502a7c2bf9fb40fb89fb1fd12
> >>> . It's just a typo, so I hope it's ok to cover it in Beta1.
> >>>
> >>> Marek
> >>>
> >>> On 28.5.2014 18:34, Bill Burke wrote:
> >>>> I'll look into all the demos tomorrow.  I think I finished my
> >>>> documentation.
> >>>>
> >>>> On 5/28/2014 12:31 PM, Stian Thorgersen wrote:
> >>>>> Quite a few issues so far:
> >>>>>
> >>>>> * angular-product not working
> >>>>> * admin-access not found
> >>>>> * customer-portal/admin/admin.jsp not working
> >>>>> * customer-app-cli not working
> >>>>>
> >>>>> Also cordova example wasn't working, but I've fixed that.
> >>>>>
> >>>>> I'm calling it a day now, but I'll carry on tomorrow...
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> To: "Bill Burke" <bburke at redhat.com>
> >>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Wednesday, 28 May, 2014 4:38:22 PM
> >>>>>> Subject: Re: [keycloak-dev] Release status
> >>>>>>
> >>>>>> We need to hire some monkeys!
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Wednesday, 28 May, 2014 4:13:22 PM
> >>>>>>> Subject: Re: Release status
> >>>>>>>
> >>>>>>> Tell me about it!  Why do you think I haven't released yet!  My
> >>>>>>> attention deficit disorder kicks in whenever I wrote documentation!
> >>>>>>>
> >>>>>>> (Not only that, but having in-laws here this week helps kill my
> >>>>>>> productivity!)
> >>>>>>>
> >>>>>>> On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
> >>>>>>>> But, that's so booooooooooring ;)
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>,
> >>>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>>> Sent: Wednesday, 28 May, 2014 3:47:12 PM
> >>>>>>>>> Subject: Re: Release status
> >>>>>>>>>
> >>>>>>>>> Working on updating documentation at the moment.  We need to check
> >>>>>>>>> that
> >>>>>>>>> all the demos work as well as the aerogear demo.  We need people to
> >>>>>>>>> review the docs, readme's, etc.
> >>>>>>>>>
> >>>>>>>>> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
> >>>>>>>>>> Where are we at with the release? From my point of view it looks
> >>>>>>>>>> like
> >>>>>>>>>> we're
> >>>>>>>>>> ready to go.
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Bill Burke
> >>>>>>>>> JBoss, a division of Red Hat
> >>>>>>>>> http://bill.burkecentral.com
> >>>>>>>>>
> >>>>>>> --
> >>>>>>> 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
> >>>>>>
> >>>
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Thu May 29 13:01:49 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 29 May 2014 19:01:49 +0200
Subject: [keycloak-dev] Release status
In-Reply-To: <1173286637.17193191.1401378971165.JavaMail.zimbra@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>	<381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>	<1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>	<5386102F.9010103@redhat.com>
	<538701ED.2030600@redhat.com>	<652468466.16990707.1401357099073.JavaMail.zimbra@redhat.com>	<870899209.17186950.1401378488566.JavaMail.zimbra@redhat.com>	<538757E4.4010201@redhat.com>
	<1173286637.17193191.1401378971165.JavaMail.zimbra@redhat.com>
Message-ID: <538767FD.5080205@redhat.com>

I found that js-console doesn't work well on my FF due to "innerText" 
attribute. Sent another PR https://github.com/keycloak/keycloak/pull/439 
, but I guess it's too late for Beta-1...

Marek

On 29.5.2014 17:56, Stian Thorgersen wrote:
> Please add "-Pdistribution" when you're doing "mvn deploy" to make sure all the dists are deployed to maven as well :)
>
> ----- 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, 29 May, 2014 4:53:08 PM
>> Subject: Re: [keycloak-dev] Release status
>>
>> Ok, i'll do the release then.  I was just in the middle of testing with
>> no problems so far too.
>>
>> On 5/29/2014 11:48 AM, Stian Thorgersen wrote:
>>> I've tested all examples (including js-console, themes, providers) on the
>>> appliance-dist.
>>>
>>> I've also tested installing the WAR dist on AS 7.1.1, EAP 6.2, EAP 6.3.beta
>>> and WF 8.1.0.CR2 + the preconfigured demo on all of those.
>>>
>>> IMO we're ready to release ;)
>>>
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Marek Posolda" <mposolda at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 29 May, 2014 10:51:39 AM
>>>> Subject: Re: [keycloak-dev] Release status
>>>>
>>>> A couple more minor fixes from me:
>>>>
>>>> * Admin console listed themes twice -
>>>> https://github.com/keycloak/keycloak/commit/24ac6cbbac17290654eac4501369755f07277853
>>>> * Every now and again console doesn't display anything except header -
>>>> https://github.com/keycloak/keycloak/commit/0b68e52b8318bb4e1276ccfb3042aead2386116d
>>>>
>>>> ----- Original Message -----
>>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>>> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen"
>>>>> <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, 29 May, 2014 10:46:21 AM
>>>>> Subject: Re: [keycloak-dev] Release status
>>>>>
>>>>> When fixing examples, I found the small bug in admin console causing
>>>>> that it's not possible to change passwordCredentialGrant configuration
>>>>> for the realm. I did a fix here
>>>>> https://github.com/mposolda/keycloak/commit/06b949980573b45502a7c2bf9fb40fb89fb1fd12
>>>>> . It's just a typo, so I hope it's ok to cover it in Beta1.
>>>>>
>>>>> Marek
>>>>>
>>>>> On 28.5.2014 18:34, Bill Burke wrote:
>>>>>> I'll look into all the demos tomorrow.  I think I finished my
>>>>>> documentation.
>>>>>>
>>>>>> On 5/28/2014 12:31 PM, Stian Thorgersen wrote:
>>>>>>> Quite a few issues so far:
>>>>>>>
>>>>>>> * angular-product not working
>>>>>>> * admin-access not found
>>>>>>> * customer-portal/admin/admin.jsp not working
>>>>>>> * customer-app-cli not working
>>>>>>>
>>>>>>> Also cordova example wasn't working, but I've fixed that.
>>>>>>>
>>>>>>> I'm calling it a day now, but I'll carry on tomorrow...
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Wednesday, 28 May, 2014 4:38:22 PM
>>>>>>>> Subject: Re: [keycloak-dev] Release status
>>>>>>>>
>>>>>>>> We need to hire some monkeys!
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Wednesday, 28 May, 2014 4:13:22 PM
>>>>>>>>> Subject: Re: Release status
>>>>>>>>>
>>>>>>>>> Tell me about it!  Why do you think I haven't released yet!  My
>>>>>>>>> attention deficit disorder kicks in whenever I wrote documentation!
>>>>>>>>>
>>>>>>>>> (Not only that, but having in-laws here this week helps kill my
>>>>>>>>> productivity!)
>>>>>>>>>
>>>>>>>>> On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
>>>>>>>>>> But, that's so booooooooooring ;)
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>,
>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>> Sent: Wednesday, 28 May, 2014 3:47:12 PM
>>>>>>>>>>> Subject: Re: Release status
>>>>>>>>>>>
>>>>>>>>>>> Working on updating documentation at the moment.  We need to check
>>>>>>>>>>> that
>>>>>>>>>>> all the demos work as well as the aerogear demo.  We need people to
>>>>>>>>>>> review the docs, readme's, etc.
>>>>>>>>>>>
>>>>>>>>>>> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
>>>>>>>>>>>> Where are we at with the release? From my point of view it looks
>>>>>>>>>>>> like
>>>>>>>>>>>> we're
>>>>>>>>>>>> ready to go.
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Bill Burke
>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>>>
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>> --
>> 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


From bburke at redhat.com  Thu May 29 13:06:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 29 May 2014 13:06:25 -0400
Subject: [keycloak-dev] Release status
In-Reply-To: <538767FD.5080205@redhat.com>
References: <133535624.16442973.1401288324181.JavaMail.zimbra@redhat.com>	<381155232.16489487.1401291501999.JavaMail.zimbra@redhat.com>	<1102534459.16552866.1401294681725.JavaMail.zimbra@redhat.com>	<5386102F.9010103@redhat.com>
	<538701ED.2030600@redhat.com>	<652468466.16990707.1401357099073.JavaMail.zimbra@redhat.com>	<870899209.17186950.1401378488566.JavaMail.zimbra@redhat.com>	<538757E4.4010201@redhat.com>
	<1173286637.17193191.1401378971165.JavaMail.zimbra@redhat.com>
	<538767FD.5080205@redhat.com>
Message-ID: <53876911.7070801@redhat.com>

It is too late. Everything is being uploaded at the moment.

On 5/29/2014 1:01 PM, Marek Posolda wrote:
> I found that js-console doesn't work well on my FF due to "innerText"
> attribute. Sent another PR https://github.com/keycloak/keycloak/pull/439
> , but I guess it's too late for Beta-1...
>
> Marek
>
> On 29.5.2014 17:56, Stian Thorgersen wrote:
>> Please add "-Pdistribution" when you're doing "mvn deploy" to make
>> sure all the dists are deployed to maven as well :)
>>
>> ----- 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, 29 May, 2014 4:53:08 PM
>>> Subject: Re: [keycloak-dev] Release status
>>>
>>> Ok, i'll do the release then.  I was just in the middle of testing with
>>> no problems so far too.
>>>
>>> On 5/29/2014 11:48 AM, Stian Thorgersen wrote:
>>>> I've tested all examples (including js-console, themes, providers)
>>>> on the
>>>> appliance-dist.
>>>>
>>>> I've also tested installing the WAR dist on AS 7.1.1, EAP 6.2, EAP
>>>> 6.3.beta
>>>> and WF 8.1.0.CR2 + the preconfigured demo on all of those.
>>>>
>>>> IMO we're ready to release ;)
>>>>
>>>> ----- Original Message -----
>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>> To: "Marek Posolda" <mposolda at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, 29 May, 2014 10:51:39 AM
>>>>> Subject: Re: [keycloak-dev] Release status
>>>>>
>>>>> A couple more minor fixes from me:
>>>>>
>>>>> * Admin console listed themes twice -
>>>>> https://github.com/keycloak/keycloak/commit/24ac6cbbac17290654eac4501369755f07277853
>>>>>
>>>>> * Every now and again console doesn't display anything except header -
>>>>> https://github.com/keycloak/keycloak/commit/0b68e52b8318bb4e1276ccfb3042aead2386116d
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>>>> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen"
>>>>>> <stian at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, 29 May, 2014 10:46:21 AM
>>>>>> Subject: Re: [keycloak-dev] Release status
>>>>>>
>>>>>> When fixing examples, I found the small bug in admin console causing
>>>>>> that it's not possible to change passwordCredentialGrant
>>>>>> configuration
>>>>>> for the realm. I did a fix here
>>>>>> https://github.com/mposolda/keycloak/commit/06b949980573b45502a7c2bf9fb40fb89fb1fd12
>>>>>>
>>>>>> . It's just a typo, so I hope it's ok to cover it in Beta1.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>> On 28.5.2014 18:34, Bill Burke wrote:
>>>>>>> I'll look into all the demos tomorrow.  I think I finished my
>>>>>>> documentation.
>>>>>>>
>>>>>>> On 5/28/2014 12:31 PM, Stian Thorgersen wrote:
>>>>>>>> Quite a few issues so far:
>>>>>>>>
>>>>>>>> * angular-product not working
>>>>>>>> * admin-access not found
>>>>>>>> * customer-portal/admin/admin.jsp not working
>>>>>>>> * customer-app-cli not working
>>>>>>>>
>>>>>>>> Also cordova example wasn't working, but I've fixed that.
>>>>>>>>
>>>>>>>> I'm calling it a day now, but I'll carry on tomorrow...
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Wednesday, 28 May, 2014 4:38:22 PM
>>>>>>>>> Subject: Re: [keycloak-dev] Release status
>>>>>>>>>
>>>>>>>>> We need to hire some monkeys!
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>> Sent: Wednesday, 28 May, 2014 4:13:22 PM
>>>>>>>>>> Subject: Re: Release status
>>>>>>>>>>
>>>>>>>>>> Tell me about it!  Why do you think I haven't released yet!  My
>>>>>>>>>> attention deficit disorder kicks in whenever I wrote
>>>>>>>>>> documentation!
>>>>>>>>>>
>>>>>>>>>> (Not only that, but having in-laws here this week helps kill my
>>>>>>>>>> productivity!)
>>>>>>>>>>
>>>>>>>>>> On 5/28/2014 11:02 AM, Stian Thorgersen wrote:
>>>>>>>>>>> But, that's so booooooooooring ;)
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>,
>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>> Sent: Wednesday, 28 May, 2014 3:47:12 PM
>>>>>>>>>>>> Subject: Re: Release status
>>>>>>>>>>>>
>>>>>>>>>>>> Working on updating documentation at the moment.  We need to
>>>>>>>>>>>> check
>>>>>>>>>>>> that
>>>>>>>>>>>> all the demos work as well as the aerogear demo.  We need
>>>>>>>>>>>> people to
>>>>>>>>>>>> review the docs, readme's, etc.
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/28/2014 10:45 AM, Stian Thorgersen wrote:
>>>>>>>>>>>>> Where are we at with the release? From my point of view it
>>>>>>>>>>>>> looks
>>>>>>>>>>>>> like
>>>>>>>>>>>>> we're
>>>>>>>>>>>>> ready to go.
>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Bill Burke
>>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>> --
>>> 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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May 29 14:48:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 29 May 2014 14:48:59 -0400
Subject: [keycloak-dev] Keycloak Beta 1 Released
Message-ID: <5387811B.8090009@redhat.com>

A lot of hard work!  A lot of new features and improvements.

http://blog.keycloak.org/2014/05/29/keycloak-beta-1-released/

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu May 29 15:12:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 29 May 2014 15:12:03 -0400
Subject: [keycloak-dev] Next step performance
Message-ID: <53878683.5060206@redhat.com>

I'd like to have a hangout next week on this.  There's really 4 areas to 
focus on:

1. Set up a good performance test and get a baseline on current code.

2. Database caching.  There are multiple approaches.
* Our caches will be read-mostly except for user session management.
* Write our own REST cache.  My idea was to implement a new model 
provider that delegates to the real underlying model provider.  It would 
send RESTful invalidation messages secured by keycloak in a clustered 
environment.  Maybe use Infinispan or some other local-only cache as the 
backbone.  I'm really really wary of using Infinispan (or other cache's) 
clustering options.  I'm not sure how well these guys work in cloud 
clustered environments. And I'm not sure how well they've thought of 
security.
* Use Hibernate 2nd level cache.  Really wary of this as I don't know 
how well Infinispan et. al. work in a cloud environment.  I'd really 
like something HTTP based and authenticated by Keycloak.  I'm not sure 
we'll be able to get the level of control here either that we need.
* Another reason for a custom cache, is, IMO, almost everything can be 
stored in memory. Even users.

3. Clustering.
* Keycloak is not completely stateless.  Specifically access codes are 
stored in memory.  We should be able to move this state information into 
a cookie.
* User Session management is a huge issue as it is the only thing that 
is write-mostly.

4. HTTP Cache-Control
* All themed static content should support a way to set up cache-control 
headers.
* Admin REST api could do cache-control too if we had a way to determine 
a version number or timestamp on model data.  Not that important though 
as, IMO, admin rest api isn't going to have a lot of volume.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Thu May 29 17:15:09 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 29 May 2014 18:15:09 -0300
Subject: [keycloak-dev] Keycloak Beta 1 Released
In-Reply-To: <5387811B.8090009@redhat.com>
References: <5387811B.8090009@redhat.com>
Message-ID: <20140529211508.GA89601@abstractj.org>

Congrats! Landed on AeroGear.

On 2014-05-29, Bill Burke wrote:
> A lot of hard work!  A lot of new features and improvements.
>
> http://blog.keycloak.org/2014/05/29/keycloak-beta-1-released/
>
> --
> 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

--

abstractj

From bburke at redhat.com  Thu May 29 17:21:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 29 May 2014 17:21:53 -0400
Subject: [keycloak-dev] Keycloak release process
Message-ID: <5387A4F1.1080304@redhat.com>

FYI:

https://github.com/keycloak/keycloak/wiki/Keycloak-release-process


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From matzew at apache.org  Fri May 30 02:01:26 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 30 May 2014 08:01:26 +0200
Subject: [keycloak-dev] Keycloak Beta 1 Released
In-Reply-To: <5387811B.8090009@redhat.com>
References: <5387811B.8090009@redhat.com>
Message-ID: <CAAg5f2Sqgr79jz2G5a7UKNyCwjkb3ibhB8G2X4FirNCh22EQ4g@mail.gmail.com>

Awesome!

Congrats to the team!

On Thursday, May 29, 2014, Bill Burke <bburke at redhat.com> wrote:

> A lot of hard work!  A lot of new features and improvements.
>
> http://blog.keycloak.org/2014/05/29/keycloak-beta-1-released/
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140530/6d921474/attachment-0001.html 

From bdawidow at redhat.com  Fri May 30 02:24:16 2014
From: bdawidow at redhat.com (=?UTF-8?B?Qm9sZXPFgmF3IERhd2lkb3dpY3o=?=)
Date: Fri, 30 May 2014 08:24:16 +0200
Subject: [keycloak-dev] Keycloak Beta 1 Released
In-Reply-To: <5387811B.8090009@redhat.com>
References: <5387811B.8090009@redhat.com>
Message-ID: <53882410.2040805@redhat.com>

Congrats!

On 05/29/2014 08:48 PM, Bill Burke wrote:
> A lot of hard work!  A lot of new features and improvements.
>
> http://blog.keycloak.org/2014/05/29/keycloak-beta-1-released/
>



-- 
Boles?aw Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead

From mposolda at redhat.com  Fri May 30 03:09:01 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 30 May 2014 09:09:01 +0200
Subject: [keycloak-dev] Keycloak release process
In-Reply-To: <5387A4F1.1080304@redhat.com>
References: <5387A4F1.1080304@redhat.com>
Message-ID: <53882E8D.9010707@redhat.com>

oops, the current version in keycloak master seems to be "1.0-beta-1", I 
think should be updated to "1.0-beta-2-SNAPSHOT" ?

Marek

On 29.5.2014 23:21, Bill Burke wrote:
> FYI:
>
> https://github.com/keycloak/keycloak/wiki/Keycloak-release-process
>
>


From stian at redhat.com  Fri May 30 03:52:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 May 2014 03:52:51 -0400 (EDT)
Subject: [keycloak-dev] Keycloak release process
In-Reply-To: <53882E8D.9010707@redhat.com>
References: <5387A4F1.1080304@redhat.com> <53882E8D.9010707@redhat.com>
Message-ID: <348227510.17595042.1401436371464.JavaMail.zimbra@redhat.com>

Bumped to beta-2 snapshot

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Friday, 30 May, 2014 8:09:01 AM
> Subject: Re: [keycloak-dev] Keycloak release process
> 
> oops, the current version in keycloak master seems to be "1.0-beta-1", I
> think should be updated to "1.0-beta-2-SNAPSHOT" ?
> 
> Marek
> 
> On 29.5.2014 23:21, Bill Burke wrote:
> > FYI:
> >
> > https://github.com/keycloak/keycloak/wiki/Keycloak-release-process
> >
> >
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Fri May 30 03:57:20 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 30 May 2014 09:57:20 +0200
Subject: [keycloak-dev] Next step performance
In-Reply-To: <53878683.5060206@redhat.com>
References: <53878683.5060206@redhat.com>
Message-ID: <538839E0.1070408@redhat.com>

On 29.5.2014 21:12, Bill Burke wrote:
> I'd like to have a hangout next week on this.  There's really 4 areas to
> focus on:
>
> 1. Set up a good performance test and get a baseline on current code.
I've already did some performance tests longer time ago when comparing 
model implementations. Those are at "testsuite/performance" . These are 
just Java tests, which are directly using model API (no end-to-end HTTP 
tests ATM).

It's based on JMeter and it allows to configure number of concurrent 
workers and number of "iterations" for each worker. For example test for 
creating users with 10 workers and each worker creating 100 users means 
1000 created users in total. Also in property files you can configure 
number of users to create, realms where to create users etc.

Just figured out that tests doesn't work atm, but will try to possibly 
fix and send PR also with some instructions.

>
> 2. Database caching.  There are multiple approaches.
> * Our caches will be read-mostly except for user session management.
I think that in very big systems there might be also big number of user 
registrations . And each user can change his account, so it might be big 
number of edit actions, which can user done by himself (for example 
linking/unlinking social account).
> * Write our own REST cache.  My idea was to implement a new model
> provider that delegates to the real underlying model provider.  It would
> send RESTful invalidation messages secured by keycloak in a clustered
> environment.  Maybe use Infinispan or some other local-only cache as the
> backbone.  I'm really really wary of using Infinispan (or other cache's)
> clustering options.  I'm not sure how well these guys work in cloud
> clustered environments. And I'm not sure how well they've thought of
> security.
> * Use Hibernate 2nd level cache.  Really wary of this as I don't know
> how well Infinispan et. al. work in a cloud environment.  I'd really
> like something HTTP based and authenticated by Keycloak.  I'm not sure
> we'll be able to get the level of control here either that we need.
> * Another reason for a custom cache, is, IMO, almost everything can be
> stored in memory. Even users.
Reusing infinispan at last as local-only cache would be nice as it 
solves many other things, like for example eviction/expiration . It has 
also support for transactions (but if we want to use it, we may need to 
add JTA support...)

Creating our own model provider will add good control, but might be time 
consuming tasks . Tricky part is invalidation IMO. For example when you 
delete application, you should drop also all application roles, role 
memberships, scopes and scope memberships and userSession links to this 
application. In the end, it might drop almost whole cache:-)
But probably we need to focus especially on events, which will happen 
often (like creating new userSession or registering new user) and ensure 
that there is no invalidation of more things then needed in these 
cases.  But for example registration of new user should invalidate all 
user queries as well (I mean realm.getUsers() , realm.searchForUser and 
realm.searchForUserByuAttribute).

>
> 3. Clustering.
> * Keycloak is not completely stateless.  Specifically access codes are
> stored in memory.  We should be able to move this state information into
> a cookie.
> * User Session management is a huge issue as it is the only thing that
> is write-mostly.
There is also some state on SocialRequestManager .
>
> 4. HTTP Cache-Control
> * All themed static content should support a way to set up cache-control
> headers.
> * Admin REST api could do cache-control too if we had a way to determine
> a version number or timestamp on model data.  Not that important though
> as, IMO, admin rest api isn't going to have a lot of volume.
>
I would add "pagination" support. I think we need pagination at least 
for users, probably also for userSessions on clients (I mean 
clientModel.getUserSessions() ). Maybe also for AuditProvider query results.

Marek

From stian at redhat.com  Fri May 30 04:15:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 May 2014 04:15:39 -0400 (EDT)
Subject: [keycloak-dev] why doesnt import/expot use reps?
In-Reply-To: <53859BEA.5070302@redhat.com>
References: <537E0AD7.3010101@redhat.com> <53859BEA.5070302@redhat.com>
Message-ID: <399548004.17606763.1401437739170.JavaMail.zimbra@redhat.com>

A few things I'd like to see from this:

* One JSON representation for everything (this includes exports, admin console and examples)
* Use a serializing json provider when dumping the database
* Support dumping all realms or a specific realm to a single json file, also it would be nice to export users only
* Support importing the exported realms through the admin console
* Support splitting users into a separate file - this can also support pagination to have a specified amount of users per file
* JSON exports needs to have a version
* Database needs to have a version - so we can easily detect if the db is out of date and kill the server if it is
* Transformation pipeline for JSON representation of version 1 to version 2 to version 3, etc
* I think encrypting with bouncycastle would be better than winzipaes

This is an important feature, and should support the following use cases:

* Export the database to migrate to another Keycloak version
* Export the database for backup, or to extract the data from Keycloak (to prevent vendor lock-in)
* Import from other sources - for example someone that has an existing user-database could export their users to our format (we already have someone that's asked for this). I'd imagine this would be done by supporting import a users only export into an existing realm
* Export a specific realm for testing/demo purposes - this lets you create/configure a realm through the console, then export for future use

Lower priority, but things I'd also like to see:

* Automatically migrating database on startup / done by checking version in db, export to json, clear db, import from json - one caveat here is if we somehow manage to delete everything :/
* What to do if realm being imported already exists (skip, merge, overwrite, users-only, etc..)
* Import through the console / with single JSON representation we should already support importing single-file, but we should also add support for separate users file(s) and encrypted file

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 28 May, 2014 9:18:50 AM
> Subject: Re: [keycloak-dev] why doesnt import/expot use reps?
> 
> I assume that main purpose of export/import is especially migration of
> full DB from one environment to another, so it's a bit different than
> just importing JSON file like testrealm.json with few data related to
> one realm IMO.
> 
> My main worry is especially about performance. For example if you have
> realm with million users and want to migrate it, the resulting
> realm.json file will be very big and IMO it would be impossible to
> import it with current approach used in RealmManager.importRealm, which
> is doing whole import in 1 transaction and needs whole
> RealmRepresentation to be read into memory with all the data and all
> million users.
> 
> So that's why I used a bit different approach, which is doing import in
> few steps and should scale well even with very big amount of data.
> 
> Also some data in representations can't be used as they are because it's
> impossible to retrieve them from DB. For example
> CredentialRepresentation assumes password in plain-text, but DB doesn't
> contain password in plain-text. To workaround, I will need
> CredentialRepresentation to support both plain-text password and also
> hash+salt. Similarly for privateKey (if we ever have an SPI for secure
> store of private key). Is it fine to change CredentialRepresentation
> (and possibly other places) this way? Also I will need to add support
> for "id" into representations as export/import is exporting everything
> including ID of objects, but that's not a big issue though...
> 
> Also the stuff inside model/api is not used just by export/import, but
> also by Mongo model. Mongo is storing it's data in JSON like format and
> I am reusing same format for export/import. So we not to maintain more
> things than before. If you want to add new configuration option with
> getter+setter into Realm, you still have "just" 7 places to update :) (I
> count RealmModel, 2xRealmEntity, 2xRealmAdapter, RealmRepresentation and
> ModelToRepresentation)
> 
> I have already JIRA opened for investigation of using same format -
> https://issues.jboss.org/browse/KEYCLOAK-487 . I can also investigate
> the possibility to read data in stream instead of everything into memory
> like RealmRepresentation is doing.
> 
> Marek
> 
> On 22.5.2014 16:33, Bill Burke wrote:
> > We now have two different models for dealing with imports and two
> > different code paths too.  Why does import/export have its own json
> > model under model/api/...entities?  Why weren't the JSON representations
> > in keycloak-core/.../representations used?
> >
> > We already have code that converts between
> > keycloak-core/...representations and Models that is updated and
> > maintained.  We now have double the work to keep the export/import stuff
> > in sync too!
> >
> >
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri May 30 06:06:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 May 2014 06:06:15 -0400 (EDT)
Subject: [keycloak-dev] Next step performance
In-Reply-To: <53878683.5060206@redhat.com>
References: <53878683.5060206@redhat.com>
Message-ID: <106250783.17669732.1401444375903.JavaMail.zimbra@redhat.com>

Sent invite for Monday in Zimbra (15pm GMT). If that's not suitable let me know.

A few more areas to look at:

* Profile to find crappy code
* Tune FreeMarker and themes
* Sharding / sticky sessions - this is probably for later, but I'd like to discuss it in the hangout

A few comments on database caching:

* We may need to do this in stages
   - 2nd level cache for beta-2?
   - Something more advanced in after 1.0.final
* I'd don't like the idea of us re-inventing the wheel
   - Caching has a lot of complex considerations (node discovery, fail-over, node recovery, invalidation, lan/wan, jta, etc.)
* I really like the idea of having a cache model provider that delegates to another model for persistence / this is definitively the way to go IMO
* User sessions needs to separate considerations, specifically I think we can come up with something clever to minimise the writes required

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 29 May, 2014 8:12:03 PM
> Subject: [keycloak-dev] Next step performance
> 
> I'd like to have a hangout next week on this.  There's really 4 areas to
> focus on:
> 
> 1. Set up a good performance test and get a baseline on current code.
> 
> 2. Database caching.  There are multiple approaches.
> * Our caches will be read-mostly except for user session management.
> * Write our own REST cache.  My idea was to implement a new model
> provider that delegates to the real underlying model provider.  It would
> send RESTful invalidation messages secured by keycloak in a clustered
> environment.  Maybe use Infinispan or some other local-only cache as the
> backbone.  I'm really really wary of using Infinispan (or other cache's)
> clustering options.  I'm not sure how well these guys work in cloud
> clustered environments. And I'm not sure how well they've thought of
> security.
> * Use Hibernate 2nd level cache.  Really wary of this as I don't know
> how well Infinispan et. al. work in a cloud environment.  I'd really
> like something HTTP based and authenticated by Keycloak.  I'm not sure
> we'll be able to get the level of control here either that we need.
> * Another reason for a custom cache, is, IMO, almost everything can be
> stored in memory. Even users.
> 
> 3. Clustering.
> * Keycloak is not completely stateless.  Specifically access codes are
> stored in memory.  We should be able to move this state information into
> a cookie.
> * User Session management is a huge issue as it is the only thing that
> is write-mostly.
> 
> 4. HTTP Cache-Control
> * All themed static content should support a way to set up cache-control
> headers.
> * Admin REST api could do cache-control too if we had a way to determine
> a version number or timestamp on model data.  Not that important though
> as, IMO, admin rest api isn't going to have a lot of volume.
> 
> --
> 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
> 

From bburke at redhat.com  Fri May 30 07:25:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 30 May 2014 07:25:51 -0400
Subject: [keycloak-dev] Next step performance
In-Reply-To: <538839E0.1070408@redhat.com>
References: <53878683.5060206@redhat.com> <538839E0.1070408@redhat.com>
Message-ID: <53886ABF.3060908@redhat.com>



On 5/30/2014 3:57 AM, Marek Posolda wrote:
> On 29.5.2014 21:12, Bill Burke wrote:
>> I'd like to have a hangout next week on this.  There's really 4 areas to
>> focus on:
>>
>> 1. Set up a good performance test and get a baseline on current code.
> I've already did some performance tests longer time ago when comparing
> model implementations. Those are at "testsuite/performance" . These are
> just Java tests, which are directly using model API (no end-to-end HTTP
> tests ATM).
>
> It's based on JMeter and it allows to configure number of concurrent
> workers and number of "iterations" for each worker. For example test for
> creating users with 10 workers and each worker creating 100 users means
> 1000 created users in total. Also in property files you can configure
> number of users to create, realms where to create users etc.
>
> Just figured out that tests doesn't work atm, but will try to possibly
> fix and send PR also with some instructions.
>
>>
>> 2. Database caching.  There are multiple approaches.
>> * Our caches will be read-mostly except for user session management.
> I think that in very big systems there might be also big number of user
> registrations . And each user can change his account, so it might be big
> number of edit actions, which can user done by himself (for example
> linking/unlinking social account).
>> * Write our own REST cache.  My idea was to implement a new model
>> provider that delegates to the real underlying model provider.  It would
>> send RESTful invalidation messages secured by keycloak in a clustered
>> environment.  Maybe use Infinispan or some other local-only cache as the
>> backbone.  I'm really really wary of using Infinispan (or other cache's)
>> clustering options.  I'm not sure how well these guys work in cloud
>> clustered environments. And I'm not sure how well they've thought of
>> security.
>> * Use Hibernate 2nd level cache.  Really wary of this as I don't know
>> how well Infinispan et. al. work in a cloud environment.  I'd really
>> like something HTTP based and authenticated by Keycloak.  I'm not sure
>> we'll be able to get the level of control here either that we need.
>> * Another reason for a custom cache, is, IMO, almost everything can be
>> stored in memory. Even users.
> Reusing infinispan at last as local-only cache would be nice as it
> solves many other things, like for example eviction/expiration . It has
> also support for transactions (but if we want to use it, we may need to
> add JTA support...)
>
> Creating our own model provider will add good control, but might be time
> consuming tasks . Tricky part is invalidation IMO. For example when you
> delete application, you should drop also all application roles, role
> memberships, scopes and scope memberships and userSession links to this
> application. In the end, it might drop almost whole cache:-)

The thing is, we can be as fine-grain as we want.  If there is one 
update in the realm, we can drop the whole cache of the realm.  Our 
custom invalidation could be really really simple in that if there is an 
update, invalidate.


> But probably we need to focus especially on events, which will happen
> often (like creating new userSession or registering new user) and ensure
> that there is no invalidation of more things then needed in these
> cases.  But for example registration of new user should invalidate all
> user queries as well (I mean realm.getUsers() , realm.searchForUser and
> realm.searchForUserByuAttribute).
>
>>
>> 3. Clustering.
>> * Keycloak is not completely stateless.  Specifically access codes are
>> stored in memory.  We should be able to move this state information into
>> a cookie.
>> * User Session management is a huge issue as it is the only thing that
>> is write-mostly.
> There is also some state on SocialRequestManager .
>>
>> 4. HTTP Cache-Control
>> * All themed static content should support a way to set up cache-control
>> headers.
>> * Admin REST api could do cache-control too if we had a way to determine
>> a version number or timestamp on model data.  Not that important though
>> as, IMO, admin rest api isn't going to have a lot of volume.
>>
> I would add "pagination" support. I think we need pagination at least
> for users, probably also for userSessions on clients (I mean
> clientModel.getUserSessions() ). Maybe also for AuditProvider query results.
>

Ah thanks.  Pagination yes.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri May 30 07:29:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 30 May 2014 07:29:23 -0400
Subject: [keycloak-dev] Next step performance
In-Reply-To: <106250783.17669732.1401444375903.JavaMail.zimbra@redhat.com>
References: <53878683.5060206@redhat.com>
	<106250783.17669732.1401444375903.JavaMail.zimbra@redhat.com>
Message-ID: <53886B93.4000201@redhat.com>



On 5/30/2014 6:06 AM, Stian Thorgersen wrote:
> Sent invite for Monday in Zimbra (15pm GMT). If that's not suitable let me know.
>
> A few more areas to look at:
>
> * Profile to find crappy code
> * Tune FreeMarker and themes
> * Sharding / sticky sessions - this is probably for later, but I'd like to discuss it in the hangout
>
> A few comments on database caching:
>
> * We may need to do this in stages
>     - 2nd level cache for beta-2?
>     - Something more advanced in after 1.0.final
> * I'd don't like the idea of us re-inventing the wheel
>     - Caching has a lot of complex considerations (node discovery, fail-over, node recovery, invalidation, lan/wan, jta, etc.)

I know and agree and have experience with this.  But, these traditional 
caches just don't work well in many environments.

> * I really like the idea of having a cache model provider that delegates to another model for persistence / this is definitively the way to go IMO
> * User sessions needs to separate considerations, specifically I think we can come up with something clever to minimise the writes required
>

Yes, User sessions are a special case.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri May 30 08:17:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 May 2014 08:17:43 -0400 (EDT)
Subject: [keycloak-dev] Next step performance
In-Reply-To: <53886B93.4000201@redhat.com>
References: <53878683.5060206@redhat.com>
	<106250783.17669732.1401444375903.JavaMail.zimbra@redhat.com>
	<53886B93.4000201@redhat.com>
Message-ID: <1354205697.17740746.1401452263126.JavaMail.zimbra@redhat.com>

FIY I've started looking at caching FreeMarker templates and cache-control for static content

----- 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, 30 May, 2014 12:29:23 PM
> Subject: Re: [keycloak-dev] Next step performance
> 
> 
> 
> On 5/30/2014 6:06 AM, Stian Thorgersen wrote:
> > Sent invite for Monday in Zimbra (15pm GMT). If that's not suitable let me
> > know.
> >
> > A few more areas to look at:
> >
> > * Profile to find crappy code
> > * Tune FreeMarker and themes
> > * Sharding / sticky sessions - this is probably for later, but I'd like to
> > discuss it in the hangout
> >
> > A few comments on database caching:
> >
> > * We may need to do this in stages
> >     - 2nd level cache for beta-2?
> >     - Something more advanced in after 1.0.final
> > * I'd don't like the idea of us re-inventing the wheel
> >     - Caching has a lot of complex considerations (node discovery,
> >     fail-over, node recovery, invalidation, lan/wan, jta, etc.)
> 
> I know and agree and have experience with this.  But, these traditional
> caches just don't work well in many environments.
> 
> > * I really like the idea of having a cache model provider that delegates to
> > another model for persistence / this is definitively the way to go IMO
> > * User sessions needs to separate considerations, specifically I think we
> > can come up with something clever to minimise the writes required
> >
> 
> Yes, User sessions are a special case.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From gcardoso at redhat.com  Fri May 30 10:35:36 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Fri, 30 May 2014 11:35:36 -0300
Subject: [keycloak-dev] Keycloak Beta 1 Released
In-Reply-To: <53882410.2040805@redhat.com>
References: <5387811B.8090009@redhat.com> <53882410.2040805@redhat.com>
Message-ID: <900014B2-3C05-486E-9606-16C3441A5A75@redhat.com>

Congratulations folks!

On May 30, 2014, at 3:24 AM, Boles?aw Dawidowicz <bdawidow at redhat.com> wrote:

> Congrats!
> 
> On 05/29/2014 08:48 PM, Bill Burke wrote:
>> A lot of hard work!  A lot of new features and improvements.
>> 
>> http://blog.keycloak.org/2014/05/29/keycloak-beta-1-released/
>> 
> 
> 
> 
> -- 
> Boles?aw Dawidowicz
> JBoss Portal Platform Architect | GateIn Portal Project Lead
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140530/831ade85/attachment.html 

From psilva at redhat.com  Fri May 30 10:45:11 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 30 May 2014 10:45:11 -0400 (EDT)
Subject: [keycloak-dev] Keycloak Beta 1 Released
In-Reply-To: <900014B2-3C05-486E-9606-16C3441A5A75@redhat.com>
References: <5387811B.8090009@redhat.com> <53882410.2040805@redhat.com>
	<900014B2-3C05-486E-9606-16C3441A5A75@redhat.com>
Message-ID: <87719720.14522683.1401461111668.JavaMail.zimbra@redhat.com>

Congrats !

----- Original Message -----
From: "Gabriel Cardoso" <gcardoso at redhat.com>
To: "Boles?aw Dawidowicz" <bdawidow at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Friday, May 30, 2014 11:35:36 AM
Subject: Re: [keycloak-dev] Keycloak Beta 1 Released

Congratulations folks! 

On May 30, 2014, at 3:24 AM, Boles?aw Dawidowicz < bdawidow at redhat.com > wrote: 



Congrats! 

On 05/29/2014 08:48 PM, Bill Burke wrote: 


A lot of hard work! A lot of new features and improvements. 

http://blog.keycloak.org/2014/05/29/keycloak-beta-1-released/ 




-- 
Boles?aw Dawidowicz 
JBoss Portal Platform Architect | GateIn Portal Project Lead 
_______________________________________________ 
keycloak-dev mailing list 
keycloak-dev at lists.jboss.org 
https://lists.jboss.org/mailman/listinfo/keycloak-dev 

--- 
Gabriel Cardoso 
User Experience Designer @ Red Hat 


_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From amendonc at redhat.com  Fri May 30 12:00:36 2014
From: amendonc at redhat.com (=?utf-8?Q?Alexandre_Mendon=C3=A7a?=)
Date: Fri, 30 May 2014 17:00:36 +0100
Subject: [keycloak-dev] Keycloak Beta 1 Released
In-Reply-To: <5387811B.8090009@redhat.com>
References: <5387811B.8090009@redhat.com>
Message-ID: <etPan.5388ab24.238e1f29.5882@trojan.local>

Congratulations guys, really good stuff!
__
Alexandre Mendon?a


On 29 May 2014 at 19:49:01, Bill Burke (bburke at redhat.com) wrote:

A lot of hard work! A lot of new features and improvements.  

http://blog.keycloak.org/2014/05/29/keycloak-beta-1-released/  

--  
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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140530/7e3208d0/attachment.html 

From stian at redhat.com  Fri May 30 12:02:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 May 2014 12:02:38 -0400 (EDT)
Subject: [keycloak-dev] Next step performance
In-Reply-To: <1354205697.17740746.1401452263126.JavaMail.zimbra@redhat.com>
References: <53878683.5060206@redhat.com>
	<106250783.17669732.1401444375903.JavaMail.zimbra@redhat.com>
	<53886B93.4000201@redhat.com>
	<1354205697.17740746.1401452263126.JavaMail.zimbra@redhat.com>
Message-ID: <923450065.18020212.1401465758451.JavaMail.zimbra@redhat.com>

Cache-control made a huge difference - halved the load time of the login screen!

Caching FreeMarker templates made much less of a difference (~10%). I'm a bit disappointed as I thought it would be a bigger win (it did load and parse 2-3 files templates for each page). 

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 30 May, 2014 1:17:43 PM
> Subject: Re: [keycloak-dev] Next step performance
> 
> FIY I've started looking at caching FreeMarker templates and cache-control
> for static content
> 
> ----- 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, 30 May, 2014 12:29:23 PM
> > Subject: Re: [keycloak-dev] Next step performance
> > 
> > 
> > 
> > On 5/30/2014 6:06 AM, Stian Thorgersen wrote:
> > > Sent invite for Monday in Zimbra (15pm GMT). If that's not suitable let
> > > me
> > > know.
> > >
> > > A few more areas to look at:
> > >
> > > * Profile to find crappy code
> > > * Tune FreeMarker and themes
> > > * Sharding / sticky sessions - this is probably for later, but I'd like
> > > to
> > > discuss it in the hangout
> > >
> > > A few comments on database caching:
> > >
> > > * We may need to do this in stages
> > >     - 2nd level cache for beta-2?
> > >     - Something more advanced in after 1.0.final
> > > * I'd don't like the idea of us re-inventing the wheel
> > >     - Caching has a lot of complex considerations (node discovery,
> > >     fail-over, node recovery, invalidation, lan/wan, jta, etc.)
> > 
> > I know and agree and have experience with this.  But, these traditional
> > caches just don't work well in many environments.
> > 
> > > * I really like the idea of having a cache model provider that delegates
> > > to
> > > another model for persistence / this is definitively the way to go IMO
> > > * User sessions needs to separate considerations, specifically I think we
> > > can come up with something clever to minimise the writes required
> > >
> > 
> > Yes, User sessions are a special case.
> > 
> > --
> > 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
>