From mcaspers at redhat.com  Sun Feb  2 15:56:48 2014
From: mcaspers at redhat.com (Matt Casperson)
Date: Sun, 2 Feb 2014 15:56:48 -0500 (EST)
Subject: [keycloak-dev] SAML as social login?
In-Reply-To: <2118799794.11654134.1391373932443.JavaMail.root@redhat.com>
Message-ID: <673263009.11654303.1391374608185.JavaMail.root@redhat.com>

If I am reading https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java correctly, the only thing needed for a Keycloak social login is a URL to a login page that the user can be directed to when they are not logged in, and to have that login page send back a response that Keycloak can use to verify the user and get their details. 

So if I had appropriate permissions to use https://saml.redhat.com/idp/, could that be added as a social login? 

Regards 

Matthew Casperson 
RHCE, RHCJA # 111-072-237 
Engineering Content Services 
Brisbane, Australia 

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

From stian at redhat.com  Mon Feb  3 04:51:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 3 Feb 2014 04:51:14 -0500 (EST)
Subject: [keycloak-dev] when next release
In-Reply-To: <E6BD6063-2510-4240-B46D-E2F5E4F358F8@redhat.com>
References: <52EA705A.1090303@redhat.com>
	<DEC6E3E4-AFCE-4634-B93D-49364F026BEF@redhat.com>
	<724709703.16542392.1391099569069.JavaMail.root@redhat.com>
	<6B6B493F-1AB7-48D6-9A4C-BD4D38EE6DB6@redhat.com>
	<1098440394.16892910.1391158365974.JavaMail.root@redhat.com>
	<E6BD6063-2510-4240-B46D-E2F5E4F358F8@redhat.com>
Message-ID: <1052497834.17635048.1391421074844.JavaMail.root@redhat.com>

Yeah, that looks nice :)

----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 31 January, 2014 5:43:13 PM
> Subject: Re: [keycloak-dev] when next release
> 
> I?ve refined your quick mockup and it really looks better.
> 
> IMO we can go with this version.
> 
> Gabriel
> 
> 
> 
> 
> On Jan 31, 2014, at 6:52 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > The RCUE recommended selector looks better
> > 
> > Why not use the color scheme from the login page in the border? Attached a
> > quick mock-up. IMO that looks better.
> > 
> > "move to RCUE styles first" - We should use the widgets provided on that
> > page, as well as the css from https://github.com/rhamilto/rcue. That way
> > we don't have to maintain the css ourselves + we know for sure it's
> > compatible.
> > 
> > ----- Original Message -----
> >> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 30 January, 2014 7:14:07 PM
> >> Subject: Re: [keycloak-dev] when next release
> >> 
> >> 
> >> 
> >> With regards to changes I think we should move to RCUE styles first, and
> >> apply the changes in the way they recommend changing it. As I've said I'm
> >> not happy with the new design for it either.
> >> 
> >> What exactly do you mean by ?move to RCUE styles first?? Changing the
> >> markup
> >> according to the widgets provided in this page?
> >> http://rcue-uxd.itos.redhat.com/widgets/
> >> 
> >> The visual design is following RCUE. I just see two details that should be
> >> changed:
> >> - Align the labels to the right and make it bold (see ?forms? section in
> >> widgets)
> >> - Change the realm selector (dropdown) to their context selector (below)
> >> 
> >> 
> >> With regards to the design, I updated the colour of the lighter bar.
> >> 
> >> 
> >> And make a version with the RCUE recommended selector:
> >> 
> >> 
> >> What do you think?
> >> 
> >> Gabriel
> >> 
> >> ---
> >> 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
> > <customization.jpg>
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 

From bdawidow at redhat.com  Tue Feb  4 03:21:06 2014
From: bdawidow at redhat.com (=?UTF-8?B?Qm9sZXPFgmF3IERhd2lkb3dpY3o=?=)
Date: Tue, 04 Feb 2014 09:21:06 +0100
Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
In-Reply-To: <20140130141357.4b609bf8@kapy-ntb-x220>
References: <20140130095345.2f02b639@kapy-ntb-x220>	<716351205.16276132.1391077327802.JavaMail.root@redhat.com>
	<20140130141357.4b609bf8@kapy-ntb-x220>
Message-ID: <52F0A2F2.70508@redhat.com>

On 01/30/2014 02:13 PM, Karel Piwko wrote:
> I did some checks and there is some work needed:
>
> 1/ According to Maven Central rules, there should not be any <repository>
> elements in pom.xml files

This is the rule that no one obeys on our side. In the end it is not 
practical. What happens is that one of your transient deps has 
<repository> element and you inherit it - you just have no clue from where.

> 2/ When I removed them, org.jboss.web:jbossweb:jar:7.0.17.Final is not
> available no Maven Central
>
> So, following steps are needed:
>
> * figure out whether jbossweb dependency could be replaced by something else,
>    if not - it has to undergo same checks as keycloak and be synced to Maven
>    Central or, which I prefer, to release it relocated to org.keycloak groupId.
>    Given that 7.0.17.Final has do external dependencies at all -
>    seems much easier then trying to convince sonatype to pick a single version
>    of jbossweb tree
> * remove all <repositories> from pom.xml files
>
> Then, 1.0-alpha-2 and further releases can be synced to Maven Central. Sonatype
> might apply more rules but project looks in good shape Maven-wise IMO.
>
> Karel
>
> On Thu, 30 Jan 2014 05:22:07 -0500 (EST)
> Stian Thorgersen <stian at redhat.com> wrote:
>
>> That'd be great
>>
>> ----- Original Message -----
>>> From: "Karel Piwko" <kpiwko at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 30 January, 2014 8:53:45 AM
>>> Subject: [keycloak-dev] Keycloak artifacts not in Maven Central
>>>
>>> Hi,
>>>
>>> I've noticed that Keycloak Maven artifacts are not synced to Maven Central,
>>> they are only on JBoss Nexus. Do you plan to sync them to Central?
>>>
>>> Let me know if so, I can help with that.
>>>
>>> Karel
>>> _______________________________________________
>>> 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 stian at redhat.com  Tue Feb  4 07:30:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 4 Feb 2014 07:30:53 -0500 (EST)
Subject: [keycloak-dev] SAML as social login?
In-Reply-To: <673263009.11654303.1391374608185.JavaMail.root@redhat.com>
References: <673263009.11654303.1391374608185.JavaMail.root@redhat.com>
Message-ID: <584811480.18681956.1391517053239.JavaMail.root@redhat.com>

In theory that should work. The social login feature at the moment has only been tested for OAuth and OAuth2 providers, so may need some tweaking for a SAML provider.

We're also assuming that a social provider is able to retrieve a basic user profile (https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java#L85), but you could just return a username and require users to update their profile on first social login ("Update profile on first social login" option on realm settings in admin console). 

In the future we plan to provide support for federation of authentication (other Keycloak realms, SAML, LDAP, etc.), but this is a good way to get something working with what Keycloak provides at the moment.

By the way at the moment the admin console has a hard-coded list of social providers, but in the next release this will be dynamic. So all you'd need is to add a jar that implements the social provider spi, and it will be available to configure it for a realm through the admin console.

----- Original Message -----
> From: "Matt Casperson" <mcaspers at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, 2 February, 2014 8:56:48 PM
> Subject: [keycloak-dev] SAML as social login?
> 
> If I am reading
> https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java
> correctly, the only thing needed for a Keycloak social login is a URL to a
> login page that the user can be directed to when they are not logged in, and
> to have that login page send back a response that Keycloak can use to verify
> the user and get their details.
> 
> So if I had appropriate permissions to use https://saml.redhat.com/idp/,
> could that be added as a social login?
> 
> Regards
> 
> Matthew Casperson
> RHCE, RHCJA # 111-072-237
> Engineering Content Services
> Brisbane, Australia
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Tue Feb  4 10:26:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Feb 2014 10:26:49 -0500
Subject: [keycloak-dev] SAML as social login?
In-Reply-To: <584811480.18681956.1391517053239.JavaMail.root@redhat.com>
References: <673263009.11654303.1391374608185.JavaMail.root@redhat.com>
	<584811480.18681956.1391517053239.JavaMail.root@redhat.com>
Message-ID: <52F106B9.2050106@redhat.com>

I guess this would be interesting in the case where your federated IDP 
didn't have role and session mgmt, single sign off, oauth/openid connect 
support?  Would Keycloak offer enough value add in this scenario?

On 2/4/2014 7:30 AM, Stian Thorgersen wrote:
> In theory that should work. The social login feature at the moment has only been tested for OAuth and OAuth2 providers, so may need some tweaking for a SAML provider.
>
> We're also assuming that a social provider is able to retrieve a basic user profile (https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java#L85), but you could just return a username and require users to update their profile on first social login ("Update profile on first social login" option on realm settings in admin console).
>
> In the future we plan to provide support for federation of authentication (other Keycloak realms, SAML, LDAP, etc.), but this is a good way to get something working with what Keycloak provides at the moment.
>
> By the way at the moment the admin console has a hard-coded list of social providers, but in the next release this will be dynamic. So all you'd need is to add a jar that implements the social provider spi, and it will be available to configure it for a realm through the admin console.
>
> ----- Original Message -----
>> From: "Matt Casperson" <mcaspers at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Sunday, 2 February, 2014 8:56:48 PM
>> Subject: [keycloak-dev] SAML as social login?
>>
>> If I am reading
>> https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java
>> correctly, the only thing needed for a Keycloak social login is a URL to a
>> login page that the user can be directed to when they are not logged in, and
>> to have that login page send back a response that Keycloak can use to verify
>> the user and get their details.
>>
>> So if I had appropriate permissions to use https://saml.redhat.com/idp/,
>> could that be added as a social login?
>>
>> Regards
>>
>> Matthew Casperson
>> RHCE, RHCJA # 111-072-237
>> Engineering Content Services
>> Brisbane, Australia
>>
>>
>> _______________________________________________
>> 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  Tue Feb  4 10:29:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 4 Feb 2014 10:29:08 -0500 (EST)
Subject: [keycloak-dev] SAML as social login?
In-Reply-To: <52F106B9.2050106@redhat.com>
References: <673263009.11654303.1391374608185.JavaMail.root@redhat.com>
	<584811480.18681956.1391517053239.JavaMail.root@redhat.com>
	<52F106B9.2050106@redhat.com>
Message-ID: <2122720506.18805504.1391527748827.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 4 February, 2014 3:26:49 PM
> Subject: Re: [keycloak-dev] SAML as social login?
> 
> I guess this would be interesting in the case where your federated IDP
> didn't have role and session mgmt, single sign off, oauth/openid connect
> support?  Would Keycloak offer enough value add in this scenario?

Anything to prevent users from having to maintain multiple usernames and passwords is a good thing IMO

> 
> On 2/4/2014 7:30 AM, Stian Thorgersen wrote:
> > In theory that should work. The social login feature at the moment has only
> > been tested for OAuth and OAuth2 providers, so may need some tweaking for
> > a SAML provider.
> >
> > We're also assuming that a social provider is able to retrieve a basic user
> > profile
> > (https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java#L85),
> > but you could just return a username and require users to update their
> > profile on first social login ("Update profile on first social login"
> > option on realm settings in admin console).
> >
> > In the future we plan to provide support for federation of authentication
> > (other Keycloak realms, SAML, LDAP, etc.), but this is a good way to get
> > something working with what Keycloak provides at the moment.
> >
> > By the way at the moment the admin console has a hard-coded list of social
> > providers, but in the next release this will be dynamic. So all you'd need
> > is to add a jar that implements the social provider spi, and it will be
> > available to configure it for a realm through the admin console.
> >
> > ----- Original Message -----
> >> From: "Matt Casperson" <mcaspers at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Sunday, 2 February, 2014 8:56:48 PM
> >> Subject: [keycloak-dev] SAML as social login?
> >>
> >> If I am reading
> >> https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java
> >> correctly, the only thing needed for a Keycloak social login is a URL to a
> >> login page that the user can be directed to when they are not logged in,
> >> and
> >> to have that login page send back a response that Keycloak can use to
> >> verify
> >> the user and get their details.
> >>
> >> So if I had appropriate permissions to use https://saml.redhat.com/idp/,
> >> could that be added as a social login?
> >>
> >> Regards
> >>
> >> Matthew Casperson
> >> RHCE, RHCJA # 111-072-237
> >> Engineering Content Services
> >> Brisbane, Australia
> >>
> >>
> >> _______________________________________________
> >> 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  Tue Feb  4 10:35:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Feb 2014 10:35:08 -0500
Subject: [keycloak-dev] SAML as social login?
In-Reply-To: <2122720506.18805504.1391527748827.JavaMail.root@redhat.com>
References: <673263009.11654303.1391374608185.JavaMail.root@redhat.com>
	<584811480.18681956.1391517053239.JavaMail.root@redhat.com>
	<52F106B9.2050106@redhat.com>
	<2122720506.18805504.1391527748827.JavaMail.root@redhat.com>
Message-ID: <52F108AC.30102@redhat.com>



On 2/4/2014 10:29 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 4 February, 2014 3:26:49 PM
>> Subject: Re: [keycloak-dev] SAML as social login?
>>
>> I guess this would be interesting in the case where your federated IDP
>> didn't have role and session mgmt, single sign off, oauth/openid connect
>> support?  Would Keycloak offer enough value add in this scenario?
>
> Anything to prevent users from having to maintain multiple usernames and passwords is a good thing IMO
>

I'm saying that why would you use Keycloak if you already had a SAML 
IDP?  Does Keycloak provide enough additional value-add in that scenario 
to justify us making a SAML "social" connector a priority?

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

From stian at redhat.com  Tue Feb  4 10:49:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 4 Feb 2014 10:49:04 -0500 (EST)
Subject: [keycloak-dev] SAML as social login?
In-Reply-To: <52F108AC.30102@redhat.com>
References: <673263009.11654303.1391374608185.JavaMail.root@redhat.com>
	<584811480.18681956.1391517053239.JavaMail.root@redhat.com>
	<52F106B9.2050106@redhat.com>
	<2122720506.18805504.1391527748827.JavaMail.root@redhat.com>
	<52F108AC.30102@redhat.com>
Message-ID: <485597124.18816756.1391528944527.JavaMail.root@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, 4 February, 2014 3:35:08 PM
> Subject: Re: [keycloak-dev] SAML as social login?
> 
> 
> 
> On 2/4/2014 10:29 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 4 February, 2014 3:26:49 PM
> >> Subject: Re: [keycloak-dev] SAML as social login?
> >>
> >> I guess this would be interesting in the case where your federated IDP
> >> didn't have role and session mgmt, single sign off, oauth/openid connect
> >> support?  Would Keycloak offer enough value add in this scenario?
> >
> > Anything to prevent users from having to maintain multiple usernames and
> > passwords is a good thing IMO
> >
> 
> I'm saying that why would you use Keycloak if you already had a SAML
> IDP?  Does Keycloak provide enough additional value-add in that scenario
> to justify us making a SAML "social" connector a priority?

I think it's a nice feature to allow users login with their account on a different provider (whether or not its a KC realm, Google+, or a SAML IDP). 

Also, shouldn't jboss.org be counted as one of the social "networks" we support? I think adding some more professional social networks such as LinkedIn, GitHub and jboss.org! would be good.

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

From stian at redhat.com  Tue Feb  4 11:39:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 4 Feb 2014 11:39:51 -0500 (EST)
Subject: [keycloak-dev] JIRA
In-Reply-To: <989154895.18886748.1391531881825.JavaMail.root@redhat.com>
Message-ID: <1536544254.18902054.1391531991903.JavaMail.root@redhat.com>

I've had a scan through JIRA to clean-up some old issues. There's two issues I think we can close, but I'm not 100% sure:

- https://issues.jboss.org/browse/KEYCLOAK-54
- https://issues.jboss.org/browse/KEYCLOAK-187

Now that we have our first release out and started getting users it would be good to improve our JIRA usage a bit. JIRA issues are helpful to create a road-map, so all bug fixes and new features should have a JIRA issue.

From bburke at redhat.com  Tue Feb  4 11:41:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Feb 2014 11:41:23 -0500
Subject: [keycloak-dev] JIRA
In-Reply-To: <1536544254.18902054.1391531991903.JavaMail.root@redhat.com>
References: <1536544254.18902054.1391531991903.JavaMail.root@redhat.com>
Message-ID: <52F11833.8060009@redhat.com>

Bruno added some better password hashing.  keep 54 open as there's still 
subsystem work to do even though we have an adapter.

On 2/4/2014 11:39 AM, Stian Thorgersen wrote:
> I've had a scan through JIRA to clean-up some old issues. There's two issues I think we can close, but I'm not 100% sure:
>
> - https://issues.jboss.org/browse/KEYCLOAK-54
> - https://issues.jboss.org/browse/KEYCLOAK-187
>
> Now that we have our first release out and started getting users it would be good to improve our JIRA usage a bit. JIRA issues are helpful to create a road-map, so all bug fixes and new features should have a JIRA issue.
> _______________________________________________
> 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 kpiwko at redhat.com  Tue Feb  4 12:13:39 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Tue, 4 Feb 2014 18:13:39 +0100
Subject: [keycloak-dev] Aerogear UPS + Keycloak cartridge combined together
	POC
Message-ID: <20140204181339.60267f2c@kapy-ntb-x220>

Hey,

I've combined Aerogear UPS and Keycloak cartridges together. You can check the
results at:

https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
https://keycloak-mobileqa.rhcloud.com/ (admin/password)

For keycloak, I have used original cart [1]:

$ rhc app create -g small --no-git keycloak
https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml

For UPS, I have modified matzew's one stored in my repo [2] and modified UPS
[3]:

$ rhc app create -g small --no-git agpushkeycloak mysql-5.1
'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75'

There are some gotchas though:

* keycloak.json - I'm not sure how this will be addressed by WF subsystem. We
  still need a way how to pass keycloak.json to UPS cartridge, which is AS7
  and we can't ask user to modify standalone.xml anyway. However, we could make
  a hook on OpenShift - user will add keycloak.json to git repo and it will
  automagically put at right location. Could we have a hook in Keycloak to
  load keycloak.json from external location? Or should we rather do some war
  exploding magic?
* AS7-3227 I worked this around by doing parameter injection for
  SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of Keycloak
  package for AS7? Any better option?
* Ember in UPS is firing AJAX request to REST Endpoints on the same domain.
  However, as it goes through Keycloak Auth Server, this is considered CORS
  request. I had to configure Web Origin for UPS application. This is
  confusing to me, Origin header should be transparent for Keycloak as I'm
  firing request to the same domain. Note this does not happen in Firefox,
  which identifies same domain and avoids Origin header. I need some insight
  here from more skilled people.
* I wasn't able to keep http->https rewriting valve with Keycloak to avoid UPS
  usage via http protocol. I'll go deeper into that.
* Changes to Web Origin in Keycloak admin UI are not reflected to already logged
  users. They need to log out first.
* Missing logout button in UPS. Related to previous point.

Let me know if you want me to convert some of these points to JIRAs in AGPUSH
or KEYCLOAK projects. Also, let me please now if I should have configured
something differently.

Thanks,

Karel

[1] https://github.com/stianst/openshift-keycloak-cartridge
[2]
https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/keycloak
[3] 
https://github.com/kpiwko/aerogear-unifiedpush-server/tree/keycloak-openshift

More detailed steps:

1/ Create Keycloak cart
2/ Add AeroGear-UnifiedPush realm with roles admin, user
3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart
location
4/ Get keycloak.json
5/ Enable CORS in keycloak.json, modify password
6/ Add keycloak.json to aerogear-unifiedpush-server/src/main/webapp/WEB-INF
7/ Package UPS via 'mvn clean package'
8/ Put war into
openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments
9/ Push that online
10/ Create UPS cart using reflector cartridge (use commit sha1 if not using
master), enable mysql-5.1 gear as well
11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm
12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee.



From matzew at apache.org  Tue Feb  4 12:21:10 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 4 Feb 2014 18:21:10 +0100
Subject: [keycloak-dev] [aerogear-dev] Aerogear UPS + Keycloak cartridge
 combined together POC
In-Reply-To: <CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
Message-ID: <CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>

oh, this was a cross-post :-) (adding keycloak)


On Tue, Feb 4, 2014 at 6:20 PM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko <kpiwko at redhat.com> wrote:
>
>> Hey,
>>
>> I've combined Aerogear UPS and Keycloak cartridges together. You can
>> check the
>> results at:
>>
>> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
>> https://keycloak-mobileqa.rhcloud.com/ (admin/password)
>>
>>
> I think it would be awesome if the keycloak bits would be included into
> the UPS bits, to have something OOTB, instead of pointing to a different
> server (CORS)
>
>
>> For keycloak, I have used original cart [1]:
>>
>> $ rhc app create -g small --no-git keycloak
>>
>> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
>>
>> For UPS, I have modified matzew's one stored in my repo [2] and modified
>> UPS
>> [3]:
>>
>> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1
>> '
>> http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75
>> '
>>
>> There are some gotchas though:
>>
>> * keycloak.json - I'm not sure how this will be addressed by WF subsystem.
>
>
> the public-key needs to be, as far as I can see, included inside of the
> standalone.xml (keycloak subsystem section).
> Which is somewhat a similar issue; I think, if I get it right, that means
> as you plan to support more and more 'realms', you keep editing the
> standalone xml.
>
>
>> We
>>   still need a way how to pass keycloak.json to UPS cartridge, which is
>> AS7
>>   and we can't ask user to modify standalone.xml anyway. However, we
>> could make
>>   a hook on OpenShift - user will add keycloak.json to git repo and it
>> will
>>   automagically put at right location. Could we have a hook in Keycloak to
>>   load keycloak.json from external location? Or should we rather do some
>> war
>>   exploding magic?
>> * AS7-3227 I worked this around by doing parameter injection for
>>   SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of
>> Keycloak
>>   package for AS7? Any better option?
>> * Ember in UPS is firing AJAX request to REST Endpoints on the same
>> domain.
>>   However, as it goes through Keycloak Auth Server, this is considered
>> CORS
>>   request. I had to configure Web Origin for UPS application. This is
>>   confusing to me, Origin header should be transparent for Keycloak as I'm
>>   firing request to the same domain. Note this does not happen in Firefox,
>>   which identifies same domain and avoids Origin header. I need some
>> insight
>>   here from more skilled people.
>>
>
> hmmmmm .... sounds 'good' :-)
>
>
>> * I wasn't able to keep http->https rewriting valve with Keycloak to
>> avoid UPS
>>   usage via http protocol. I'll go deeper into that.
>>
>
> https is enforced on our UPS cartridge
>
>
>> * Changes to Web Origin in Keycloak admin UI are not reflected to already
>> logged
>>   users. They need to log out first.
>> * Missing logout button in UPS. Related to previous point.
>>
>> Let me know if you want me to convert some of these points to JIRAs in
>> AGPUSH
>> or KEYCLOAK projects. Also, let me please now if I should have configured
>> something differently.
>>
>> Thanks,
>>
>> Karel
>>
>> [1] https://github.com/stianst/openshift-keycloak-cartridge
>> [2]
>>
>> https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/keycloak
>> [3]
>>
>> https://github.com/kpiwko/aerogear-unifiedpush-server/tree/keycloak-openshift
>>
>> More detailed steps:
>>
>> 1/ Create Keycloak cart
>> 2/ Add AeroGear-UnifiedPush realm with roles admin, user
>> 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart
>> location
>> 4/ Get keycloak.json
>> 5/ Enable CORS in keycloak.json, modify password
>> 6/ Add keycloak.json to
>> aerogear-unifiedpush-server/src/main/webapp/WEB-INF
>> 7/ Package UPS via 'mvn clean package'
>> 8/ Put war into
>>
>> openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments
>> 9/ Push that online
>> 10/ Create UPS cart using reflector cartridge (use commit sha1 if not
>> using
>> master), enable mysql-5.1 gear as well
>> 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm
>> 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee.
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140204/7ebc93e2/attachment.html 

From kpiwko at redhat.com  Tue Feb  4 12:34:37 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Tue, 4 Feb 2014 18:34:37 +0100
Subject: [keycloak-dev] [aerogear-dev] Aerogear UPS + Keycloak cartridge
 combined together POC
In-Reply-To: <CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
	<CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>
Message-ID: <20140204183437.0737d77f@kapy-ntb-x220>

On Tue, 4 Feb 2014 18:21:10 +0100
Matthias Wessendorf <matzew at apache.org> wrote:

> oh, this was a cross-post :-) (adding keycloak)
> 
> 
> On Tue, Feb 4, 2014 at 6:20 PM, Matthias Wessendorf <matzew at apache.org>wrote:
> 
> >
> >
> >
> > On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> >
> >> Hey,
> >>
> >> I've combined Aerogear UPS and Keycloak cartridges together. You can
> >> check the
> >> results at:
> >>
> >> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
> >> https://keycloak-mobileqa.rhcloud.com/ (admin/password)
> >>
> >>
> > I think it would be awesome if the keycloak bits would be included into
> > the UPS bits, to have something OOTB, instead of pointing to a different
> > server (CORS)

I've added Keycloak AS7 modules to UPS cart but not admin console. I believe
that Keycloak is SaaS, so usage with two different carts reflect reality better.
Configuring Keycloak cart once and let all other carts use is seems the right
way to me.

> >
> >
> >> For keycloak, I have used original cart [1]:
> >>
> >> $ rhc app create -g small --no-git keycloak
> >>
> >> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
> >>
> >> For UPS, I have modified matzew's one stored in my repo [2] and modified
> >> UPS
> >> [3]:
> >>
> >> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1
> >> '
> >> http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75
> >> '
> >>
> >> There are some gotchas though:
> >>
> >> * keycloak.json - I'm not sure how this will be addressed by WF subsystem.
> >
> >
> > the public-key needs to be, as far as I can see, included inside of the
> > standalone.xml (keycloak subsystem section).
> > Which is somewhat a similar issue; I think, if I get it right, that means
> > as you plan to support more and more 'realms', you keep editing the
> > standalone xml.

That is great improvement w.r.t. current situation but does not handle OpenShift
cart scenarios.

> >
> >
> >> We
> >>   still need a way how to pass keycloak.json to UPS cartridge, which is
> >> AS7
> >>   and we can't ask user to modify standalone.xml anyway. However, we
> >> could make
> >>   a hook on OpenShift - user will add keycloak.json to git repo and it
> >> will
> >>   automagically put at right location. Could we have a hook in Keycloak to
> >>   load keycloak.json from external location? Or should we rather do some
> >> war
> >>   exploding magic?
> >> * AS7-3227 I worked this around by doing parameter injection for
> >>   SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of
> >> Keycloak
> >>   package for AS7? Any better option?
> >> * Ember in UPS is firing AJAX request to REST Endpoints on the same
> >> domain.
> >>   However, as it goes through Keycloak Auth Server, this is considered
> >> CORS
> >>   request. I had to configure Web Origin for UPS application. This is
> >>   confusing to me, Origin header should be transparent for Keycloak as I'm
> >>   firing request to the same domain. Note this does not happen in Firefox,
> >>   which identifies same domain and avoids Origin header. I need some
> >> insight
> >>   here from more skilled people.
> >>
> >
> > hmmmmm .... sounds 'good' :-)
:-)
> >
> >
> >> * I wasn't able to keep http->https rewriting valve with Keycloak to
> >> avoid UPS
> >>   usage via http protocol. I'll go deeper into that.
> >>
> >
> > https is enforced on our UPS cartridge
RI had to remove this enforcement. I'm just trying to put it back. 
> >
> >
> >> * Changes to Web Origin in Keycloak admin UI are not reflected to already
> >> logged
> >>   users. They need to log out first.
> >> * Missing logout button in UPS. Related to previous point.
> >>
> >> Let me know if you want me to convert some of these points to JIRAs in
> >> AGPUSH
> >> or KEYCLOAK projects. Also, let me please now if I should have configured
> >> something differently.
> >>
> >> Thanks,
> >>
> >> Karel
> >>
> >> [1] https://github.com/stianst/openshift-keycloak-cartridge
> >> [2]
> >>
> >> https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/keycloak
> >> [3]
> >>
> >> https://github.com/kpiwko/aerogear-unifiedpush-server/tree/keycloak-openshift
> >>
> >> More detailed steps:
> >>
> >> 1/ Create Keycloak cart
> >> 2/ Add AeroGear-UnifiedPush realm with roles admin, user
> >> 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart
> >> location
> >> 4/ Get keycloak.json
> >> 5/ Enable CORS in keycloak.json, modify password
> >> 6/ Add keycloak.json to
> >> aerogear-unifiedpush-server/src/main/webapp/WEB-INF
> >> 7/ Package UPS via 'mvn clean package'
> >> 8/ Put war into
> >>
> >> openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments
> >> 9/ Push that online
> >> 10/ Create UPS cart using reflector cartridge (use commit sha1 if not
> >> using
> >> master), enable mysql-5.1 gear as well
> >> 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm
> >> 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee.
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> 
> 
> 


From matzew at apache.org  Tue Feb  4 12:38:03 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 4 Feb 2014 18:38:03 +0100
Subject: [keycloak-dev] [aerogear-dev] Aerogear UPS + Keycloak cartridge
 combined together POC
In-Reply-To: <20140204183437.0737d77f@kapy-ntb-x220>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
	<CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>
	<20140204183437.0737d77f@kapy-ntb-x220>
Message-ID: <CAAg5f2RzyGYRf36-abKv_rn8TZ6v1sH3LO-_YfFoLRczs8Ln3g@mail.gmail.com>

On Tue, Feb 4, 2014 at 6:34 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> On Tue, 4 Feb 2014 18:21:10 +0100
> Matthias Wessendorf <matzew at apache.org> wrote:
>
> > oh, this was a cross-post :-) (adding keycloak)
> >
> >
> > On Tue, Feb 4, 2014 at 6:20 PM, Matthias Wessendorf <matzew at apache.org
> >wrote:
> >
> > >
> > >
> > >
> > > On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> > >
> > >> Hey,
> > >>
> > >> I've combined Aerogear UPS and Keycloak cartridges together. You can
> > >> check the
> > >> results at:
> > >>
> > >> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
> > >> https://keycloak-mobileqa.rhcloud.com/ (admin/password)
> > >>
> > >>
> > > I think it would be awesome if the keycloak bits would be included into
> > > the UPS bits, to have something OOTB, instead of pointing to a
> different
> > > server (CORS)
>
> I've added Keycloak AS7 modules to UPS cart but not admin console. I
> believe
> that Keycloak is SaaS, so usage with two different carts reflect reality
> better.
> Configuring Keycloak cart once and let all other carts use is seems the
> right
> way to me.
>
>
there is IMO pros and cons in both ways



> > >
> > >
> > >> For keycloak, I have used original cart [1]:
> > >>
> > >> $ rhc app create -g small --no-git keycloak
> > >>
> > >>
> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
> > >>
> > >> For UPS, I have modified matzew's one stored in my repo [2] and
> modified
> > >> UPS
> > >> [3]:
> > >>
> > >> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1
> > >> '
> > >>
> http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75
> > >> '
> > >>
> > >> There are some gotchas though:
> > >>
> > >> * keycloak.json - I'm not sure how this will be addressed by WF
> subsystem.
> > >
> > >
> > > the public-key needs to be, as far as I can see, included inside of the
> > > standalone.xml (keycloak subsystem section).
> > > Which is somewhat a similar issue; I think, if I get it right, that
> means
> > > as you plan to support more and more 'realms', you keep editing the
> > > standalone xml.
>
> That is great improvement w.r.t. current situation but does not handle
> OpenShift
> cart scenarios.
>
> > >
> > >
> > >> We
> > >>   still need a way how to pass keycloak.json to UPS cartridge, which
> is
> > >> AS7
> > >>   and we can't ask user to modify standalone.xml anyway. However, we
> > >> could make
> > >>   a hook on OpenShift - user will add keycloak.json to git repo and it
> > >> will
> > >>   automagically put at right location. Could we have a hook in
> Keycloak to
> > >>   load keycloak.json from external location? Or should we rather do
> some
> > >> war
> > >>   exploding magic?
> > >> * AS7-3227 I worked this around by doing parameter injection for
> > >>   SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of
> > >> Keycloak
> > >>   package for AS7? Any better option?
> > >> * Ember in UPS is firing AJAX request to REST Endpoints on the same
> > >> domain.
> > >>   However, as it goes through Keycloak Auth Server, this is considered
> > >> CORS
> > >>   request. I had to configure Web Origin for UPS application. This is
> > >>   confusing to me, Origin header should be transparent for Keycloak
> as I'm
> > >>   firing request to the same domain. Note this does not happen in
> Firefox,
> > >>   which identifies same domain and avoids Origin header. I need some
> > >> insight
> > >>   here from more skilled people.
> > >>
> > >
> > > hmmmmm .... sounds 'good' :-)
> :-)
> > >
> > >
> > >> * I wasn't able to keep http->https rewriting valve with Keycloak to
> > >> avoid UPS
> > >>   usage via http protocol. I'll go deeper into that.
> > >>
> > >
> > > https is enforced on our UPS cartridge
> RI had to remove this enforcement. I'm just trying to put it back.
> > >
> > >
> > >> * Changes to Web Origin in Keycloak admin UI are not reflected to
> already
> > >> logged
> > >>   users. They need to log out first.
> > >> * Missing logout button in UPS. Related to previous point.
> > >>
> > >> Let me know if you want me to convert some of these points to JIRAs in
> > >> AGPUSH
> > >> or KEYCLOAK projects. Also, let me please now if I should have
> configured
> > >> something differently.
> > >>
> > >> Thanks,
> > >>
> > >> Karel
> > >>
> > >> [1] https://github.com/stianst/openshift-keycloak-cartridge
> > >> [2]
> > >>
> > >>
> https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/keycloak
> > >> [3]
> > >>
> > >>
> https://github.com/kpiwko/aerogear-unifiedpush-server/tree/keycloak-openshift
> > >>
> > >> More detailed steps:
> > >>
> > >> 1/ Create Keycloak cart
> > >> 2/ Add AeroGear-UnifiedPush realm with roles admin, user
> > >> 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS
> cart
> > >> location
> > >> 4/ Get keycloak.json
> > >> 5/ Enable CORS in keycloak.json, modify password
> > >> 6/ Add keycloak.json to
> > >> aerogear-unifiedpush-server/src/main/webapp/WEB-INF
> > >> 7/ Package UPS via 'mvn clean package'
> > >> 8/ Put war into
> > >>
> > >>
> openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments
> > >> 9/ Push that online
> > >> 10/ Create UPS cart using reflector cartridge (use commit sha1 if not
> > >> using
> > >> master), enable mysql-5.1 gear as well
> > >> 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm
> > >> 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee.
> > >>
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>
> > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > >
> >
> >
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140204/854fbd15/attachment.html 

From bburke at redhat.com  Tue Feb  4 13:51:37 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Feb 2014 13:51:37 -0500
Subject: [keycloak-dev] Aerogear UPS + Keycloak cartridge combined
 together POC
In-Reply-To: <20140204181339.60267f2c@kapy-ntb-x220>
References: <20140204181339.60267f2c@kapy-ntb-x220>
Message-ID: <52F136B9.3090906@redhat.com>



On 2/4/2014 12:13 PM, Karel Piwko wrote:
> Hey,
>
> I've combined Aerogear UPS and Keycloak cartridges together. You can check the
> results at:
>
> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
> https://keycloak-mobileqa.rhcloud.com/ (admin/password)
>
> For keycloak, I have used original cart [1]:
>
> $ rhc app create -g small --no-git keycloak
> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
>
> For UPS, I have modified matzew's one stored in my repo [2] and modified UPS
> [3]:
>
> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1
> 'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75'
>
> There are some gotchas though:
>
> * keycloak.json - I'm not sure how this will be addressed by WF subsystem. We
>    still need a way how to pass keycloak.json to UPS cartridge, which is AS7
>    and we can't ask user to modify standalone.xml anyway. However, we could make
>    a hook on OpenShift - user will add keycloak.json to git repo and it will
>    automagically put at right location. Could we have a hook in Keycloak to
>    load keycloak.json from external location? Or should we rather do some war
>    exploding magic?

I need to go through Stan's work.  I want to be able to configure the 
subsystem from the keycloak admin console without having to create a 
keycloak.json file.  I just don't know yet if the subsystem will work on 
AS7.


> * AS7-3227 I worked this around by doing parameter injection for
>    SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of Keycloak
>    package for AS7? Any better option?

This is an UPS issue right?  Keycloak WAR bundles is own Resteasy and 
excludes built in one.

> * Ember in UPS is firing AJAX request to REST Endpoints on the same domain.
>    However, as it goes through Keycloak Auth Server, this is considered CORS
>    request. I had to configure Web Origin for UPS application. This is
>    confusing to me, Origin header should be transparent for Keycloak as I'm
>    firing request to the same domain. Note this does not happen in Firefox,
>    which identifies same domain and avoids Origin header. I need some insight
>    here from more skilled people.

JIRA for this one.  I've only tested/experimented with CORS on Firefox.

> * I wasn't able to keep http->https rewriting valve with Keycloak to avoid UPS
>    usage via http protocol. I'll go deeper into that.
> * Changes to Web Origin in Keycloak admin UI are not reflected to already logged
>    users. They need to log out first.

We can't fix this.  But it will be mitigated when we add refresh tokens. 
  We'll have a short token lifespan that needs to be refreshed.  The 
refresh will pick up the changes.

> More detailed steps:
>
> 1/ Create Keycloak cart
> 2/ Add AeroGear-UnifiedPush realm with roles admin, user
> 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart
> location


Couldn't the cartridge come with a pre-configured keycloak database?  We 
also have a realm import option, but we haven't documented the json 
format yet.  Also there's the admin REST interface you could use to 
create the realm/application/roles etc.


> 4/ Get keycloak.json
> 5/ Enable CORS in keycloak.json, modify password
> 6/ Add keycloak.json to aerogear-unifiedpush-server/src/main/webapp/WEB-INF
> 7/ Package UPS via 'mvn clean package'
> 8/ Put war into
> openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments

This may be able to be done from the keycloak console.

> 9/ Push that online
> 10/ Create UPS cart using reflector cartridge (use commit sha1 if not using
> master), enable mysql-5.1 gear as well
> 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm
> 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee.
>

:)

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

From bburke at redhat.com  Tue Feb  4 13:58:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Feb 2014 13:58:07 -0500
Subject: [keycloak-dev] [aerogear-dev] Aerogear UPS + Keycloak cartridge
 combined together POC
In-Reply-To: <CAAg5f2RzyGYRf36-abKv_rn8TZ6v1sH3LO-_YfFoLRczs8Ln3g@mail.gmail.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>	<CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>	<CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>	<20140204183437.0737d77f@kapy-ntb-x220>
	<CAAg5f2RzyGYRf36-abKv_rn8TZ6v1sH3LO-_YfFoLRczs8Ln3g@mail.gmail.com>
Message-ID: <52F1383F.1080804@redhat.com>



On 2/4/2014 12:38 PM, Matthias Wessendorf wrote:
>     I've added Keycloak AS7 modules to UPS cart but not admin console. I
>     believe
>     that Keycloak is SaaS, so usage with two different carts reflect
>     reality better.
>     Configuring Keycloak cart once and let all other carts use is seems
>     the right
>     way to me.
>
>
> there is IMO pros and cons in both ways
>

Originally, Keycloak was going to be a SaaS.  One internet service where 
users could register and create their own Realms....But, we decided that 
users will probably want to have full control of their security metadata 
and not share a database with other users.  Less we have to worry about 
from a storage security standpoint.

I've never built a cartridge so apologies if I have it wrong, but IMO, 
UPS should support bundling its own keycloak server already 
preconfigured, or, it should hook into an existing keycloak instance.  I 
don't know if this would require 2 different cartridges, or if you would 
have an online "installation" UI to make these types of decisions.

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

From matzew at apache.org  Tue Feb  4 14:28:53 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 4 Feb 2014 20:28:53 +0100
Subject: [keycloak-dev] [aerogear-dev] Aerogear UPS + Keycloak cartridge
 combined together POC
In-Reply-To: <52F1383F.1080804@redhat.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
	<CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>
	<20140204183437.0737d77f@kapy-ntb-x220>
	<CAAg5f2RzyGYRf36-abKv_rn8TZ6v1sH3LO-_YfFoLRczs8Ln3g@mail.gmail.com>
	<52F1383F.1080804@redhat.com>
Message-ID: <CAAg5f2TmR_2=wwCQaGRQQWBaWx4n3NPzNEeYOu+zN+LZ+i8+OQ@mail.gmail.com>

On Tue, Feb 4, 2014 at 7:58 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 2/4/2014 12:38 PM, Matthias Wessendorf wrote:
> >     I've added Keycloak AS7 modules to UPS cart but not admin console. I
> >     believe
> >     that Keycloak is SaaS, so usage with two different carts reflect
> >     reality better.
> >     Configuring Keycloak cart once and let all other carts use is seems
> >     the right
> >     way to me.
> >
> >
> > there is IMO pros and cons in both ways
> >
>
> Originally, Keycloak was going to be a SaaS.  One internet service where
> users could register and create their own Realms....But, we decided that
> users will probably want to have full control of their security metadata
> and not share a database with other users.  Less we have to worry about
> from a storage security standpoint.
>
> IMO, UPS should support bundling its own keycloak server already
> preconfigured, or, it should hook into an existing keycloak instance.



exactly - that also makes the user experience way better, running
everything in the cloud, OOTB

-M


>  I
> don't know if this would require 2 different cartridges, or if you would
> have an online "installation" UI to make these types of decisions.
>
> --
> 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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140204/287a0b95/attachment-0001.html 

From mcaspers at redhat.com  Tue Feb  4 15:57:08 2014
From: mcaspers at redhat.com (Matt Casperson)
Date: Tue, 4 Feb 2014 15:57:08 -0500 (EST)
Subject: [keycloak-dev] SAML as social login?
In-Reply-To: <52F106B9.2050106@redhat.com>
References: <673263009.11654303.1391374608185.JavaMail.root@redhat.com>
	<584811480.18681956.1391517053239.JavaMail.root@redhat.com>
	<52F106B9.2050106@redhat.com>
Message-ID: <1536898992.12380883.1391547428760.JavaMail.root@redhat.com>

The value KeyCloak offers us (if I understand correctly) is that we can build applications against KeyCloak and not have to worry about where the users details eventually come from. In our local deployment, KeyCloak might be nothing more than a middleman between our application and an existing SSO solution. But it is nice to be able to support other deployment scenarios where KeyCloak is used as a complete and independent security solution, with no changes to our code. 

So it is very valuable to us to have a project like KeyCloak providing a sliding scale solution from "just bouncing messages between the browser and the existing user database" to "we have no existing user database, so KeyCloak has to do everything" with little more than a few toggles in a UI. 

Regards 

Matthew Casperson 
RHCE, RHCJA # 111-072-237 
Engineering Content Services 
Brisbane, Australia 

----- Original Message -----

From: "Bill Burke" <bburke at redhat.com> 
To: keycloak-dev at lists.jboss.org 
Sent: Wednesday, 5 February, 2014 1:26:49 AM 
Subject: Re: [keycloak-dev] SAML as social login? 

I guess this would be interesting in the case where your federated IDP 
didn't have role and session mgmt, single sign off, oauth/openid connect 
support? Would Keycloak offer enough value add in this scenario? 

On 2/4/2014 7:30 AM, Stian Thorgersen wrote: 
> In theory that should work. The social login feature at the moment has only been tested for OAuth and OAuth2 providers, so may need some tweaking for a SAML provider. 
> 
> We're also assuming that a social provider is able to retrieve a basic user profile (https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java#L85), but you could just return a username and require users to update their profile on first social login ("Update profile on first social login" option on realm settings in admin console). 
> 
> In the future we plan to provide support for federation of authentication (other Keycloak realms, SAML, LDAP, etc.), but this is a good way to get something working with what Keycloak provides at the moment. 
> 
> By the way at the moment the admin console has a hard-coded list of social providers, but in the next release this will be dynamic. So all you'd need is to add a jar that implements the social provider spi, and it will be available to configure it for a realm through the admin console. 
> 
> ----- Original Message ----- 
>> From: "Matt Casperson" <mcaspers at redhat.com> 
>> To: keycloak-dev at lists.jboss.org 
>> Sent: Sunday, 2 February, 2014 8:56:48 PM 
>> Subject: [keycloak-dev] SAML as social login? 
>> 
>> If I am reading 
>> https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java 
>> correctly, the only thing needed for a Keycloak social login is a URL to a 
>> login page that the user can be directed to when they are not logged in, and 
>> to have that login page send back a response that Keycloak can use to verify 
>> the user and get their details. 
>> 
>> So if I had appropriate permissions to use https://saml.redhat.com/idp/, 
>> could that be added as a social login? 
>> 
>> Regards 
>> 
>> Matthew Casperson 
>> RHCE, RHCJA # 111-072-237 
>> Engineering Content Services 
>> Brisbane, Australia 
>> 
>> 
>> _______________________________________________ 
>> 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 

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

From bburke at redhat.com  Tue Feb  4 16:06:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Feb 2014 16:06:24 -0500
Subject: [keycloak-dev] SAML as social login?
In-Reply-To: <1536898992.12380883.1391547428760.JavaMail.root@redhat.com>
References: <673263009.11654303.1391374608185.JavaMail.root@redhat.com>
	<584811480.18681956.1391517053239.JavaMail.root@redhat.com>
	<52F106B9.2050106@redhat.com>
	<1536898992.12380883.1391547428760.JavaMail.root@redhat.com>
Message-ID: <52F15650.8050701@redhat.com>

Thanks for the input!

On 2/4/2014 3:57 PM, Matt Casperson wrote:
> The value KeyCloak offers us (if I understand correctly) is that we can
> build applications against KeyCloak and not have to worry about where
> the users details eventually come from. In our local deployment,
> KeyCloak might be nothing more than a middleman between our application
> and an existing SSO solution. But it is nice to be able to support other
> deployment scenarios where KeyCloak is used as a complete and
> independent security solution, with no changes to our code.
>
> So it is very valuable to us to have a project like KeyCloak providing a
> sliding scale solution from "just bouncing messages between the browser
> and the existing user database" to "we have no existing user database,
> so KeyCloak has to do everything" with little more than a few toggles in
> a UI.
>
> Regards
>
> Matthew Casperson
> RHCE, RHCJA # 111-072-237
> <https://www.redhat.com/wapps/training/certification/verify.html?certNumber=111-072-237&isSearch=False&verify=Verify>
> Engineering Content Services
> Brisbane, Australia
>
> ------------------------------------------------------------------------
> *From: *"Bill Burke" <bburke at redhat.com>
> *To: *keycloak-dev at lists.jboss.org
> *Sent: *Wednesday, 5 February, 2014 1:26:49 AM
> *Subject: *Re: [keycloak-dev] SAML as social login?
>
> I guess this would be interesting in the case where your federated IDP
> didn't have role and session mgmt, single sign off, oauth/openid connect
> support?  Would Keycloak offer enough value add in this scenario?
>
> On 2/4/2014 7:30 AM, Stian Thorgersen wrote:
>  > In theory that should work. The social login feature at the moment
> has only been tested for OAuth and OAuth2 providers, so may need some
> tweaking for a SAML provider.
>  >
>  > We're also assuming that a social provider is able to retrieve a
> basic user profile
> (https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java#L85),
> but you could just return a username and require users to update their
> profile on first social login ("Update profile on first social login"
> option on realm settings in admin console).
>  >
>  > In the future we plan to provide support for federation of
> authentication (other Keycloak realms, SAML, LDAP, etc.), but this is a
> good way to get something working with what Keycloak provides at the moment.
>  >
>  > By the way at the moment the admin console has a hard-coded list of
> social providers, but in the next release this will be dynamic. So all
> you'd need is to add a jar that implements the social provider spi, and
> it will be available to configure it for a realm through the admin console.
>  >
>  > ----- Original Message -----
>  >> From: "Matt Casperson" <mcaspers at redhat.com>
>  >> To: keycloak-dev at lists.jboss.org
>  >> Sent: Sunday, 2 February, 2014 8:56:48 PM
>  >> Subject: [keycloak-dev] SAML as social login?
>  >>
>  >> If I am reading
>  >>
> https://github.com/keycloak/keycloak/blob/master/social/google/src/main/java/org/keycloak/social/google/GoogleProvider.java
>  >> correctly, the only thing needed for a Keycloak social login is a
> URL to a
>  >> login page that the user can be directed to when they are not logged
> in, and
>  >> to have that login page send back a response that Keycloak can use
> to verify
>  >> the user and get their details.
>  >>
>  >> So if I had appropriate permissions to use https://saml.redhat.com/idp/,
>  >> could that be added as a social login?
>  >>
>  >> Regards
>  >>
>  >> Matthew Casperson
>  >> RHCE, RHCJA # 111-072-237
>  >> Engineering Content Services
>  >> Brisbane, Australia
>  >>
>  >>
>  >> _______________________________________________
>  >> 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  Tue Feb  4 18:05:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Feb 2014 18:05:57 -0500
Subject: [keycloak-dev] postgres and mysql
Message-ID: <52F17255.6020406@redhat.com>

A user was reporting postgres issues.   Does anybody want to test out 
keycloak with postgres and mysql and write install docs on it?  Its on 
my todo list, but hoping somebody will take it on.  Boring work, but 
hey, doing screencasts are even more boring ;)

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

From bburke at redhat.com  Tue Feb  4 18:31:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Feb 2014 18:31:52 -0500
Subject: [keycloak-dev] theme thought
Message-ID: <52F17868.3090400@redhat.com>

You'd probably want to support multiple concurrent themes for different 
languages (french, spanish, english, etc...).  I'm just not sure how the 
user-agent's language would be discovered.  Some do it by hostname i.e. 
www.google.es or by a URL pattern example.com/en-US/...

Just something to think about.

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

From bburke at redhat.com  Tue Feb  4 18:46:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 04 Feb 2014 18:46:04 -0500
Subject: [keycloak-dev] composite roles in
Message-ID: <52F17BBC.4030609@redhat.com>

I still need to do a screencast (and eventually do some documentation). 
  I'm waiting on that as I want to see how our UI might change for the 
next release.  I had to change a bit in the import realm json 
representation to support composites.

I'm going to take a look at Stan's Wildfly subsystem work next and see 
if it can be improved at all, or if its ready to go.

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

From matzew at apache.org  Wed Feb  5 03:59:20 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 5 Feb 2014 09:59:20 +0100
Subject: [keycloak-dev] postgres and mysql
In-Reply-To: <52F17255.6020406@redhat.com>
References: <52F17255.6020406@redhat.com>
Message-ID: <CAAg5f2SzEXNpkXdVta25u96vjTYPk5vwqExpZsVWO--Vq+b0RA@mail.gmail.com>

I am touching databases today, will take a look at MySQL/PSQL.

will post a gist or so w/ my findings etc


On Wed, Feb 5, 2014 at 12:05 AM, Bill Burke <bburke at redhat.com> wrote:

> A user was reporting postgres issues.   Does anybody want to test out
> keycloak with postgres and mysql and write install docs on it?  Its on
> my todo list, but hoping somebody will take it on.  Boring work, but
> hey, doing screencasts are even more boring ;)
>
> --
> 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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140205/3386a61f/attachment.html 

From stian at redhat.com  Wed Feb  5 06:12:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 5 Feb 2014 06:12:39 -0500 (EST)
Subject: [keycloak-dev] theme thought
In-Reply-To: <52F17868.3090400@redhat.com>
References: <52F17868.3090400@redhat.com>
Message-ID: <1511434428.19743255.1391598759865.JavaMail.root@redhat.com>

Not sure why you'd want multiple themes? 

Internationalization will be taken care of by locale specific message bundles (e.g. messages_no.properties). We could also add the option of having locale specific templates (e.g. login_no.ftl), not sure that would be needed though.

I'm not sure how correct locale is discovered either, I'm sure there's folks on the portal theme that knows this ;). We may need to add an option to pass it as a query param from the app though. With the hostname examples you've given wouldn't those be app urls rather than keycloak urls?

For example:

www.myapp.co.uk -> keycloak.org/auth/rest/realm/myrealm?client_id=...&locale=en_UK
www.myapp.no -> keycloak.org/auth/rest/realm/myrealm?client_id=...&locale=no

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 4 February, 2014 11:31:52 PM
> Subject: [keycloak-dev] theme thought
> 
> You'd probably want to support multiple concurrent themes for different
> languages (french, spanish, english, etc...).  I'm just not sure how the
> user-agent's language would be discovered.  Some do it by hostname i.e.
> www.google.es or by a URL pattern example.com/en-US/...
> 
> Just something to think about.
> 
> --
> 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 Feb  5 06:57:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 5 Feb 2014 06:57:18 -0500 (EST)
Subject: [keycloak-dev] composite roles in
In-Reply-To: <52F17BBC.4030609@redhat.com>
References: <52F17BBC.4030609@redhat.com>
Message-ID: <585965965.19757889.1391601438372.JavaMail.root@redhat.com>

Instead of allowing multiple default roles should we not have a single initial role on a realm? This means we can remove the default roles page, and instead have a simple select list on the realm settings page.

We could also have both a initial role and a default role associated with a realm. The initial role is provided to users when they register or are created through admin console, while the default role is always granted to all users.

When listing and selecting roles it would be good if there was some indication if it's a composite role or a simple role.

Editing the roles is a bit confusing as the "Composite Realm Roles" and "Composite Application Roles" sections are always shown. It was more clear when there was a "composite" on/off toggle. Also, can we have composite app roles? If so can a composite app role consist of roles for other apps and realm?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 4 February, 2014 11:46:04 PM
> Subject: [keycloak-dev] composite roles in
> 
> I still need to do a screencast (and eventually do some documentation).
>   I'm waiting on that as I want to see how our UI might change for the
> next release.  I had to change a bit in the import realm json
> representation to support composites.
> 
> I'm going to take a look at Stan's Wildfly subsystem work next and see
> if it can be improved at all, or if its 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
> 
.

From aemmanou at redhat.com  Wed Feb  5 04:46:12 2014
From: aemmanou at redhat.com (Apostolos Emmanouilidis)
Date: Wed, 05 Feb 2014 10:46:12 +0100
Subject: [keycloak-dev] [aerogear-dev] Aerogear UPS + Keycloak cartridge
 combined together POC
In-Reply-To: <20140204181339.60267f2c@kapy-ntb-x220>
References: <20140204181339.60267f2c@kapy-ntb-x220>
Message-ID: <1391593572.2541.12.camel@dhcp129-205.brq.redhat.com>

This case appears because Chrome and Safari are sending the Origin
header on same origin PUT, DELETE & POST requests.
On the other side, Firefox does not send the Origin header on same
origin requests. As the Keycloak team explained to me, 
in most JS/HTML apps you'd add origin part of the base url as web origin
in the application's settings through the Keycloak administration
console.
However, this does not apply to non-js based app and that's why the base
url is not automatically considered as web origin.

Request Method:POST
Request Headersview source
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,el;q=0.6
Connection:keep-alive
Content-Length:15
Content-Type:application/json
Cookie:JSESSIONID=Tw9NmJjHUlRO6JnimwyzS1w3.undefined
Host:agpushkeycloak-mobileqa.rhcloud.com
Origin:http://agpushkeycloak-mobileqa.rhcloud.com
Referer:http://agpushkeycloak-mobileqa.rhcloud.com/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/31.0.1650.63 Safari/537.36
X-Requested-With:XMLHttpRequest

On Tue, 2014-02-04 at 18:13 +0100, Karel Piwko wrote:

> * Ember in UPS is firing AJAX request to REST Endpoints on the same domain.
>   However, as it goes through Keycloak Auth Server, this is considered CORS
>   request. I had to configure Web Origin for UPS application. This is
>   confusing to me, Origin header should be transparent for Keycloak as I'm
>   firing request to the same domain. Note this does not happen in Firefox,
>   which identifies same domain and avoids Origin header. I need some insight
>   here from more skilled people.



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

From bburke at redhat.com  Wed Feb  5 08:01:42 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 08:01:42 -0500
Subject: [keycloak-dev] theme thought
In-Reply-To: <1511434428.19743255.1391598759865.JavaMail.root@redhat.com>
References: <52F17868.3090400@redhat.com>
	<1511434428.19743255.1391598759865.JavaMail.root@redhat.com>
Message-ID: <52F23636.8040102@redhat.com>



On 2/5/2014 6:12 AM, Stian Thorgersen wrote:
> Not sure why you'd want multiple themes?
>

Different apps may want a different logon screens?

> Internationalization will be taken care of by locale specific message bundles (e.g. messages_no.properties). We could also add the option of having locale specific templates (e.g. login_no.ftl), not sure that would be needed though.
>

message bundles work great for logging messages.  I'm not sure its 
always the case for rendered content.  I've also been told in the past 
that different cultures prefer different color schemes.

I don't know what the right answer is, but its something that should be 
researched for best practice.

> I'm not sure how correct locale is discovered either, I'm sure there's folks on the portal theme that knows this ;). We may need to add an option to pass it as a query param from the app though. With the hostname examples you've given wouldn't those be app urls rather than keycloak urls?
>

Answering my own question: Openid Connect supports locale as a query param.	


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

From bburke at redhat.com  Wed Feb  5 08:24:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 08:24:24 -0500
Subject: [keycloak-dev] composite roles in
In-Reply-To: <585965965.19757889.1391601438372.JavaMail.root@redhat.com>
References: <52F17BBC.4030609@redhat.com>
	<585965965.19757889.1391601438372.JavaMail.root@redhat.com>
Message-ID: <52F23B88.5020300@redhat.com>



On 2/5/2014 6:57 AM, Stian Thorgersen wrote:
> Instead of allowing multiple default roles should we not have a single initial role on a realm? This means we can remove the default roles page, and instead have a simple select list on the realm settings page.
>

I'd also like to consolidate default roles into one place on Realm Settings.

Implementation wise, default roles wouldn't be a composite as I don't 
want it showing up in role listings, or having to put in special logic 
not to show it.

> We could also have both a initial role and a default role associated with a realm. The initial role is provided to users when they register or are created through admin console, while the default role is always granted to all users.
>

I don't agree you need two different types here.  What we really need is 
the ability to apply bulk changes to users.

> When listing and selecting roles it would be good if there was some indication if it's a composite role or a simple role.
>

Ok, i'll add that.

> Editing the roles is a bit confusing as the "Composite Realm Roles" and "Composite Application Roles" sections are always shown. It was more clear when there was a "composite" on/off toggle.

Having a toggle at the Representation and data model was annoying, 
specifically having to specify composite: true in the json import file. 
  I forgot it twice when writing the tests :)

So, i'll add the on/off toggle just to show/hide the composite field sets.

> Also, can we have composite app roles? If so can a composite app role consist of roles for other apps and realm?
>

Apps or realms can have composite roles.  These composites can be made 
up of any realm or app role.  Does the app-role screen not allow 
composites, not work?

Can't do cross-realm composites.

> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 4 February, 2014 11:46:04 PM
>> Subject: [keycloak-dev] composite roles in
>>
>> I still need to do a screencast (and eventually do some documentation).
>>    I'm waiting on that as I want to see how our UI might change for the
>> next release.  I had to change a bit in the import realm json
>> representation to support composites.
>>
>> I'm going to take a look at Stan's Wildfly subsystem work next and see
>> if it can be improved at all, or if its 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
>>
> .
>

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

From kpiwko at redhat.com  Wed Feb  5 08:35:04 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Wed, 5 Feb 2014 14:35:04 +0100
Subject: [keycloak-dev] Aerogear UPS + Keycloak cartridge combined
 together POC
In-Reply-To: <52F136B9.3090906@redhat.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<52F136B9.3090906@redhat.com>
Message-ID: <20140205143504.563c6771@kapy-ntb-x220>

On Tue, 04 Feb 2014 13:51:37 -0500
Bill Burke <bburke at redhat.com> wrote:

> 
> 
> On 2/4/2014 12:13 PM, Karel Piwko wrote:
> > Hey,
> >
> > I've combined Aerogear UPS and Keycloak cartridges together. You can check
> > the results at:
> >
> > https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
> > https://keycloak-mobileqa.rhcloud.com/ (admin/password)
> >
> > For keycloak, I have used original cart [1]:
> >
> > $ rhc app create -g small --no-git keycloak
> > https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
> >
> > For UPS, I have modified matzew's one stored in my repo [2] and modified UPS
> > [3]:

Given your comments, I'll modify setup to have (primarily) single cart option.
Should I keep two carts setup? It at least seems as a good QE test case ;-)

Note, I will either have to wait for WF8 Final (due to Hibernate bug in CR1) or
base cart on AS7.

> >
> > $ rhc app create -g small --no-git agpushkeycloak mysql-5.1
> > 'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75'
> >
> > There are some gotchas though:
> >
> > * keycloak.json - I'm not sure how this will be addressed by WF subsystem.
> > We still need a way how to pass keycloak.json to UPS cartridge, which is AS7
> >    and we can't ask user to modify standalone.xml anyway. However, we could
> > make a hook on OpenShift - user will add keycloak.json to git repo and it
> > will automagically put at right location. Could we have a hook in Keycloak
> > to load keycloak.json from external location? Or should we rather do some
> > war exploding magic?
> 
> I need to go through Stan's work.  I want to be able to configure the 
> subsystem from the keycloak admin console without having to create a 
> keycloak.json file.  I just don't know yet if the subsystem will work on 
> AS7.


This will work for app and Keycloak being deployed on a single server. It does
not solve SaaS scenario - keycloak admin console can configure subsystem of
current WF(AS) only. Keycloak would need to manage subsystem of a remote WF - I
doubt this would ever be possible with AS7 on OpenShift and I think security
concerns of such setup are not even allowing this on WF8.

> 
> 
> > * AS7-3227 I worked this around by doing parameter injection for
> >    SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of
> > Keycloak package for AS7? Any better option?
> 
> This is an UPS issue right?  Keycloak WAR bundles is own Resteasy and 
> excludes built in one.

Well, it is either keycloak packaging issue or documentation issue (or problem
here in Brno in between chair and keyboard). I've added
keycloak-as7-adapter-dist to AS7. Keycloak WAR was added to different
cartridge. So, AS7 (UPS) is still using old RESTEasy 2.x. This will be fixed
if newer RESTEasy is packaged inside of keycloak-as7-adapter-dist instead of
Keycloak WAR. IIRC this was setup pre alpha-1.

> 
> > * Ember in UPS is firing AJAX request to REST Endpoints on the same domain.
> >    However, as it goes through Keycloak Auth Server, this is considered CORS
> >    request. I had to configure Web Origin for UPS application. This is
> >    confusing to me, Origin header should be transparent for Keycloak as I'm
> >    firing request to the same domain. Note this does not happen in Firefox,
> >    which identifies same domain and avoids Origin header. I need some
> > insight here from more skilled people.
> 
> JIRA for this one.  I've only tested/experimented with CORS on Firefox.

https://issues.jboss.org/browse/KEYCLOAK-281

> 
> > * I wasn't able to keep http->https rewriting valve with Keycloak to avoid
> > UPS usage via http protocol. I'll go deeper into that.
> > * Changes to Web Origin in Keycloak admin UI are not reflected to already
> > logged users. They need to log out first.
> 
> We can't fix this.  But it will be mitigated when we add refresh tokens. 
>   We'll have a short token lifespan that needs to be refreshed.  The 
> refresh will pick up the changes.
> 

Sounds good.

> > More detailed steps:
> >
> > 1/ Create Keycloak cart
> > 2/ Add AeroGear-UnifiedPush realm with roles admin, user
> > 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart
> > location
> 
> 
> Couldn't the cartridge come with a pre-configured keycloak database?  We 
> also have a realm import option, but we haven't documented the json 
> format yet.  Also there's the admin REST interface you could use to 
> create the realm/application/roles etc.

If I'm able to get public key via admin REST interface, it should be possible
to preconfigure that. Setup will be complicated but possible with
Keycloak subsystem. Having realm import json format documentation will
definitely help here.

> 
> 
> > 4/ Get keycloak.json
> > 5/ Enable CORS in keycloak.json, modify password
> > 6/ Add keycloak.json to aerogear-unifiedpush-server/src/main/webapp/WEB-INF
> > 7/ Package UPS via 'mvn clean package'
> > 8/ Put war into
> > openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments
> 
> This may be able to be done from the keycloak console.

Right, but not in SaaS scenario, only if app and Keycloak run on same instance.

> 
> > 9/ Push that online
> > 10/ Create UPS cart using reflector cartridge (use commit sha1 if not using
> > master), enable mysql-5.1 gear as well
> > 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm
> > 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee.
> >
> 
> :)
> 

From stian at redhat.com  Wed Feb  5 08:37:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 5 Feb 2014 08:37:13 -0500 (EST)
Subject: [keycloak-dev] composite roles in
In-Reply-To: <52F23B88.5020300@redhat.com>
References: <52F17BBC.4030609@redhat.com>
	<585965965.19757889.1391601438372.JavaMail.root@redhat.com>
	<52F23B88.5020300@redhat.com>
Message-ID: <287296343.19825112.1391607433613.JavaMail.root@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: Wednesday, 5 February, 2014 1:24:24 PM
> Subject: Re: [keycloak-dev] composite roles in
> 
> 
> 
> On 2/5/2014 6:57 AM, Stian Thorgersen wrote:
> > Instead of allowing multiple default roles should we not have a single
> > initial role on a realm? This means we can remove the default roles page,
> > and instead have a simple select list on the realm settings page.
> >
> 
> I'd also like to consolidate default roles into one place on Realm Settings.
> 
> Implementation wise, default roles wouldn't be a composite as I don't
> want it showing up in role listings, or having to put in special logic
> not to show it.

What I was thinking was that the default roles would be a single role. It could be a composite role if the user wanted to. You simply select which role you want to use as the default role that is assigned to all user when created.

This then lets you manage this role as a normal role, which means there's no special logic or screens required for it. It's possible to add/remove this role to users, apps, etc if you want to. And as its can be a composite role you can add/remove roles to it if you want as well.

'Default roles' is confusing as well, is it not some initial roles granted users when they are created?

> 
> > We could also have both a initial role and a default role associated with a
> > realm. The initial role is provided to users when they register or are
> > created through admin console, while the default role is always granted to
> > all users.
> >
> 
> I don't agree you need two different types here.  What we really need is
> the ability to apply bulk changes to users.

Are there not situations where you have some roles that all logged-in users should have? For example 'view-profile' would be an example of a role that all users should have regardless.

Then again there's the situation where you want to have roles allocated to users when they register, but you may want to remove those later. I'm not sure I'm that convinced about this use-case, but both you and Marek argued this would be needed. Reason why I'm unsure about it, is that if a user self-registers, then looses some registration roles the user can simply re-register to gain those permissions again.

> 
> > When listing and selecting roles it would be good if there was some
> > indication if it's a composite role or a simple role.
> >
> 
> Ok, i'll add that.
> 
> > Editing the roles is a bit confusing as the "Composite Realm Roles" and
> > "Composite Application Roles" sections are always shown. It was more clear
> > when there was a "composite" on/off toggle.
> 
> Having a toggle at the Representation and data model was annoying,
> specifically having to specify composite: true in the json import file.
>   I forgot it twice when writing the tests :)
> 
> So, i'll add the on/off toggle just to show/hide the composite field sets.
> 
> > Also, can we have composite app roles? If so can a composite app role
> > consist of roles for other apps and realm?
> >
> 
> Apps or realms can have composite roles.  These composites can be made
> up of any realm or app role.  Does the app-role screen not allow
> composites, not work?

This doesn't make sense to me. Why can you have an app specific role that can be made up of roles from other apps?

> 
> Can't do cross-realm composites.
> 
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 4 February, 2014 11:46:04 PM
> >> Subject: [keycloak-dev] composite roles in
> >>
> >> I still need to do a screencast (and eventually do some documentation).
> >>    I'm waiting on that as I want to see how our UI might change for the
> >> next release.  I had to change a bit in the import realm json
> >> representation to support composites.
> >>
> >> I'm going to take a look at Stan's Wildfly subsystem work next and see
> >> if it can be improved at all, or if its 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
> >>
> > .
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From kpiwko at redhat.com  Wed Feb  5 08:17:22 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Wed, 5 Feb 2014 14:17:22 +0100
Subject: [keycloak-dev] Aerogear UPS + Keycloak cartridge combined
 together POC
In-Reply-To: <52F136B9.3090906@redhat.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<52F136B9.3090906@redhat.com>
Message-ID: <20140205141722.0e810a3c@kapy-ntb-x220>

On Tue, 04 Feb 2014 13:51:37 -0500
Bill Burke <bburke at redhat.com> wrote:

> 
> 
> On 2/4/2014 12:13 PM, Karel Piwko wrote:
> > Hey,
> >
> > I've combined Aerogear UPS and Keycloak cartridges together. You can check
> > the results at:
> >
> > https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
> > https://keycloak-mobileqa.rhcloud.com/ (admin/password)
> >
> > For keycloak, I have used original cart [1]:
> >
> > $ rhc app create -g small --no-git keycloak
> > https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
> >
> > For UPS, I have modified matzew's one stored in my repo [2] and modified UPS
> > [3]:

Given your comments, I'll modify setup to have (primarily) single cart option.
Should I keep two carts setup? It at least seems as a good QE test case ;-)

Note, I will either have to wait for WF8 Final (due to Hibernate bug in CR1) or
base it on AS7.

> >
> > $ rhc app create -g small --no-git agpushkeycloak mysql-5.1
> > 'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75'
> >
> > There are some gotchas though:
> >
> > * keycloak.json - I'm not sure how this will be addressed by WF subsystem.
> > We still need a way how to pass keycloak.json to UPS cartridge, which is AS7
> >    and we can't ask user to modify standalone.xml anyway. However, we could
> > make a hook on OpenShift - user will add keycloak.json to git repo and it
> > will automagically put at right location. Could we have a hook in Keycloak
> > to load keycloak.json from external location? Or should we rather do some
> > war exploding magic?
> 
> I need to go through Stan's work.  I want to be able to configure the 
> subsystem from the keycloak admin console without having to create a 
> keycloak.json file.  I just don't know yet if the subsystem will work on 
> AS7.


This will work for app and Keycloak being deployed on a single server. It does
not solve SaaS scenario - keycloak admin console can configure subsystem of
current AS/WF only. Keycloak would need to manage subsystem of remote WF - I
doubt this would ever be possible with AS7 on OpenShift and I think security
concerns of such setup are not 

> 
> 
> > * AS7-3227 I worked this around by doing parameter injection for
> >    SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of
> > Keycloak package for AS7? Any better option?
> 
> This is an UPS issue right?  Keycloak WAR bundles is own Resteasy and 
> excludes built in one.

Well, it is either keycloak packaging issue or documentation issue (or problem
here in Brno in between chair and keyboard). I've added
keycloak-as7-adapter-dist to AS7. Keycloak WAR was added to different
cartridge. So, AS7 (UPS) is still using old RESTEasy 2.x. This will be fixed
if newer RESTEasy is packaged inside of keycloak-as7-adapter-dist instead of
Keycloak WAR. IIRC this was setup pre alpha-1.

> 
> > * Ember in UPS is firing AJAX request to REST Endpoints on the same domain.
> >    However, as it goes through Keycloak Auth Server, this is considered CORS
> >    request. I had to configure Web Origin for UPS application. This is
> >    confusing to me, Origin header should be transparent for Keycloak as I'm
> >    firing request to the same domain. Note this does not happen in Firefox,
> >    which identifies same domain and avoids Origin header. I need some
> > insight here from more skilled people.
> 
> JIRA for this one.  I've only tested/experimented with CORS on Firefox.

https://issues.jboss.org/browse/KEYCLOAK-233

> 
> > * I wasn't able to keep http->https rewriting valve with Keycloak to avoid
> > UPS usage via http protocol. I'll go deeper into that.
> > * Changes to Web Origin in Keycloak admin UI are not reflected to already
> > logged users. They need to log out first.
> 
> We can't fix this.  But it will be mitigated when we add refresh tokens. 
>   We'll have a short token lifespan that needs to be refreshed.  The 
> refresh will pick up the changes.
> 

Sounds good.

> > More detailed steps:
> >
> > 1/ Create Keycloak cart
> > 2/ Add AeroGear-UnifiedPush realm with roles admin, user
> > 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart
> > location
> 
> 
> Couldn't the cartridge come with a pre-configured keycloak database?  We 
> also have a realm import option, but we haven't documented the json 
> format yet.  Also there's the admin REST interface you could use to 
> create the realm/application/roles etc.

If I'm able to get public key via admin REST interface, it should be possible
to preconfigure that. Setup will be complicated but possible with
Keycloak subsystem. Having realm import json format documentation will
definitely help here.

> 
> 
> > 4/ Get keycloak.json
> > 5/ Enable CORS in keycloak.json, modify password
> > 6/ Add keycloak.json to aerogear-unifiedpush-server/src/main/webapp/WEB-INF
> > 7/ Package UPS via 'mvn clean package'
> > 8/ Put war into
> > openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments
> 
> This may be able to be done from the keycloak console.

Right, but not in SaaS scenario, only if app and Keycloak run on same instance.

> 
> > 9/ Push that online
> > 10/ Create UPS cart using reflector cartridge (use commit sha1 if not using
> > master), enable mysql-5.1 gear as well
> > 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm
> > 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee.
> >
> 
> :)
> 


From stian at redhat.com  Wed Feb  5 08:52:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 5 Feb 2014 08:52:43 -0500 (EST)
Subject: [keycloak-dev] theme thought
In-Reply-To: <52F23636.8040102@redhat.com>
References: <52F17868.3090400@redhat.com>
	<1511434428.19743255.1391598759865.JavaMail.root@redhat.com>
	<52F23636.8040102@redhat.com>
Message-ID: <87480995.19836624.1391608363363.JavaMail.root@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: Wednesday, 5 February, 2014 1:01:42 PM
> Subject: Re: [keycloak-dev] theme thought
> 
> 
> 
> On 2/5/2014 6:12 AM, Stian Thorgersen wrote:
> > Not sure why you'd want multiple themes?
> >
> 
> Different apps may want a different logon screens?

As you login to a SSO realm, and not an individual app, shouldn't it be the same?

> 
> > Internationalization will be taken care of by locale specific message
> > bundles (e.g. messages_no.properties). We could also add the option of
> > having locale specific templates (e.g. login_no.ftl), not sure that would
> > be needed though.
> >
> 
> message bundles work great for logging messages.  I'm not sure its
> always the case for rendered content.  I've also been told in the past
> that different cultures prefer different color schemes.

True, so you may need local specific stylesheets as well

> 
> I don't know what the right answer is, but its something that should be
> researched for best practice.

Yup, that's the main reason I've not included internationalization support now ;)

> 
> > I'm not sure how correct locale is discovered either, I'm sure there's
> > folks on the portal theme that knows this ;). We may need to add an option
> > to pass it as a query param from the app though. With the hostname
> > examples you've given wouldn't those be app urls rather than keycloak
> > urls?
> >
> 
> Answering my own question: Openid Connect supports locale as a query param.

Seems like every time when I propose to add a query param to the login url, OpenID connect has done the same ;)

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

From bburke at redhat.com  Wed Feb  5 09:05:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 09:05:26 -0500
Subject: [keycloak-dev] composite roles in
In-Reply-To: <287296343.19825112.1391607433613.JavaMail.root@redhat.com>
References: <52F17BBC.4030609@redhat.com>
	<585965965.19757889.1391601438372.JavaMail.root@redhat.com>
	<52F23B88.5020300@redhat.com>
	<287296343.19825112.1391607433613.JavaMail.root@redhat.com>
Message-ID: <52F24526.9060902@redhat.com>



On 2/5/2014 8:37 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: Wednesday, 5 February, 2014 1:24:24 PM
>> Subject: Re: [keycloak-dev] composite roles in
>>
>>
>>
>> On 2/5/2014 6:57 AM, Stian Thorgersen wrote:
>>> Instead of allowing multiple default roles should we not have a single
>>> initial role on a realm? This means we can remove the default roles page,
>>> and instead have a simple select list on the realm settings page.
>>>
>>
>> I'd also like to consolidate default roles into one place on Realm Settings.
>>
>> Implementation wise, default roles wouldn't be a composite as I don't
>> want it showing up in role listings, or having to put in special logic
>> not to show it.
>
> What I was thinking was that the default roles would be a single role. It could be a composite role if the user wanted to. You simply select which role you want to use as the default role that is assigned to all user when created.
>
> This then lets you manage this role as a normal role, which means there's no special logic or screens required for it. It's possible to add/remove this role to users, apps, etc if you want to. And as its can be a composite role you can add/remove roles to it if you want as well.
>
> 'Default roles' is confusing as well, is it not some initial roles granted users when they are created?
>

There's special logic as you don't want "DEFAULT ROLE" showing up in the 
OAuth Grant page.  There's also an additional screen required, in that 
you have to specify what your default role is.  Also you have to have 2 
clicks to actually view what the default roles are.

IMO, just have 1 default-roles screen where you can see and manage your 
default roles in one place.

>>
>>> We could also have both a initial role and a default role associated with a
>>> realm. The initial role is provided to users when they register or are
>>> created through admin console, while the default role is always granted to
>>> all users.
>>>
>>
>> I don't agree you need two different types here.  What we really need is
>> the ability to apply bulk changes to users.
>
> Are there not situations where you have some roles that all logged-in users should have? For example 'view-profile' would be an example of a role that all users should have regardless.
>

Right now, this is automatically added to default roles, right?

> Then again there's the situation where you want to have roles allocated to users when they register, but you may want to remove those later. I'm not sure I'm that convinced about this use-case, but both you and Marek argued this would be needed. Reason why I'm unsure about it, is that if a user self-registers, then looses some registration roles the user can simply re-register to gain those permissions again.
>

The case is when I want to disallow a role for 1 user, so I have to 
remove that role from "default roles" which would then require me to add 
that role to every other user.

>> Apps or realms can have composite roles.  These composites can be made
>> up of any realm or app role.  Does the app-role screen not allow
>> composites, not work?
>
> This doesn't make sense to me. Why can you have an app specific role that can be made up of roles from other apps?
>

Makes a lot of sense when you have an application that is a REST service 
that is being called by another application.  Our demo for instance.  So 
a "USER" role in the customer-portal would have "CUSTOMER_READ" 
privilege in the database-service.

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

From bburke at redhat.com  Wed Feb  5 09:11:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 09:11:01 -0500
Subject: [keycloak-dev] openid connect logout is weird
Message-ID: <52F24675.3090906@redhat.com>

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

They set up invisible iframes so that an app can query the auth server's 
iframe to check to see if the login cookie is still set.  Doesn't that 
seem weird?

Was kind of hoping for a REST interface back to the application like we 
currently have.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Feb  5 09:23:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 09:23:06 -0500
Subject: [keycloak-dev] Aerogear UPS + Keycloak cartridge combined
 together POC
In-Reply-To: <20140205143504.563c6771@kapy-ntb-x220>
References: <20140204181339.60267f2c@kapy-ntb-x220>	<52F136B9.3090906@redhat.com>
	<20140205143504.563c6771@kapy-ntb-x220>
Message-ID: <52F2494A.9040904@redhat.com>



On 2/5/2014 8:35 AM, Karel Piwko wrote:
> On Tue, 04 Feb 2014 13:51:37 -0500
> Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 2/4/2014 12:13 PM, Karel Piwko wrote:
>>> Hey,
>>>
>>> I've combined Aerogear UPS and Keycloak cartridges together. You can check
>>> the results at:
>>>
>>> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
>>> https://keycloak-mobileqa.rhcloud.com/ (admin/password)
>>>
>>> For keycloak, I have used original cart [1]:
>>>
>>> $ rhc app create -g small --no-git keycloak
>>> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
>>>
>>> For UPS, I have modified matzew's one stored in my repo [2] and modified UPS
>>> [3]:
>
> Given your comments, I'll modify setup to have (primarily) single cart option.
> Should I keep two carts setup? It at least seems as a good QE test case ;-)
>
> Note, I will either have to wait for WF8 Final (due to Hibernate bug in CR1) or
> base cart on AS7.
>
>>>
>>> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1
>>> 'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75'
>>>
>>> There are some gotchas though:
>>>
>>> * keycloak.json - I'm not sure how this will be addressed by WF subsystem.
>>> We still need a way how to pass keycloak.json to UPS cartridge, which is AS7
>>>     and we can't ask user to modify standalone.xml anyway. However, we could
>>> make a hook on OpenShift - user will add keycloak.json to git repo and it
>>> will automagically put at right location. Could we have a hook in Keycloak
>>> to load keycloak.json from external location? Or should we rather do some
>>> war exploding magic?
>>
>> I need to go through Stan's work.  I want to be able to configure the
>> subsystem from the keycloak admin console without having to create a
>> keycloak.json file.  I just don't know yet if the subsystem will work on
>> AS7.
>
>
> This will work for app and Keycloak being deployed on a single server. It does
> not solve SaaS scenario - keycloak admin console can configure subsystem of
> current WF(AS) only. Keycloak would need to manage subsystem of a remote WF - I
> doubt this would ever be possible with AS7 on OpenShift and I think security
> concerns of such setup are not even allowing this on WF8.
>

You can make authenticated HTTP requests to the WF/AS7 admin interface. 
  Maybe Openshift is disallowing this, but its certainly not the case 
with WF.  My understanding is that the new WF admin console will be a 
pure HTML 5 application making CORS requests to the admin REST interface 
of WF.

What I'm saying is, this will work in the SaaS scenario if Openshift has 
not turned off the AS7/WF admin interface.

>>
>>
>>> * AS7-3227 I worked this around by doing parameter injection for
>>>     SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of
>>> Keycloak package for AS7? Any better option?
>>
>> This is an UPS issue right?  Keycloak WAR bundles is own Resteasy and
>> excludes built in one.
>
> Well, it is either keycloak packaging issue or documentation issue (or problem
> here in Brno in between chair and keyboard). I've added
> keycloak-as7-adapter-dist to AS7. Keycloak WAR was added to different
> cartridge. So, AS7 (UPS) is still using old RESTEasy 2.x. This will be fixed
> if newer RESTEasy is packaged inside of keycloak-as7-adapter-dist instead of
> Keycloak WAR. IIRC this was setup pre alpha-1.

There are two things:

* The keycloak auth-server.war which is the authentication server
* The adapter zip which installs "client" modules and used only for 
WF/AS7 instances that want to interact with a Keycloak auth server.

The adapter does not have a dependency on Resteasy, only on Apache HTTP 
Client 4.1.x (or higher).  The auth-server does have a dependency on 
Resteasy.


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

From stian at redhat.com  Wed Feb  5 09:54:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 5 Feb 2014 09:54:11 -0500 (EST)
Subject: [keycloak-dev] openid connect logout is weird
In-Reply-To: <52F24675.3090906@redhat.com>
References: <52F24675.3090906@redhat.com>
Message-ID: <784670642.19898695.1391612051158.JavaMail.root@redhat.com>

Haven't read up on OpenID Connect yet, but it does seem a bit hack'ish. With cors support I don't see why the same couldn't be achieved with a ajax request.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 5 February, 2014 2:11:01 PM
> Subject: [keycloak-dev] openid connect logout is weird
> 
> http://openid.net/specs/openid-connect-session-1_0.html
> 
> They set up invisible iframes so that an app can query the auth server's
> iframe to check to see if the login cookie is still set.  Doesn't that
> seem weird?
> 
> Was kind of hoping for a REST interface back to the application like we
> currently have.
> --
> 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 Feb  5 09:56:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 09:56:10 -0500
Subject: [keycloak-dev] openid connect logout is weird
In-Reply-To: <784670642.19898695.1391612051158.JavaMail.root@redhat.com>
References: <52F24675.3090906@redhat.com>
	<784670642.19898695.1391612051158.JavaMail.root@redhat.com>
Message-ID: <52F2510A.9080403@redhat.com>

It seems to exist for mobile apps to get rid of a distribute call.

On 2/5/2014 9:54 AM, Stian Thorgersen wrote:
> Haven't read up on OpenID Connect yet, but it does seem a bit hack'ish. With cors support I don't see why the same couldn't be achieved with a ajax request.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 5 February, 2014 2:11:01 PM
>> Subject: [keycloak-dev] openid connect logout is weird
>>
>> http://openid.net/specs/openid-connect-session-1_0.html
>>
>> They set up invisible iframes so that an app can query the auth server's
>> iframe to check to see if the login cookie is still set.  Doesn't that
>> seem weird?
>>
>> Was kind of hoping for a REST interface back to the application like we
>> currently have.
>> --
>> 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 kpiwko at redhat.com  Wed Feb  5 10:08:29 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Wed, 5 Feb 2014 16:08:29 +0100
Subject: [keycloak-dev] Aerogear UPS + Keycloak cartridge combined
 together POC
In-Reply-To: <52F2494A.9040904@redhat.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<52F136B9.3090906@redhat.com>
	<20140205143504.563c6771@kapy-ntb-x220>
	<52F2494A.9040904@redhat.com>
Message-ID: <20140205160829.1cacf8b3@kapy-ntb-x220>

On Wed, 05 Feb 2014 09:23:06 -0500
Bill Burke <bburke at redhat.com> wrote:

> 
> 
> On 2/5/2014 8:35 AM, Karel Piwko wrote:
> > On Tue, 04 Feb 2014 13:51:37 -0500
> > Bill Burke <bburke at redhat.com> wrote:
> >
> >>
> >>
> >> On 2/4/2014 12:13 PM, Karel Piwko wrote:
> >>> Hey,
> >>>
> >>> I've combined Aerogear UPS and Keycloak cartridges together. You can check
> >>> the results at:
> >>>
> >>> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
> >>> https://keycloak-mobileqa.rhcloud.com/ (admin/password)
> >>>
> >>> For keycloak, I have used original cart [1]:
> >>>
> >>> $ rhc app create -g small --no-git keycloak
> >>> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
> >>>
> >>> For UPS, I have modified matzew's one stored in my repo [2] and modified
> >>> UPS [3]:
> >
> > Given your comments, I'll modify setup to have (primarily) single cart
> > option. Should I keep two carts setup? It at least seems as a good QE test
> > case ;-)
> >
> > Note, I will either have to wait for WF8 Final (due to Hibernate bug in
> > CR1) or base cart on AS7.
> >
> >>>
> >>> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1
> >>> 'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75'
> >>>
> >>> There are some gotchas though:
> >>>
> >>> * keycloak.json - I'm not sure how this will be addressed by WF subsystem.
> >>> We still need a way how to pass keycloak.json to UPS cartridge, which is
> >>> AS7 and we can't ask user to modify standalone.xml anyway. However, we
> >>> could make a hook on OpenShift - user will add keycloak.json to git repo
> >>> and it will automagically put at right location. Could we have a hook in
> >>> Keycloak to load keycloak.json from external location? Or should we
> >>> rather do some war exploding magic?
> >>
> >> I need to go through Stan's work.  I want to be able to configure the
> >> subsystem from the keycloak admin console without having to create a
> >> keycloak.json file.  I just don't know yet if the subsystem will work on
> >> AS7.
> >
> >
> > This will work for app and Keycloak being deployed on a single server. It
> > does not solve SaaS scenario - keycloak admin console can configure
> > subsystem of current WF(AS) only. Keycloak would need to manage subsystem
> > of a remote WF - I doubt this would ever be possible with AS7 on OpenShift
> > and I think security concerns of such setup are not even allowing this on
> > WF8.
> >
> 
> You can make authenticated HTTP requests to the WF/AS7 admin interface. 
>   Maybe Openshift is disallowing this, but its certainly not the case 
> with WF.  My understanding is that the new WF admin console will be a 
> pure HTML 5 application making CORS requests to the admin REST interface 
> of WF.
> 
> What I'm saying is, this will work in the SaaS scenario if Openshift has 
> not turned off the AS7/WF admin interface.
> 

OpenShift disabled most of the ports but 8080, admin interface port being on
of disabled. WF provides port multiplexing, I have no idea whether they
allowed management port there. Ports can be reached using port forwarding [1]
though but this will add much to complexity of cart setup steps.

I'll need to go through Stan's work and get more info.

[1] https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift
> >>
> >>
> >>> * AS7-3227 I worked this around by doing parameter injection for
> >>>     SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of
> >>> Keycloak package for AS7? Any better option?
> >>
> >> This is an UPS issue right?  Keycloak WAR bundles is own Resteasy and
> >> excludes built in one.
> >
> > Well, it is either keycloak packaging issue or documentation issue (or
> > problem here in Brno in between chair and keyboard). I've added
> > keycloak-as7-adapter-dist to AS7. Keycloak WAR was added to different
> > cartridge. So, AS7 (UPS) is still using old RESTEasy 2.x. This will be fixed
> > if newer RESTEasy is packaged inside of keycloak-as7-adapter-dist instead of
> > Keycloak WAR. IIRC this was setup pre alpha-1.
> 
> There are two things:
> 
> * The keycloak auth-server.war which is the authentication server
> * The adapter zip which installs "client" modules and used only for 
> WF/AS7 instances that want to interact with a Keycloak auth server.
> 
> The adapter does not have a dependency on Resteasy, only on Apache HTTP 
> Client 4.1.x (or higher).  The auth-server does have a dependency on 
> Resteasy.
> 

So the point is, if UPS does injection via @javax.ws.rs.core.Context, it should
bundle newer RESTEasy in WAR instead of relying on 2.3.2.Final in AS7, right?

> 


From bburke at redhat.com  Wed Feb  5 10:20:30 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 10:20:30 -0500
Subject: [keycloak-dev] Aerogear UPS + Keycloak cartridge combined
 together POC
In-Reply-To: <20140205160829.1cacf8b3@kapy-ntb-x220>
References: <20140204181339.60267f2c@kapy-ntb-x220>	<52F136B9.3090906@redhat.com>	<20140205143504.563c6771@kapy-ntb-x220>	<52F2494A.9040904@redhat.com>
	<20140205160829.1cacf8b3@kapy-ntb-x220>
Message-ID: <52F256BE.1060503@redhat.com>



On 2/5/2014 10:08 AM, Karel Piwko wrote:
> On Wed, 05 Feb 2014 09:23:06 -0500
> Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 2/5/2014 8:35 AM, Karel Piwko wrote:
>>> On Tue, 04 Feb 2014 13:51:37 -0500
>>> Bill Burke <bburke at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 2/4/2014 12:13 PM, Karel Piwko wrote:
>>>>> Hey,
>>>>>
>>>>> I've combined Aerogear UPS and Keycloak cartridges together. You can check
>>>>> the results at:
>>>>>
>>>>> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password)
>>>>> https://keycloak-mobileqa.rhcloud.com/ (admin/password)
>>>>>
>>>>> For keycloak, I have used original cart [1]:
>>>>>
>>>>> $ rhc app create -g small --no-git keycloak
>>>>> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml
>>>>>
>>>>> For UPS, I have modified matzew's one stored in my repo [2] and modified
>>>>> UPS [3]:
>>>
>>> Given your comments, I'll modify setup to have (primarily) single cart
>>> option. Should I keep two carts setup? It at least seems as a good QE test
>>> case ;-)
>>>
>>> Note, I will either have to wait for WF8 Final (due to Hibernate bug in
>>> CR1) or base cart on AS7.
>>>
>>>>>
>>>>> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1
>>>>> 'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75'
>>>>>
>>>>> There are some gotchas though:
>>>>>
>>>>> * keycloak.json - I'm not sure how this will be addressed by WF subsystem.
>>>>> We still need a way how to pass keycloak.json to UPS cartridge, which is
>>>>> AS7 and we can't ask user to modify standalone.xml anyway. However, we
>>>>> could make a hook on OpenShift - user will add keycloak.json to git repo
>>>>> and it will automagically put at right location. Could we have a hook in
>>>>> Keycloak to load keycloak.json from external location? Or should we
>>>>> rather do some war exploding magic?
>>>>
>>>> I need to go through Stan's work.  I want to be able to configure the
>>>> subsystem from the keycloak admin console without having to create a
>>>> keycloak.json file.  I just don't know yet if the subsystem will work on
>>>> AS7.
>>>
>>>
>>> This will work for app and Keycloak being deployed on a single server. It
>>> does not solve SaaS scenario - keycloak admin console can configure
>>> subsystem of current WF(AS) only. Keycloak would need to manage subsystem
>>> of a remote WF - I doubt this would ever be possible with AS7 on OpenShift
>>> and I think security concerns of such setup are not even allowing this on
>>> WF8.
>>>
>>
>> You can make authenticated HTTP requests to the WF/AS7 admin interface.
>>    Maybe Openshift is disallowing this, but its certainly not the case
>> with WF.  My understanding is that the new WF admin console will be a
>> pure HTML 5 application making CORS requests to the admin REST interface
>> of WF.
>>
>> What I'm saying is, this will work in the SaaS scenario if Openshift has
>> not turned off the AS7/WF admin interface.
>>
>
> OpenShift disabled most of the ports but 8080, admin interface port being on
> of disabled. WF provides port multiplexing, I have no idea whether they
> allowed management port there. Ports can be reached using port forwarding [1]
> though but this will add much to complexity of cart setup steps.
>
> I'll need to go through Stan's work and get more info.
>

Ugh, I guess we're up shit creek [1].  Maybe the adapter could be 
modified so that it could initiate joining the realm instead of the 
other way around.

[1] http://www.youtube.com/watch?v=2GqNstUJ3uY


> [1] https://www.openshift.com/forums/openshift/jboss-as7-management-in-openshift
>> The adapter does not have a dependency on Resteasy, only on Apache HTTP
>> Client 4.1.x (or higher).  The auth-server does have a dependency on
>> Resteasy.
>>
>
> So the point is, if UPS does injection via @javax.ws.rs.core.Context, it should
> bundle newer RESTEasy in WAR instead of relying on 2.3.2.Final in AS7, right?
>

@Context should work in 2.3.2, but maybe the context you're using 
@Context in doesn't work ;)

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

From vrockai at redhat.com  Wed Feb  5 12:12:03 2014
From: vrockai at redhat.com (Viliam Rockai)
Date: Wed, 05 Feb 2014 18:12:03 +0100
Subject: [keycloak-dev] The "powered" link
Message-ID: <1391620323.11607.2.camel@vrockai-laptop>

Hi All,

In the log-in form, at bottom right, we got a "powered by KC" link.
What's the purpose of such link? Any objections against removing it?

Viliam


From ssilvert at redhat.com  Wed Feb  5 12:19:07 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Wed, 05 Feb 2014 12:19:07 -0500
Subject: [keycloak-dev] theme thought
In-Reply-To: <52F17868.3090400@redhat.com>
References: <52F17868.3090400@redhat.com>
Message-ID: <52F2728B.7050708@redhat.com>

On 2/4/2014 6:31 PM, Bill Burke wrote:
> You'd probably want to support multiple concurrent themes for different 
> languages (french, spanish, english, etc...).  I'm just not sure how the 
> user-agent's language would be discovered.  Some do it by hostname i.e. 
> www.google.es or by a URL pattern example.com/en-US/...
The accept-language http header can be a good starting point.

I'd like to see preferred and accepted locales be a setting in the
user's profile.  That way, a federated application can find out that
information at login and pick the appropriate locale for the app's user
session.
>
> Just something to think about.
>


From stian at redhat.com  Wed Feb  5 12:31:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 5 Feb 2014 12:31:39 -0500 (EST)
Subject: [keycloak-dev] The "powered" link
In-Reply-To: <1391620323.11607.2.camel@vrockai-laptop>
References: <1391620323.11607.2.camel@vrockai-laptop>
Message-ID: <569946811.20017616.1391621499665.JavaMail.root@redhat.com>

+1 To removing

Was added once upon a time when we where aiming more for a SaaS solution. I think it's not required now, especially not as we have a nice Keycloak logo in the default theme ;)

----- Original Message -----
> From: "Viliam Rockai" <vrockai at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 5 February, 2014 5:12:03 PM
> Subject: [keycloak-dev] The "powered" link
> 
> Hi All,
> 
> In the log-in form, at bottom right, we got a "powered by KC" link.
> What's the purpose of such link? Any objections against removing it?
> 
> Viliam
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Wed Feb  5 14:35:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 14:35:17 -0500
Subject: [keycloak-dev] The "powered" link
In-Reply-To: <569946811.20017616.1391621499665.JavaMail.root@redhat.com>
References: <1391620323.11607.2.camel@vrockai-laptop>
	<569946811.20017616.1391621499665.JavaMail.root@redhat.com>
Message-ID: <52F29275.40200@redhat.com>

I say keep it.  Don't need it for admin console login, but IMO, its nice 
for other realms to have it in by default for branding purposes.

On 2/5/2014 12:31 PM, Stian Thorgersen wrote:
> +1 To removing
>
> Was added once upon a time when we where aiming more for a SaaS solution. I think it's not required now, especially not as we have a nice Keycloak logo in the default theme ;)
>
> ----- Original Message -----
>> From: "Viliam Rockai" <vrockai at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 5 February, 2014 5:12:03 PM
>> Subject: [keycloak-dev] The "powered" link
>>
>> Hi All,
>>
>> In the log-in form, at bottom right, we got a "powered by KC" link.
>> What's the purpose of such link? Any objections against removing it?
>>
>> Viliam
>>
>> _______________________________________________
>> 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 bburke at redhat.com  Wed Feb  5 16:03:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 16:03:52 -0500
Subject: [keycloak-dev] moving subsystem/
Message-ID: <52F2A738.2040609@redhat.com>

Moving subsystem to integration and renaming the directory.  Hopefully 
nobody is mucking with it.

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

From bburke at redhat.com  Wed Feb  5 20:40:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 20:40:10 -0500
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52EA68CA.800@redhat.com>
References: <52EA68CA.800@redhat.com>
Message-ID: <52F2E7FA.9060104@redhat.com>

I assume that we want to override any login-config/auth-method settings 
in the web.xml if the keycloak subsystem is using the deployment? 
Meaning, if web.xml defines auth-method as BASIC, and the subsystem has 
that war listed as a deployment we override the auth-method to be KEYCLOAK?


On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
> I've done the initial pull request for the Keycloak subsystem.  After
> starting fresh with the latest build I was finally able to verify  that
> it really does work end to end!
>
> I probably won't have much more time to work on Keycloak for the next
> 4-5 weeks.  So I'll try to put everything I know about it into these
> notes in case someone wants to take it over.  I happy to answer
> questions though.
>
> Directions to try the subsystem on your own:
> * Build the new subsystem module.
> * Rebuild the undertow adapter.  The EAP6 adapter has not been updated
> to use the subsystem, so you will need to use WildFly.
> * Update standalone.xml.  I've attached a version of standalone.xml that
> I used with the Keycloak appliance.  It shows adding the Keycloak
> extension near the top of the file and adding the subsystem definition
> near the bottom.
> * Copy
> keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
> * Copy
> keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
> to
> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
> * Edit module.xml and add the subsystem jar as a resource-root.
> Alternatively, you can just use the module.xml attached to this email.
> * Copy
> keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
> to
> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
>
> Now if you reboot WildFly you can view and manipulate the subsystem
> using CLI or CLI GUI.  All operations such as add/remove/write-attribute
> should be working.  I recommend CLI GUI so you can see everything in
> context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
>
> To test the subsystem with a live application, I did the following:
> * Copy the customer-portal.war to customer-portal-subsys.war.
> * Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
> The subsystem makes those files redundant.
> * Edit the web.xml inside the WAR and change the <module-name> to
> customer-portal-subsys.  I'm not sure if this is really needed.  If we
> need to manipulate web.xml settings at deploy time then the subsystem
> can be modified to do that too.
> * Define the customer-portal-subsys application in Keycloak Admin.  It
> should have the same settings as customer-portal.
> * Deploy customer-portal-subsys.war to WildFly and test it out.
>
> Future tasks for the Keycloak Subsystem:
> * Integration with the Keycloak Admin
> * Review the attributes of realm and secure-deployment to make sure they
> align with keycloak.json.
> * Fill in help text in
> keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
> * See comments in KeycloakAdapterConfigService.java.  This class may
> work better as a plain Singleton instead of a service.
> * It probably wouldn't hurt to ask Brian Stansberry to give the
> subsystem a quick review.
> * More tests
> * Package the subsystem with the distribution
> * Documentation
>
>
>
>
> _______________________________________________
> 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 Feb  5 21:19:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Feb 2014 21:19:04 -0500
Subject: [keycloak-dev] subsystem integration phase 1
Message-ID: <52F2F118.1020309@redhat.com>

Going to iterate on this.  The admin console UI could end up different 
in the end, but for phase 1 this is what I've decided to do:

* Get rid of RequiredApplicationCredentials.  Applications will have a 
viewable client secret from admin console.  This will be resetable form 
admin console too.  (cloud.google.com allows you to view the client secret)
* Application Install page will now just have a select list.  Options 
will be: "config file", "remote wildfly".  Basically all integration 
points we support.
* "config file" will display what we have now, except credential will be 
set up as client secret will be exposed
* "remote wildfly" will bring you to a page that asks for:

- URL of Wildfly admin
- username and password of wildfly instance
- deployment name
- A "Configure" button

Clicking the configure button will remotely set up the wildfly 
subsystem.  Creating a realm if it doesn't already exist, then creating 
the deployment.

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

From stian at redhat.com  Thu Feb  6 04:52:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Feb 2014 04:52:48 -0500 (EST)
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52F2E7FA.9060104@redhat.com>
References: <52EA68CA.800@redhat.com> <52F2E7FA.9060104@redhat.com>
Message-ID: <977427785.20734471.1391680368363.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 February, 2014 1:40:10 AM
> Subject: Re: [keycloak-dev] Keycloak Subsystem PR
> 
> I assume that we want to override any login-config/auth-method settings
> in the web.xml if the keycloak subsystem is using the deployment?
> Meaning, if web.xml defines auth-method as BASIC, and the subsystem has
> that war listed as a deployment we override the auth-method to be KEYCLOAK?

+1

> 
> 
> On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
> > I've done the initial pull request for the Keycloak subsystem.  After
> > starting fresh with the latest build I was finally able to verify  that
> > it really does work end to end!
> >
> > I probably won't have much more time to work on Keycloak for the next
> > 4-5 weeks.  So I'll try to put everything I know about it into these
> > notes in case someone wants to take it over.  I happy to answer
> > questions though.
> >
> > Directions to try the subsystem on your own:
> > * Build the new subsystem module.
> > * Rebuild the undertow adapter.  The EAP6 adapter has not been updated
> > to use the subsystem, so you will need to use WildFly.
> > * Update standalone.xml.  I've attached a version of standalone.xml that
> > I used with the Keycloak appliance.  It shows adding the Keycloak
> > extension near the top of the file and adding the subsystem definition
> > near the bottom.
> > * Copy
> > keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
> > <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
> > * Copy
> > keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
> > to
> > <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
> > * Edit module.xml and add the subsystem jar as a resource-root.
> > Alternatively, you can just use the module.xml attached to this email.
> > * Copy
> > keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
> > to
> > <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
> >
> > Now if you reboot WildFly you can view and manipulate the subsystem
> > using CLI or CLI GUI.  All operations such as add/remove/write-attribute
> > should be working.  I recommend CLI GUI so you can see everything in
> > context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
> >
> > To test the subsystem with a live application, I did the following:
> > * Copy the customer-portal.war to customer-portal-subsys.war.
> > * Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
> > The subsystem makes those files redundant.
> > * Edit the web.xml inside the WAR and change the <module-name> to
> > customer-portal-subsys.  I'm not sure if this is really needed.  If we
> > need to manipulate web.xml settings at deploy time then the subsystem
> > can be modified to do that too.
> > * Define the customer-portal-subsys application in Keycloak Admin.  It
> > should have the same settings as customer-portal.
> > * Deploy customer-portal-subsys.war to WildFly and test it out.
> >
> > Future tasks for the Keycloak Subsystem:
> > * Integration with the Keycloak Admin
> > * Review the attributes of realm and secure-deployment to make sure they
> > align with keycloak.json.
> > * Fill in help text in
> > keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
> > * See comments in KeycloakAdapterConfigService.java.  This class may
> > work better as a plain Singleton instead of a service.
> > * It probably wouldn't hurt to ask Brian Stansberry to give the
> > subsystem a quick review.
> > * More tests
> > * Package the subsystem with the distribution
> > * Documentation
> >
> >
> >
> >
> > _______________________________________________
> > 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 Feb  6 04:55:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Feb 2014 04:55:24 -0500 (EST)
Subject: [keycloak-dev] subsystem integration phase 1
In-Reply-To: <52F2F118.1020309@redhat.com>
References: <52F2F118.1020309@redhat.com>
Message-ID: <530736801.20735399.1391680524337.JavaMail.root@redhat.com>

Sounds good

I assume client secret will be generated by the server?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 February, 2014 2:19:04 AM
> Subject: [keycloak-dev] subsystem integration phase 1
> 
> Going to iterate on this.  The admin console UI could end up different
> in the end, but for phase 1 this is what I've decided to do:
> 
> * Get rid of RequiredApplicationCredentials.  Applications will have a
> viewable client secret from admin console.  This will be resetable form
> admin console too.  (cloud.google.com allows you to view the client secret)
> * Application Install page will now just have a select list.  Options
> will be: "config file", "remote wildfly".  Basically all integration
> points we support.
> * "config file" will display what we have now, except credential will be
> set up as client secret will be exposed
> * "remote wildfly" will bring you to a page that asks for:
> 
> - URL of Wildfly admin
> - username and password of wildfly instance
> - deployment name
> - A "Configure" button
> 
> Clicking the configure button will remotely set up the wildfly
> subsystem.  Creating a realm if it doesn't already exist, then creating
> the deployment.
> 
> --
> 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 Feb  6 05:02:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Feb 2014 05:02:31 -0500 (EST)
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <1246011560.20736389.1391680620149.JavaMail.root@redhat.com>
Message-ID: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>

A user should have an id, username and email (what we have now). The id should be generated by the server and should never change for a user. The sub field in the token should use this id, not the username. Applications that wants to store information associated with a specific user should also use this id, not the username or email, as the id will never change.

That means it should be possible for a user to change his/her username. Obviously a username has to be unique within a realm. We should then allow a user to login with either their username or their password. When a user is able to login with their username we can also remove the forgot username option on the login form, and only have a forgot password option.

This would also help integration with social login as now we don't have to try to create a sensible username for a user on social login. Instead we create a generated id, and don't even set a username. A user can then set the username they want through the account management (or on the update profile action page if that option is enabled).

If there's no objections to this, I'd like to add these changes to alpha2.

From kpiwko at redhat.com  Thu Feb  6 06:50:09 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 6 Feb 2014 12:50:09 +0100
Subject: [keycloak-dev] subsystem integration phase 1
In-Reply-To: <52F2F118.1020309@redhat.com>
References: <52F2F118.1020309@redhat.com>
Message-ID: <20140206125009.3c014835@kapy-ntb-x220>

On Wed, 05 Feb 2014 21:19:04 -0500
Bill Burke <bburke at redhat.com> wrote:

> Going to iterate on this.  The admin console UI could end up different 
> in the end, but for phase 1 this is what I've decided to do:
> 
> * Get rid of RequiredApplicationCredentials.  Applications will have a 
> viewable client secret from admin console.  This will be resetable form 
> admin console too.  (cloud.google.com allows you to view the client secret)
> * Application Install page will now just have a select list.  Options 
> will be: "config file", "remote wildfly".  Basically all integration 
> points we support.
> * "config file" will display what we have now, except credential will be 
> set up as client secret will be exposed
> * "remote wildfly" will bring you to a page that asks for:
> 
> - URL of Wildfly admin
> - username and password of wildfly instance
> - deployment name
> - A "Configure" button
> 
> Clicking the configure button will remotely set up the wildfly 
> subsystem.  
Sounds great.

> Creating a realm if it doesn't already exist, then creating 
> the deployment.
> 
What is meant by deployment here? User will provide a WAR/EAR that we be
remotely deployed?


From ssilvert at redhat.com  Thu Feb  6 07:21:59 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 06 Feb 2014 07:21:59 -0500
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52F2E7FA.9060104@redhat.com>
References: <52EA68CA.800@redhat.com> <52F2E7FA.9060104@redhat.com>
Message-ID: <52F37E67.7070800@redhat.com>

On 2/5/2014 8:40 PM, Bill Burke wrote:
> I assume that we want to override any login-config/auth-method settings 
> in the web.xml if the keycloak subsystem is using the deployment? 
> Meaning, if web.xml defines auth-method as BASIC, and the subsystem has 
> that war listed as a deployment we override the auth-method to be KEYCLOAK?
Yes, I think it should do that.

I think probably the subsystem should always take precedence.  It occurs
to me that I did not follow that rule when loading json.  Right now a
keycloak.json file will take precedence over subsystem settings.  But
that is probably wrong.
>
>
> On 1/30/2014 9:59 AM, ssilvert at redhat.com wrote:
>> I've done the initial pull request for the Keycloak subsystem.  After
>> starting fresh with the latest build I was finally able to verify  that
>> it really does work end to end!
>>
>> I probably won't have much more time to work on Keycloak for the next
>> 4-5 weeks.  So I'll try to put everything I know about it into these
>> notes in case someone wants to take it over.  I happy to answer
>> questions though.
>>
>> Directions to try the subsystem on your own:
>> * Build the new subsystem module.
>> * Rebuild the undertow adapter.  The EAP6 adapter has not been updated
>> to use the subsystem, so you will need to use WildFly.
>> * Update standalone.xml.  I've attached a version of standalone.xml that
>> I used with the Keycloak appliance.  It shows adding the Keycloak
>> extension near the top of the file and adding the subsystem definition
>> near the bottom.
>> * Copy
>> keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>> * Copy
>> keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
>> to
>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
>> * Edit module.xml and add the subsystem jar as a resource-root.
>> Alternatively, you can just use the module.xml attached to this email.
>> * Copy
>> keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
>> to
>> <WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
>>
>> Now if you reboot WildFly you can view and manipulate the subsystem
>> using CLI or CLI GUI.  All operations such as add/remove/write-attribute
>> should be working.  I recommend CLI GUI so you can see everything in
>> context.  https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
>>
>> To test the subsystem with a live application, I did the following:
>> * Copy the customer-portal.war to customer-portal-subsys.war.
>> * Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
>> The subsystem makes those files redundant.
>> * Edit the web.xml inside the WAR and change the <module-name> to
>> customer-portal-subsys.  I'm not sure if this is really needed.  If we
>> need to manipulate web.xml settings at deploy time then the subsystem
>> can be modified to do that too.
>> * Define the customer-portal-subsys application in Keycloak Admin.  It
>> should have the same settings as customer-portal.
>> * Deploy customer-portal-subsys.war to WildFly and test it out.
>>
>> Future tasks for the Keycloak Subsystem:
>> * Integration with the Keycloak Admin
>> * Review the attributes of realm and secure-deployment to make sure they
>> align with keycloak.json.
>> * Fill in help text in
>> keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
>> * See comments in KeycloakAdapterConfigService.java.  This class may
>> work better as a plain Singleton instead of a service.
>> * It probably wouldn't hurt to ask Brian Stansberry to give the
>> subsystem a quick review.
>> * More tests
>> * Package the subsystem with the distribution
>> * Documentation
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From ssilvert at redhat.com  Thu Feb  6 08:01:18 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 06 Feb 2014 08:01:18 -0500
Subject: [keycloak-dev] subsystem integration phase 1
In-Reply-To: <20140206125009.3c014835@kapy-ntb-x220>
References: <52F2F118.1020309@redhat.com>
	<20140206125009.3c014835@kapy-ntb-x220>
Message-ID: <52F3879E.7010506@redhat.com>

On 2/6/2014 6:50 AM, Karel Piwko wrote:
> On Wed, 05 Feb 2014 21:19:04 -0500
> Bill Burke <bburke at redhat.com> wrote:
>
>> Going to iterate on this.  The admin console UI could end up different 
>> in the end, but for phase 1 this is what I've decided to do:
>>
>> * Get rid of RequiredApplicationCredentials.  Applications will have a 
>> viewable client secret from admin console.  This will be resetable form 
>> admin console too.  (cloud.google.com allows you to view the client secret)
>> * Application Install page will now just have a select list.  Options 
>> will be: "config file", "remote wildfly".  Basically all integration 
>> points we support.
>> * "config file" will display what we have now, except credential will be 
>> set up as client secret will be exposed
>> * "remote wildfly" will bring you to a page that asks for:
>>
>> - URL of Wildfly admin
>> - username and password of wildfly instance
>> - deployment name
>> - A "Configure" button
>>
>> Clicking the configure button will remotely set up the wildfly 
>> subsystem.  
> Sounds great.
>
>> Creating a realm if it doesn't already exist, then creating 
>> the deployment.
>>
> What is meant by deployment here? User will provide a WAR/EAR that we be
> remotely deployed?
He means the association of the deployment with the realm.  A realm can
have zero or more secure-deployment resources.  The name of the
secure-deployment maps to a deployment name in WildFly.

At deploy time, the keycloak subsystem checks to see if the deployment
name matches a secure-deployment defined in the subsystem.  If so, it
adds all the keycloak goodness.

This does bring up one possible usability issue.  If you intend for your
deployment to be managed by the keycloak subsystem then you don't want
to deploy it until you have defined it in the subsystem.  So the
workflow is like this:

1) Define the secure-deployment in the keycloak subsystem.
2) Deploy the application on WildFly

The problem here in step 1 is that there is no way to pick the
deployment from a list in Keycloak admin.  You just have to know what
name it will be deployed under before you deploy.  That's not a big
problem, but it's not ideal.

Alternatively, you could do this:
1) Deploy the application in a disabled state.  This is allowed in both
CLI and web console, but it is not the default.
2) Define the secure-deployment in the keycloak subsystem.
3) Enable the deployment.

The problem with this is that because disabled is not the default, the
application is likely to be deployed in an unsecure state for some
period of time.

Ideally, you could deploy the application from Keycloak admin.  It would
automatically deploy in a disabled state and then enable the application
when security setup is complete.  IMO, deployment from Keycloak should
become the preferred deployment method in production systems.  It would
be a lot cleaner than what admins are faced with today.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From kpiwko at redhat.com  Thu Feb  6 08:22:15 2014
From: kpiwko at redhat.com (Karel Piwko)
Date: Thu, 6 Feb 2014 14:22:15 +0100
Subject: [keycloak-dev] [aerogear-dev] Aerogear UPS + Keycloak cartridge
 combined together POC
In-Reply-To: <CAAg5f2TmR_2=wwCQaGRQQWBaWx4n3NPzNEeYOu+zN+LZ+i8+OQ@mail.gmail.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
	<CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>
	<20140204183437.0737d77f@kapy-ntb-x220>
	<CAAg5f2RzyGYRf36-abKv_rn8TZ6v1sH3LO-_YfFoLRczs8Ln3g@mail.gmail.com>
	<52F1383F.1080804@redhat.com>
	<CAAg5f2TmR_2=wwCQaGRQQWBaWx4n3NPzNEeYOu+zN+LZ+i8+OQ@mail.gmail.com>
Message-ID: <20140206142215.769083f8@kapy-ntb-x220>

On Tue, 4 Feb 2014 20:28:53 +0100
Matthias Wessendorf <matzew at apache.org> wrote:

> On Tue, Feb 4, 2014 at 7:58 PM, Bill Burke <bburke at redhat.com> wrote:
> 
> >
> >
> > On 2/4/2014 12:38 PM, Matthias Wessendorf wrote:
> > >     I've added Keycloak AS7 modules to UPS cart but not admin console. I
> > >     believe
> > >     that Keycloak is SaaS, so usage with two different carts reflect
> > >     reality better.
> > >     Configuring Keycloak cart once and let all other carts use is seems
> > >     the right
> > >     way to me.
> > >
> > >
> > > there is IMO pros and cons in both ways
> > >
> >
> > Originally, Keycloak was going to be a SaaS.  One internet service where
> > users could register and create their own Realms....But, we decided that
> > users will probably want to have full control of their security metadata
> > and not share a database with other users.  Less we have to worry about
> > from a storage security standpoint.
> >
> > IMO, UPS should support bundling its own keycloak server already
> > preconfigured, or, it should hook into an existing keycloak instance.
> 
> 
> 
> exactly - that also makes the user experience way better, running
> everything in the cloud, OOTB
> 

How would we handle "scaling" scenario in cloud? While it does make perfect
sense to scale UPS part of combined cartridge, scaling Keycloak auth app does
not make any sense to me. 

> -M
> 
> 
> >  I
> > don't know if this would require 2 different cartridges, or if you would
> > have an online "installation" UI to make these types of decisions.
> >
> > --
> > 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 Feb  6 09:15:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 09:15:41 -0500
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
Message-ID: <52F3990D.5070101@redhat.com>



On 2/6/2014 5:02 AM, Stian Thorgersen wrote:
> A user should have an id, username and email (what we have now). The id should be generated by the server and should never change for a user. The sub field in the token should use this id, not the username. Applications that wants to store information associated with a specific user should also use this id, not the username or email, as the id will never change.
>
> That means it should be possible for a user to change his/her username. Obviously a username has to be unique within a realm. We should then allow a user to login with either their username or their password. When a user is able to login with their username we can also remove the forgot username option on the login form, and only have a forgot password option.
>
> This would also help integration with social login as now we don't have to try to create a sensible username for a user on social login. Instead we create a generated id, and don't even set a username. A user can then set the username they want through the account management (or on the update profile action page if that option is enabled).
>
> If there's no objections to this, I'd like to add these changes to alpha2.

Ugh, this is just a nasty change.  usernames will rarely, if ever, 
change and I don't like the idea that users can change their username. 
A principal name of "bill" is much more coherent than 
"2341235234234-234123-234123-2341234".

I want to ping jboss.org guys and see if they allow changing or setting 
usernames for their social login or how they handle that scenario.

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

From bburke at redhat.com  Thu Feb  6 09:27:13 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 09:27:13 -0500
Subject: [keycloak-dev] Keycloak Subsystem PR
In-Reply-To: <52F37E67.7070800@redhat.com>
References: <52EA68CA.800@redhat.com> <52F2E7FA.9060104@redhat.com>
	<52F37E67.7070800@redhat.com>
Message-ID: <52F39BC1.1040200@redhat.com>



On 2/6/2014 7:21 AM, ssilvert at redhat.com wrote:
> On 2/5/2014 8:40 PM, Bill Burke wrote:
>> I assume that we want to override any login-config/auth-method settings
>> in the web.xml if the keycloak subsystem is using the deployment?
>> Meaning, if web.xml defines auth-method as BASIC, and the subsystem has
>> that war listed as a deployment we override the auth-method to be KEYCLOAK?
> Yes, I think it should do that.
>
> I think probably the subsystem should always take precedence.  It occurs
> to me that I did not follow that rule when loading json.  Right now a
> keycloak.json file will take precedence over subsystem settings.  But
> that is probably wrong.

I already made the login-config change.  I'll need to make the subsystem 
precedence change.


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

From bburke at redhat.com  Thu Feb  6 09:45:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 09:45:43 -0500
Subject: [keycloak-dev] subsystem integration phase 1
In-Reply-To: <52F3879E.7010506@redhat.com>
References: <52F2F118.1020309@redhat.com>	<20140206125009.3c014835@kapy-ntb-x220>
	<52F3879E.7010506@redhat.com>
Message-ID: <52F3A017.5090500@redhat.com>



On 2/6/2014 8:01 AM, ssilvert at redhat.com wrote:
>
> The problem with this is that because disabled is not the default, the
> application is likely to be deployed in an unsecure state for some
> period of time.
>

This isn't a big deal if you have enabled login-config.  I'm pretty sure 
it defaults to "other" which defaults to the application*.properties 
files (which are empty by default).  So you wouldn't be able to use the 
application anyways.

> Ideally, you could deploy the application from Keycloak admin.  It would
> automatically deploy in a disabled state and then enable the application
> when security setup is complete.  IMO, deployment from Keycloak should
> become the preferred deployment method in production systems.  It would
> be a lot cleaner than what admins are faced with today.

Not sure I like the idea of deploying apps through Keycloak, although it 
would probably be really easy to implement it.  I think we need to 
define the preferred ways we want this to work.

It might be like this:

Scenario 1:  There is no existing keycloak app

1. Deploy the app to wildfly instance
2. Go to Keycloak Realm
3. Click a "Import Application" button on Application page
4. specify URL of wildfly instance and deployment name (and credentials)
5. Suck up role definitions from Wildfly instance
6. push back to instance a client id and secret, realm information, etc.

Scenario 2: There is an existing app

1. Go to Keycloak Realm
2. Go to Application page
3. Go to Installation page
4. Specify URL of wildfly instance and deployment name (and creds)
5. Push to the client id and secret and realm info to the wildfly instance.

What sucks implementation wise is that we have to have a Wildfly plugin 
on the Keycloak server.  Would be cool if we could define a common REST 
API for this.

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

From stian at redhat.com  Thu Feb  6 09:48:07 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Feb 2014 09:48:07 -0500 (EST)
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <52F3990D.5070101@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3990D.5070101@redhat.com>
Message-ID: <318495862.21013566.1391698087737.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 February, 2014 2:15:41 PM
> Subject: Re: [keycloak-dev] User ids and usernames
> 
> 
> 
> On 2/6/2014 5:02 AM, Stian Thorgersen wrote:
> > A user should have an id, username and email (what we have now). The id
> > should be generated by the server and should never change for a user. The
> > sub field in the token should use this id, not the username. Applications
> > that wants to store information associated with a specific user should
> > also use this id, not the username or email, as the id will never change.
> >
> > That means it should be possible for a user to change his/her username.
> > Obviously a username has to be unique within a realm. We should then allow
> > a user to login with either their username or their password. When a user
> > is able to login with their username we can also remove the forgot
> > username option on the login form, and only have a forgot password option.
> >
> > This would also help integration with social login as now we don't have to
> > try to create a sensible username for a user on social login. Instead we
> > create a generated id, and don't even set a username. A user can then set
> > the username they want through the account management (or on the update
> > profile action page if that option is enabled).
> >
> > If there's no objections to this, I'd like to add these changes to alpha2.
> 
> Ugh, this is just a nasty change.  usernames will rarely, if ever,
> change and I don't like the idea that users can change their username.
> A principal name of "bill" is much more coherent than
> "2341235234234-234123-234123-2341234".

Doesn't matter does it? It's just an identifier, if someone wants to know more about the user they should retrieve the user profile.

> 
> I want to ping jboss.org guys and see if they allow changing or setting
> usernames for their social login or how they handle that scenario.

Some sites lets users change their username, others don't. Without using the id of a user in the token we can't support applications that do want to let users change their passwords

BTW Google, Twitter, Facebook and GitHub all have a ID on a user as well as a username/login name.

In the future I think we should support various scenarios to accommodate what users of keycloaks needs are:

* No username, users can only login with email
* Allow changing username
* Don't allow users to change username

> 
> --
> 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 Feb  6 09:59:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 09:59:31 -0500
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <318495862.21013566.1391698087737.JavaMail.root@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3990D.5070101@redhat.com>
	<318495862.21013566.1391698087737.JavaMail.root@redhat.com>
Message-ID: <52F3A353.9010307@redhat.com>



On 2/6/2014 9:48 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 6 February, 2014 2:15:41 PM
>> Subject: Re: [keycloak-dev] User ids and usernames
>>
>>
>>
>> On 2/6/2014 5:02 AM, Stian Thorgersen wrote:
>>> A user should have an id, username and email (what we have now). The id
>>> should be generated by the server and should never change for a user. The
>>> sub field in the token should use this id, not the username. Applications
>>> that wants to store information associated with a specific user should
>>> also use this id, not the username or email, as the id will never change.
>>>
>>> That means it should be possible for a user to change his/her username.
>>> Obviously a username has to be unique within a realm. We should then allow
>>> a user to login with either their username or their password. When a user
>>> is able to login with their username we can also remove the forgot
>>> username option on the login form, and only have a forgot password option.
>>>
>>> This would also help integration with social login as now we don't have to
>>> try to create a sensible username for a user on social login. Instead we
>>> create a generated id, and don't even set a username. A user can then set
>>> the username they want through the account management (or on the update
>>> profile action page if that option is enabled).
>>>
>>> If there's no objections to this, I'd like to add these changes to alpha2.
>>
>> Ugh, this is just a nasty change.  usernames will rarely, if ever,
>> change and I don't like the idea that users can change their username.
>> A principal name of "bill" is much more coherent than
>> "2341235234234-234123-234123-2341234".
>
> Doesn't matter does it? It's just an identifier, if someone wants to know more about the user they should retrieve the user profile.

User profile would then have to be retrieved for most apps as most apps 
would want to display the username.  Maybe add an additional token 
extension for the username?  So an additional REST invocation back to 
obtain the user profile doesn't need to be done?

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

From ssilvert at redhat.com  Thu Feb  6 10:12:03 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 06 Feb 2014 10:12:03 -0500
Subject: [keycloak-dev] subsystem integration phase 1
In-Reply-To: <52F3A017.5090500@redhat.com>
References: <52F2F118.1020309@redhat.com>	<20140206125009.3c014835@kapy-ntb-x220>	<52F3879E.7010506@redhat.com>
	<52F3A017.5090500@redhat.com>
Message-ID: <52F3A643.8050406@redhat.com>

On 2/6/2014 9:45 AM, Bill Burke wrote:
>
> On 2/6/2014 8:01 AM, ssilvert at redhat.com wrote:
>> The problem with this is that because disabled is not the default, the
>> application is likely to be deployed in an unsecure state for some
>> period of time.
>>
> This isn't a big deal if you have enabled login-config.  I'm pretty sure 
> it defaults to "other" which defaults to the application*.properties 
> files (which are empty by default).  So you wouldn't be able to use the 
> application anyways.
That's the thing.  You shouldn't need a login-config if you are using
the Keycloak subsystem.
>
>> Ideally, you could deploy the application from Keycloak admin.  It would
>> automatically deploy in a disabled state and then enable the application
>> when security setup is complete.  IMO, deployment from Keycloak should
>> become the preferred deployment method in production systems.  It would
>> be a lot cleaner than what admins are faced with today.
> Not sure I like the idea of deploying apps through Keycloak, although it 
> would probably be really easy to implement it.  I think we need to 
> define the preferred ways we want this to work.
Yes, it's easy to implement.  I've already done it twice for web console
and CLI GUI.  I still think it's a cleaner, safer way to do it.  But
it's also something we don't need right away.  We need to support your
two scenarios anyway.
>
> It might be like this:
>
> Scenario 1:  There is no existing keycloak app
>
> 1. Deploy the app to wildfly instance
> 2. Go to Keycloak Realm
> 3. Click a "Import Application" button on Application page
> 4. specify URL of wildfly instance and deployment name (and credentials)
> 5. Suck up role definitions from Wildfly instance
> 6. push back to instance a client id and secret, realm information, etc.
>
> Scenario 2: There is an existing app
>
> 1. Go to Keycloak Realm
> 2. Go to Application page
> 3. Go to Installation page
> 4. Specify URL of wildfly instance and deployment name (and creds)
> 5. Push to the client id and secret and realm info to the wildfly instance.
>
> What sucks implementation wise is that we have to have a Wildfly plugin 
> on the Keycloak server.  Would be cool if we could define a common REST 
> API for this.
>
Do you mean a plugin for the Keycloak Admin?   You are saying that it
would be nice if we could do the equivalent of a subsystem on other app
servers and have a common API to talk to it?

From bburke at redhat.com  Thu Feb  6 10:22:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 10:22:17 -0500
Subject: [keycloak-dev] subsystem integration phase 1
In-Reply-To: <52F3A643.8050406@redhat.com>
References: <52F2F118.1020309@redhat.com>	<20140206125009.3c014835@kapy-ntb-x220>	<52F3879E.7010506@redhat.com>	<52F3A017.5090500@redhat.com>
	<52F3A643.8050406@redhat.com>
Message-ID: <52F3A8A9.4080604@redhat.com>



On 2/6/2014 10:12 AM, ssilvert at redhat.com wrote:
> On 2/6/2014 9:45 AM, Bill Burke wrote:
>>
>> On 2/6/2014 8:01 AM, ssilvert at redhat.com wrote:
>>> The problem with this is that because disabled is not the default, the
>>> application is likely to be deployed in an unsecure state for some
>>> period of time.
>>>
>> This isn't a big deal if you have enabled login-config.  I'm pretty sure
>> it defaults to "other" which defaults to the application*.properties
>> files (which are empty by default).  So you wouldn't be able to use the
>> application anyways.
> That's the thing.  You shouldn't need a login-config if you are using
> the Keycloak subsystem.

But you need security constraints :)

>>
>>> Ideally, you could deploy the application from Keycloak admin.  It would
>>> automatically deploy in a disabled state and then enable the application
>>> when security setup is complete.  IMO, deployment from Keycloak should
>>> become the preferred deployment method in production systems.  It would
>>> be a lot cleaner than what admins are faced with today.
>> Not sure I like the idea of deploying apps through Keycloak, although it
>> would probably be really easy to implement it.  I think we need to
>> define the preferred ways we want this to work.
> Yes, it's easy to implement.  I've already done it twice for web console
> and CLI GUI.  I still think it's a cleaner, safer way to do it.  But
> it's also something we don't need right away.  We need to support your
> two scenarios anyway.
>>
>> It might be like this:
>>
>> Scenario 1:  There is no existing keycloak app
>>
>> 1. Deploy the app to wildfly instance
>> 2. Go to Keycloak Realm
>> 3. Click a "Import Application" button on Application page
>> 4. specify URL of wildfly instance and deployment name (and credentials)
>> 5. Suck up role definitions from Wildfly instance
>> 6. push back to instance a client id and secret, realm information, etc.
>>
>> Scenario 2: There is an existing app
>>
>> 1. Go to Keycloak Realm
>> 2. Go to Application page
>> 3. Go to Installation page
>> 4. Specify URL of wildfly instance and deployment name (and creds)
>> 5. Push to the client id and secret and realm info to the wildfly instance.
>>
>> What sucks implementation wise is that we have to have a Wildfly plugin
>> on the Keycloak server.  Would be cool if we could define a common REST
>> API for this.
>>
> Do you mean a plugin for the Keycloak Admin?   You are saying that it
> would be nice if we could do the equivalent of a subsystem on other app
> servers and have a common API to talk to it?

common REST API that all app server's use.  We would write those 
adapters, but the admin console just talks through the common REST API.


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

From stian at redhat.com  Thu Feb  6 10:35:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Feb 2014 10:35:04 -0500 (EST)
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <52F3A353.9010307@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3990D.5070101@redhat.com>
	<318495862.21013566.1391698087737.JavaMail.root@redhat.com>
	<52F3A353.9010307@redhat.com>
Message-ID: <1692735266.21184297.1391700904957.JavaMail.root@redhat.com>

Why would an application need the username? I would think the application would more likely want the id, email and first/last name. For example:

* To store an entry in a db associated to the user the id should be used
* To display the logged in user the first/last name would be used

Thinking about this further, I really think the "reference" used on a user should be a unique id generated by the system and not a user specified string. An example scenario for a online image gallery where using a user specified username would cause problems:

1. User registers with 'bob'
2. User logs in to the image gallery
3. User uploads some private images
4. The user is later deleted by an admin because the user didn't pay his fees
5. Another user now registers as 'bob'
6. If the private images from the initial user are still there, the new user will now be able to access images not belonging to him

This makes me think that Keycloak should generate user ids, and we should make sure that even if a user is deleted, the id wouldn't be reused.

----- 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, 6 February, 2014 2:59:31 PM
> Subject: Re: [keycloak-dev] User ids and usernames
> 
> 
> 
> On 2/6/2014 9:48 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 6 February, 2014 2:15:41 PM
> >> Subject: Re: [keycloak-dev] User ids and usernames
> >>
> >>
> >>
> >> On 2/6/2014 5:02 AM, Stian Thorgersen wrote:
> >>> A user should have an id, username and email (what we have now). The id
> >>> should be generated by the server and should never change for a user. The
> >>> sub field in the token should use this id, not the username. Applications
> >>> that wants to store information associated with a specific user should
> >>> also use this id, not the username or email, as the id will never change.
> >>>
> >>> That means it should be possible for a user to change his/her username.
> >>> Obviously a username has to be unique within a realm. We should then
> >>> allow
> >>> a user to login with either their username or their password. When a user
> >>> is able to login with their username we can also remove the forgot
> >>> username option on the login form, and only have a forgot password
> >>> option.
> >>>
> >>> This would also help integration with social login as now we don't have
> >>> to
> >>> try to create a sensible username for a user on social login. Instead we
> >>> create a generated id, and don't even set a username. A user can then set
> >>> the username they want through the account management (or on the update
> >>> profile action page if that option is enabled).
> >>>
> >>> If there's no objections to this, I'd like to add these changes to
> >>> alpha2.
> >>
> >> Ugh, this is just a nasty change.  usernames will rarely, if ever,
> >> change and I don't like the idea that users can change their username.
> >> A principal name of "bill" is much more coherent than
> >> "2341235234234-234123-234123-2341234".
> >
> > Doesn't matter does it? It's just an identifier, if someone wants to know
> > more about the user they should retrieve the user profile.
> 
> User profile would then have to be retrieved for most apps as most apps
> would want to display the username.  Maybe add an additional token
> extension for the username?  So an additional REST invocation back to
> obtain the user profile doesn't need to be done?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Feb  6 10:41:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 10:41:34 -0500
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <1692735266.21184297.1391700904957.JavaMail.root@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3990D.5070101@redhat.com>
	<318495862.21013566.1391698087737.JavaMail.root@redhat.com>
	<52F3A353.9010307@redhat.com>
	<1692735266.21184297.1391700904957.JavaMail.root@redhat.com>
Message-ID: <52F3AD2E.2000903@redhat.com>

Maybe just return additional information in the json response from 
obtaining an access token.  The access token would just contain a link 
to user profile information.  This reduces token size and yet allows 
pure REST Bearer Token services to get profile information if they 
desire it.

On 2/6/2014 10:35 AM, Stian Thorgersen wrote:
> Why would an application need the username? I would think the application would more likely want the id, email and first/last name. For example:
>
> * To store an entry in a db associated to the user the id should be used
> * To display the logged in user the first/last name would be used
>
> Thinking about this further, I really think the "reference" used on a user should be a unique id generated by the system and not a user specified string. An example scenario for a online image gallery where using a user specified username would cause problems:
>
> 1. User registers with 'bob'
> 2. User logs in to the image gallery
> 3. User uploads some private images
> 4. The user is later deleted by an admin because the user didn't pay his fees
> 5. Another user now registers as 'bob'
> 6. If the private images from the initial user are still there, the new user will now be able to access images not belonging to him
>
> This makes me think that Keycloak should generate user ids, and we should make sure that even if a user is deleted, the id wouldn't be reused.
>
> ----- 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, 6 February, 2014 2:59:31 PM
>> Subject: Re: [keycloak-dev] User ids and usernames
>>
>>
>>
>> On 2/6/2014 9:48 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 6 February, 2014 2:15:41 PM
>>>> Subject: Re: [keycloak-dev] User ids and usernames
>>>>
>>>>
>>>>
>>>> On 2/6/2014 5:02 AM, Stian Thorgersen wrote:
>>>>> A user should have an id, username and email (what we have now). The id
>>>>> should be generated by the server and should never change for a user. The
>>>>> sub field in the token should use this id, not the username. Applications
>>>>> that wants to store information associated with a specific user should
>>>>> also use this id, not the username or email, as the id will never change.
>>>>>
>>>>> That means it should be possible for a user to change his/her username.
>>>>> Obviously a username has to be unique within a realm. We should then
>>>>> allow
>>>>> a user to login with either their username or their password. When a user
>>>>> is able to login with their username we can also remove the forgot
>>>>> username option on the login form, and only have a forgot password
>>>>> option.
>>>>>
>>>>> This would also help integration with social login as now we don't have
>>>>> to
>>>>> try to create a sensible username for a user on social login. Instead we
>>>>> create a generated id, and don't even set a username. A user can then set
>>>>> the username they want through the account management (or on the update
>>>>> profile action page if that option is enabled).
>>>>>
>>>>> If there's no objections to this, I'd like to add these changes to
>>>>> alpha2.
>>>>
>>>> Ugh, this is just a nasty change.  usernames will rarely, if ever,
>>>> change and I don't like the idea that users can change their username.
>>>> A principal name of "bill" is much more coherent than
>>>> "2341235234234-234123-234123-2341234".
>>>
>>> Doesn't matter does it? It's just an identifier, if someone wants to know
>>> more about the user they should retrieve the user profile.
>>
>> User profile would then have to be retrieved for most apps as most apps
>> would want to display the username.  Maybe add an additional token
>> extension for the username?  So an additional REST invocation back to
>> obtain the user profile doesn't need to be done?
>>
>> --
>> 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 Feb  6 10:47:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Feb 2014 10:47:38 -0500 (EST)
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <52F3AD2E.2000903@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3990D.5070101@redhat.com>
	<318495862.21013566.1391698087737.JavaMail.root@redhat.com>
	<52F3A353.9010307@redhat.com>
	<1692735266.21184297.1391700904957.JavaMail.root@redhat.com>
	<52F3AD2E.2000903@redhat.com>
Message-ID: <1398450755.21199356.1391701658679.JavaMail.root@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, 6 February, 2014 3:41:34 PM
> Subject: Re: [keycloak-dev] User ids and usernames
> 
> Maybe just return additional information in the json response from
> obtaining an access token.  The access token would just contain a link
> to user profile information.  This reduces token size and yet allows
> pure REST Bearer Token services to get profile information if they
> desire it.

I agree some mechanism to retrieve the token + profile in the same request would be nice, but IMO that's an performance optimization that can be done later. Google for example only return the ID, and you need to go an retrieve the profile if you want. I believe this is the way OpenID Connect does it as well, as I'm using Google's OpenID connect endpoints to retrieve the profile.

There's also the case where you don't want to give an app access to your full profile. Currently the token would have to have account/view-profile role to be able to retrieve the profile.

> 
> On 2/6/2014 10:35 AM, Stian Thorgersen wrote:
> > Why would an application need the username? I would think the application
> > would more likely want the id, email and first/last name. For example:
> >
> > * To store an entry in a db associated to the user the id should be used
> > * To display the logged in user the first/last name would be used
> >
> > Thinking about this further, I really think the "reference" used on a user
> > should be a unique id generated by the system and not a user specified
> > string. An example scenario for a online image gallery where using a user
> > specified username would cause problems:
> >
> > 1. User registers with 'bob'
> > 2. User logs in to the image gallery
> > 3. User uploads some private images
> > 4. The user is later deleted by an admin because the user didn't pay his
> > fees
> > 5. Another user now registers as 'bob'
> > 6. If the private images from the initial user are still there, the new
> > user will now be able to access images not belonging to him
> >
> > This makes me think that Keycloak should generate user ids, and we should
> > make sure that even if a user is deleted, the id wouldn't be reused.
> >
> > ----- 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, 6 February, 2014 2:59:31 PM
> >> Subject: Re: [keycloak-dev] User ids and usernames
> >>
> >>
> >>
> >> On 2/6/2014 9:48 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 6 February, 2014 2:15:41 PM
> >>>> Subject: Re: [keycloak-dev] User ids and usernames
> >>>>
> >>>>
> >>>>
> >>>> On 2/6/2014 5:02 AM, Stian Thorgersen wrote:
> >>>>> A user should have an id, username and email (what we have now). The id
> >>>>> should be generated by the server and should never change for a user.
> >>>>> The
> >>>>> sub field in the token should use this id, not the username.
> >>>>> Applications
> >>>>> that wants to store information associated with a specific user should
> >>>>> also use this id, not the username or email, as the id will never
> >>>>> change.
> >>>>>
> >>>>> That means it should be possible for a user to change his/her username.
> >>>>> Obviously a username has to be unique within a realm. We should then
> >>>>> allow
> >>>>> a user to login with either their username or their password. When a
> >>>>> user
> >>>>> is able to login with their username we can also remove the forgot
> >>>>> username option on the login form, and only have a forgot password
> >>>>> option.
> >>>>>
> >>>>> This would also help integration with social login as now we don't have
> >>>>> to
> >>>>> try to create a sensible username for a user on social login. Instead
> >>>>> we
> >>>>> create a generated id, and don't even set a username. A user can then
> >>>>> set
> >>>>> the username they want through the account management (or on the update
> >>>>> profile action page if that option is enabled).
> >>>>>
> >>>>> If there's no objections to this, I'd like to add these changes to
> >>>>> alpha2.
> >>>>
> >>>> Ugh, this is just a nasty change.  usernames will rarely, if ever,
> >>>> change and I don't like the idea that users can change their username.
> >>>> A principal name of "bill" is much more coherent than
> >>>> "2341235234234-234123-234123-2341234".
> >>>
> >>> Doesn't matter does it? It's just an identifier, if someone wants to know
> >>> more about the user they should retrieve the user profile.
> >>
> >> User profile would then have to be retrieved for most apps as most apps
> >> would want to display the username.  Maybe add an additional token
> >> extension for the username?  So an additional REST invocation back to
> >> obtain the user profile doesn't need to be done?
> >>
> >> --
> >> 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 Feb  6 10:59:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 10:59:24 -0500
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <1398450755.21199356.1391701658679.JavaMail.root@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3990D.5070101@redhat.com>
	<318495862.21013566.1391698087737.JavaMail.root@redhat.com>
	<52F3A353.9010307@redhat.com>
	<1692735266.21184297.1391700904957.JavaMail.root@redhat.com>
	<52F3AD2E.2000903@redhat.com>
	<1398450755.21199356.1391701658679.JavaMail.root@redhat.com>
Message-ID: <52F3B15C.9000202@redhat.com>



On 2/6/2014 10:47 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, 6 February, 2014 3:41:34 PM
>> Subject: Re: [keycloak-dev] User ids and usernames
>>
>> Maybe just return additional information in the json response from
>> obtaining an access token.  The access token would just contain a link
>> to user profile information.  This reduces token size and yet allows
>> pure REST Bearer Token services to get profile information if they
>> desire it.
>
> I agree some mechanism to retrieve the token + profile in the same request would be nice, but IMO that's an performance optimization that can be done later. Google for example only return the ID, and you need to go an retrieve the profile if you want. I believe this is the way OpenID Connect does it as well, as I'm using Google's OpenID connect endpoints to retrieve the profile.
>

Yeah, but wanting to know username, first, last, and/or email is just so 
common it should be optimzied.

> There's also the case where you don't want to give an app access to your full profile. Currently the token would have to have account/view-profile role to be able to retrieve the profile.
>

Keycloak knows the client's permissions.  So that is not an issue.

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

From stian at redhat.com  Thu Feb  6 11:05:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Feb 2014 11:05:52 -0500 (EST)
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <52F3B15C.9000202@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3990D.5070101@redhat.com>
	<318495862.21013566.1391698087737.JavaMail.root@redhat.com>
	<52F3A353.9010307@redhat.com>
	<1692735266.21184297.1391700904957.JavaMail.root@redhat.com>
	<52F3AD2E.2000903@redhat.com>
	<1398450755.21199356.1391701658679.JavaMail.root@redhat.com>
	<52F3B15C.9000202@redhat.com>
Message-ID: <50750140.21213899.1391702752107.JavaMail.root@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, 6 February, 2014 3:59:24 PM
> Subject: Re: [keycloak-dev] User ids and usernames
> 
> 
> 
> On 2/6/2014 10:47 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, 6 February, 2014 3:41:34 PM
> >> Subject: Re: [keycloak-dev] User ids and usernames
> >>
> >> Maybe just return additional information in the json response from
> >> obtaining an access token.  The access token would just contain a link
> >> to user profile information.  This reduces token size and yet allows
> >> pure REST Bearer Token services to get profile information if they
> >> desire it.
> >
> > I agree some mechanism to retrieve the token + profile in the same request
> > would be nice, but IMO that's an performance optimization that can be done
> > later. Google for example only return the ID, and you need to go an
> > retrieve the profile if you want. I believe this is the way OpenID Connect
> > does it as well, as I'm using Google's OpenID connect endpoints to
> > retrieve the profile.
> >
> 
> Yeah, but wanting to know username, first, last, and/or email is just so
> common it should be optimzied.

Have you read OpenID Connect spec yet? Is there anything like that in there?

Could add a query param or a different endpoint that returns profile with token, or something like that. If it's embedded in token, token is bigger. There's also the case when we introduce refresh tokens you'll not want to return the profile then I suppose.

Can we introduce these changes now? Then add a JIRA for adding some mechanism to retrieve token + profile in one request soon?

> 
> > There's also the case where you don't want to give an app access to your
> > full profile. Currently the token would have to have account/view-profile
> > role to be able to retrieve the profile.
> >
> 
> Keycloak knows the client's permissions.  So that is not an issue.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From ssilvert at redhat.com  Thu Feb  6 12:04:26 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 06 Feb 2014 12:04:26 -0500
Subject: [keycloak-dev] subsystem integration phase 1
In-Reply-To: <52F3A8A9.4080604@redhat.com>
References: <52F2F118.1020309@redhat.com>	<20140206125009.3c014835@kapy-ntb-x220>	<52F3879E.7010506@redhat.com>	<52F3A017.5090500@redhat.com>	<52F3A643.8050406@redhat.com>
	<52F3A8A9.4080604@redhat.com>
Message-ID: <52F3C09A.30008@redhat.com>

On 2/6/2014 10:22 AM, Bill Burke wrote:
>
> On 2/6/2014 10:12 AM, ssilvert at redhat.com wrote:
>> On 2/6/2014 9:45 AM, Bill Burke wrote:
>>> On 2/6/2014 8:01 AM, ssilvert at redhat.com wrote:
>>>> The problem with this is that because disabled is not the default, the
>>>> application is likely to be deployed in an unsecure state for some
>>>> period of time.
>>>>
>>> This isn't a big deal if you have enabled login-config.  I'm pretty sure
>>> it defaults to "other" which defaults to the application*.properties
>>> files (which are empty by default).  So you wouldn't be able to use the
>>> application anyways.
>> That's the thing.  You shouldn't need a login-config if you are using
>> the Keycloak subsystem.
> But you need security constraints :)
Exactly.  Role-related stuff only.  You shouldn't need login-config.
>
>>>> Ideally, you could deploy the application from Keycloak admin.  It would
>>>> automatically deploy in a disabled state and then enable the application
>>>> when security setup is complete.  IMO, deployment from Keycloak should
>>>> become the preferred deployment method in production systems.  It would
>>>> be a lot cleaner than what admins are faced with today.
>>> Not sure I like the idea of deploying apps through Keycloak, although it
>>> would probably be really easy to implement it.  I think we need to
>>> define the preferred ways we want this to work.
>> Yes, it's easy to implement.  I've already done it twice for web console
>> and CLI GUI.  I still think it's a cleaner, safer way to do it.  But
>> it's also something we don't need right away.  We need to support your
>> two scenarios anyway.
>>> It might be like this:
>>>
>>> Scenario 1:  There is no existing keycloak app
>>>
>>> 1. Deploy the app to wildfly instance
>>> 2. Go to Keycloak Realm
>>> 3. Click a "Import Application" button on Application page
>>> 4. specify URL of wildfly instance and deployment name (and credentials)
>>> 5. Suck up role definitions from Wildfly instance
>>> 6. push back to instance a client id and secret, realm information, etc.
>>>
>>> Scenario 2: There is an existing app
>>>
>>> 1. Go to Keycloak Realm
>>> 2. Go to Application page
>>> 3. Go to Installation page
>>> 4. Specify URL of wildfly instance and deployment name (and creds)
>>> 5. Push to the client id and secret and realm info to the wildfly instance.
>>>
>>> What sucks implementation wise is that we have to have a Wildfly plugin
>>> on the Keycloak server.  Would be cool if we could define a common REST
>>> API for this.
>>>
>> Do you mean a plugin for the Keycloak Admin?   You are saying that it
>> would be nice if we could do the equivalent of a subsystem on other app
>> servers and have a common API to talk to it?
> common REST API that all app server's use.  We would write those 
> adapters, but the admin console just talks through the common REST API.
>
>


From bburke at redhat.com  Thu Feb  6 20:37:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 20:37:25 -0500
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <50750140.21213899.1391702752107.JavaMail.root@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3990D.5070101@redhat.com>
	<318495862.21013566.1391698087737.JavaMail.root@redhat.com>
	<52F3A353.9010307@redhat.com>
	<1692735266.21184297.1391700904957.JavaMail.root@redhat.com>
	<52F3AD2E.2000903@redhat.com>
	<1398450755.21199356.1391701658679.JavaMail.root@redhat.com>
	<52F3B15C.9000202@redhat.com>
	<50750140.21213899.1391702752107.JavaMail.root@redhat.com>
Message-ID: <52F438D5.5010203@redhat.com>



On 2/6/2014 11:05 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, 6 February, 2014 3:59:24 PM
>> Subject: Re: [keycloak-dev] User ids and usernames
>>
>>
>>
>> On 2/6/2014 10:47 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, 6 February, 2014 3:41:34 PM
>>>> Subject: Re: [keycloak-dev] User ids and usernames
>>>>
>>>> Maybe just return additional information in the json response from
>>>> obtaining an access token.  The access token would just contain a link
>>>> to user profile information.  This reduces token size and yet allows
>>>> pure REST Bearer Token services to get profile information if they
>>>> desire it.
>>>
>>> I agree some mechanism to retrieve the token + profile in the same request
>>> would be nice, but IMO that's an performance optimization that can be done
>>> later. Google for example only return the ID, and you need to go an
>>> retrieve the profile if you want. I believe this is the way OpenID Connect
>>> does it as well, as I'm using Google's OpenID connect endpoints to
>>> retrieve the profile.
>>>
>>
>> Yeah, but wanting to know username, first, last, and/or email is just so
>> common it should be optimzied.
>
> Have you read OpenID Connect spec yet? Is there anything like that in there?
>

I think there might be.  I'll have to research a bit.  I"ll make OpenID 
connect a priority after we do Alpha 2 release (which should be soon right?)

> Could add a query param or a different endpoint that returns profile with token, or something like that. If it's embedded in token, token is bigger. There's also the case when we introduce refresh tokens you'll not want to return the profile then I suppose.
>
> Can we introduce these changes now? Then add a JIRA for adding some mechanism to retrieve token + profile in one request soon?

Sure, do it.  You're right.  I was just being devil's advocate to make 
sure we're not making a decision we'll regret.  We'll do the profile 
stuff later I guess.  We don't need it right now.  And there might be an 
openid solution.


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

From bburke at redhat.com  Thu Feb  6 21:15:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 21:15:00 -0500
Subject: [keycloak-dev] Aerogear UPS + External Keycloak boostrap
Message-ID: <52F441A4.9050001@redhat.com>

We still need to figure this out.

Can't port mappings be set up from the cartridge config so the 
as7/wildfly mgmt HTTP interface can be exposed?  There's also a problem 
of setting up credentials for the as7/wildfly HTTP mgmt service.  Quite 
honestly, I'm not sure how we can use a Wildfly subsystem for this.

We just might have to build support for all this within the keycloak 
adapter itself.  Allow it the ability to modify the keycloak.json file. 
  Then you only have one Aerogear UPS + Keycloak cartridge.

1. UPS would use a preconfigured co-bundled Keycloak for initial login
2. Initial login would require you to change the admin password
3. UPS Admin page allows you to switch Keycloak realms.
4. Switching a realm automatically creates the UPS Application on the 
new Keycloak realm.  It also rewrites the keycloak.json file, and also 
modifies the adapter's runtime config.

Am I making any sense?

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

From bburke at redhat.com  Thu Feb  6 22:37:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Feb 2014 22:37:39 -0500
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <50750140.21213899.1391702752107.JavaMail.root@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3990D.5070101@redhat.com>
	<318495862.21013566.1391698087737.JavaMail.root@redhat.com>
	<52F3A353.9010307@redhat.com>
	<1692735266.21184297.1391700904957.JavaMail.root@redhat.com>
	<52F3AD2E.2000903@redhat.com>
	<1398450755.21199356.1391701658679.JavaMail.root@redhat.com>
	<52F3B15C.9000202@redhat.com>
	<50750140.21213899.1391702752107.JavaMail.root@redhat.com>
Message-ID: <52F45503.8080106@redhat.com>



On 2/6/2014 11:05 AM, Stian Thorgersen wrote:
>> Yeah, but wanting to know username, first, last, and/or email is just so
>> common it should be optimzied.
>
> Have you read OpenID Connect spec yet? Is there anything like that in there?
>

I read a little bit more...and of course... its in there :)  Somebody 
must be actually using this spec for real apps instead of just writing 
it. ;)

A "Successful Token Response" contains the access token, expiration, and 
the ID Token.

ID token can have a bunch of useful shit in it.

http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

I claim OpenID work :)  I'll do it after Alpha 2.


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

From matzew at apache.org  Fri Feb  7 03:01:05 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 7 Feb 2014 09:01:05 +0100
Subject: [keycloak-dev] Aerogear UPS + External Keycloak boostrap
In-Reply-To: <52F441A4.9050001@redhat.com>
References: <52F441A4.9050001@redhat.com>
Message-ID: <CAAg5f2Tu2dmNQhhofQK8oVkdA-1BB+xQ59RezT1+hB17vnf4Yg@mail.gmail.com>

Hi,


On Fri, Feb 7, 2014 at 3:15 AM, Bill Burke <bburke at redhat.com> wrote:

> We still need to figure this out.
>
> Can't port mappings be set up from the cartridge config so the
> as7/wildfly mgmt HTTP interface can be exposed?  There's also a problem
> of setting up credentials for the as7/wildfly HTTP mgmt service.  Quite
> honestly, I'm not sure how we can use a Wildfly subsystem for this.
>
>
I am also not really sure on this, atm.
I started looking into this a bit this week, but didn't make real progress.
Next week I will continue;



> We just might have to build support for all this within the keycloak
> adapter itself.  Allow it the ability to modify the keycloak.json file.
>   Then you only have one Aerogear UPS + Keycloak cartridge.
>
> 1. UPS would use a preconfigured co-bundled Keycloak for initial login
> 2. Initial login would require you to change the admin password
> 3. UPS Admin page allows you to switch Keycloak realms.
> 4. Switching a realm automatically creates the UPS Application on the
> new Keycloak realm.  It also rewrites the keycloak.json file, and also
> modifies the adapter's runtime config.
>
> Am I making any sense?
>

That would be for a bundled integration, where everything runs
out-of-the-box, right?

I believe this does make sense, and would be a good starting point.

I am not yet sure on the 'external' case - e.g. where one company has a
single Keycloak server, and several apps
pointing to it. If the org. than wants to run the UPS w/ against that
keycloak as well, they would have to open the WAR and start editing some
files.



-Matthias



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



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140207/bfaf87f7/attachment.html 

From stian at redhat.com  Fri Feb  7 03:20:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 7 Feb 2014 03:20:20 -0500 (EST)
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <52F45503.8080106@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3A353.9010307@redhat.com>
	<1692735266.21184297.1391700904957.JavaMail.root@redhat.com>
	<52F3AD2E.2000903@redhat.com>
	<1398450755.21199356.1391701658679.JavaMail.root@redhat.com>
	<52F3B15C.9000202@redhat.com>
	<50750140.21213899.1391702752107.JavaMail.root@redhat.com>
	<52F45503.8080106@redhat.com>
Message-ID: <581835364.21866019.1391761220668.JavaMail.root@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, 7 February, 2014 3:37:39 AM
> Subject: Re: [keycloak-dev] User ids and usernames
> 
> 
> 
> On 2/6/2014 11:05 AM, Stian Thorgersen wrote:
> >> Yeah, but wanting to know username, first, last, and/or email is just so
> >> common it should be optimzied.
> >
> > Have you read OpenID Connect spec yet? Is there anything like that in
> > there?
> >
> 
> I read a little bit more...and of course... its in there :)  Somebody
> must be actually using this spec for real apps instead of just writing
> it. ;)
> 
> A "Successful Token Response" contains the access token, expiration, and
> the ID Token.
> 
> ID token can have a bunch of useful shit in it.
> 
> http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
> 
> I claim OpenID work :)  I'll do it after Alpha 2.

Cool, it'll be nice to have it in :)

How about refresh tokens? and implicit flow?

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

From stian at redhat.com  Fri Feb  7 04:12:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 7 Feb 2014 04:12:42 -0500 (EST)
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
Message-ID: <174068773.21904241.1391764362645.JavaMail.root@redhat.com>

I propose we use java.util.UUID to IDs generated by DB (JPA @GeneratedValue). Reasoning behind this is:

* IDs are the same independent of store used (JPA, Mongo, PicketLink, LDAP, etc)
* Easy to support many RDBMS (some support sequence and/or identity, so it seems the recommended approach when you don't know what the db will be is table)
* IDs can be generated without a "central" db

Also, we'd like to be able to export all data to a json then import into any store. We then need to make sure there's no conflicts in IDs. For example you first use KC with H2, then export all data, import into MySQL, then export all data, import into Mongo. I can see that causing some issues with IDs generated by DB.

This is related to DB issues (Mysql, PostgreSQL not working), Mongo store impl as well as move to using user id instead of username as the reference for a user.

From matzew at apache.org  Fri Feb  7 05:45:13 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 7 Feb 2014 11:45:13 +0100
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <174068773.21904241.1391764362645.JavaMail.root@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
Message-ID: <CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>

+1 on UUIDs; we do same on UPS

On Friday, February 7, 2014, Stian Thorgersen <stian at redhat.com> wrote:

> I propose we use java.util.UUID to IDs generated by DB (JPA
> @GeneratedValue). Reasoning behind this is:


W/ the hibernate specific annotations?



>
> * IDs are the same independent of store used (JPA, Mongo, PicketLink,
> LDAP, etc)
> * Easy to support many RDBMS (some support sequence and/or identity, so it
> seems the recommended approach when you don't know what the db will be is
> table)
> * IDs can be generated without a "central" db
>
> Also, we'd like to be able to export all data to a json then import into
> any store. We then need to make sure there's no conflicts in IDs. For
> example you first use KC with H2, then export all data, import into MySQL,
> then export all data, import into Mongo. I can see that causing some issues
> with IDs generated by DB.
>
> This is related to DB issues (Mysql, PostgreSQL not working), Mongo store
> impl as well as move to using user id instead of username as the reference
> for a user.

_______________________________________________
> 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/20140207/f2974b86/attachment.html 

From bburke at redhat.com  Fri Feb  7 08:56:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Feb 2014 08:56:12 -0500
Subject: [keycloak-dev] Aerogear UPS + External Keycloak boostrap
In-Reply-To: <CAAg5f2Tu2dmNQhhofQK8oVkdA-1BB+xQ59RezT1+hB17vnf4Yg@mail.gmail.com>
References: <52F441A4.9050001@redhat.com>
	<CAAg5f2Tu2dmNQhhofQK8oVkdA-1BB+xQ59RezT1+hB17vnf4Yg@mail.gmail.com>
Message-ID: <52F4E5FC.7010608@redhat.com>



On 2/7/2014 3:01 AM, Matthias Wessendorf wrote:
> Hi,
>
>
> On Fri, Feb 7, 2014 at 3:15 AM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     We still need to figure this out.
>
>     Can't port mappings be set up from the cartridge config so the
>     as7/wildfly mgmt HTTP interface can be exposed?  There's also a problem
>     of setting up credentials for the as7/wildfly HTTP mgmt service.  Quite
>     honestly, I'm not sure how we can use a Wildfly subsystem for this.
>
>
> I am also not really sure on this, atm.
> I started looking into this a bit this week, but didn't make real progress.
> Next week I will continue;
>
>     We just might have to build support for all this within the keycloak
>     adapter itself.  Allow it the ability to modify the keycloak.json file.
>        Then you only have one Aerogear UPS + Keycloak cartridge.
>
>     1. UPS would use a preconfigured co-bundled Keycloak for initial login
>     2. Initial login would require you to change the admin password
>     3. UPS Admin page allows you to switch Keycloak realms.
>     4. Switching a realm automatically creates the UPS Application on the
>     new Keycloak realm.  It also rewrites the keycloak.json file, and also
>     modifies the adapter's runtime config.
>
>     Am I making any sense?
>
>
> That would be for a bundled integration, where everything runs
> out-of-the-box, right?
>
> I believe this does make sense, and would be a good starting point.
>
> I am not yet sure on the 'external' case - e.g. where one company has a
> single Keycloak server, and several apps
> pointing to it. If the org. than wants to run the UPS w/ against that
> keycloak as well, they would have to open the WAR and start editing some
> files.
>

That's what I'm trying to suggest.  There would be a button somewhere in 
Keycloak that allowed you to switch/migrate your Realm.  The adapter 
could have a REST interface that allowed you to do a one-time modify of 
the keycloak.json file from the keycloak admin console.

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

From bburke at redhat.com  Fri Feb  7 08:57:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Feb 2014 08:57:56 -0500
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <581835364.21866019.1391761220668.JavaMail.root@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3A353.9010307@redhat.com>
	<1692735266.21184297.1391700904957.JavaMail.root@redhat.com>
	<52F3AD2E.2000903@redhat.com>
	<1398450755.21199356.1391701658679.JavaMail.root@redhat.com>
	<52F3B15C.9000202@redhat.com>
	<50750140.21213899.1391702752107.JavaMail.root@redhat.com>
	<52F45503.8080106@redhat.com>
	<581835364.21866019.1391761220668.JavaMail.root@redhat.com>
Message-ID: <52F4E664.7080001@redhat.com>



On 2/7/2014 3:20 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: Friday, 7 February, 2014 3:37:39 AM
>> Subject: Re: [keycloak-dev] User ids and usernames
>>
>>
>>
>> On 2/6/2014 11:05 AM, Stian Thorgersen wrote:
>>>> Yeah, but wanting to know username, first, last, and/or email is just so
>>>> common it should be optimzied.
>>>
>>> Have you read OpenID Connect spec yet? Is there anything like that in
>>> there?
>>>
>>
>> I read a little bit more...and of course... its in there :)  Somebody
>> must be actually using this spec for real apps instead of just writing
>> it. ;)
>>
>> A "Successful Token Response" contains the access token, expiration, and
>> the ID Token.
>>
>> ID token can have a bunch of useful shit in it.
>>
>> http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
>>
>> I claim OpenID work :)  I'll do it after Alpha 2.
>
> Cool, it'll be nice to have it in :)
>
> How about refresh tokens? and implicit flow?

We have to support implicit flow?  I thought that was a huge security hole?

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

From stian at redhat.com  Fri Feb  7 09:00:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 7 Feb 2014 09:00:50 -0500 (EST)
Subject: [keycloak-dev] User ids and usernames
In-Reply-To: <52F4E664.7080001@redhat.com>
References: <1829950628.20738410.1391680951492.JavaMail.root@redhat.com>
	<52F3AD2E.2000903@redhat.com>
	<1398450755.21199356.1391701658679.JavaMail.root@redhat.com>
	<52F3B15C.9000202@redhat.com>
	<50750140.21213899.1391702752107.JavaMail.root@redhat.com>
	<52F45503.8080106@redhat.com>
	<581835364.21866019.1391761220668.JavaMail.root@redhat.com>
	<52F4E664.7080001@redhat.com>
Message-ID: <361236827.22093821.1391781650442.JavaMail.root@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, 7 February, 2014 1:57:56 PM
> Subject: Re: [keycloak-dev] User ids and usernames
> 
> 
> 
> On 2/7/2014 3:20 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: Friday, 7 February, 2014 3:37:39 AM
> >> Subject: Re: [keycloak-dev] User ids and usernames
> >>
> >>
> >>
> >> On 2/6/2014 11:05 AM, Stian Thorgersen wrote:
> >>>> Yeah, but wanting to know username, first, last, and/or email is just so
> >>>> common it should be optimzied.
> >>>
> >>> Have you read OpenID Connect spec yet? Is there anything like that in
> >>> there?
> >>>
> >>
> >> I read a little bit more...and of course... its in there :)  Somebody
> >> must be actually using this spec for real apps instead of just writing
> >> it. ;)
> >>
> >> A "Successful Token Response" contains the access token, expiration, and
> >> the ID Token.
> >>
> >> ID token can have a bunch of useful shit in it.
> >>
> >> http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
> >>
> >> I claim OpenID work :)  I'll do it after Alpha 2.
> >
> > Cool, it'll be nice to have it in :)
> >
> > How about refresh tokens? and implicit flow?
> 
> We have to support implicit flow?  I thought that was a huge security hole?

Not sure tbh - let's leave it and consider again if we get demand

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

From bburke at redhat.com  Fri Feb  7 09:04:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Feb 2014 09:04:24 -0500
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
Message-ID: <52F4E7E8.10209@redhat.com>

Not sure why I didn't use UUID in the first place.  I've used it in 
other code bases.  I guess maybe I wasn't sure if UUID.randomUUID() 
guaranteed that the UUID was always unique.  Wasn't clear if a time 
component is added to the UUID.

Are you going to use UUIDs for the whole model?

On 2/7/2014 5:45 AM, Matthias Wessendorf wrote:
> +1 on UUIDs; we do same on UPS
>
> On Friday, February 7, 2014, Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>> wrote:
>
>     I propose we use java.util.UUID to IDs generated by DB (JPA
>     @GeneratedValue). Reasoning behind this is:
>
>
> W/ the hibernate specific annotations?
>
>
>     * IDs are the same independent of store used (JPA, Mongo,
>     PicketLink, LDAP, etc)
>     * Easy to support many RDBMS (some support sequence and/or identity,
>     so it seems the recommended approach when you don't know what the db
>     will be is table)
>     * IDs can be generated without a "central" db
>
>     Also, we'd like to be able to export all data to a json then import
>     into any store. We then need to make sure there's no conflicts in
>     IDs. For example you first use KC with H2, then export all data,
>     import into MySQL, then export all data, import into Mongo. I can
>     see that causing some issues with IDs generated by DB.
>
>     This is related to DB issues (Mysql, PostgreSQL not working), Mongo
>     store impl as well as move to using user id instead of username as
>     the reference for a user.
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <javascript:;>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Sent from Gmail Mobile
>
>
> _______________________________________________
> 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 Feb  7 09:33:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 7 Feb 2014 09:33:00 -0500 (EST)
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <52F4E7E8.10209@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
	<52F4E7E8.10209@redhat.com>
Message-ID: <1498059408.22120221.1391783580418.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 7 February, 2014 2:04:24 PM
> Subject: Re: [keycloak-dev] Use UUID for IDs
> 
> Not sure why I didn't use UUID in the first place.  I've used it in
> other code bases.  I guess maybe I wasn't sure if UUID.randomUUID()
> guaranteed that the UUID was always unique.  Wasn't clear if a time
> component is added to the UUID.

AFAIK there's no time component, but the risk of collision is extremely small

> 
> Are you going to use UUIDs for the whole model?

That was the plan

> 
> On 2/7/2014 5:45 AM, Matthias Wessendorf wrote:
> > +1 on UUIDs; we do same on UPS
> >
> > On Friday, February 7, 2014, Stian Thorgersen <stian at redhat.com
> > <mailto:stian at redhat.com>> wrote:
> >
> >     I propose we use java.util.UUID to IDs generated by DB (JPA
> >     @GeneratedValue). Reasoning behind this is:
> >
> >
> > W/ the hibernate specific annotations?
> >
> >
> >     * IDs are the same independent of store used (JPA, Mongo,
> >     PicketLink, LDAP, etc)
> >     * Easy to support many RDBMS (some support sequence and/or identity,
> >     so it seems the recommended approach when you don't know what the db
> >     will be is table)
> >     * IDs can be generated without a "central" db
> >
> >     Also, we'd like to be able to export all data to a json then import
> >     into any store. We then need to make sure there's no conflicts in
> >     IDs. For example you first use KC with H2, then export all data,
> >     import into MySQL, then export all data, import into Mongo. I can
> >     see that causing some issues with IDs generated by DB.
> >
> >     This is related to DB issues (Mysql, PostgreSQL not working), Mongo
> >     store impl as well as move to using user id instead of username as
> >     the reference for a user.
> >
> >     _______________________________________________
> >     keycloak-dev mailing list
> >     keycloak-dev at lists.jboss.org <javascript:;>
> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > --
> > Sent from Gmail Mobile
> >
> >
> > _______________________________________________
> > 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 Feb  7 09:53:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Feb 2014 09:53:43 -0500
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <1498059408.22120221.1391783580418.JavaMail.root@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
	<52F4E7E8.10209@redhat.com>
	<1498059408.22120221.1391783580418.JavaMail.root@redhat.com>
Message-ID: <52F4F377.7010500@redhat.com>



On 2/7/2014 9:33 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 7 February, 2014 2:04:24 PM
>> Subject: Re: [keycloak-dev] Use UUID for IDs
>>
>> Not sure why I didn't use UUID in the first place.  I've used it in
>> other code bases.  I guess maybe I wasn't sure if UUID.randomUUID()
>> guaranteed that the UUID was always unique.  Wasn't clear if a time
>> component is added to the UUID.
>
> AFAIK there's no time component, but the risk of collision is extremely small
>

Hopefully no security weeny identifies that as a security risk.

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

From stian at redhat.com  Fri Feb  7 10:17:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 7 Feb 2014 10:17:18 -0500 (EST)
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <52F4F377.7010500@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
	<52F4E7E8.10209@redhat.com>
	<1498059408.22120221.1391783580418.JavaMail.root@redhat.com>
	<52F4F377.7010500@redhat.com>
Message-ID: <1544741170.22214767.1391786238506.JavaMail.root@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, 7 February, 2014 2:53:43 PM
> Subject: Re: [keycloak-dev] Use UUID for IDs
> 
> 
> 
> On 2/7/2014 9:33 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 7 February, 2014 2:04:24 PM
> >> Subject: Re: [keycloak-dev] Use UUID for IDs
> >>
> >> Not sure why I didn't use UUID in the first place.  I've used it in
> >> other code bases.  I guess maybe I wasn't sure if UUID.randomUUID()
> >> guaranteed that the UUID was always unique.  Wasn't clear if a time
> >> component is added to the UUID.
> >
> > AFAIK there's no time component, but the risk of collision is extremely
> > small
> >
> 
> Hopefully no security weeny identifies that as a security risk.

We can wrap it in our own UUID class, that way we'll be able to quickly change the underlying algorithm if some weenies complain

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

From bburke at redhat.com  Fri Feb  7 10:33:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Feb 2014 10:33:49 -0500
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <1544741170.22214767.1391786238506.JavaMail.root@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
	<52F4E7E8.10209@redhat.com>
	<1498059408.22120221.1391783580418.JavaMail.root@redhat.com>
	<52F4F377.7010500@redhat.com>
	<1544741170.22214767.1391786238506.JavaMail.root@redhat.com>
Message-ID: <52F4FCDD.9090706@redhat.com>



On 2/7/2014 10:17 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: Friday, 7 February, 2014 2:53:43 PM
>> Subject: Re: [keycloak-dev] Use UUID for IDs
>>
>>
>>
>> On 2/7/2014 9:33 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 7 February, 2014 2:04:24 PM
>>>> Subject: Re: [keycloak-dev] Use UUID for IDs
>>>>
>>>> Not sure why I didn't use UUID in the first place.  I've used it in
>>>> other code bases.  I guess maybe I wasn't sure if UUID.randomUUID()
>>>> guaranteed that the UUID was always unique.  Wasn't clear if a time
>>>> component is added to the UUID.
>>>
>>> AFAIK there's no time component, but the risk of collision is extremely
>>> small
>>>
>>
>> Hopefully no security weeny identifies that as a security risk.
>
> We can wrap it in our own UUID class, that way we'll be able to quickly change the underlying algorithm if some weenies complain

Why use the UUID class directly?  Just use a string.

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

From stian at redhat.com  Fri Feb  7 10:41:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 7 Feb 2014 10:41:34 -0500 (EST)
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <52F4FCDD.9090706@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
	<52F4E7E8.10209@redhat.com>
	<1498059408.22120221.1391783580418.JavaMail.root@redhat.com>
	<52F4F377.7010500@redhat.com>
	<1544741170.22214767.1391786238506.JavaMail.root@redhat.com>
	<52F4FCDD.9090706@redhat.com>
Message-ID: <1675776790.22280127.1391787694580.JavaMail.root@redhat.com>

I didn't mean use the UUID class as the id. I meant wrap the creation. So instead of:

  new User(java.util.UUID.randomUUID().toString());

we do:

  new User(org.keycloak.UUID.createUUID());


----- 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, 7 February, 2014 3:33:49 PM
> Subject: Re: [keycloak-dev] Use UUID for IDs
> 
> 
> 
> On 2/7/2014 10:17 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: Friday, 7 February, 2014 2:53:43 PM
> >> Subject: Re: [keycloak-dev] Use UUID for IDs
> >>
> >>
> >>
> >> On 2/7/2014 9:33 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, 7 February, 2014 2:04:24 PM
> >>>> Subject: Re: [keycloak-dev] Use UUID for IDs
> >>>>
> >>>> Not sure why I didn't use UUID in the first place.  I've used it in
> >>>> other code bases.  I guess maybe I wasn't sure if UUID.randomUUID()
> >>>> guaranteed that the UUID was always unique.  Wasn't clear if a time
> >>>> component is added to the UUID.
> >>>
> >>> AFAIK there's no time component, but the risk of collision is extremely
> >>> small
> >>>
> >>
> >> Hopefully no security weeny identifies that as a security risk.
> >
> > We can wrap it in our own UUID class, that way we'll be able to quickly
> > change the underlying algorithm if some weenies complain
> 
> Why use the UUID class directly?  Just use a string.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Sun Feb  9 11:37:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Sun, 09 Feb 2014 11:37:25 -0500
Subject: [keycloak-dev] Aerogear UPS + External Keycloak boostrap
In-Reply-To: <52F4E5FC.7010608@redhat.com>
References: <52F441A4.9050001@redhat.com>	<CAAg5f2Tu2dmNQhhofQK8oVkdA-1BB+xQ59RezT1+hB17vnf4Yg@mail.gmail.com>
	<52F4E5FC.7010608@redhat.com>
Message-ID: <52F7AEC5.4040400@redhat.com>

More thoughts on this:

Can the Aerogear Openshift cartridge be based on Wildfly?

There's some general issues/problems/road blocks we have:
* Wildfly REST mgmt api requires port mappings on Openshift
* Wildfly Mgmt API requires the setup of an admin user.  Not sure how 
easily this can be done for Openshift deployments.
* Both of the above are extra steps the user has to do which make the 
user experience much more complicated and require a lot of knowledge 
about Wildfly, etc.
* Similarly, Keycloak cannot be preconfigured with a distro as it 
requires unique keypairs for digital signatures it uses for token signing.

UPS + Keycloak in one bundle:

1. Have Aerogear installed with Keycloak on the same Wildfly instance.
2. The Keycloak adapter will allow for an UNCONFIGURED state.  In this 
state, the adapter is configured and running for the application, but 
will not allow any connections until the underlying wildfly subsystem 
for that deployment is set up.
3. Aerogear should have a "Bootstrap Subsystem" that is triggered on 
launch.  It should check to see if security is UNCONFIGURED for the 
aerogear deployment.  If it hasn't, locally it creates the necessary 
keycloak metadata using keycloak apis to initialize the UPS realm and 
initial users and locally updates the wildfly subsystem so the Aerogear 
WAR deployment keycloak adapter becomes aware of configuration.


UPS joining an external Keycloak realm:
* The Keycloak Adapter will have an optional switch so that its config 
settings can be changed remotely.  It will be secured similarly to how 
we secure single logout requests.
* The Keycloak admin console will have a "Move Application" option.  You 
will specify a URL of the external Keycloak Realm you want to move to. 
This action will upload application metadata to the remote realm.  It 
will also communicate with the application deployment (the keycloak 
adapter) to update its settings to point to the new realm.
* UPS admin will login to the UPS + Keycloak deployment.  He will then 
use this "Move Application" feature.

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

From mposolda at redhat.com  Mon Feb 10 15:45:16 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 10 Feb 2014 21:45:16 +0100
Subject: [keycloak-dev] Running unit tests with different model
	implementations
Message-ID: <52F93A5C.6090304@redhat.com>

Hi,

For improving testability, it would be nice if it's possible to execute 
unit tests with all available model implementations.

It seems that for testability of various model implementations, it may 
be good to move majority of unit test classes (like AdapterTest, 
ImportTest etc) from module "services" into "model/api" and then each 
model implementation will run all unit tests for particular model during 
it's own build. So building of module "model/jpa" will run all unit 
tests with JPA model and similarly building of "model/mongo" will run 
same set of tests for mongo module. This means that unit tests for all 
enabled models will be automatically executed during Keycloak build, 
which means that various model implementations won't be out of sync.

This would mean that some util classes used in unit tests will be moved 
from services to model/api as well because unit tests need them (For 
example RealmManager, ApplicationManager etc.)

Another possibility is to keep unit tests in "services" module and just 
add some dedicated profile for running tests with Mongo. So for example 
-Dkeycloak.model=mongo will run unit tests with Mongo model and 
-Dkeycloak.model=all will run unit tests with all available model 
implementations (so currently jpa and mongo).

What do you think?

Thanks,
Marek

From bburke at redhat.com  Mon Feb 10 16:02:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 10 Feb 2014 16:02:36 -0500
Subject: [keycloak-dev] Running unit tests with different model
	implementations
In-Reply-To: <52F93A5C.6090304@redhat.com>
References: <52F93A5C.6090304@redhat.com>
Message-ID: <52F93E6C.9030504@redhat.com>

I still think there is a bit of model work to be done.  This is why I've 
turned off the picketlink and mongo builds as it is a pain to keep them 
in sync while we're developing new features.

But, the idea was that Model classes are as close to the data model as 
possible with as little business logic as possible.  Manager classes are 
business logic, and the Resource/Service classes are the JAX-RS layer. 
We need to move logic to Manager layer and create a better API at the 
Manager level.  Then move the Manager code to another module (model-api?).

We used to run mongo, picketlink, and JPA as you describe (you 
implemented it).

On 2/10/2014 3:45 PM, Marek Posolda wrote:
> Hi,
>
> For improving testability, it would be nice if it's possible to execute
> unit tests with all available model implementations.
>
> It seems that for testability of various model implementations, it may
> be good to move majority of unit test classes (like AdapterTest,
> ImportTest etc) from module "services" into "model/api" and then each
> model implementation will run all unit tests for particular model during
> it's own build. So building of module "model/jpa" will run all unit
> tests with JPA model and similarly building of "model/mongo" will run
> same set of tests for mongo module. This means that unit tests for all
> enabled models will be automatically executed during Keycloak build,
> which means that various model implementations won't be out of sync.
>
> This would mean that some util classes used in unit tests will be moved
> from services to model/api as well because unit tests need them (For
> example RealmManager, ApplicationManager etc.)
>
> Another possibility is to keep unit tests in "services" module and just
> add some dedicated profile for running tests with Mongo. So for example
> -Dkeycloak.model=mongo will run unit tests with Mongo model and
> -Dkeycloak.model=all will run unit tests with all available model
> implementations (so currently jpa and mongo).
>
> What do you think?
>
> Thanks,
> 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 mposolda at redhat.com  Mon Feb 10 16:51:13 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 10 Feb 2014 22:51:13 +0100
Subject: [keycloak-dev] Running unit tests with different model
	implementations
In-Reply-To: <52F93E6C.9030504@redhat.com>
References: <52F93A5C.6090304@redhat.com> <52F93E6C.9030504@redhat.com>
Message-ID: <52F949D1.7050205@redhat.com>

On 10.2.2014 22:02, Bill Burke wrote:
> I still think there is a bit of model work to be done.  This is why I've
> turned off the picketlink and mongo builds as it is a pain to keep them
> in sync while we're developing new features.
The disadvantage of current approach with all unit tests in "services" 
module is that you need to have dependencies with scope "test" declared 
in services/pom.xml for all model implementations, which means that 
there are both hibernate, picketlink and mongo dependencies. And if you 
want to disable some model, you need to disable line in pom.xml but also 
these test dependencies in services/pom.xml
>
> But, the idea was that Model classes are as close to the data model as
> possible with as little business logic as possible.  Manager classes are
> business logic, and the Resource/Service classes are the JAX-RS layer.
> We need to move logic to Manager layer and create a better API at the
> Manager level.  Then move the Manager code to another module (model-api?).
>
> We used to run mongo, picketlink, and JPA as you describe (you
> implemented it).
Ok, so I am seeing 2 possible ways how to proceed:
1) Create new module as you described (not sure about model-api as we 
already have "model/api" . How about "model-managers" or "model-logic" 
?) and move some manager classes like RealmManager, ApplicationManager, 
OAuthClientManager etc. to this. This module will have dependency just 
on "core" and "model/api" . I will keep rest of manager classes, which 
are not used to model logic but mainly for jax-rs handling logic (like 
TokenManager, SocialRequestManager etc) in services module. Then I will 
move some model related tests from "services" module to this new module. 
All concrete model implementations like "model/jpa" , 
"model/picketltink" or "model/mongo" will have test-scoped dependency on 
this model-logic module and will run all unit tests during it's own build.

In "services" module, I will keep just unit tests not related to model 
logic (like EmailSenderTest for instance)


2) Keep unit tests in "services" module and just add some profiles like 
I mentioned. Especially running -Dkeycloak.model=all will run unit tests 
with all available model implementations. This will leverage junit 
parameterized approach and model related tests will be changed to be 
subclass of AbstractKeycloakTest (This is what I already have in my 
working copy)

I prefer 1 but it's more work and more required changes of current 
project structure. wdyt?

Marek
>
> On 2/10/2014 3:45 PM, Marek Posolda wrote:
>> Hi,
>>
>> For improving testability, it would be nice if it's possible to execute
>> unit tests with all available model implementations.
>>
>> It seems that for testability of various model implementations, it may
>> be good to move majority of unit test classes (like AdapterTest,
>> ImportTest etc) from module "services" into "model/api" and then each
>> model implementation will run all unit tests for particular model during
>> it's own build. So building of module "model/jpa" will run all unit
>> tests with JPA model and similarly building of "model/mongo" will run
>> same set of tests for mongo module. This means that unit tests for all
>> enabled models will be automatically executed during Keycloak build,
>> which means that various model implementations won't be out of sync.
>>
>> This would mean that some util classes used in unit tests will be moved
>> from services to model/api as well because unit tests need them (For
>> example RealmManager, ApplicationManager etc.)
>>
>> Another possibility is to keep unit tests in "services" module and just
>> add some dedicated profile for running tests with Mongo. So for example
>> -Dkeycloak.model=mongo will run unit tests with Mongo model and
>> -Dkeycloak.model=all will run unit tests with all available model
>> implementations (so currently jpa and mongo).
>>
>> What do you think?
>>
>> Thanks,
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Mon Feb 10 17:50:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 10 Feb 2014 17:50:04 -0500
Subject: [keycloak-dev] Running unit tests with different model
	implementations
In-Reply-To: <52F949D1.7050205@redhat.com>
References: <52F93A5C.6090304@redhat.com> <52F93E6C.9030504@redhat.com>
	<52F949D1.7050205@redhat.com>
Message-ID: <52F9579C.6070008@redhat.com>



On 2/10/2014 4:51 PM, Marek Posolda wrote:
> I prefer 1 but it's more work and more required changes of current
> project structure. wdyt?
>

I agree. I thought that was the plan even before this email.  That we 
needed restructuring of the codebase to separate JAX-RS code from 
business logic, from model logic.  That we needed more comprehensive 
testing.

Minimally, to do this work we have to wait until after Alpha 2 (end of 
this week).  But my preference is that there is no refactoring work at 
all until we're done with core feature implementations or unless a 
feature needs the refactoring.  I just don't want merge conflicts 
distracting people from feature work.  Stan took awhile to merge his 
keycloak subsystem because our code was a moving target.  I've had 
delays before because of merge conflicts as well.

My thought is that we will have a few more Alphas every 2-3 weeks. 
Going into Beta will mean that our major features have been implemented 
and we'll then start focusing on test coverage, refactoring, cleaning up 
code, documentation, and polishing the project.

But, Stian can be the tie-breaker here if he wants this refactoring to 
happen sooner rather than later.  I'll go with what he wants.



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

From bburke at redhat.com  Mon Feb 10 19:11:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 10 Feb 2014 19:11:11 -0500
Subject: [keycloak-dev] subsystem status
Message-ID: <52F96A9F.7060608@redhat.com>

Forked and ported Stan's subsystem to AS7/EAP 6.1.  I still have some 
cleanup work to do, but what this means is that we will no longer have 
special examples directories in the distribution!  Installation and 
configuration between AS7/EAP/Wildfly will be consistent too.

The side effect of this is that I'll have to redo some of the 
screencasts.  But that was inevitable.  I hope to be done by Friday.

Bill

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

From bruno at abstractj.org  Tue Feb 11 09:01:18 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 11 Feb 2014 12:01:18 -0200
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <1675776790.22280127.1391787694580.JavaMail.root@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
	<52F4E7E8.10209@redhat.com>
	<1498059408.22120221.1391783580418.JavaMail.root@redhat.com>
	<52F4F377.7010500@redhat.com>
	<1544741170.22214767.1391786238506.JavaMail.root@redhat.com>
	<52F4FCDD.9090706@redhat.com>
	<1675776790.22280127.1391787694580.JavaMail.root@redhat.com>
Message-ID: <etPan.52fa2d2e.74b0dc51.36cc@animus>

Are you considering to use java.util.UUID behind the scenes for?org.keycloak.UUID? Either way you could just stick to?java.util.UUID, the probability of a collision is pretty low.

--  
abstractj

On February 7, 2014 at 1:41:37 PM, Stian Thorgersen (stian at redhat.com) wrote:
> > I didn't mean use the UUID class as the id. I meant wrap the creation.  
> So instead of:
>  
> new User(java.util.UUID.randomUUID().toString());
>  
> we do:
>  
> new User(org.keycloak.UUID.createUUID());



From bburke at redhat.com  Tue Feb 11 09:03:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Feb 2014 09:03:58 -0500
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <etPan.52fa2d2e.74b0dc51.36cc@animus>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
	<52F4E7E8.10209@redhat.com>
	<1498059408.22120221.1391783580418.JavaMail.root@redhat.com>
	<52F4F377.7010500@redhat.com>
	<1544741170.22214767.1391786238506.JavaMail.root@redhat.com>
	<52F4FCDD.9090706@redhat.com>
	<1675776790.22280127.1391787694580.JavaMail.root@redhat.com>
	<etPan.52fa2d2e.74b0dc51.36cc@animus>
Message-ID: <52FA2DCE.1040709@redhat.com>

IMO, should just reuse the static class we have now:

String IdGenerator.generateId();

and use UUID as the impl instead of creating a dependency on UUID 
everywhere.

On 2/11/2014 9:01 AM, Bruno Oliveira wrote:
> Are you considering to use java.util.UUID behind the scenes for org.keycloak.UUID? Either way you could just stick to java.util.UUID, the probability of a collision is pretty low.
>
> --
> abstractj
>
> On February 7, 2014 at 1:41:37 PM, Stian Thorgersen (stian at redhat.com) wrote:
>>> I didn't mean use the UUID class as the id. I meant wrap the creation.
>> So instead of:
>>
>> new User(java.util.UUID.randomUUID().toString());
>>
>> we do:
>>
>> new User(org.keycloak.UUID.createUUID());
>

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

From bruno at abstractj.org  Tue Feb 11 09:13:47 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 11 Feb 2014 12:13:47 -0200
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <52FA2DCE.1040709@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>
	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>
	<52F4E7E8.10209@redhat.com>
	<1498059408.22120221.1391783580418.JavaMail.root@redhat.com>
	<52F4F377.7010500@redhat.com>
	<1544741170.22214767.1391786238506.JavaMail.root@redhat.com>
	<52F4FCDD.9090706@redhat.com>
	<1675776790.22280127.1391787694580.JavaMail.root@redhat.com>
	<etPan.52fa2d2e.74b0dc51.36cc@animus> <52FA2DCE.1040709@redhat.com>
Message-ID: <etPan.52fa301b.19495cff.36cc@animus>

+1 I guess TokenIdGenerator does the job well

-- 
abstractj

On February 11, 2014 at 12:04:03 PM, Bill Burke (bburke at redhat.com) wrote:
> > IMO, should just reuse the static class we have now:
> 
> String IdGenerator.generateId();
> 
> and use UUID as the impl instead of creating a dependency on UUID 
> everywhere.


From mposolda at redhat.com  Tue Feb 11 10:45:19 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 11 Feb 2014 16:45:19 +0100
Subject: [keycloak-dev] Running unit tests with different model
	implementations
In-Reply-To: <52F9579C.6070008@redhat.com>
References: <52F93A5C.6090304@redhat.com> <52F93E6C.9030504@redhat.com>
	<52F949D1.7050205@redhat.com> <52F9579C.6070008@redhat.com>
Message-ID: <52FA458F.90709@redhat.com>

Thanks for the clarification, thing is that we may need mongo model in 
alpha 2 too because of liveoak.

So for now I did not made any big refactoring and movement of existing 
manager classes. I just introduced new module "model/tests" and moved 
just existing model related unit tests (basically everything except 
EmailSenderTest) from "services" module to this one. Then I configured 
model/jpa and model/mongo modules to use tests from this one. So 
currently all these model unit tests are always executed during build of 
particular model implementation (ie. building model/jpa runs all tests 
with "jpa" model implementation and building model/mongo runs all tests 
with "mongo" model implementation).

So only thing moved to different location are those unit tests classes. 
Is this acceptable change for Alpha 2?

With this change, if you decide to enable/disable some model 
implementation, you will need just comment/uncomment one line in 
model/pom.xml and that's it. Side-effect of this is that many 
test-scoped dependencies from "services" module are not needed anymore 
(especially hibernate and H2, which were needed for "jpa" model)

Testsuite is executed just with JPA model by default, there is separate 
profile for running it with mongo, which is used only if you add 
-Dkeycloak.model=mongo .

Hope to send PR with mongo model later today or early tomorrow with this 
change introduced.

Thanks,
Marek

On 10.2.2014 23:50, Bill Burke wrote:
>
>
> On 2/10/2014 4:51 PM, Marek Posolda wrote:
>> I prefer 1 but it's more work and more required changes of current
>> project structure. wdyt?
>>
>
> I agree. I thought that was the plan even before this email.  That we 
> needed restructuring of the codebase to separate JAX-RS code from 
> business logic, from model logic.  That we needed more comprehensive 
> testing.
>
> Minimally, to do this work we have to wait until after Alpha 2 (end of 
> this week).  But my preference is that there is no refactoring work at 
> all until we're done with core feature implementations or unless a 
> feature needs the refactoring.  I just don't want merge conflicts 
> distracting people from feature work. Stan took awhile to merge his 
> keycloak subsystem because our code was a moving target.  I've had 
> delays before because of merge conflicts as well.
>
> My thought is that we will have a few more Alphas every 2-3 weeks. 
> Going into Beta will mean that our major features have been 
> implemented and we'll then start focusing on test coverage, 
> refactoring, cleaning up code, documentation, and polishing the project.
>
> But, Stian can be the tie-breaker here if he wants this refactoring to 
> happen sooner rather than later.  I'll go with what he wants.
>
>
>


From bburke at redhat.com  Tue Feb 11 10:46:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Feb 2014 10:46:53 -0500
Subject: [keycloak-dev] missing styles from initial login page
Message-ID: <52FA45ED.60607@redhat.com>

I'm seeing this weird behavior where my first login (from the 
customer-portal) shows a login page with no styles.  If you look at the 
HTML page source, no stylesheets are linked.  Hitting browser refresh 
then loads the login page correctly, and the stylesheets are linked and 
shown in the source of the HTML.  This is only for the 1st time you see 
the login screen.

Any ideas?

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

From bburke at redhat.com  Tue Feb 11 10:50:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Feb 2014 10:50:03 -0500
Subject: [keycloak-dev] Running unit tests with different model
	implementations
In-Reply-To: <52FA458F.90709@redhat.com>
References: <52F93A5C.6090304@redhat.com> <52F93E6C.9030504@redhat.com>
	<52F949D1.7050205@redhat.com> <52F9579C.6070008@redhat.com>
	<52FA458F.90709@redhat.com>
Message-ID: <52FA46AB.3020906@redhat.com>

Sounds good.

On 2/11/2014 10:45 AM, Marek Posolda wrote:
> Thanks for the clarification, thing is that we may need mongo model in
> alpha 2 too because of liveoak.
>
> So for now I did not made any big refactoring and movement of existing
> manager classes. I just introduced new module "model/tests" and moved
> just existing model related unit tests (basically everything except
> EmailSenderTest) from "services" module to this one. Then I configured
> model/jpa and model/mongo modules to use tests from this one. So
> currently all these model unit tests are always executed during build of
> particular model implementation (ie. building model/jpa runs all tests
> with "jpa" model implementation and building model/mongo runs all tests
> with "mongo" model implementation).
>
> So only thing moved to different location are those unit tests classes.
> Is this acceptable change for Alpha 2?
>
> With this change, if you decide to enable/disable some model
> implementation, you will need just comment/uncomment one line in
> model/pom.xml and that's it. Side-effect of this is that many
> test-scoped dependencies from "services" module are not needed anymore
> (especially hibernate and H2, which were needed for "jpa" model)
>
> Testsuite is executed just with JPA model by default, there is separate
> profile for running it with mongo, which is used only if you add
> -Dkeycloak.model=mongo .
>
> Hope to send PR with mongo model later today or early tomorrow with this
> change introduced.
>
> Thanks,
> Marek
>
> On 10.2.2014 23:50, Bill Burke wrote:
>>
>>
>> On 2/10/2014 4:51 PM, Marek Posolda wrote:
>>> I prefer 1 but it's more work and more required changes of current
>>> project structure. wdyt?
>>>
>>
>> I agree. I thought that was the plan even before this email.  That we
>> needed restructuring of the codebase to separate JAX-RS code from
>> business logic, from model logic.  That we needed more comprehensive
>> testing.
>>
>> Minimally, to do this work we have to wait until after Alpha 2 (end of
>> this week).  But my preference is that there is no refactoring work at
>> all until we're done with core feature implementations or unless a
>> feature needs the refactoring.  I just don't want merge conflicts
>> distracting people from feature work. Stan took awhile to merge his
>> keycloak subsystem because our code was a moving target.  I've had
>> delays before because of merge conflicts as well.
>>
>> My thought is that we will have a few more Alphas every 2-3 weeks.
>> Going into Beta will mean that our major features have been
>> implemented and we'll then start focusing on test coverage,
>> refactoring, cleaning up code, documentation, and polishing the project.
>>
>> But, Stian can be the tie-breaker here if he wants this refactoring to
>> happen sooner rather than later.  I'll go with what he wants.
>>
>>
>>
>

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

From stian at redhat.com  Tue Feb 11 11:23:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 11 Feb 2014 11:23:31 -0500 (EST)
Subject: [keycloak-dev] missing styles from initial login page
In-Reply-To: <52FA45ED.60607@redhat.com>
References: <52FA45ED.60607@redhat.com>
Message-ID: <362809051.3586368.1392135811860.JavaMail.zimbra@redhat.com>

This should be recently fixed. Can you confirm if this happens in master now?

Basically some rather crappy code I wrote resulted in keycloak theme not being set as default theme until after the first load. So on first load it would fall back to the base theme which doesn't have any styles.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 11 February, 2014 3:46:53 PM
> Subject: [keycloak-dev] missing styles from initial login page
> 
> I'm seeing this weird behavior where my first login (from the
> customer-portal) shows a login page with no styles.  If you look at the
> HTML page source, no stylesheets are linked.  Hitting browser refresh
> then loads the login page correctly, and the stylesheets are linked and
> shown in the source of the HTML.  This is only for the 1st time you see
> the login screen.
> 
> Any ideas?
> 
> --
> 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 Feb 11 11:33:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 11 Feb 2014 11:33:30 -0500 (EST)
Subject: [keycloak-dev] Running unit tests with different
	model	implementations
In-Reply-To: <52FA46AB.3020906@redhat.com>
References: <52F93A5C.6090304@redhat.com> <52F93E6C.9030504@redhat.com>
	<52F949D1.7050205@redhat.com> <52F9579C.6070008@redhat.com>
	<52FA458F.90709@redhat.com> <52FA46AB.3020906@redhat.com>
Message-ID: <1465463092.3616126.1392136410268.JavaMail.zimbra@redhat.com>

Sounds good. Getting Mongo in now is a priority for us, but it doesn't have to be perfect now.

With regards to refactoring changes proposed they all sound great, but I agree with Bill. Let's do a few more rounds to get some more "core" features in. Then let's do refactoring, testing, etc..

At this point there's no immediate refactoring I can think of, except for swapping from DB generated IDs to UUIDs + the changes to users I proposed:

* Login with username or email
* Use id in token#sub
* Remove recover username
* Let users change their username (probably an option on the realm to disable?)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 11 February, 2014 3:50:03 PM
> Subject: Re: [keycloak-dev] Running unit tests with different model	implementations
> 
> Sounds good.
> 
> On 2/11/2014 10:45 AM, Marek Posolda wrote:
> > Thanks for the clarification, thing is that we may need mongo model in
> > alpha 2 too because of liveoak.
> >
> > So for now I did not made any big refactoring and movement of existing
> > manager classes. I just introduced new module "model/tests" and moved
> > just existing model related unit tests (basically everything except
> > EmailSenderTest) from "services" module to this one. Then I configured
> > model/jpa and model/mongo modules to use tests from this one. So
> > currently all these model unit tests are always executed during build of
> > particular model implementation (ie. building model/jpa runs all tests
> > with "jpa" model implementation and building model/mongo runs all tests
> > with "mongo" model implementation).
> >
> > So only thing moved to different location are those unit tests classes.
> > Is this acceptable change for Alpha 2?
> >
> > With this change, if you decide to enable/disable some model
> > implementation, you will need just comment/uncomment one line in
> > model/pom.xml and that's it. Side-effect of this is that many
> > test-scoped dependencies from "services" module are not needed anymore
> > (especially hibernate and H2, which were needed for "jpa" model)
> >
> > Testsuite is executed just with JPA model by default, there is separate
> > profile for running it with mongo, which is used only if you add
> > -Dkeycloak.model=mongo .
> >
> > Hope to send PR with mongo model later today or early tomorrow with this
> > change introduced.
> >
> > Thanks,
> > Marek
> >
> > On 10.2.2014 23:50, Bill Burke wrote:
> >>
> >>
> >> On 2/10/2014 4:51 PM, Marek Posolda wrote:
> >>> I prefer 1 but it's more work and more required changes of current
> >>> project structure. wdyt?
> >>>
> >>
> >> I agree. I thought that was the plan even before this email.  That we
> >> needed restructuring of the codebase to separate JAX-RS code from
> >> business logic, from model logic.  That we needed more comprehensive
> >> testing.
> >>
> >> Minimally, to do this work we have to wait until after Alpha 2 (end of
> >> this week).  But my preference is that there is no refactoring work at
> >> all until we're done with core feature implementations or unless a
> >> feature needs the refactoring.  I just don't want merge conflicts
> >> distracting people from feature work. Stan took awhile to merge his
> >> keycloak subsystem because our code was a moving target.  I've had
> >> delays before because of merge conflicts as well.
> >>
> >> My thought is that we will have a few more Alphas every 2-3 weeks.
> >> Going into Beta will mean that our major features have been
> >> implemented and we'll then start focusing on test coverage,
> >> refactoring, cleaning up code, documentation, and polishing the project.
> >>
> >> But, Stian can be the tie-breaker here if he wants this refactoring to
> >> happen sooner rather than later.  I'll go with what he wants.
> >>
> >>
> >>
> >
> 
> --
> 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 mposolda at redhat.com  Tue Feb 11 14:13:50 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 11 Feb 2014 20:13:50 +0100
Subject: [keycloak-dev] Running unit tests with different model
	implementations
In-Reply-To: <1465463092.3616126.1392136410268.JavaMail.zimbra@redhat.com>
References: <52F93A5C.6090304@redhat.com> <52F93E6C.9030504@redhat.com>
	<52F949D1.7050205@redhat.com> <52F9579C.6070008@redhat.com>
	<52FA458F.90709@redhat.com> <52FA46AB.3020906@redhat.com>
	<1465463092.3616126.1392136410268.JavaMail.zimbra@redhat.com>
Message-ID: <52FA766E.2020705@redhat.com>

I've sent PR https://github.com/keycloak/keycloak/pull/199 for mongo 
model and for changes in unit tests as mentioned previously (introducing 
model/tests module and moving unit tests from "services" module)

I would be happy if you can merge it just to avoid later conflicts 
during rebasing with master. Feel free to disable mongo model again if 
you need to add more features into model API and don't want to edit files.

It seems that from the changes/refactoring you mentioned below there 
will be changes in model just for UUID stuff. If you not already started 
on it, I can look at it and add support for it into both jpa and mongo 
models (from last mail on this, you want to use UUID generated from 
IdGenerator like "1-4564897" which should ensure that there won't never 
be any collision, right?)

It seems that other user related features won't require much changes on 
model if I am not wrong? Unless some realm configuration options, which 
should be quite easy to add into both model implementations.

Marek

On 11.2.2014 17:33, Stian Thorgersen wrote:
> Sounds good. Getting Mongo in now is a priority for us, but it doesn't have to be perfect now.
>
> With regards to refactoring changes proposed they all sound great, but I agree with Bill. Let's do a few more rounds to get some more "core" features in. Then let's do refactoring, testing, etc..
>
> At this point there's no immediate refactoring I can think of, except for swapping from DB generated IDs to UUIDs + the changes to users I proposed:
>
> * Login with username or email
> * Use id in token#sub
> * Remove recover username
> * Let users change their username (probably an option on the realm to disable?)
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 11 February, 2014 3:50:03 PM
>> Subject: Re: [keycloak-dev] Running unit tests with different model	implementations
>>
>> Sounds good.
>>
>> On 2/11/2014 10:45 AM, Marek Posolda wrote:
>>> Thanks for the clarification, thing is that we may need mongo model in
>>> alpha 2 too because of liveoak.
>>>
>>> So for now I did not made any big refactoring and movement of existing
>>> manager classes. I just introduced new module "model/tests" and moved
>>> just existing model related unit tests (basically everything except
>>> EmailSenderTest) from "services" module to this one. Then I configured
>>> model/jpa and model/mongo modules to use tests from this one. So
>>> currently all these model unit tests are always executed during build of
>>> particular model implementation (ie. building model/jpa runs all tests
>>> with "jpa" model implementation and building model/mongo runs all tests
>>> with "mongo" model implementation).
>>>
>>> So only thing moved to different location are those unit tests classes.
>>> Is this acceptable change for Alpha 2?
>>>
>>> With this change, if you decide to enable/disable some model
>>> implementation, you will need just comment/uncomment one line in
>>> model/pom.xml and that's it. Side-effect of this is that many
>>> test-scoped dependencies from "services" module are not needed anymore
>>> (especially hibernate and H2, which were needed for "jpa" model)
>>>
>>> Testsuite is executed just with JPA model by default, there is separate
>>> profile for running it with mongo, which is used only if you add
>>> -Dkeycloak.model=mongo .
>>>
>>> Hope to send PR with mongo model later today or early tomorrow with this
>>> change introduced.
>>>
>>> Thanks,
>>> Marek
>>>
>>> On 10.2.2014 23:50, Bill Burke wrote:
>>>>
>>>> On 2/10/2014 4:51 PM, Marek Posolda wrote:
>>>>> I prefer 1 but it's more work and more required changes of current
>>>>> project structure. wdyt?
>>>>>
>>>> I agree. I thought that was the plan even before this email.  That we
>>>> needed restructuring of the codebase to separate JAX-RS code from
>>>> business logic, from model logic.  That we needed more comprehensive
>>>> testing.
>>>>
>>>> Minimally, to do this work we have to wait until after Alpha 2 (end of
>>>> this week).  But my preference is that there is no refactoring work at
>>>> all until we're done with core feature implementations or unless a
>>>> feature needs the refactoring.  I just don't want merge conflicts
>>>> distracting people from feature work. Stan took awhile to merge his
>>>> keycloak subsystem because our code was a moving target.  I've had
>>>> delays before because of merge conflicts as well.
>>>>
>>>> My thought is that we will have a few more Alphas every 2-3 weeks.
>>>> Going into Beta will mean that our major features have been
>>>> implemented and we'll then start focusing on test coverage,
>>>> refactoring, cleaning up code, documentation, and polishing the project.
>>>>
>>>> But, Stian can be the tie-breaker here if he wants this refactoring to
>>>> happen sooner rather than later.  I'll go with what he wants.
>>>>
>>>>
>>>>
>> --
>> 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 Feb 11 14:49:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Feb 2014 14:49:16 -0500
Subject: [keycloak-dev] Running unit tests with different model
	implementations
In-Reply-To: <52FA766E.2020705@redhat.com>
References: <52F93A5C.6090304@redhat.com> <52F93E6C.9030504@redhat.com>
	<52F949D1.7050205@redhat.com> <52F9579C.6070008@redhat.com>
	<52FA458F.90709@redhat.com> <52FA46AB.3020906@redhat.com>
	<1465463092.3616126.1392136410268.JavaMail.zimbra@redhat.com>
	<52FA766E.2020705@redhat.com>
Message-ID: <52FA7EBC.9010600@redhat.com>



On 2/11/2014 2:13 PM, Marek Posolda wrote:
> I've sent PR https://github.com/keycloak/keycloak/pull/199 for mongo
> model and for changes in unit tests as mentioned previously (introducing
> model/tests module and moving unit tests from "services" module)
>

Merged.

> I would be happy if you can merge it just to avoid later conflicts
> during rebasing with master. Feel free to disable mongo model again if
> you need to add more features into model API and don't want to edit files.
>

I don't know Mongo.  That's the only reason I would disable it.

> It seems that from the changes/refactoring you mentioned below there
> will be changes in model just for UUID stuff. If you not already started
> on it, I can look at it and add support for it into both jpa and mongo
> models (from last mail on this, you want to use UUID generated from
> IdGenerator like "1-4564897" which should ensure that there won't never
> be any collision, right?)
>

I just wanted the models to use Strings for IDs and not UUID objects.



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

From mposolda at redhat.com  Tue Feb 11 18:38:56 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 12 Feb 2014 00:38:56 +0100
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <etPan.52fa301b.19495cff.36cc@animus>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>	<174068773.21904241.1391764362645.JavaMail.root@redhat.com>	<CAAg5f2RMUK=11YpZqKV+V2wAwXOHh=vZ-qY83WW=O5zEZ-wVSA@mail.gmail.com>	<52F4E7E8.10209@redhat.com>	<1498059408.22120221.1391783580418.JavaMail.root@redhat.com>	<52F4F377.7010500@redhat.com>	<1544741170.22214767.1391786238506.JavaMail.root@redhat.com>	<52F4FCDD.9090706@redhat.com>	<1675776790.22280127.1391787694580.JavaMail.root@redhat.com>	<etPan.52fa2d2e.74b0dc51.36cc@animus>
	<52FA2DCE.1040709@redhat.com> <etPan.52fa301b.19495cff.36cc@animus>
Message-ID: <52FAB490.50302@redhat.com>

I wonder if it's not better to just use Long instead of String? In 
GateIn portal we use old Picketlink IDM backed by Hibernate and we have 
autogenerated Ids of type Long, which are "externally" seen as Strings, 
so it's not a problem to keep getId() method in API returning String.

See the class here (and getter/setters for Strings): 
https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/java/org/picketlink/idm/impl/model/hibernate/HibernateIdentityObject.java#L55
and Hibernate mapping: 
https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/resources/mappings/HibernateIdentityObject.hbm.xml#L8

The most important thing is, that this is tested and works with all 
major databases (H2, MySQL, PostgreSQL, IBM DB2, Oracle, Sybase, MSSQL). 
Another thing is that long might have better performance than String.

I am not sure about the usecase with import/export stuff from/into 
completely different DB (like have data in H2, then export them and then 
import same data into MySQL). This may not work as different DBs may 
have different rules for allowing ID (some may have unique ID just for 
single table, some may enforce to have unique ID globally). However I am 
also not sure if String Id like "1-898928392" is allowed in all RDBMS...

Marek


On 11.2.2014 15:13, Bruno Oliveira wrote:
> +1 I guess TokenIdGenerator does the job well
>


From bburke at redhat.com  Tue Feb 11 20:47:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Feb 2014 20:47:05 -0500
Subject: [keycloak-dev] missing styles from initial login page
In-Reply-To: <362809051.3586368.1392135811860.JavaMail.zimbra@redhat.com>
References: <52FA45ED.60607@redhat.com>
	<362809051.3586368.1392135811860.JavaMail.zimbra@redhat.com>
Message-ID: <52FAD299.6040604@redhat.com>

Seems to work now.

On 2/11/2014 11:23 AM, Stian Thorgersen wrote:
> This should be recently fixed. Can you confirm if this happens in master now?
>
> Basically some rather crappy code I wrote resulted in keycloak theme not being set as default theme until after the first load. So on first load it would fall back to the base theme which doesn't have any styles.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 11 February, 2014 3:46:53 PM
>> Subject: [keycloak-dev] missing styles from initial login page
>>
>> I'm seeing this weird behavior where my first login (from the
>> customer-portal) shows a login page with no styles.  If you look at the
>> HTML page source, no stylesheets are linked.  Hitting browser refresh
>> then loads the login page correctly, and the stylesheets are linked and
>> shown in the source of the HTML.  This is only for the 1st time you see
>> the login screen.
>>
>> Any ideas?
>>
>> --
>> 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 Feb 12 06:30:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Feb 2014 06:30:06 -0500 (EST)
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <52FAB490.50302@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<1544741170.22214767.1391786238506.JavaMail.root@redhat.com>
	<52F4FCDD.9090706@redhat.com>
	<1675776790.22280127.1391787694580.JavaMail.root@redhat.com>
	<etPan.52fa2d2e.74b0dc51.36cc@animus> <52FA2DCE.1040709@redhat.com>
	<etPan.52fa301b.19495cff.36cc@animus> <52FAB490.50302@redhat.com>
Message-ID: <1458987062.5070083.1392204606766.JavaMail.zimbra@redhat.com>

I'm confused - so let's clarify:

Let's use IdGenerator to create IDs, but replace the implementation with:

public class IdGenerator {
  public static String generateId() {
    return java.lang.UUID.randomUUID().toString();
  }
}

* IdGenerator as it stands doesn't work. For example it won't work in a cluster. It also could quite likely generated duplicates if a server is restarted after the time has been changed (admin restarts server, realizes time is 60 min wrong, fixes that and starts Keycloak).

We'll then use this to generate IDs when creating new realms, apps, users, roles, etc. (for all model implementations). In the model api and in the db these will be 128-bits strings.

I don't see the need for TokenIdGenerator and we should use IdGenerator for that as well.

If there is a demand for it in the future, we could investigate a better solution. For example we could get away with a smaller id (64-bits?), we could generate sequential UUIDs to improve db performance, etc. In the short/medium term though, we have other higher priorities.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bruno Oliveira" <bruno at abstractj.org>, "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 11 February, 2014 11:38:56 PM
> Subject: Re: [keycloak-dev] Use UUID for IDs
> 
> I wonder if it's not better to just use Long instead of String? In
> GateIn portal we use old Picketlink IDM backed by Hibernate and we have
> autogenerated Ids of type Long, which are "externally" seen as Strings,
> so it's not a problem to keep getId() method in API returning String.
> 
> See the class here (and getter/setters for Strings):
> https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/java/org/picketlink/idm/impl/model/hibernate/HibernateIdentityObject.java#L55
> and Hibernate mapping:
> https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/resources/mappings/HibernateIdentityObject.hbm.xml#L8
> 
> The most important thing is, that this is tested and works with all
> major databases (H2, MySQL, PostgreSQL, IBM DB2, Oracle, Sybase, MSSQL).
> Another thing is that long might have better performance than String.
> 
> I am not sure about the usecase with import/export stuff from/into
> completely different DB (like have data in H2, then export them and then
> import same data into MySQL). This may not work as different DBs may
> have different rules for allowing ID (some may have unique ID just for
> single table, some may enforce to have unique ID globally). However I am
> also not sure if String Id like "1-898928392" is allowed in all RDBMS...
> 
> Marek
> 
> 
> On 11.2.2014 15:13, Bruno Oliveira wrote:
> > +1 I guess TokenIdGenerator does the job well
> >
> 
> 

From bburke at redhat.com  Wed Feb 12 08:54:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Feb 2014 08:54:20 -0500
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <1458987062.5070083.1392204606766.JavaMail.zimbra@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<1544741170.22214767.1391786238506.JavaMail.root@redhat.com>
	<52F4FCDD.9090706@redhat.com>
	<1675776790.22280127.1391787694580.JavaMail.root@redhat.com>
	<etPan.52fa2d2e.74b0dc51.36cc@animus> <52FA2DCE.1040709@redhat.com>
	<etPan.52fa301b.19495cff.36cc@animus> <52FAB490.50302@redhat.com>
	<1458987062.5070083.1392204606766.JavaMail.zimbra@redhat.com>
Message-ID: <52FB7D0C.2080806@redhat.com>

IIRC, String ids was an artifact from when we used Picketlink as the 
sole backend store.  Why wouldn't we just use a Long and use whatever 
facility the persistence layer has for generating unique ids?  (i.e. a 
sequence)?

+1 that current IdGenerator sucks.  My bad.  I should know better (and 
have done better in the past, and have even used UUID in the past). 
Don't know what I was thinking...

On 2/12/2014 6:30 AM, Stian Thorgersen wrote:
> I'm confused - so let's clarify:
>
> Let's use IdGenerator to create IDs, but replace the implementation with:
>
> public class IdGenerator {
>    public static String generateId() {
>      return java.lang.UUID.randomUUID().toString();
>    }
> }
>
> * IdGenerator as it stands doesn't work. For example it won't work in a cluster. It also could quite likely generated duplicates if a server is restarted after the time has been changed (admin restarts server, realizes time is 60 min wrong, fixes that and starts Keycloak).
>
> We'll then use this to generate IDs when creating new realms, apps, users, roles, etc. (for all model implementations). In the model api and in the db these will be 128-bits strings.
>
> I don't see the need for TokenIdGenerator and we should use IdGenerator for that as well.
>
> If there is a demand for it in the future, we could investigate a better solution. For example we could get away with a smaller id (64-bits?), we could generate sequential UUIDs to improve db performance, etc. In the short/medium term though, we have other higher priorities.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bruno Oliveira" <bruno at abstractj.org>, "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 11 February, 2014 11:38:56 PM
>> Subject: Re: [keycloak-dev] Use UUID for IDs
>>
>> I wonder if it's not better to just use Long instead of String? In
>> GateIn portal we use old Picketlink IDM backed by Hibernate and we have
>> autogenerated Ids of type Long, which are "externally" seen as Strings,
>> so it's not a problem to keep getId() method in API returning String.
>>
>> See the class here (and getter/setters for Strings):
>> https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/java/org/picketlink/idm/impl/model/hibernate/HibernateIdentityObject.java#L55
>> and Hibernate mapping:
>> https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/resources/mappings/HibernateIdentityObject.hbm.xml#L8
>>
>> The most important thing is, that this is tested and works with all
>> major databases (H2, MySQL, PostgreSQL, IBM DB2, Oracle, Sybase, MSSQL).
>> Another thing is that long might have better performance than String.
>>
>> I am not sure about the usecase with import/export stuff from/into
>> completely different DB (like have data in H2, then export them and then
>> import same data into MySQL). This may not work as different DBs may
>> have different rules for allowing ID (some may have unique ID just for
>> single table, some may enforce to have unique ID globally). However I am
>> also not sure if String Id like "1-898928392" is allowed in all RDBMS...
>>
>> Marek
>>
>>
>> On 11.2.2014 15:13, Bruno Oliveira wrote:
>>> +1 I guess TokenIdGenerator does the job well
>>>
>>
>>

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

From stian at redhat.com  Wed Feb 12 09:18:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Feb 2014 09:18:03 -0500 (EST)
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <52FB7D0C.2080806@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<1675776790.22280127.1391787694580.JavaMail.root@redhat.com>
	<etPan.52fa2d2e.74b0dc51.36cc@animus> <52FA2DCE.1040709@redhat.com>
	<etPan.52fa301b.19495cff.36cc@animus> <52FAB490.50302@redhat.com>
	<1458987062.5070083.1392204606766.JavaMail.zimbra@redhat.com>
	<52FB7D0C.2080806@redhat.com>
Message-ID: <814727014.5252889.1392214683360.JavaMail.zimbra@redhat.com>

We've come full circle ;)

My reasoning for not to use db generated ids are:

* ID format would be different depending on the store (H2, MySQL, PostgreSQL, Oracle, Mongo, etc.) / for example apps will want to refer to users by id, and they need to know how to store it
* What happens to a "sequences" (or whatever mechanism the db chooses to use) if you export to json, then import again. Especially if you change the underlying db (e.g. from H2 to PostgreSQL)

Further (this is a stupid reason) if we want to support huge deployments shards will be involved, in which case it'd be simpler to use UUIDs.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: "Bruno Oliveira" <bruno at abstractj.org>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 February, 2014 1:54:20 PM
> Subject: Re: [keycloak-dev] Use UUID for IDs
> 
> IIRC, String ids was an artifact from when we used Picketlink as the
> sole backend store.  Why wouldn't we just use a Long and use whatever
> facility the persistence layer has for generating unique ids?  (i.e. a
> sequence)?
> 
> +1 that current IdGenerator sucks.  My bad.  I should know better (and
> have done better in the past, and have even used UUID in the past).
> Don't know what I was thinking...
> 
> On 2/12/2014 6:30 AM, Stian Thorgersen wrote:
> > I'm confused - so let's clarify:
> >
> > Let's use IdGenerator to create IDs, but replace the implementation with:
> >
> > public class IdGenerator {
> >    public static String generateId() {
> >      return java.lang.UUID.randomUUID().toString();
> >    }
> > }
> >
> > * IdGenerator as it stands doesn't work. For example it won't work in a
> > cluster. It also could quite likely generated duplicates if a server is
> > restarted after the time has been changed (admin restarts server, realizes
> > time is 60 min wrong, fixes that and starts Keycloak).
> >
> > We'll then use this to generate IDs when creating new realms, apps, users,
> > roles, etc. (for all model implementations). In the model api and in the
> > db these will be 128-bits strings.
> >
> > I don't see the need for TokenIdGenerator and we should use IdGenerator for
> > that as well.
> >
> > If there is a demand for it in the future, we could investigate a better
> > solution. For example we could get away with a smaller id (64-bits?), we
> > could generate sequential UUIDs to improve db performance, etc. In the
> > short/medium term though, we have other higher priorities.
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Bruno Oliveira" <bruno at abstractj.org>, "Bill Burke"
> >> <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 11 February, 2014 11:38:56 PM
> >> Subject: Re: [keycloak-dev] Use UUID for IDs
> >>
> >> I wonder if it's not better to just use Long instead of String? In
> >> GateIn portal we use old Picketlink IDM backed by Hibernate and we have
> >> autogenerated Ids of type Long, which are "externally" seen as Strings,
> >> so it's not a problem to keep getId() method in API returning String.
> >>
> >> See the class here (and getter/setters for Strings):
> >> https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/java/org/picketlink/idm/impl/model/hibernate/HibernateIdentityObject.java#L55
> >> and Hibernate mapping:
> >> https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/resources/mappings/HibernateIdentityObject.hbm.xml#L8
> >>
> >> The most important thing is, that this is tested and works with all
> >> major databases (H2, MySQL, PostgreSQL, IBM DB2, Oracle, Sybase, MSSQL).
> >> Another thing is that long might have better performance than String.
> >>
> >> I am not sure about the usecase with import/export stuff from/into
> >> completely different DB (like have data in H2, then export them and then
> >> import same data into MySQL). This may not work as different DBs may
> >> have different rules for allowing ID (some may have unique ID just for
> >> single table, some may enforce to have unique ID globally). However I am
> >> also not sure if String Id like "1-898928392" is allowed in all RDBMS...
> >>
> >> Marek
> >>
> >>
> >> On 11.2.2014 15:13, Bruno Oliveira wrote:
> >>> +1 I guess TokenIdGenerator does the job well
> >>>
> >>
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Wed Feb 12 09:56:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Feb 2014 09:56:50 -0500
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <814727014.5252889.1392214683360.JavaMail.zimbra@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<1675776790.22280127.1391787694580.JavaMail.root@redhat.com>
	<etPan.52fa2d2e.74b0dc51.36cc@animus> <52FA2DCE.1040709@redhat.com>
	<etPan.52fa301b.19495cff.36cc@animus> <52FAB490.50302@redhat.com>
	<1458987062.5070083.1392204606766.JavaMail.zimbra@redhat.com>
	<52FB7D0C.2080806@redhat.com>
	<814727014.5252889.1392214683360.JavaMail.zimbra@redhat.com>
Message-ID: <52FB8BB2.6020805@redhat.com>



On 2/12/2014 9:18 AM, Stian Thorgersen wrote:
> We've come full circle ;)
>
> My reasoning for not to use db generated ids are:
>
> * ID format would be different depending on the store (H2, MySQL, PostgreSQL, Oracle, Mongo, etc.) / for example apps will want to refer to users by id, and they need to know how to store it

Dbs will support long primary keys :)

> * What happens to a "sequences" (or whatever mechanism the db chooses to use) if you export to json, then import again. Especially if you change the underlying db (e.g. from H2 to PostgreSQL)
>

Export to json does not have to contain ids.  Our import format doesn't 
require ids.  I'm not even sure it honors ids :)

> Further (this is a stupid reason) if we want to support huge deployments shards will be involved, in which case it'd be simpler to use UUIDs.
>

That is beyond my experience so I don't have a counter argument to that.

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

From stian at redhat.com  Wed Feb 12 10:05:58 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Feb 2014 10:05:58 -0500 (EST)
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <52FB8BB2.6020805@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<52FA2DCE.1040709@redhat.com> <etPan.52fa301b.19495cff.36cc@animus>
	<52FAB490.50302@redhat.com>
	<1458987062.5070083.1392204606766.JavaMail.zimbra@redhat.com>
	<52FB7D0C.2080806@redhat.com>
	<814727014.5252889.1392214683360.JavaMail.zimbra@redhat.com>
	<52FB8BB2.6020805@redhat.com>
Message-ID: <192360171.5327252.1392217558871.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 February, 2014 2:56:50 PM
> Subject: Re: [keycloak-dev] Use UUID for IDs
> 
> 
> 
> On 2/12/2014 9:18 AM, Stian Thorgersen wrote:
> > We've come full circle ;)
> >
> > My reasoning for not to use db generated ids are:
> >
> > * ID format would be different depending on the store (H2, MySQL,
> > PostgreSQL, Oracle, Mongo, etc.) / for example apps will want to refer to
> > users by id, and they need to know how to store it
> 
> Dbs will support long primary keys :)

Sure, but if an IDs DB sequences (1, 2, 3, 4, 5, 6). That's what users will end up expecting. Then they change to Mongo and now suddenly the IDs are generated by Mongo (507f1f77bcf86cd799439011) they are different.

> 
> > * What happens to a "sequences" (or whatever mechanism the db chooses to
> > use) if you export to json, then import again. Especially if you change
> > the underlying db (e.g. from H2 to PostgreSQL)
> >
> 
> Export to json does not have to contain ids.  Our import format doesn't
> require ids.  I'm not even sure it honors ids :)

That depends why you export to json right? If you export to backup, to migrate to another db, or even to upgrade KC when the db schema has changed, you will expect the IDs to remain the same.

> 
> > Further (this is a stupid reason) if we want to support huge deployments
> > shards will be involved, in which case it'd be simpler to use UUIDs.
> >
> 
> That is beyond my experience so I don't have a counter argument to that.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Wed Feb 12 10:18:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Feb 2014 10:18:39 -0500
Subject: [keycloak-dev] Use UUID for IDs
In-Reply-To: <192360171.5327252.1392217558871.JavaMail.zimbra@redhat.com>
References: <1449358974.21897403.1391763876813.JavaMail.root@redhat.com>
	<52FA2DCE.1040709@redhat.com> <etPan.52fa301b.19495cff.36cc@animus>
	<52FAB490.50302@redhat.com>
	<1458987062.5070083.1392204606766.JavaMail.zimbra@redhat.com>
	<52FB7D0C.2080806@redhat.com>
	<814727014.5252889.1392214683360.JavaMail.zimbra@redhat.com>
	<52FB8BB2.6020805@redhat.com>
	<192360171.5327252.1392217558871.JavaMail.zimbra@redhat.com>
Message-ID: <52FB90CF.8070207@redhat.com>

Stian, whatever you want.  I honestly haven't written a RDBMS 
application in 10+ years.  Only best practices I know were absorbed 
through osmosis by being so close to the JPA/EJB3 efforts in mid-2000s 
or by listening/responding to users on those forums.

On 2/12/2014 10:05 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Marek Posolda" <mposolda at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>, keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 12 February, 2014 2:56:50 PM
>> Subject: Re: [keycloak-dev] Use UUID for IDs
>>
>>
>>
>> On 2/12/2014 9:18 AM, Stian Thorgersen wrote:
>>> We've come full circle ;)
>>>
>>> My reasoning for not to use db generated ids are:
>>>
>>> * ID format would be different depending on the store (H2, MySQL,
>>> PostgreSQL, Oracle, Mongo, etc.) / for example apps will want to refer to
>>> users by id, and they need to know how to store it
>>
>> Dbs will support long primary keys :)
>
> Sure, but if an IDs DB sequences (1, 2, 3, 4, 5, 6). That's what users will end up expecting. Then they change to Mongo and now suddenly the IDs are generated by Mongo (507f1f77bcf86cd799439011) they are different.
>
>>
>>> * What happens to a "sequences" (or whatever mechanism the db chooses to
>>> use) if you export to json, then import again. Especially if you change
>>> the underlying db (e.g. from H2 to PostgreSQL)
>>>
>>
>> Export to json does not have to contain ids.  Our import format doesn't
>> require ids.  I'm not even sure it honors ids :)
>
> That depends why you export to json right? If you export to backup, to migrate to another db, or even to upgrade KC when the db schema has changed, you will expect the IDs to remain the same.
>
>>
>>> Further (this is a stupid reason) if we want to support huge deployments
>>> shards will be involved, in which case it'd be simpler to use UUIDs.
>>>
>>
>> That is beyond my experience so I don't have a counter argument to that.
>>
>> --
>> 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 Feb 12 10:50:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Feb 2014 10:50:51 -0500 (EST)
Subject: [keycloak-dev] Jenkins
In-Reply-To: <1645983767.5395861.1392220092946.JavaMail.zimbra@redhat.com>
Message-ID: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>

To make sure Keycloak works on different containers (EAP, WildFly, others?), multiple databases (MySQL, PostgreSQL, Mongo, others?) and that I don't break the build it would be great to have Jenkins setup to run tests for us.

Question is, do we rely on internal Jenkins servers (tickets, vpn, etc.) or do we use CloudBees? My personal preference is CloudBees, but if there is strong objections I don't mind either way.

Marek has experience with Jenkins so he's kindly volunteered to set this up for us (right?) ;)

From bburke at redhat.com  Wed Feb 12 12:25:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Feb 2014 12:25:04 -0500
Subject: [keycloak-dev] Jenkins
In-Reply-To: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>
References: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>
Message-ID: <52FBAE70.50906@redhat.com>

marek now how to integrate it with PRs?

On 2/12/2014 10:50 AM, Stian Thorgersen wrote:
> To make sure Keycloak works on different containers (EAP, WildFly, others?), multiple databases (MySQL, PostgreSQL, Mongo, others?) and that I don't break the build it would be great to have Jenkins setup to run tests for us.
>
> Question is, do we rely on internal Jenkins servers (tickets, vpn, etc.) or do we use CloudBees? My personal preference is CloudBees, but if there is strong objections I don't mind either way.
>
> Marek has experience with Jenkins so he's kindly volunteered to set this up for us (right?) ;)
> _______________________________________________
> 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 matzew at apache.org  Wed Feb 12 12:27:50 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 12 Feb 2014 18:27:50 +0100
Subject: [keycloak-dev] Jenkins
In-Reply-To: <52FBAE70.50906@redhat.com>
References: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>
	<52FBAE70.50906@redhat.com>
Message-ID: <CAAg5f2RdhGX=ckkM1wEg9zN7xYOV3Fe4=0oBHr7pyQTCdXKDwA@mail.gmail.com>

W/ TravisCI, that's easy.


On Wed, Feb 12, 2014 at 6:25 PM, Bill Burke <bburke at redhat.com> wrote:

> marek now how to integrate it with PRs?
>
> On 2/12/2014 10:50 AM, Stian Thorgersen wrote:
> > To make sure Keycloak works on different containers (EAP, WildFly,
> others?), multiple databases (MySQL, PostgreSQL, Mongo, others?) and that I
> don't break the build it would be great to have Jenkins setup to run tests
> for us.
> >
> > Question is, do we rely on internal Jenkins servers (tickets, vpn, etc.)
> or do we use CloudBees? My personal preference is CloudBees, but if there
> is strong objections I don't mind either way.
> >
> > Marek has experience with Jenkins so he's kindly volunteered to set this
> up for us (right?) ;)
> > _______________________________________________
> > 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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140212/c2448515/attachment.html 

From stian at redhat.com  Wed Feb 12 12:29:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Feb 2014 12:29:19 -0500 (EST)
Subject: [keycloak-dev] Patternfly and RCUE styles
In-Reply-To: <1225472906.5569298.1392225601834.JavaMail.zimbra@redhat.com>
Message-ID: <970244978.5582653.1392226159133.JavaMail.zimbra@redhat.com>

Currently we use our own styles in Keycloak. Problems with this include:

* We have to maintain our own styles
* Can't integrate as easily with other projects

To solve these issues we need to replace our styles with the stylesheets provided by RCUE project, or more specifically the PatternFly project (which is basically RCUE for projects, while RCUE is for products).

Villiam has done an excellent start on this work. However, there was a fair few changes required to the html so there may be some bugs.

I'd like to include this work ASAP. This is to prevent headaches with merging and also to introduce the slight changes to the l&f as early as possible. So I think it would be good to include this in alpha2.

If you want to have a look at the current state go to https://kc2-sthorger.rhcloud.com/auth/admin/index.html (username/password: admin/secret). Code is at https://github.com/stianst/keycloak/tree/FORMS2.

From bburke at redhat.com  Wed Feb 12 12:32:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Feb 2014 12:32:01 -0500
Subject: [keycloak-dev] Patternfly and RCUE styles
In-Reply-To: <970244978.5582653.1392226159133.JavaMail.zimbra@redhat.com>
References: <970244978.5582653.1392226159133.JavaMail.zimbra@redhat.com>
Message-ID: <52FBB011.9080007@redhat.com>

Yes please include this work ASAP as I'm updating a few screencasts.

On 2/12/2014 12:29 PM, Stian Thorgersen wrote:
> Currently we use our own styles in Keycloak. Problems with this include:
>
> * We have to maintain our own styles
> * Can't integrate as easily with other projects
>
> To solve these issues we need to replace our styles with the stylesheets provided by RCUE project, or more specifically the PatternFly project (which is basically RCUE for projects, while RCUE is for products).
>
> Villiam has done an excellent start on this work. However, there was a fair few changes required to the html so there may be some bugs.
>
> I'd like to include this work ASAP. This is to prevent headaches with merging and also to introduce the slight changes to the l&f as early as possible. So I think it would be good to include this in alpha2.
>
> If you want to have a look at the current state go to https://kc2-sthorger.rhcloud.com/auth/admin/index.html (username/password: admin/secret). Code is at https://github.com/stianst/keycloak/tree/FORMS2.
> _______________________________________________
> 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  Wed Feb 12 12:34:07 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Wed, 12 Feb 2014 15:34:07 -0200
Subject: [keycloak-dev] Patternfly and RCUE styles
In-Reply-To: <970244978.5582653.1392226159133.JavaMail.zimbra@redhat.com>
References: <970244978.5582653.1392226159133.JavaMail.zimbra@redhat.com>
Message-ID: <5A9C6455-4CCB-4E35-9DD3-285805468914@redhat.com>

Nice!!!

Just FYI, Viliam and I will contribute to the Patternfly library, making widgets of some elements that we implemented for Keycloak and that are not on Patternfly yet, such as the ?left sidebar?, the input with search icon and the collapsible fieldset.

On Feb 12, 2014, at 3:29 PM, Stian Thorgersen <stian at redhat.com> wrote:

> Currently we use our own styles in Keycloak. Problems with this include:
> 
> * We have to maintain our own styles
> * Can't integrate as easily with other projects
> 
> To solve these issues we need to replace our styles with the stylesheets provided by RCUE project, or more specifically the PatternFly project (which is basically RCUE for projects, while RCUE is for products).
> 
> Villiam has done an excellent start on this work. However, there was a fair few changes required to the html so there may be some bugs.
> 
> I'd like to include this work ASAP. This is to prevent headaches with merging and also to introduce the slight changes to the l&f as early as possible. So I think it would be good to include this in alpha2.
> 
> If you want to have a look at the current state go to https://kc2-sthorger.rhcloud.com/auth/admin/index.html (username/password: admin/secret). Code is at https://github.com/stianst/keycloak/tree/FORMS2.
> _______________________________________________
> 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/20140212/a9091a51/attachment.html 

From bburke at redhat.com  Wed Feb 12 19:02:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Feb 2014 19:02:44 -0500
Subject: [keycloak-dev] possible change to subsystem format
Message-ID: <52FC0BA4.1000601@redhat.com>

Old format was

<realm>
    realm info
    <secure-deployment name="war name">
       app specific deployment
    </secure-deployment
</realm>

For now, I'm getting rid of the concept of a realm.  So it will just be:

<secure-deployment name="war name">
   all the config you'd see in a keycloak.json file
</secure-deployment>

The benefits of this is that it will be really easy for the keycloak 
admin console to initiate a deployment.  Also, not sure yet, but we may 
end up having an "UNCONFIGURED" mode for keycloak adapters.  Where they 
aren't attached to a realm/application, but are applied to the WAR 
deployment (see the Aerogear hread).

The downside to this is that there will be duplicate config if there is 
more than one app on the server.  Later on I'll add a "realm-ref" 
element or something to secure-deployment so we can define common realm 
data elsewhere.  I'll do that next iteration.

Bill

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

From bburke at redhat.com  Wed Feb 12 19:02:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Feb 2014 19:02:48 -0500
Subject: [keycloak-dev] possible change to subsystem format
Message-ID: <52FC0BA8.2090006@redhat.com>

Old format was

<realm>
    realm info
    <secure-deployment name="war name">
       app specific deployment
    </secure-deployment
</realm>

For now, I'm getting rid of the concept of a realm.  So it will just be:

<secure-deployment name="war name">
   all the config you'd see in a keycloak.json file
</secure-deployment>

The benefits of this is that it will be really easy for the keycloak 
admin console to initiate a deployment.  Also, not sure yet, but we may 
end up having an "UNCONFIGURED" mode for keycloak adapters.  Where they 
aren't attached to a realm/application, but are applied to the WAR 
deployment (see the Aerogear hread).

The downside to this is that there will be duplicate config if there is 
more than one app on the server.  Later on I'll add a "realm-ref" 
element or something to secure-deployment so we can define common realm 
data elsewhere.  I'll do that next iteration.

Bill

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

From mposolda at redhat.com  Thu Feb 13 05:43:35 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 13 Feb 2014 11:43:35 +0100
Subject: [keycloak-dev] Jenkins
In-Reply-To: <52FBAE70.50906@redhat.com>
References: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>
	<52FBAE70.50906@redhat.com>
Message-ID: <52FCA1D7.60208@redhat.com>

I've created job in internal jenkins to build keycloak master: 
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Keycloak/job/keycloak_master_commit/

This build should be triggered automatically after new PR is merged to 
git at github.com:keycloak/keycloak.git . Currently you can see that build 
is failing due to some errors in references to parent-poms but this 
should be fixed after you merge my PR 
https://github.com/keycloak/keycloak/pull/202 .

You need to be on RH VPN to see the build. If you want to do some 
changes in build configuration or create new build, you will need to 
login into Jenkins (use your RH kerberos credentials). If you have 
access to 
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Keycloak/job/keycloak_master_commit/configure 
we are fine.


Do you want to trigger job automatically just when PR is merged or also 
when someone send PR? AFAIK Jenkins has support just for the former. We 
have setup the latter in gatein-portal, but that doesn't use RH Jenkins 
but some other CI AFAIK. I can ask Thomas if you want this too, but do 
you think it's needed? IMHO it is quite sufficient to trigger build just 
when PR is merged?

One of the advantages of our jenkins is, that it has support for all 
databases. If you want me to continue, I will try to add more builds. I 
think we need:
- Build for running testsuite with mongo
- Matrix build for run unit tests with all RDBMS
- Matrix build for run testsuite with all RDBMS

When I finish UUID stuff (String Id generated by java.util.UUID instead 
of autogenerated by DB), we will be hopefully fine with all databases 
and won't see more DB related issues.

Marek


On 12.2.2014 18:25, Bill Burke wrote:
> marek now how to integrate it with PRs?
>
> On 2/12/2014 10:50 AM, Stian Thorgersen wrote:
>> To make sure Keycloak works on different containers (EAP, WildFly, others?), multiple databases (MySQL, PostgreSQL, Mongo, others?) and that I don't break the build it would be great to have Jenkins setup to run tests for us.
>>
>> Question is, do we rely on internal Jenkins servers (tickets, vpn, etc.) or do we use CloudBees? My personal preference is CloudBees, but if there is strong objections I don't mind either way.
>>
>> Marek has experience with Jenkins so he's kindly volunteered to set this up for us (right?) ;)
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From ssilvert at redhat.com  Thu Feb 13 09:26:36 2014
From: ssilvert at redhat.com (ssilvert at redhat.com)
Date: Thu, 13 Feb 2014 09:26:36 -0500
Subject: [keycloak-dev] Jenkins
In-Reply-To: <52FCA1D7.60208@redhat.com>
References: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>	<52FBAE70.50906@redhat.com>
	<52FCA1D7.60208@redhat.com>
Message-ID: <52FCD61C.2080703@redhat.com>

On 2/13/2014 5:43 AM, Marek Posolda wrote:
> Do you want to trigger job automatically just when PR is merged or also 
> when someone send PR? 
In WildFly we kick off a build and test for each PR sent.  If it is not
successful it doesn't get merged.  That saves us a ton of headache.  I
can't remember the last time the build was broken.  It just practically
never happens any more.

I think Keycloak will soon enter a phase where it gets lots of
contributors submitting PR's.  The sooner you force a successful build
and test BEFORE a merge the better.

Stan

From bburke at redhat.com  Thu Feb 13 09:29:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Feb 2014 09:29:06 -0500
Subject: [keycloak-dev] Jenkins
In-Reply-To: <52FCD61C.2080703@redhat.com>
References: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>	<52FBAE70.50906@redhat.com>	<52FCA1D7.60208@redhat.com>
	<52FCD61C.2080703@redhat.com>
Message-ID: <52FCD6B2.30904@redhat.com>



On 2/13/2014 9:26 AM, ssilvert at redhat.com wrote:
> On 2/13/2014 5:43 AM, Marek Posolda wrote:
>> Do you want to trigger job automatically just when PR is merged or also
>> when someone send PR?
> In WildFly we kick off a build and test for each PR sent.  If it is not
> successful it doesn't get merged.  That saves us a ton of headache.  I
> can't remember the last time the build was broken.  It just practically
> never happens any more.
>
> I think Keycloak will soon enter a phase where it gets lots of
> contributors submitting PR's.  The sooner you force a successful build
> and test BEFORE a merge the better.
>

+1.

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

From stian at redhat.com  Thu Feb 13 09:49:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Feb 2014 09:49:20 -0500 (EST)
Subject: [keycloak-dev] Jenkins
In-Reply-To: <52FCD6B2.30904@redhat.com>
References: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>
	<52FBAE70.50906@redhat.com> <52FCA1D7.60208@redhat.com>
	<52FCD61C.2080703@redhat.com> <52FCD6B2.30904@redhat.com>
Message-ID: <559161925.6405408.1392302960661.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 February, 2014 2:29:06 PM
> Subject: Re: [keycloak-dev] Jenkins
> 
> 
> 
> On 2/13/2014 9:26 AM, ssilvert at redhat.com wrote:
> > On 2/13/2014 5:43 AM, Marek Posolda wrote:
> >> Do you want to trigger job automatically just when PR is merged or also
> >> when someone send PR?
> > In WildFly we kick off a build and test for each PR sent.  If it is not
> > successful it doesn't get merged.  That saves us a ton of headache.  I
> > can't remember the last time the build was broken.  It just practically
> > never happens any more.
> >
> > I think Keycloak will soon enter a phase where it gets lots of
> > contributors submitting PR's.  The sooner you force a successful build
> > and test BEFORE a merge the better.
> >
> 
> +1.

+10 (one point for every time I've broken the build!)

> 
> --
> 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 Feb 13 09:57:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Feb 2014 09:57:32 -0500
Subject: [keycloak-dev] Jenkins
In-Reply-To: <559161925.6405408.1392302960661.JavaMail.zimbra@redhat.com>
References: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>
	<52FBAE70.50906@redhat.com> <52FCA1D7.60208@redhat.com>
	<52FCD61C.2080703@redhat.com> <52FCD6B2.30904@redhat.com>
	<559161925.6405408.1392302960661.JavaMail.zimbra@redhat.com>
Message-ID: <52FCDD5C.2010806@redhat.com>



On 2/13/2014 9:49 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 13 February, 2014 2:29:06 PM
>> Subject: Re: [keycloak-dev] Jenkins
>>
>>
>>
>> On 2/13/2014 9:26 AM, ssilvert at redhat.com wrote:
>>> On 2/13/2014 5:43 AM, Marek Posolda wrote:
>>>> Do you want to trigger job automatically just when PR is merged or also
>>>> when someone send PR?
>>> In WildFly we kick off a build and test for each PR sent.  If it is not
>>> successful it doesn't get merged.  That saves us a ton of headache.  I
>>> can't remember the last time the build was broken.  It just practically
>>> never happens any more.
>>>
>>> I think Keycloak will soon enter a phase where it gets lots of
>>> contributors submitting PR's.  The sooner you force a successful build
>>> and test BEFORE a merge the better.
>>>
>>
>> +1.
>
> +10 (one point for every time I've broken the build!)
>

I don't know if you remember Iona?  An Irish CORBA company.  When 
somebody broke the build you had to buy everybody on team a Guiness.  On 
our team page, your name had a Guiness pint jpg for each time you broke 
the build.



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

From stian at redhat.com  Thu Feb 13 10:03:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Feb 2014 10:03:15 -0500 (EST)
Subject: [keycloak-dev] Jenkins
In-Reply-To: <52FCDD5C.2010806@redhat.com>
References: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>
	<52FBAE70.50906@redhat.com> <52FCA1D7.60208@redhat.com>
	<52FCD61C.2080703@redhat.com> <52FCD6B2.30904@redhat.com>
	<559161925.6405408.1392302960661.JavaMail.zimbra@redhat.com>
	<52FCDD5C.2010806@redhat.com>
Message-ID: <2035381309.6421742.1392303795776.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, 13 February, 2014 2:57:32 PM
> Subject: Re: [keycloak-dev] Jenkins
> 
> 
> 
> On 2/13/2014 9:49 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 13 February, 2014 2:29:06 PM
> >> Subject: Re: [keycloak-dev] Jenkins
> >>
> >>
> >>
> >> On 2/13/2014 9:26 AM, ssilvert at redhat.com wrote:
> >>> On 2/13/2014 5:43 AM, Marek Posolda wrote:
> >>>> Do you want to trigger job automatically just when PR is merged or also
> >>>> when someone send PR?
> >>> In WildFly we kick off a build and test for each PR sent.  If it is not
> >>> successful it doesn't get merged.  That saves us a ton of headache.  I
> >>> can't remember the last time the build was broken.  It just practically
> >>> never happens any more.
> >>>
> >>> I think Keycloak will soon enter a phase where it gets lots of
> >>> contributors submitting PR's.  The sooner you force a successful build
> >>> and test BEFORE a merge the better.
> >>>
> >>
> >> +1.
> >
> > +10 (one point for every time I've broken the build!)
> >
> 
> I don't know if you remember Iona?  An Irish CORBA company.  When
> somebody broke the build you had to buy everybody on team a Guiness.  On
> our team page, your name had a Guiness pint jpg for each time you broke
> the build.

That would be very expensive in shipping costs :(

Luckily CORBA was before my days, but Arjuna had loads of Iona boxes ;)

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

From bburke at redhat.com  Thu Feb 13 10:06:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Feb 2014 10:06:08 -0500
Subject: [keycloak-dev] Jenkins
In-Reply-To: <2035381309.6421742.1392303795776.JavaMail.zimbra@redhat.com>
References: <922361014.5399130.1392220251487.JavaMail.zimbra@redhat.com>
	<52FBAE70.50906@redhat.com> <52FCA1D7.60208@redhat.com>
	<52FCD61C.2080703@redhat.com> <52FCD6B2.30904@redhat.com>
	<559161925.6405408.1392302960661.JavaMail.zimbra@redhat.com>
	<52FCDD5C.2010806@redhat.com>
	<2035381309.6421742.1392303795776.JavaMail.zimbra@redhat.com>
Message-ID: <52FCDF60.4040805@redhat.com>



On 2/13/2014 10:03 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, 13 February, 2014 2:57:32 PM
>> Subject: Re: [keycloak-dev] Jenkins
>>
>>
>>
>> On 2/13/2014 9:49 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 13 February, 2014 2:29:06 PM
>>>> Subject: Re: [keycloak-dev] Jenkins
>>>>
>>>>
>>>>
>>>> On 2/13/2014 9:26 AM, ssilvert at redhat.com wrote:
>>>>> On 2/13/2014 5:43 AM, Marek Posolda wrote:
>>>>>> Do you want to trigger job automatically just when PR is merged or also
>>>>>> when someone send PR?
>>>>> In WildFly we kick off a build and test for each PR sent.  If it is not
>>>>> successful it doesn't get merged.  That saves us a ton of headache.  I
>>>>> can't remember the last time the build was broken.  It just practically
>>>>> never happens any more.
>>>>>
>>>>> I think Keycloak will soon enter a phase where it gets lots of
>>>>> contributors submitting PR's.  The sooner you force a successful build
>>>>> and test BEFORE a merge the better.
>>>>>
>>>>
>>>> +1.
>>>
>>> +10 (one point for every time I've broken the build!)
>>>
>>
>> I don't know if you remember Iona?  An Irish CORBA company.  When
>> somebody broke the build you had to buy everybody on team a Guiness.  On
>> our team page, your name had a Guiness pint jpg for each time you broke
>> the build.
>
> That would be very expensive in shipping costs :(
>
> Luckily CORBA was before my days, but Arjuna had loads of Iona boxes ;)
>

Holy hell.  Am I that old?


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

From bburke at redhat.com  Thu Feb 13 10:27:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Feb 2014 10:27:26 -0500
Subject: [keycloak-dev] bill rocks!
Message-ID: <52FCE45E.9020703@redhat.com>

Does Viliam Rockai translate to "Bill Rocks!"?

:)

What sucks is that "Bill Berk" translates to "Bill Cunt" in British :(

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

From bburke at redhat.com  Thu Feb 13 10:41:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Feb 2014 10:41:45 -0500
Subject: [keycloak-dev] default themes all set?
Message-ID: <52FCE7B9.1020602@redhat.com>

Can I start redoing some of the screencasts I need to redo?  Or is there 
still stylesheet/theme work being done?

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

From stian at redhat.com  Thu Feb 13 10:50:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Feb 2014 10:50:08 -0500 (EST)
Subject: [keycloak-dev] default themes all set?
In-Reply-To: <52FCE7B9.1020602@redhat.com>
References: <52FCE7B9.1020602@redhat.com>
Message-ID: <408669074.6482514.1392306608746.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 February, 2014 3:41:45 PM
> Subject: [keycloak-dev] default themes all set?
> 
> Can I start redoing some of the screencasts I need to redo?  Or is there
> still stylesheet/theme work being done?

Admin console is pretty much done. There may be some minor fixes needed, but nothing that would ruin a screencast.

There may be some changes to login forms though, as I want to investigate if it would be possible to use Patternfly styles instead of our own bespoke stylesheets there as well.

> 
> --
> 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 Feb 13 18:48:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Feb 2014 18:48:15 -0500
Subject: [keycloak-dev] code changes, please note
Message-ID: <52FD59BF.1080603@redhat.com>

* There is no more RequireApplication and RequiredOAuthClient 
credentials in the UI.  They still exist in the data model and some of 
the APIs but they are not expossed by the admin console.
* New Credential Type:  "secret".  Secrets are stored in plain text and 
are the only cred type that can be retrieved from the model.
* Applications/OAuthClients are hard coded to use "secrets" as a 
credential type.
* Application and OAuth Installation page has changed!  It now populates 
the credentials with the secret.  You now also have an option to view 
Wildfly/JBoss Subsystem XML that you can cut and paste.
* Application and OAuth credentials page now shows the client secret. 
It also allows you to regenerate it.
* All demo code has been updated to reflect above changes.
* Installing the wildfly/as7/eap6 subsystem is now a requirement
* Demo code has changed.  There are now 2 examples.  preconfigured and 
unconfigured that work for both AS7, EAP6, and Wildfly 8.
* We now build against WIldfly 8.0.0.Final and Undertow 1.0.0.Final.

I now need to document all this stuff and update the screencasts (as 
well as document Composite roles ).

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

From vrockai at redhat.com  Fri Feb 14 05:47:41 2014
From: vrockai at redhat.com (Viliam Rockai)
Date: Fri, 14 Feb 2014 11:47:41 +0100
Subject: [keycloak-dev] bill rocks!
In-Reply-To: <52FCE45E.9020703@redhat.com>
References: <52FCE45E.9020703@redhat.com>
Message-ID: <1392374861.1683.9.camel@vrockai-laptop>

On Thu, 2014-02-13 at 10:27 -0500, Bill Burke wrote:
> Does Viliam Rockai translate to "Bill Rocks!"?
> 
> :)

If you want to make me feel good about myself, we can agree on that! :)
But from the etymology perspective it's not so great. Rocka (with
special chars its Ro?ka) is sort of a bucket :| [1] But since my
university subject field was AI, Bill Rock-AI is fine, too :)

> 
> What sucks is that "Bill Berk" translates to "Bill Cunt" in British :(
> 

Just find a better language to translate, "burka" means "storm" in my
(slovak) language. But I guess nothing can beat the almighty
Thor-gersen.

[1]
http://img18.aprod.hu/images_aprodhu/5639271_1_644x461_regi-tejes-rocska-nyiregyhaza.jpg



From stian at redhat.com  Fri Feb 14 09:01:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 14 Feb 2014 09:01:08 -0500 (EST)
Subject: [keycloak-dev] default themes all set?
In-Reply-To: <408669074.6482514.1392306608746.JavaMail.zimbra@redhat.com>
References: <52FCE7B9.1020602@redhat.com>
	<408669074.6482514.1392306608746.JavaMail.zimbra@redhat.com>
Message-ID: <1924143674.7329283.1392386468299.JavaMail.zimbra@redhat.com>

Login forms definitively changing a bit to use Patternfly/RCUE styles. Should be able to do most of the work today, and finish off on Monday.

----- 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, 13 February, 2014 3:50:08 PM
> Subject: Re: [keycloak-dev] default themes all set?
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 13 February, 2014 3:41:45 PM
> > Subject: [keycloak-dev] default themes all set?
> > 
> > Can I start redoing some of the screencasts I need to redo?  Or is there
> > still stylesheet/theme work being done?
> 
> Admin console is pretty much done. There may be some minor fixes needed, but
> nothing that would ruin a screencast.
> 
> There may be some changes to login forms though, as I want to investigate if
> it would be possible to use Patternfly styles instead of our own bespoke
> stylesheets there as well.
> 
> > 
> > --
> > 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 Feb 14 18:10:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Feb 2014 18:10:27 -0500
Subject: [keycloak-dev] initial theme feedback
Message-ID: <52FEA263.5070200@redhat.com>

Is it possible to not have the default themes stuffed in a JAR within 
WEB-INF/lib and instead have them exploded within 
standalone/configuration/themes?  Users should be able to view, modify, 
and copy them directly instead of having to download the source.

Is this just a matter of moving the theme templates out of common-themes 
and removing DefaultLoginThemeProvider from 
org.keycloak.freemarker.ThemeProvider file?

I can do this work if you're busy with other stuff.  Do you need a 
screecast created too?
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Feb 14 18:10:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Feb 2014 18:10:53 -0500
Subject: [keycloak-dev] done with my alpha2 work
Message-ID: <52FEA27D.7060308@redhat.com>

docs and screencasts are ready to put up.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon Feb 17 07:12:10 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Feb 2014 07:12:10 -0500 (EST)
Subject: [keycloak-dev] initial theme feedback
In-Reply-To: <52FEA263.5070200@redhat.com>
References: <52FEA263.5070200@redhat.com>
Message-ID: <859667033.8385087.1392639130558.JavaMail.zimbra@redhat.com>

There is reasoning behind not having the default themes exploded in standalone/configuration/themes:

* Default themes should not be modified or deleted
* You don't need those files unless you're overriding templates. That's an "advanced feature", so I believe users that wants to do that can extract them from source files or jar without difficulty
* If you're just styling the current templates, you do not need to refer to the files from the default themes
* I didn't want to always require a theme folder
* On LiveOak I want the default themes loaded by class-path, and we'll probably let users upload custom themes to mongo-fs rather than the file-system

That being said, if you really, really want to have these themes in the standalone/configuration/themes that's should be possible by copying them in there from the jar when building the dist. The "folder provider" now has a higher priority than the "classpath provider", so if a theme with the same name exists both places it will be loaded from the "folder provider".

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 14 February, 2014 11:10:27 PM
> Subject: [keycloak-dev] initial theme feedback
> 
> Is it possible to not have the default themes stuffed in a JAR within
> WEB-INF/lib and instead have them exploded within
> standalone/configuration/themes?  Users should be able to view, modify,
> and copy them directly instead of having to download the source.
> 
> Is this just a matter of moving the theme templates out of common-themes
> and removing DefaultLoginThemeProvider from
> org.keycloak.freemarker.ThemeProvider file?
> 
> I can do this work if you're busy with other stuff.  Do you need a
> screecast created 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 Feb 17 07:59:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Feb 2014 07:59:27 -0500 (EST)
Subject: [keycloak-dev] done with my alpha2 work
In-Reply-To: <52FEA27D.7060308@redhat.com>
References: <52FEA27D.7060308@redhat.com>
Message-ID: <50669916.8413283.1392641967138.JavaMail.zimbra@redhat.com>

Theme work is done. There's still a bit of work left on testing for MySQL/PostgreSQL, but Marek says he'll finish that today.

While working on themes I've spotted some issues around SSO, I'm going to look at that today.

We should be able to release alpha2 this week.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 14 February, 2014 11:10:53 PM
> Subject: [keycloak-dev] done with my alpha2 work
> 
> docs and screencasts are ready to put up.
> --
> 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 mposolda at redhat.com  Tue Feb 18 05:48:32 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 18 Feb 2014 11:48:32 +0100
Subject: [keycloak-dev] done with my alpha2 work
In-Reply-To: <50669916.8413283.1392641967138.JavaMail.zimbra@redhat.com>
References: <52FEA27D.7060308@redhat.com>
	<50669916.8413283.1392641967138.JavaMail.zimbra@redhat.com>
Message-ID: <53033A80.8090609@redhat.com>

On 17.2.2014 13:59, Stian Thorgersen wrote:
> Theme work is done. There's still a bit of work left on testing for MySQL/PostgreSQL, but Marek says he'll finish that today.
I've sent PR here https://github.com/keycloak/keycloak/pull/217 . So 
right now both JPA and Mongo model are using UUID instead of 
autogenerated IDs. And all unit tests + testsuite are passing with H2, 
Mongo, MySQL and PostgreSQL. I've also tested Wildfly distribution with 
KeycloakDS as MySQL datasource and works well!

Bad thing is, that I have some issues with Oracle11g right now. It's 
about long identifiers (At this moment, I am not yet sure if it's ID of 
entities or length of tables or indexes). I will continue in the 
afternoon with investigation and planning to test other DBs as well (MS 
SQL, IBM DB2, maybe Sybase). Do you want all databases to work in 
Alpha-2? If not, it could be postponed to Alpha-3, which means that I 
don't have anything pending in Alpha-2.


Marek
>
> While working on themes I've spotted some issues around SSO, I'm going to look at that today.
>
> We should be able to release alpha2 this week.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 14 February, 2014 11:10:53 PM
>> Subject: [keycloak-dev] done with my alpha2 work
>>
>> docs and screencasts are ready to put up.
>> --
>> 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 Feb 18 06:03:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Feb 2014 06:03:03 -0500 (EST)
Subject: [keycloak-dev] done with my alpha2 work
In-Reply-To: <53033A80.8090609@redhat.com>
References: <52FEA27D.7060308@redhat.com>
	<50669916.8413283.1392641967138.JavaMail.zimbra@redhat.com>
	<53033A80.8090609@redhat.com>
Message-ID: <1892284253.9161354.1392721383405.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 February, 2014 10:48:32 AM
> Subject: Re: [keycloak-dev] done with my alpha2 work
> 
> On 17.2.2014 13:59, Stian Thorgersen wrote:
> > Theme work is done. There's still a bit of work left on testing for
> > MySQL/PostgreSQL, but Marek says he'll finish that today.
> I've sent PR here https://github.com/keycloak/keycloak/pull/217 . So
> right now both JPA and Mongo model are using UUID instead of
> autogenerated IDs. And all unit tests + testsuite are passing with H2,
> Mongo, MySQL and PostgreSQL. I've also tested Wildfly distribution with
> KeycloakDS as MySQL datasource and works well!
> 
> Bad thing is, that I have some issues with Oracle11g right now. It's
> about long identifiers (At this moment, I am not yet sure if it's ID of
> entities or length of tables or indexes). I will continue in the
> afternoon with investigation and planning to test other DBs as well (MS
> SQL, IBM DB2, maybe Sybase). Do you want all databases to work in
> Alpha-2? If not, it could be postponed to Alpha-3, which means that I
> don't have anything pending in Alpha-2.

Great work :)

Merged - please have a look at Oracle and see if you can fix it. Could it be as simple as adding "@Column(length = 32)"?

With regards to other dbs if it doesn't take to much time, then you can add MS SQL and IBM DB2 (is it still popular?). We can probably leave Sybase until/if someone asks for it.

> 
> 
> Marek
> >
> > While working on themes I've spotted some issues around SSO, I'm going to
> > look at that today.
> >
> > We should be able to release alpha2 this week.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 14 February, 2014 11:10:53 PM
> >> Subject: [keycloak-dev] done with my alpha2 work
> >>
> >> docs and screencasts are ready to put up.
> >> --
> >> 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 Feb 18 07:16:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Feb 2014 07:16:20 -0500 (EST)
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <1764069427.9864093.1392725212090.JavaMail.zimbra@redhat.com>
Message-ID: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>

I've just tried out deploying the demo manually using the WildFly subsystem. It's very cool and I really like how the WildFly subsystem has made things so much simpler. Some comments though on my "experience" trying this out.

1. Having to edit standalone.xml to add secure-deployment requires restarting the server. In installation tab we could have an additional option that lists the jboss-cli command to add this at runtime

2. Customer portal error messages are horrible at best. First I forgot to deploy the database services, which caused the exception "Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')". This should have probably been something like "Database services not found". Then I deployed database services, but used the wrong WAR name in the secure-deployment and the error message was the same, but should have been "Unauthorized".

3. Finally, it's not clear enough in the log output when the Keycloak sub-system acts on a deployment and when it doesn't. We definitively need something along the lines of:

   INFO [org.keycloak.wildfly] Keycloak configured for 'customer-portal.war'

   Could also be an idea to add (not sure if it should be info or debug):

   DEBUG [org.keycloak.wildfly] Ignoring 'customer-portal.war'

From ssilvert at redhat.com  Tue Feb 18 07:44:08 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 18 Feb 2014 07:44:08 -0500
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
Message-ID: <53035598.3060509@redhat.com>

On 2/18/2014 7:16 AM, Stian Thorgersen wrote:
> I've just tried out deploying the demo manually using the WildFly subsystem. It's very cool and I really like how the WildFly subsystem has made things so much simpler. Some comments though on my "experience" trying this out.
>
> 1. Having to edit standalone.xml to add secure-deployment requires restarting the server. In installation tab we could have an additional option that lists the jboss-cli command to add this at runtime
Yes, it's usually easier and more accurate to run a CLI script instead 
of editing standalone.xml by hand.  Using CLI also allows you to make 
the update remotely when you might not have access to the remote file 
system.

When we get everything integrated a little tighter then the admin 
console will be able to make the changes directly to WildFly without 
involving standalone.xml or CLI.
>
> 2. Customer portal error messages are horrible at best. First I forgot to deploy the database services, which caused the exception "Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')". This should have probably been something like "Database services not found". Then I deployed database services, but used the wrong WAR name in the secure-deployment and the error message was the same, but should have been "Unauthorized".
>
> 3. Finally, it's not clear enough in the log output when the Keycloak sub-system acts on a deployment and when it doesn't. We definitively need something along the lines of:
>
>     INFO [org.keycloak.wildfly] Keycloak configured for 'customer-portal.war'
+1
>     Could also be an idea to add (not sure if it should be info or debug):
>
>     DEBUG [org.keycloak.wildfly] Ignoring 'customer-portal.war'
Definitely DEBUG.  Always remember that log messages add to startup time 
and certain people on the WildFly team get (understandably) grumpy when 
you affect that in any way.

I do think we can justify the "Keycloak configured" message though. That 
one seems pretty important.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Tue Feb 18 09:32:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 09:32:34 -0500
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
Message-ID: <53036F02.4070909@redhat.com>

Sorry, took a vacation day yesterday.  had some friends from Denmark 
here in the US and we went skiing locally...

On 2/18/2014 7:16 AM, Stian Thorgersen wrote:
> I've just tried out deploying the demo manually using the WildFly subsystem. It's very cool and I really like how the WildFly subsystem has made things so much simpler. Some comments though on my "experience" trying this out.
>
> 1. Having to edit standalone.xml to add secure-deployment requires restarting the server. In installation tab we could have an additional option that lists the jboss-cli command to add this at runtime
>

Ugh, I forgot to mention you needed to restart in the doco.

Also, if you remember, I was going to add an option in keycloak that 
allowed the admin console to remotely set up this config.  But, on 
second thought, this requires setting up an admin on the wildfly 
instance.  It actually seems easier to just cut and paste from the admin 
console window to standalone.xml and restart the server.  I don't think 
you're going to be securing live systems.


> 2. Customer portal error messages are horrible at best. First I forgot to deploy the database services, which caused the exception "Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')". This should have probably been something like "Database services not found". Then I deployed database services, but used the wrong WAR name in the secure-deployment and the error message was the same, but should have been "Unauthorized".
>

Long standing issue.  I'll fix that.

> 3. Finally, it's not clear enough in the log output when the Keycloak sub-system acts on a deployment and when it doesn't. We definitively need something along the lines of:
>

Ok, i'll add that.


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

From bburke at redhat.com  Tue Feb 18 09:44:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 09:44:41 -0500
Subject: [keycloak-dev] initial theme feedback
In-Reply-To: <859667033.8385087.1392639130558.JavaMail.zimbra@redhat.com>
References: <52FEA263.5070200@redhat.com>
	<859667033.8385087.1392639130558.JavaMail.zimbra@redhat.com>
Message-ID: <530371D9.2070200@redhat.com>

Eventually, I hope our users will be non-Java developers.  Extracting 
from source files or jars may be beyond them.  Pointing the user to a 
git repo to get sample themes is just unacceptable.  A user is not going 
to know how to create a theme or modify a theme without getting access 
to the source.

Maybe I'll just extract the default theme into a file copy in the 
distro.  It will be provided as an option in the admin console and 
tutorials/docs will point to that template theme folder for users to 
play with.

On 2/17/2014 7:12 AM, Stian Thorgersen wrote:
> There is reasoning behind not having the default themes exploded in standalone/configuration/themes:
>
> * Default themes should not be modified or deleted
> * You don't need those files unless you're overriding templates. That's an "advanced feature", so I believe users that wants to do that can extract them from source files or jar without difficulty
> * If you're just styling the current templates, you do not need to refer to the files from the default themes
> * I didn't want to always require a theme folder
> * On LiveOak I want the default themes loaded by class-path, and we'll probably let users upload custom themes to mongo-fs rather than the file-system
>
> That being said, if you really, really want to have these themes in the standalone/configuration/themes that's should be possible by copying them in there from the jar when building the dist. The "folder provider" now has a higher priority than the "classpath provider", so if a theme with the same name exists both places it will be loaded from the "folder provider".
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 14 February, 2014 11:10:27 PM
>> Subject: [keycloak-dev] initial theme feedback
>>
>> Is it possible to not have the default themes stuffed in a JAR within
>> WEB-INF/lib and instead have them exploded within
>> standalone/configuration/themes?  Users should be able to view, modify,
>> and copy them directly instead of having to download the source.
>>
>> Is this just a matter of moving the theme templates out of common-themes
>> and removing DefaultLoginThemeProvider from
>> org.keycloak.freemarker.ThemeProvider file?
>>
>> I can do this work if you're busy with other stuff.  Do you need a
>> screecast created 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
>>

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

From bburke at redhat.com  Tue Feb 18 09:45:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 09:45:32 -0500
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <53035598.3060509@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
	<53035598.3060509@redhat.com>
Message-ID: <5303720C.5080903@redhat.com>



On 2/18/2014 7:44 AM, Stan Silvert wrote:
> On 2/18/2014 7:16 AM, Stian Thorgersen wrote:
>> I've just tried out deploying the demo manually using the WildFly subsystem. It's very cool and I really like how the WildFly subsystem has made things so much simpler. Some comments though on my "experience" trying this out.
>>
>> 1. Having to edit standalone.xml to add secure-deployment requires restarting the server. In installation tab we could have an additional option that lists the jboss-cli command to add this at runtime
> Yes, it's usually easier and more accurate to run a CLI script instead
> of editing standalone.xml by hand.  Using CLI also allows you to make
> the update remotely when you might not have access to the remote file
> system.
>

Stan.  I actually kinda (not wholeheartedly) disagree.  To run the CLI 
requires setting up a local user to administrate the server.  Its 
actually easier to cut, paste, and restart, IMO.



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

From bburke at redhat.com  Tue Feb 18 09:51:18 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 09:51:18 -0500
Subject: [keycloak-dev] done with my alpha2 work
In-Reply-To: <53033A80.8090609@redhat.com>
References: <52FEA27D.7060308@redhat.com>
	<50669916.8413283.1392641967138.JavaMail.zimbra@redhat.com>
	<53033A80.8090609@redhat.com>
Message-ID: <53037366.6050200@redhat.com>



On 2/18/2014 5:48 AM, Marek Posolda wrote:
> On 17.2.2014 13:59, Stian Thorgersen wrote:
>> Theme work is done. There's still a bit of work left on testing for
>> MySQL/PostgreSQL, but Marek says he'll finish that today.
> I've sent PR here https://github.com/keycloak/keycloak/pull/217 . So
> right now both JPA and Mongo model are using UUID instead of
> autogenerated IDs. And all unit tests + testsuite are passing with H2,
> Mongo, MySQL and PostgreSQL. I've also tested Wildfly distribution with
> KeycloakDS as MySQL datasource and works well!
>
> Bad thing is, that I have some issues with Oracle11g right now. It's
> about long identifiers (At this moment, I am not yet sure if it's ID of
> entities or length of tables or indexes). I will continue in the
> afternoon with investigation and planning to test other DBs as well (MS
> SQL, IBM DB2, maybe Sybase). Do you want all databases to work in
> Alpha-2? If not, it could be postponed to Alpha-3, which means that I
> don't have anything pending in Alpha-2.
>

Thanks Marek!

Bill

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

From stian at redhat.com  Tue Feb 18 09:51:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Feb 2014 09:51:41 -0500 (EST)
Subject: [keycloak-dev] initial theme feedback
In-Reply-To: <530371D9.2070200@redhat.com>
References: <52FEA263.5070200@redhat.com>
	<859667033.8385087.1392639130558.JavaMail.zimbra@redhat.com>
	<530371D9.2070200@redhat.com>
Message-ID: <2059797642.9990831.1392735101373.JavaMail.zimbra@redhat.com>

One idea is that we can create an example theme users can start with. It could be placed in examples/themes and created by copying templates/messages from base + probably a very basic stylesheet.

----- 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, 18 February, 2014 2:44:41 PM
> Subject: Re: [keycloak-dev] initial theme feedback
> 
> Eventually, I hope our users will be non-Java developers.  Extracting
> from source files or jars may be beyond them.  Pointing the user to a
> git repo to get sample themes is just unacceptable.  A user is not going
> to know how to create a theme or modify a theme without getting access
> to the source.
> 
> Maybe I'll just extract the default theme into a file copy in the
> distro.  It will be provided as an option in the admin console and
> tutorials/docs will point to that template theme folder for users to
> play with.
> 
> On 2/17/2014 7:12 AM, Stian Thorgersen wrote:
> > There is reasoning behind not having the default themes exploded in
> > standalone/configuration/themes:
> >
> > * Default themes should not be modified or deleted
> > * You don't need those files unless you're overriding templates. That's an
> > "advanced feature", so I believe users that wants to do that can extract
> > them from source files or jar without difficulty
> > * If you're just styling the current templates, you do not need to refer to
> > the files from the default themes
> > * I didn't want to always require a theme folder
> > * On LiveOak I want the default themes loaded by class-path, and we'll
> > probably let users upload custom themes to mongo-fs rather than the
> > file-system
> >
> > That being said, if you really, really want to have these themes in the
> > standalone/configuration/themes that's should be possible by copying them
> > in there from the jar when building the dist. The "folder provider" now
> > has a higher priority than the "classpath provider", so if a theme with
> > the same name exists both places it will be loaded from the "folder
> > provider".
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 14 February, 2014 11:10:27 PM
> >> Subject: [keycloak-dev] initial theme feedback
> >>
> >> Is it possible to not have the default themes stuffed in a JAR within
> >> WEB-INF/lib and instead have them exploded within
> >> standalone/configuration/themes?  Users should be able to view, modify,
> >> and copy them directly instead of having to download the source.
> >>
> >> Is this just a matter of moving the theme templates out of common-themes
> >> and removing DefaultLoginThemeProvider from
> >> org.keycloak.freemarker.ThemeProvider file?
> >>
> >> I can do this work if you're busy with other stuff.  Do you need a
> >> screecast created 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From ssilvert at redhat.com  Tue Feb 18 10:47:27 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 18 Feb 2014 10:47:27 -0500
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <5303720C.5080903@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
	<53035598.3060509@redhat.com> <5303720C.5080903@redhat.com>
Message-ID: <5303808F.4060406@redhat.com>

On 2/18/2014 9:45 AM, Bill Burke wrote:
>
> On 2/18/2014 7:44 AM, Stan Silvert wrote:
>> On 2/18/2014 7:16 AM, Stian Thorgersen wrote:
>>> I've just tried out deploying the demo manually using the WildFly subsystem. It's very cool and I really like how the WildFly subsystem has made things so much simpler. Some comments though on my "experience" trying this out.
>>>
>>> 1. Having to edit standalone.xml to add secure-deployment requires restarting the server. In installation tab we could have an additional option that lists the jboss-cli command to add this at runtime
>> Yes, it's usually easier and more accurate to run a CLI script instead
>> of editing standalone.xml by hand.  Using CLI also allows you to make
>> the update remotely when you might not have access to the remote file
>> system.
>>
> Stan.  I actually kinda (not wholeheartedly) disagree.  To run the CLI
> requires setting up a local user to administrate the server.  Its
> actually easier to cut, paste, and restart, IMO.
If you are local then CLI does not require setting up a user.  Web 
console requires it, but CLI does not.

If you are remote then I'm sure you agree that CLI is better since it is 
that much harder to edit a remote file.

Granted, there is more work to do in this area to make it even easier.  
One thing you could do is create a CLI script along with a *.sh or *.bat 
file to launch it.  Tell the user to save it to JBOSS_HOME/bin.  Then 
you can update the server quickly and accurately with a single click.
>
>
>


From bburke at redhat.com  Tue Feb 18 10:53:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 10:53:38 -0500
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <5303808F.4060406@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>	<53035598.3060509@redhat.com>
	<5303720C.5080903@redhat.com> <5303808F.4060406@redhat.com>
Message-ID: <53038202.9040306@redhat.com>



On 2/18/2014 10:47 AM, Stan Silvert wrote:
> On 2/18/2014 9:45 AM, Bill Burke wrote:
>>
>> On 2/18/2014 7:44 AM, Stan Silvert wrote:
>>> On 2/18/2014 7:16 AM, Stian Thorgersen wrote:
>>>> I've just tried out deploying the demo manually using the WildFly subsystem. It's very cool and I really like how the WildFly subsystem has made things so much simpler. Some comments though on my "experience" trying this out.
>>>>
>>>> 1. Having to edit standalone.xml to add secure-deployment requires restarting the server. In installation tab we could have an additional option that lists the jboss-cli command to add this at runtime
>>> Yes, it's usually easier and more accurate to run a CLI script instead
>>> of editing standalone.xml by hand.  Using CLI also allows you to make
>>> the update remotely when you might not have access to the remote file
>>> system.
>>>
>> Stan.  I actually kinda (not wholeheartedly) disagree.  To run the CLI
>> requires setting up a local user to administrate the server.  Its
>> actually easier to cut, paste, and restart, IMO.
> If you are local then CLI does not require setting up a user.  Web
> console requires it, but CLI does not.
>
> If you are remote then I'm sure you agree that CLI is better since it is
> that much harder to edit a remote file.
>

I just can't see (yet) anybody securing a system remotely.  Even in the 
Openshift case, its a real pain to do anything with a subsystem remotely 
as you have to do port mapping to expose the admin HTTP interface, and 
also set up a admin user (which I don't think can be done without 
hardcoding initial credentials).

> Granted, there is more work to do in this area to make it even easier.
> One thing you could do is create a CLI script along with a *.sh or *.bat
> file to launch it.  Tell the user to save it to JBOSS_HOME/bin.  Then
> you can update the server quickly and accurately with a single click.

Or, they could just cut and paste the XML from the admin console to 
standalone.xml...which is, still...IMO...faster, simpler, and easier?


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

From bburke at redhat.com  Tue Feb 18 10:57:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 10:57:15 -0500
Subject: [keycloak-dev] migration docs
Message-ID: <530382DB.9060706@redhat.com>

In the docbook, there is a MigrationFromOlderVersions.xml.  Please edit 
this with things that may be different between alpha 1 and alpha2.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Feb 18 11:00:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Feb 2014 11:00:04 -0500 (EST)
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <53038202.9040306@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
	<53035598.3060509@redhat.com> <5303720C.5080903@redhat.com>
	<5303808F.4060406@redhat.com> <53038202.9040306@redhat.com>
Message-ID: <647451947.10096166.1392739204155.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 February, 2014 3:53:38 PM
> Subject: Re: [keycloak-dev] WildFly subsystem and demo
> 
> 
> 
> On 2/18/2014 10:47 AM, Stan Silvert wrote:
> > On 2/18/2014 9:45 AM, Bill Burke wrote:
> >>
> >> On 2/18/2014 7:44 AM, Stan Silvert wrote:
> >>> On 2/18/2014 7:16 AM, Stian Thorgersen wrote:
> >>>> I've just tried out deploying the demo manually using the WildFly
> >>>> subsystem. It's very cool and I really like how the WildFly subsystem
> >>>> has made things so much simpler. Some comments though on my
> >>>> "experience" trying this out.
> >>>>
> >>>> 1. Having to edit standalone.xml to add secure-deployment requires
> >>>> restarting the server. In installation tab we could have an additional
> >>>> option that lists the jboss-cli command to add this at runtime
> >>> Yes, it's usually easier and more accurate to run a CLI script instead
> >>> of editing standalone.xml by hand.  Using CLI also allows you to make
> >>> the update remotely when you might not have access to the remote file
> >>> system.
> >>>
> >> Stan.  I actually kinda (not wholeheartedly) disagree.  To run the CLI
> >> requires setting up a local user to administrate the server.  Its
> >> actually easier to cut, paste, and restart, IMO.
> > If you are local then CLI does not require setting up a user.  Web
> > console requires it, but CLI does not.
> >
> > If you are remote then I'm sure you agree that CLI is better since it is
> > that much harder to edit a remote file.
> >
> 
> I just can't see (yet) anybody securing a system remotely.  Even in the
> Openshift case, its a real pain to do anything with a subsystem remotely
> as you have to do port mapping to expose the admin HTTP interface, and
> also set up a admin user (which I don't think can be done without
> hardcoding initial credentials).

The WF cartridge we forked actually creates a admin user and prints out the username/password when you first create it. Not sure if the "official" WF cartridge does the same though.

One solution could be to have "deployable" config files in the same way as you can put "-ds.xml" files in standalone/deployment. That could be simpler for OpenShift at least. Basically you'd:

1. Create KC cartridge
2. Open admin console, create the app, download a "myapp-keycloak.xml"
3. Add "myapp-keycloak.xml" and your war to deployments and git push to redeploy it

> 
> > Granted, there is more work to do in this area to make it even easier.
> > One thing you could do is create a CLI script along with a *.sh or *.bat
> > file to launch it.  Tell the user to save it to JBOSS_HOME/bin.  Then
> > you can update the server quickly and accurately with a single click.
> 
> Or, they could just cut and paste the XML from the admin console to
> standalone.xml...which is, still...IMO...faster, simpler, and easier?
> 
> 
> --
> 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 Feb 18 11:02:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Feb 2014 11:02:24 -0500 (EST)
Subject: [keycloak-dev] migration docs
In-Reply-To: <530382DB.9060706@redhat.com>
References: <530382DB.9060706@redhat.com>
Message-ID: <1231376398.10097615.1392739344791.JavaMail.zimbra@redhat.com>

DB schema ;)

For the future I though a simple way to update the DB would be to add an option to export the whole db to json. Then you just install a new fresh server, and import the db again. It's simpler than having to provide instructions on how to update the DB schema (which would be different for each db) and I don't think we can rely on Hibernates autoddl update feature for production dbs.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 February, 2014 3:57:15 PM
> Subject: [keycloak-dev] migration docs
> 
> In the docbook, there is a MigrationFromOlderVersions.xml.  Please edit
> this with things that may be different between alpha 1 and alpha2.
> --
> 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 Feb 18 11:10:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 11:10:12 -0500
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <647451947.10096166.1392739204155.JavaMail.zimbra@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
	<53035598.3060509@redhat.com> <5303720C.5080903@redhat.com>
	<5303808F.4060406@redhat.com> <53038202.9040306@redhat.com>
	<647451947.10096166.1392739204155.JavaMail.zimbra@redhat.com>
Message-ID: <530385E4.4060704@redhat.com>



On 2/18/2014 11:00 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 18 February, 2014 3:53:38 PM
>> Subject: Re: [keycloak-dev] WildFly subsystem and demo
>>
>>
>>
>> On 2/18/2014 10:47 AM, Stan Silvert wrote:
>>> On 2/18/2014 9:45 AM, Bill Burke wrote:
>>>>
>>>> On 2/18/2014 7:44 AM, Stan Silvert wrote:
>>>>> On 2/18/2014 7:16 AM, Stian Thorgersen wrote:
>>>>>> I've just tried out deploying the demo manually using the WildFly
>>>>>> subsystem. It's very cool and I really like how the WildFly subsystem
>>>>>> has made things so much simpler. Some comments though on my
>>>>>> "experience" trying this out.
>>>>>>
>>>>>> 1. Having to edit standalone.xml to add secure-deployment requires
>>>>>> restarting the server. In installation tab we could have an additional
>>>>>> option that lists the jboss-cli command to add this at runtime
>>>>> Yes, it's usually easier and more accurate to run a CLI script instead
>>>>> of editing standalone.xml by hand.  Using CLI also allows you to make
>>>>> the update remotely when you might not have access to the remote file
>>>>> system.
>>>>>
>>>> Stan.  I actually kinda (not wholeheartedly) disagree.  To run the CLI
>>>> requires setting up a local user to administrate the server.  Its
>>>> actually easier to cut, paste, and restart, IMO.
>>> If you are local then CLI does not require setting up a user.  Web
>>> console requires it, but CLI does not.
>>>
>>> If you are remote then I'm sure you agree that CLI is better since it is
>>> that much harder to edit a remote file.
>>>
>>
>> I just can't see (yet) anybody securing a system remotely.  Even in the
>> Openshift case, its a real pain to do anything with a subsystem remotely
>> as you have to do port mapping to expose the admin HTTP interface, and
>> also set up a admin user (which I don't think can be done without
>> hardcoding initial credentials).
>
> The WF cartridge we forked actually creates a admin user and prints out the username/password when you first create it. Not sure if the "official" WF cartridge does the same though.
>

So you can have a custom "install script" for a cartridge that runs? 
That makes things easier.  But you still have to set up port mapping to 
expose the admin ports.

> One solution could be to have "deployable" config files in the same way as you can put "-ds.xml" files in standalone/deployment. That could be simpler for OpenShift at least. Basically you'd:
>
> 1. Create KC cartridge
> 2. Open admin console, create the app, download a "myapp-keycloak.xml"
> 3. Add "myapp-keycloak.xml" and your war to deployments and git push to redeploy it
>

Why wouldn't you just crack open the war and put in keycloak.json?

We need to figure out bootstrapping for Aerogear.  That is a separate 
email thread I started a week or so ago.  This is a case where the app 
being secured by keycloak is based on Wildfly, but you don't want to 
require the admins to actually know it is based on wildfly.


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

From bburke at redhat.com  Tue Feb 18 11:13:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 11:13:44 -0500
Subject: [keycloak-dev] migration docs
In-Reply-To: <1231376398.10097615.1392739344791.JavaMail.zimbra@redhat.com>
References: <530382DB.9060706@redhat.com>
	<1231376398.10097615.1392739344791.JavaMail.zimbra@redhat.com>
Message-ID: <530386B8.1050801@redhat.com>

We discussed export before and I think its on the roadmap.  Export could 
only be done locally to the machine where the server is installed so 
only those that have access to the machine can get the export.  I was 
also thinking that when the export is initiated, the admin provides a 
password that would be used to encrypt the export.  The only thing I 
worry about is how long it would take to externalize to disk and encrypt.

On 2/18/2014 11:02 AM, Stian Thorgersen wrote:
> DB schema ;)
>
> For the future I though a simple way to update the DB would be to add an option to export the whole db to json. Then you just install a new fresh server, and import the db again. It's simpler than having to provide instructions on how to update the DB schema (which would be different for each db) and I don't think we can rely on Hibernates autoddl update feature for production dbs.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 18 February, 2014 3:57:15 PM
>> Subject: [keycloak-dev] migration docs
>>
>> In the docbook, there is a MigrationFromOlderVersions.xml.  Please edit
>> this with things that may be different between alpha 1 and alpha2.
>> --
>> 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  Tue Feb 18 11:24:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Feb 2014 11:24:48 -0500 (EST)
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <530385E4.4060704@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
	<53035598.3060509@redhat.com> <5303720C.5080903@redhat.com>
	<5303808F.4060406@redhat.com> <53038202.9040306@redhat.com>
	<647451947.10096166.1392739204155.JavaMail.zimbra@redhat.com>
	<530385E4.4060704@redhat.com>
Message-ID: <1471435077.10117697.1392740688030.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, 18 February, 2014 4:10:12 PM
> Subject: Re: [keycloak-dev] WildFly subsystem and demo
> 
> 
> 
> On 2/18/2014 11:00 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 18 February, 2014 3:53:38 PM
> >> Subject: Re: [keycloak-dev] WildFly subsystem and demo
> >>
> >>
> >>
> >> On 2/18/2014 10:47 AM, Stan Silvert wrote:
> >>> On 2/18/2014 9:45 AM, Bill Burke wrote:
> >>>>
> >>>> On 2/18/2014 7:44 AM, Stan Silvert wrote:
> >>>>> On 2/18/2014 7:16 AM, Stian Thorgersen wrote:
> >>>>>> I've just tried out deploying the demo manually using the WildFly
> >>>>>> subsystem. It's very cool and I really like how the WildFly subsystem
> >>>>>> has made things so much simpler. Some comments though on my
> >>>>>> "experience" trying this out.
> >>>>>>
> >>>>>> 1. Having to edit standalone.xml to add secure-deployment requires
> >>>>>> restarting the server. In installation tab we could have an additional
> >>>>>> option that lists the jboss-cli command to add this at runtime
> >>>>> Yes, it's usually easier and more accurate to run a CLI script instead
> >>>>> of editing standalone.xml by hand.  Using CLI also allows you to make
> >>>>> the update remotely when you might not have access to the remote file
> >>>>> system.
> >>>>>
> >>>> Stan.  I actually kinda (not wholeheartedly) disagree.  To run the CLI
> >>>> requires setting up a local user to administrate the server.  Its
> >>>> actually easier to cut, paste, and restart, IMO.
> >>> If you are local then CLI does not require setting up a user.  Web
> >>> console requires it, but CLI does not.
> >>>
> >>> If you are remote then I'm sure you agree that CLI is better since it is
> >>> that much harder to edit a remote file.
> >>>
> >>
> >> I just can't see (yet) anybody securing a system remotely.  Even in the
> >> Openshift case, its a real pain to do anything with a subsystem remotely
> >> as you have to do port mapping to expose the admin HTTP interface, and
> >> also set up a admin user (which I don't think can be done without
> >> hardcoding initial credentials).
> >
> > The WF cartridge we forked actually creates a admin user and prints out the
> > username/password when you first create it. Not sure if the "official" WF
> > cartridge does the same though.
> >
> 
> So you can have a custom "install script" for a cartridge that runs?
> That makes things easier.  But you still have to set up port mapping to
> expose the admin ports.

Yes, it's just a bunch of bash scripts. I was going to use this as a way of automatically configuring the db. When you create KC you can choose to add the MySQL or PostgreSQL add-on cartridges, and on first startup it would detect if one is available and automatically re-configure the db.

> 
> > One solution could be to have "deployable" config files in the same way as
> > you can put "-ds.xml" files in standalone/deployment. That could be
> > simpler for OpenShift at least. Basically you'd:
> >
> > 1. Create KC cartridge
> > 2. Open admin console, create the app, download a "myapp-keycloak.xml"
> > 3. Add "myapp-keycloak.xml" and your war to deployments and git push to
> > redeploy it
> >
> 
> Why wouldn't you just crack open the war and put in keycloak.json?

Because you need to crack it open. Also, for the future if you change the config in KC, or you make some updates to your war, you're required to do it again.

IMO config should never ever be inside a WAR ;)

> 
> We need to figure out bootstrapping for Aerogear.  That is a separate
> email thread I started a week or so ago.  This is a case where the app
> being secured by keycloak is based on Wildfly, but you don't want to
> require the admins to actually know it is based on wildfly.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Tue Feb 18 17:37:12 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 18 Feb 2014 23:37:12 +0100
Subject: [keycloak-dev] done with my alpha2 work
In-Reply-To: <1892284253.9161354.1392721383405.JavaMail.zimbra@redhat.com>
References: <52FEA27D.7060308@redhat.com>
	<50669916.8413283.1392641967138.JavaMail.zimbra@redhat.com>
	<53033A80.8090609@redhat.com>
	<1892284253.9161354.1392721383405.JavaMail.zimbra@redhat.com>
Message-ID: <5303E098.60408@redhat.com>

On 18.2.2014 12:03, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 18 February, 2014 10:48:32 AM
>> Subject: Re: [keycloak-dev] done with my alpha2 work
>>
>> On 17.2.2014 13:59, Stian Thorgersen wrote:
>>> Theme work is done. There's still a bit of work left on testing for
>>> MySQL/PostgreSQL, but Marek says he'll finish that today.
>> I've sent PR here https://github.com/keycloak/keycloak/pull/217 . So
>> right now both JPA and Mongo model are using UUID instead of
>> autogenerated IDs. And all unit tests + testsuite are passing with H2,
>> Mongo, MySQL and PostgreSQL. I've also tested Wildfly distribution with
>> KeycloakDS as MySQL datasource and works well!
>>
>> Bad thing is, that I have some issues with Oracle11g right now. It's
>> about long identifiers (At this moment, I am not yet sure if it's ID of
>> entities or length of tables or indexes). I will continue in the
>> afternoon with investigation and planning to test other DBs as well (MS
>> SQL, IBM DB2, maybe Sybase). Do you want all databases to work in
>> Alpha-2? If not, it could be postponed to Alpha-3, which means that I
>> don't have anything pending in Alpha-2.
> Great work :)
>
> Merged - please have a look at Oracle and see if you can fix it. Could it be as simple as adding "@Column(length = 32)"?
Sent https://github.com/keycloak/keycloak/pull/221 , which fixes Oracle 
and Sybase. Both allow length of columns and tables to be max 30 
characters, so I needed to rename some to have shorter names. Still have 
some issues with MSSQL2012 and IBM DB2. In MSSQL2012 just one test is 
failing, so I am quite close but definitely don't want to block a 
release:-)

Will look at it again tomorrow.
>
> With regards to other dbs if it doesn't take to much time, then you can add MS SQL and IBM DB2 (is it still popular?). We can probably leave Sybase until/if someone asks for it.
>
>>
>> Marek
>>> While working on themes I've spotted some issues around SSO, I'm going to
>>> look at that today.
>>>
>>> We should be able to release alpha2 this week.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 14 February, 2014 11:10:53 PM
>>>> Subject: [keycloak-dev] done with my alpha2 work
>>>>
>>>> docs and screencasts are ready to put up.
>>>> --
>>>> 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 Feb 18 19:07:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 19:07:25 -0500
Subject: [keycloak-dev] initial theme feedback
In-Reply-To: <2059797642.9990831.1392735101373.JavaMail.zimbra@redhat.com>
References: <52FEA263.5070200@redhat.com>
	<859667033.8385087.1392639130558.JavaMail.zimbra@redhat.com>
	<530371D9.2070200@redhat.com>
	<2059797642.9990831.1392735101373.JavaMail.zimbra@redhat.com>
Message-ID: <5303F5BD.7000300@redhat.com>

This is what I did.

Appliance contains both the sunset theme and also a "template" theme 
exploded in standalone/configuration.  The WAR distro has a zip file in 
examples/ which can be unzipped in the standalone/configuration 
directory of the server the user has installed Keycloak on.

The "template" theme is a combination of the base and patternfly themes 
(no inheritance).  This allows users to see, edit, and play with all 
files which make up a theme for both login and account.

BTW, Stian, these themes are really really cool.

On 2/18/2014 9:51 AM, Stian Thorgersen wrote:
> One idea is that we can create an example theme users can start with. It could be placed in examples/themes and created by copying templates/messages from base + probably a very basic stylesheet.
>
> ----- 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, 18 February, 2014 2:44:41 PM
>> Subject: Re: [keycloak-dev] initial theme feedback
>>
>> Eventually, I hope our users will be non-Java developers.  Extracting
>> from source files or jars may be beyond them.  Pointing the user to a
>> git repo to get sample themes is just unacceptable.  A user is not going
>> to know how to create a theme or modify a theme without getting access
>> to the source.
>>
>> Maybe I'll just extract the default theme into a file copy in the
>> distro.  It will be provided as an option in the admin console and
>> tutorials/docs will point to that template theme folder for users to
>> play with.
>>
>> On 2/17/2014 7:12 AM, Stian Thorgersen wrote:
>>> There is reasoning behind not having the default themes exploded in
>>> standalone/configuration/themes:
>>>
>>> * Default themes should not be modified or deleted
>>> * You don't need those files unless you're overriding templates. That's an
>>> "advanced feature", so I believe users that wants to do that can extract
>>> them from source files or jar without difficulty
>>> * If you're just styling the current templates, you do not need to refer to
>>> the files from the default themes
>>> * I didn't want to always require a theme folder
>>> * On LiveOak I want the default themes loaded by class-path, and we'll
>>> probably let users upload custom themes to mongo-fs rather than the
>>> file-system
>>>
>>> That being said, if you really, really want to have these themes in the
>>> standalone/configuration/themes that's should be possible by copying them
>>> in there from the jar when building the dist. The "folder provider" now
>>> has a higher priority than the "classpath provider", so if a theme with
>>> the same name exists both places it will be loaded from the "folder
>>> provider".
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 14 February, 2014 11:10:27 PM
>>>> Subject: [keycloak-dev] initial theme feedback
>>>>
>>>> Is it possible to not have the default themes stuffed in a JAR within
>>>> WEB-INF/lib and instead have them exploded within
>>>> standalone/configuration/themes?  Users should be able to view, modify,
>>>> and copy them directly instead of having to download the source.
>>>>
>>>> Is this just a matter of moving the theme templates out of common-themes
>>>> and removing DefaultLoginThemeProvider from
>>>> org.keycloak.freemarker.ThemeProvider file?
>>>>
>>>> I can do this work if you're busy with other stuff.  Do you need a
>>>> screecast created 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
>>>>
>>
>> --
>> 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  Tue Feb 18 19:10:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Feb 2014 19:10:34 -0500
Subject: [keycloak-dev] what's left for release?
Message-ID: <5303F67A.1070100@redhat.com>

Where are we at?  I made some minor changes to the demo examples and 
subsystem that you suggested earlier as well as the theme distro changes 
I made that I talked about in the previous email.

Give Marek another day to get MSSQL working?  Release on Thursday?

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

From mposolda at redhat.com  Wed Feb 19 04:02:27 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 19 Feb 2014 10:02:27 +0100
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <53036F02.4070909@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
	<53036F02.4070909@redhat.com>
Message-ID: <53047323.305@redhat.com>

On 18.2.2014 15:32, Bill Burke wrote:
>> Customer portal error messages are horrible at best. First I forgot to deploy the database services, which caused the exception "Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')". This should have probably been something like "Database services not found". Then I deployed database services, but used the wrong WAR name in the secure-deployment and the error message was the same, but should have been "Unauthorized".
>> >
> Long standing issue.  I'll fix that.
>
I've tried distribution yesterday to check it works with databases and 2 
more things related to examples:
- There is minor issue that subsystem-config.xml is in the examples ZIP 
distribution in directory "preconfigured-demo" but should be in 
"unconfigured-demo" IMO because preconfigured-demo already has these 
predefined JSON files for adapter configuration and can work with empty 
subsystem definition.
- It seems that "third-party" and "third-party-cdi" in unconfigured-demo 
doesn't work. Not sure if subsystem will support configuration of 
oauth-clients as well, but right now it doesn't look like that. Now 
these examples always assume that you have keycloak.json file available 
and read configuration from it.

Marek

From stian at redhat.com  Wed Feb 19 06:00:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Feb 2014 06:00:50 -0500 (EST)
Subject: [keycloak-dev] what's left for release?
In-Reply-To: <5303F67A.1070100@redhat.com>
References: <5303F67A.1070100@redhat.com>
Message-ID: <1499773665.10926684.1392807650729.JavaMail.zimbra@redhat.com>


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 19 February, 2014 12:10:34 AM
> Subject: [keycloak-dev] what's left for release?
> 
> Where are we at?  I made some minor changes to the demo examples and
> subsystem that you suggested earlier as well as the theme distro changes
> I made that I talked about in the previous email.
> 
> Give Marek another day to get MSSQL working?  Release on Thursday?

Marek has got MSSQL working, and is adding documentation on how to configure different dbs. He'll also get rid of the keycloak-ds.xml file and instead add KeycloakDS to standalone.xml. That should be done today, so release tomorrow would be good.

I'm was going to write up a blog post on the new features (unless you've already done this?):

* Composite roles
* WildFly subsystem
* Theme support
* Support for MySQL, PostgreSQL, MS-SQL, Sybase and H2 databases
* Mongo store
* JavaScript adapter
* Login with GitHub

Anything I'm missing? Not bad for less than 1 month :)


> 
> --
> 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 Feb 19 09:22:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Feb 2014 09:22:34 -0500
Subject: [keycloak-dev] WildFly subsystem and demo
In-Reply-To: <53047323.305@redhat.com>
References: <1961614969.9869381.1392725780392.JavaMail.zimbra@redhat.com>
	<53036F02.4070909@redhat.com> <53047323.305@redhat.com>
Message-ID: <5304BE2A.5020800@redhat.com>



On 2/19/2014 4:02 AM, Marek Posolda wrote:
> On 18.2.2014 15:32, Bill Burke wrote:
>>> Customer portal error messages are horrible at best. First I forgot
>>> to deploy the database services, which caused the exception
>>> "Unexpected character ('<' (code 60)): expected a valid value
>>> (number, String, array, object, 'true', 'false' or 'null')". This
>>> should have probably been something like "Database services not
>>> found". Then I deployed database services, but used the wrong WAR
>>> name in the secure-deployment and the error message was the same, but
>>> should have been "Unauthorized".
>>> >
>> Long standing issue.  I'll fix that.
>>
> I've tried distribution yesterday to check it works with databases and 2
> more things related to examples:
> - There is minor issue that subsystem-config.xml is in the examples ZIP
> distribution in directory "preconfigured-demo" but should be in
> "unconfigured-demo" IMO because preconfigured-demo already has these
> predefined JSON files for adapter configuration and can work with empty
> subsystem definition.

Missed that one.  I'll fix it.

> - It seems that "third-party" and "third-party-cdi" in unconfigured-demo
> doesn't work. Not sure if subsystem will support configuration of
> oauth-clients as well, but right now it doesn't look like that. Now
> these examples always assume that you have keycloak.json file available
> and read configuration from it.

Yes, they don't work because you have to configure them.  The screencast 
tutorial walks you through it.



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

From bburke at redhat.com  Wed Feb 19 09:27:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Feb 2014 09:27:49 -0500
Subject: [keycloak-dev] what's left for release?
In-Reply-To: <1499773665.10926684.1392807650729.JavaMail.zimbra@redhat.com>
References: <5303F67A.1070100@redhat.com>
	<1499773665.10926684.1392807650729.JavaMail.zimbra@redhat.com>
Message-ID: <5304BF65.9000205@redhat.com>



On 2/19/2014 6:00 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 19 February, 2014 12:10:34 AM
>> Subject: [keycloak-dev] what's left for release?
>>
>> Where are we at?  I made some minor changes to the demo examples and
>> subsystem that you suggested earlier as well as the theme distro changes
>> I made that I talked about in the previous email.
>>
>> Give Marek another day to get MSSQL working?  Release on Thursday?
>
> Marek has got MSSQL working, and is adding documentation on how to configure different dbs. He'll also get rid of the keycloak-ds.xml file and instead add KeycloakDS to standalone.xml. That should be done today, so release tomorrow would be good.
>

Please don't get rid of the keycloak-ds.xml file from the WAR dist. 
Wanted a 1 step install for the WAR dist, and now its just a cp -r.

> I'm was going to write up a blog post on the new features (unless you've already done this?):
>

I always do it after I've put up all the distro bits.

> * Composite roles
> * WildFly subsystem
> * Theme support
> * Support for MySQL, PostgreSQL, MS-SQL, Sybase and H2 databases
> * Mongo store
> * JavaScript adapter
> * Login with GitHub
>
> Anything I'm missing? Not bad for less than 1 month :)
>

We can both write blogs.  Well, anybody can write any blog they want! :) 
  Where's your blog BTW?  So I can link it to my "Blogs I might read"?


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

From stian at redhat.com  Wed Feb 19 09:31:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Feb 2014 09:31:24 -0500 (EST)
Subject: [keycloak-dev] what's left for release?
In-Reply-To: <5304BF65.9000205@redhat.com>
References: <5303F67A.1070100@redhat.com>
	<1499773665.10926684.1392807650729.JavaMail.zimbra@redhat.com>
	<5304BF65.9000205@redhat.com>
Message-ID: <1304447585.11228461.1392820284237.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: Wednesday, 19 February, 2014 2:27:49 PM
> Subject: Re: [keycloak-dev] what's left for release?
> 
> 
> 
> On 2/19/2014 6:00 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 19 February, 2014 12:10:34 AM
> >> Subject: [keycloak-dev] what's left for release?
> >>
> >> Where are we at?  I made some minor changes to the demo examples and
> >> subsystem that you suggested earlier as well as the theme distro changes
> >> I made that I talked about in the previous email.
> >>
> >> Give Marek another day to get MSSQL working?  Release on Thursday?
> >
> > Marek has got MSSQL working, and is adding documentation on how to
> > configure different dbs. He'll also get rid of the keycloak-ds.xml file
> > and instead add KeycloakDS to standalone.xml. That should be done today,
> > so release tomorrow would be good.
> >
> 
> Please don't get rid of the keycloak-ds.xml file from the WAR dist.
> Wanted a 1 step install for the WAR dist, and now its just a cp -r.

Only doing this for appliance-dist ;)

> 
> > I'm was going to write up a blog post on the new features (unless you've
> > already done this?):
> >
> 
> I always do it after I've put up all the distro bits.
> 
> > * Composite roles
> > * WildFly subsystem
> > * Theme support
> > * Support for MySQL, PostgreSQL, MS-SQL, Sybase and H2 databases
> > * Mongo store
> > * JavaScript adapter
> > * Login with GitHub
> >
> > Anything I'm missing? Not bad for less than 1 month :)
> >
> 
> We can both write blogs.  Well, anybody can write any blog they want! :)
>   Where's your blog BTW?  So I can link it to my "Blogs I might read"?
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Wed Feb 19 12:01:56 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 19 Feb 2014 18:01:56 +0100
Subject: [keycloak-dev] what's left for release?
In-Reply-To: <1304447585.11228461.1392820284237.JavaMail.zimbra@redhat.com>
References: <5303F67A.1070100@redhat.com>	<1499773665.10926684.1392807650729.JavaMail.zimbra@redhat.com>	<5304BF65.9000205@redhat.com>
	<1304447585.11228461.1392820284237.JavaMail.zimbra@redhat.com>
Message-ID: <5304E384.7070206@redhat.com>

On 19.2.2014 15:31, Stian Thorgersen wrote:
>>> Marek has got MSSQL working, and is adding documentation on how to
>>> > >configure different dbs. He'll also get rid of the keycloak-ds.xml file
>>> > >and instead add KeycloakDS to standalone.xml. That should be done today,
>>> > >so release tomorrow would be good.
>>> > >
>> >
>> >Please don't get rid of the keycloak-ds.xml file from the WAR dist.
>> >Wanted a 1 step install for the WAR dist, and now its just a cp -r.
> Only doing this for appliance-dist;)
>
PR is here https://github.com/keycloak/keycloak/pull/224 . I've also 
added some docs about Mongo model and support for mongo model in 
distribution. Will also look at DB2, but looks like this is not a big 
priority DB and blocker for release.

Cheers,
Marek

From stian at redhat.com  Wed Feb 19 12:06:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Feb 2014 12:06:46 -0500 (EST)
Subject: [keycloak-dev] what's left for release?
In-Reply-To: <5304E384.7070206@redhat.com>
References: <5303F67A.1070100@redhat.com>
	<1499773665.10926684.1392807650729.JavaMail.zimbra@redhat.com>
	<5304BF65.9000205@redhat.com>
	<1304447585.11228461.1392820284237.JavaMail.zimbra@redhat.com>
	<5304E384.7070206@redhat.com>
Message-ID: <859590514.11534512.1392829606048.JavaMail.zimbra@redhat.com>

Ready for release then :)

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 19 February, 2014 5:01:56 PM
> Subject: Re: [keycloak-dev] what's left for release?
> 
> On 19.2.2014 15:31, Stian Thorgersen wrote:
> >>> Marek has got MSSQL working, and is adding documentation on how to
> >>> > >configure different dbs. He'll also get rid of the keycloak-ds.xml
> >>> > >file
> >>> > >and instead add KeycloakDS to standalone.xml. That should be done
> >>> > >today,
> >>> > >so release tomorrow would be good.
> >>> > >
> >> >
> >> >Please don't get rid of the keycloak-ds.xml file from the WAR dist.
> >> >Wanted a 1 step install for the WAR dist, and now its just a cp -r.
> > Only doing this for appliance-dist;)
> >
> PR is here https://github.com/keycloak/keycloak/pull/224 . I've also
> added some docs about Mongo model and support for mongo model in
> distribution. Will also look at DB2, but looks like this is not a big
> priority DB and blocker for release.
> 
> Cheers,
> Marek
> 

From bburke at redhat.com  Wed Feb 19 15:05:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Feb 2014 15:05:23 -0500
Subject: [keycloak-dev] what's left for release?
In-Reply-To: <859590514.11534512.1392829606048.JavaMail.zimbra@redhat.com>
References: <5303F67A.1070100@redhat.com>
	<1499773665.10926684.1392807650729.JavaMail.zimbra@redhat.com>
	<5304BF65.9000205@redhat.com>
	<1304447585.11228461.1392820284237.JavaMail.zimbra@redhat.com>
	<5304E384.7070206@redhat.com>
	<859590514.11534512.1392829606048.JavaMail.zimbra@redhat.com>
Message-ID: <53050E83.9060502@redhat.com>

Ok, I'll roll it tomorrow morning.

On 2/19/2014 12:06 PM, Stian Thorgersen wrote:
> Ready for release then :)
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 19 February, 2014 5:01:56 PM
>> Subject: Re: [keycloak-dev] what's left for release?
>>
>> On 19.2.2014 15:31, Stian Thorgersen wrote:
>>>>> Marek has got MSSQL working, and is adding documentation on how to
>>>>>>> configure different dbs. He'll also get rid of the keycloak-ds.xml
>>>>>>> file
>>>>>>> and instead add KeycloakDS to standalone.xml. That should be done
>>>>>>> today,
>>>>>>> so release tomorrow would be good.
>>>>>>>
>>>>>
>>>>> Please don't get rid of the keycloak-ds.xml file from the WAR dist.
>>>>> Wanted a 1 step install for the WAR dist, and now its just a cp -r.
>>> Only doing this for appliance-dist;)
>>>
>> PR is here https://github.com/keycloak/keycloak/pull/224 . I've also
>> added some docs about Mongo model and support for mongo model in
>> distribution. Will also look at DB2, but looks like this is not a big
>> priority DB and blocker for release.
>>
>> Cheers,
>> Marek
>>

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

From bburke at redhat.com  Wed Feb 19 23:17:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Feb 2014 23:17:06 -0500
Subject: [keycloak-dev] Alpha 2 released
Message-ID: <530581C2.90706@redhat.com>

See our new blog for details:

http://blog.keycloak.org/2014/02/20/keycloak-alpha-2-released/


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

From bburke at redhat.com  Wed Feb 19 23:21:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Feb 2014 23:21:04 -0500
Subject: [keycloak-dev] what's next for Alpha 3?
Message-ID: <530582B0.5090104@redhat.com>

I'd like to work on OpenID connect support as well as refresh tokens. 
We also need to help meet Aerogear's requirements, probably mostly 
around bootstrapping on Openshift.

Like Alpha 2.  I'd like each one of us to do one thing major, then do 
another quick release 3-4 weeks from now.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Thu Feb 20 04:36:37 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 20 Feb 2014 10:36:37 +0100
Subject: [keycloak-dev] what's next for Alpha 3?
In-Reply-To: <530582B0.5090104@redhat.com>
References: <530582B0.5090104@redhat.com>
Message-ID: <5305CCA5.4010807@redhat.com>

Some possible features I can think of:

-- Clustering support -- For example if I have load-balancer and two 
keycloak servers "kc1" and "kc2" and client application doesn't 
communicate directly with keycloak servers but it uses loadbalancer. 
Then login request could be redirected by loadbalancer to "kc1" where is 
created accessCode entry in TokenManager. But when client application 
sends another request to load-balancer for exchanging code for 
accessToken, it could be served by "kc2", which doesn't have this code 
entry --> error. I did not test this scenario, but I am assuming that it 
probably won't work due to this... Do we want to support this? I've also 
created JIRA https://issues.jboss.org/browse/KEYCLOAK-323 which could be 
related to this.

-- Importing realm from JSON file in admin console - When I choose file, 
it displays me that I choosed file "testrealm.json". How about 
displaying the content of this file instead of just file name? I think 
it would be more user-friendly and also people will be able to edit the 
content on the fly.

-- Importing data from JSON file into already existing realm - For 
example I want to add 100 new users into realm, which already exists. Or 
add new application, oauth clients or role mappings. I can imagine some 
format like:
{
   "realm": "test",
    "strategy": "IGNORE_EXISTING",
    "users" : [
         {
             "username" : "newUser",
             "enabled": true,
             "email" : "newUser at localhost",
             "credentials" : [
                 { "type" : "password",
                     "value" : "password" }
             ]
         }
    ],
    "roleMappings": [
         {
             "username": "newUser",
             "roles": ["user"]
         }
     ],
}

The strategy could be something like IGNORE_EXISTING (Ignore particular 
user/application entry if it already exists) or MERGE (update attributes 
of existing user/application). But maybe "strategy" is overcomplicated 
and we can simply ignore existing entries?


-- Test coverage -- Keycloak has good testsuite for covering server-side 
scenarios, but the test-coverage of real client-side adapters for AS7 or 
Wildfly is closed to 0. It seems that testsuite should be enhanced to 
test also with "real" applications like customer-portal, product-portal 
etc. I can imagine that this will require start of AS7 and Wildfly, so 
probably won't be tested during each build? Also it seems that there is 
not much test coverage of admin console.

-- DB2 support - This is only remaining DB, which is certified by other 
RH products. Probably not so important, but I will try to look at it 
sooner during spare time. If we later need to support it and it will 
require some changes of DB schema, there might be issues with backwards 
compatibility... I hope that at this stage backward compatibility is 
still not something important as Keycloak is still in development and 
there will be some more features (like secured storage of realm private 
keys) which will require DB schema changes?

Marek


On 20.2.2014 05:21, Bill Burke wrote:
> I'd like to work on OpenID connect support as well as refresh tokens.
> We also need to help meet Aerogear's requirements, probably mostly
> around bootstrapping on Openshift.
>
> Like Alpha 2.  I'd like each one of us to do one thing major, then do
> another quick release 3-4 weeks from now.


From stian at redhat.com  Thu Feb 20 05:40:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Feb 2014 05:40:04 -0500 (EST)
Subject: [keycloak-dev] what's next for Alpha 3?
In-Reply-To: <530582B0.5090104@redhat.com>
References: <530582B0.5090104@redhat.com>
Message-ID: <506700746.12579872.1392892804034.JavaMail.zimbra@redhat.com>

Marek and myself will need to give LiveOak a bit of TLC this time around, but we'll still try to do something for alpha3.

I'll look at KEYCLOAK-292 as this is something we'll need for LiveOak. I'll also try to sort out the issues I proposed with regards to users recently.

Marek will look at adding support to link social accounts (KEYCLOAK-26).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 February, 2014 4:21:04 AM
> Subject: [keycloak-dev] what's next for Alpha 3?
> 
> I'd like to work on OpenID connect support as well as refresh tokens.
> We also need to help meet Aerogear's requirements, probably mostly
> around bootstrapping on Openshift.
> 
> Like Alpha 2.  I'd like each one of us to do one thing major, then do
> another quick release 3-4 weeks from now.
> --
> 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 Feb 20 07:49:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Feb 2014 07:49:20 -0500 (EST)
Subject: [keycloak-dev] Refresh tokens
In-Reply-To: <829698123.12731402.1392900447628.JavaMail.zimbra@redhat.com>
Message-ID: <1793542219.12733509.1392900560619.JavaMail.zimbra@redhat.com>

With regards to refresh tokens it would be nice to add support for users to be able to manage applications at the same time.

https://issues.jboss.org/browse/KEYCLOAK-312:

Account management should have a page that lists all applications and clients that have access to a users account. This would be a list of applications and clients that have been given a refresh token (and where the refresh token hasn't expired). For clients it should also list the scope that was granted (probably doesn't make sense to list this for applications).

Users should be able to revoke access to an individual application or client. This would result in the refresh token being invalidated so the application or client wouldn't be able to retrieve a new token.

From stian at redhat.com  Thu Feb 20 09:15:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Feb 2014 09:15:00 -0500 (EST)
Subject: [keycloak-dev] OpenShift cartridge updated to WildFly 8.0.0.Final
 and Keycloak 1.0.alpha2
Message-ID: <327059541.12854000.1392905700377.JavaMail.zimbra@redhat.com>

The OpenShift cartridge has been updated to WildFly 8.0.0.Final and Keycloak 1.0.alpha2

From bburke at redhat.com  Thu Feb 20 09:31:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 09:31:44 -0500
Subject: [keycloak-dev] OpenShift cartridge updated to WildFly
 8.0.0.Final and Keycloak 1.0.alpha2
In-Reply-To: <327059541.12854000.1392905700377.JavaMail.zimbra@redhat.com>
References: <327059541.12854000.1392905700377.JavaMail.zimbra@redhat.com>
Message-ID: <530611D0.2080408@redhat.com>

thanks.

On 2/20/2014 9:15 AM, Stian Thorgersen wrote:
> The OpenShift cartridge has been updated to WildFly 8.0.0.Final and Keycloak 1.0.alpha2
> _______________________________________________
> 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 Feb 20 09:33:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 09:33:40 -0500
Subject: [keycloak-dev] what's next for Alpha 3?
In-Reply-To: <506700746.12579872.1392892804034.JavaMail.zimbra@redhat.com>
References: <530582B0.5090104@redhat.com>
	<506700746.12579872.1392892804034.JavaMail.zimbra@redhat.com>
Message-ID: <53061244.6050506@redhat.com>

Let's have a separate thread on KEYCLOAK-292

On 2/20/2014 5:40 AM, Stian Thorgersen wrote:
> Marek and myself will need to give LiveOak a bit of TLC this time around, but we'll still try to do something for alpha3.
>
> I'll look at KEYCLOAK-292 as this is something we'll need for LiveOak. I'll also try to sort out the issues I proposed with regards to users recently.
>
> Marek will look at adding support to link social accounts (KEYCLOAK-26).
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 20 February, 2014 4:21:04 AM
>> Subject: [keycloak-dev] what's next for Alpha 3?
>>
>> I'd like to work on OpenID connect support as well as refresh tokens.
>> We also need to help meet Aerogear's requirements, probably mostly
>> around bootstrapping on Openshift.
>>
>> Like Alpha 2.  I'd like each one of us to do one thing major, then do
>> another quick release 3-4 weeks from now.
>> --
>> 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 Feb 20 09:34:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 09:34:05 -0500
Subject: [keycloak-dev] Refresh tokens
In-Reply-To: <1793542219.12733509.1392900560619.JavaMail.zimbra@redhat.com>
References: <1793542219.12733509.1392900560619.JavaMail.zimbra@redhat.com>
Message-ID: <5306125D.5070909@redhat.com>

Ok, I'll add that to my list.

On 2/20/2014 7:49 AM, Stian Thorgersen wrote:
> With regards to refresh tokens it would be nice to add support for users to be able to manage applications at the same time.
>
> https://issues.jboss.org/browse/KEYCLOAK-312:
>
> Account management should have a page that lists all applications and clients that have access to a users account. This would be a list of applications and clients that have been given a refresh token (and where the refresh token hasn't expired). For clients it should also list the scope that was granted (probably doesn't make sense to list this for applications).
>
> Users should be able to revoke access to an individual application or client. This would result in the refresh token being invalidated so the application or client wouldn't be able to retrieve a new token.
> _______________________________________________
> 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 Feb 20 10:05:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Feb 2014 10:05:15 -0500 (EST)
Subject: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
In-Reply-To: <265118629.12909635.1392907415743.JavaMail.zimbra@redhat.com>
Message-ID: <1622166776.12954320.1392908715741.JavaMail.zimbra@redhat.com>

Currently a user in the 'keycloak-admin' realm with the role 'admin' has full access to all realms. We need to support a bit more fine-grained access control for admin console/endpoints. At the bare minimum we need to be able to have users that can administer only some realms. Further, it would be nice to build this on-top of roles alone and not require an ACL table or something similar.

We could start with the following permissions/roles for a realm:

* view-realm-config
* manage-realm-config
* view-users
* manage-users
* view-applications
* manage-applications
* view-clients
* manage-clients
* admin (composite role containing all the above roles)

One approach to this would be to create an application per-realm that represents that realm (application name could be 'realm-<realm name>'). This would be created automatically when we create a new realm, and it would have the above roles as application roles. Users can then be granted access to individual realms by mapping the roles for the associated application to them.

We could also have a composite realm role 'admin' that maps to the 'admin' role in all realm applications. Any user that is granted this role would have full access to all realms.

This made me think about the concept of "resources" in Keycloak. A resource is similar to an application except it doesn't have scope mappings, nor does it have credentials. This could be used in the demo for the 'database-service', which would mean we'd have roles associated with the 'database-service' rather than using realm roles. It would also provide an installation file (and wildfly config) where 'bearer-only' is set to 'true'.

From bburke at redhat.com  Thu Feb 20 10:47:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 10:47:35 -0500
Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
In-Reply-To: <5305CCA5.4010807@redhat.com>
References: <530582B0.5090104@redhat.com> <5305CCA5.4010807@redhat.com>
Message-ID: <53062397.4080201@redhat.com>



On 2/20/2014 4:36 AM, Marek Posolda wrote:
> Some possible features I can think of:
>
> -- Clustering support -- For example if I have load-balancer and two
> keycloak servers "kc1" and "kc2" and client application doesn't
> communicate directly with keycloak servers but it uses loadbalancer.
> Then login request could be redirected by loadbalancer to "kc1" where is
> created accessCode entry in TokenManager. But when client application
> sends another request to load-balancer for exchanging code for
> accessToken, it could be served by "kc2", which doesn't have this code
> entry --> error. I did not test this scenario, but I am assuming that it
> probably won't work due to this... Do we want to support this? I've also
> created JIRA https://issues.jboss.org/browse/KEYCLOAK-323 which could be
> related to this.
>

Clustering really f's up the oauth/openid flow.  The only thing I could 
think of was that the auth-code redirect URL could contain a signed URL 
where the client goes to turn the code into a token.  I was surprised, I 
couldn't find anything in the OpenID Connect spec that covered this.


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

From gcardoso at redhat.com  Thu Feb 20 10:56:45 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 20 Feb 2014 12:56:45 -0300
Subject: [keycloak-dev] Alpha 2 released
In-Reply-To: <530581C2.90706@redhat.com>
References: <530581C2.90706@redhat.com>
Message-ID: <9CDF74CE-5700-4BEB-BE0A-1D1EAFAC1047@redhat.com>

Very nice! The text is cool and the blog looks great!

+1

On Feb 20, 2014, at 1:17 AM, Bill Burke <bburke at redhat.com> wrote:

> See our new blog for details:
> 
> http://blog.keycloak.org/2014/02/20/keycloak-alpha-2-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

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140220/02438af6/attachment-0001.html 

From stian at redhat.com  Thu Feb 20 11:03:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Feb 2014 11:03:17 -0500 (EST)
Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
In-Reply-To: <53062397.4080201@redhat.com>
References: <530582B0.5090104@redhat.com> <5305CCA5.4010807@redhat.com>
	<53062397.4080201@redhat.com>
Message-ID: <1056701250.13063656.1392912197407.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 February, 2014 3:47:35 PM
> Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
> 
> 
> 
> On 2/20/2014 4:36 AM, Marek Posolda wrote:
> > Some possible features I can think of:
> >
> > -- Clustering support -- For example if I have load-balancer and two
> > keycloak servers "kc1" and "kc2" and client application doesn't
> > communicate directly with keycloak servers but it uses loadbalancer.
> > Then login request could be redirected by loadbalancer to "kc1" where is
> > created accessCode entry in TokenManager. But when client application
> > sends another request to load-balancer for exchanging code for
> > accessToken, it could be served by "kc2", which doesn't have this code
> > entry --> error. I did not test this scenario, but I am assuming that it
> > probably won't work due to this... Do we want to support this? I've also
> > created JIRA https://issues.jboss.org/browse/KEYCLOAK-323 which could be
> > related to this.
> >
> 
> Clustering really f's up the oauth/openid flow.  The only thing I could
> think of was that the auth-code redirect URL could contain a signed URL
> where the client goes to turn the code into a token.  I was surprised, I
> couldn't find anything in the OpenID Connect spec that covered this.

I'm not quite following, can you specify why it f's it up?

Couldn't we encode/encrypt everything in AccessCodeEntry into the code query param? That way it wouldn't matter what instance in the cluster is used.

> 
> 
> --
> 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 Feb 20 11:06:37 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 11:06:37 -0500
Subject: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
In-Reply-To: <1622166776.12954320.1392908715741.JavaMail.zimbra@redhat.com>
References: <1622166776.12954320.1392908715741.JavaMail.zimbra@redhat.com>
Message-ID: <5306280D.2030203@redhat.com>



On 2/20/2014 10:05 AM, Stian Thorgersen wrote:
> Currently a user in the 'keycloak-admin' realm with the role 'admin' has full access to all realms. We need to support a bit more fine-grained access control for admin console/endpoints. At the bare minimum we need to be able to have users that can administer only some realms. Further, it would be nice to build this on-top of roles alone and not require an ACL table or something similar.
>
> We could start with the following permissions/roles for a realm:
>
> * view-realm-config
> * manage-realm-config
> * view-users
> * manage-users
> * view-applications
> * manage-applications
> * view-clients
> * manage-clients
> * admin (composite role containing all the above roles)
>
> One approach to this would be to create an application per-realm that represents that realm (application name could be 'realm-<realm name>'). This would be created automatically when we create a new realm, and it would have the above roles as application roles. Users can then be granted access to individual realms by mapping the roles for the associated application to them.
>
> We could also have a composite realm role 'admin' that maps to the 'admin' role in all realm applications. Any user that is granted this role would have full access to all realms.
>
> This made me think about the concept of "resources" in Keycloak. A resource is similar to an application except it doesn't have scope mappings, nor does it have credentials. This could be used in the demo for the 'database-service', which would mean we'd have roles associated with the 'database-service' rather than using realm roles. It would also provide an installation file (and wildfly config) where 'bearer-only' is set to 'true'.

We need to think of this in terms of OAuth grants.  i.e.  You have one 
Keycloak server that wants to export/migrate metadata from its realm(s) 
to another Keycloak server.  You have a service like Aerogear UPS where 
you want to grant it temporary permission to define applications within 
the realm.

This is why I think the best approach would be to create an application 
per-realm that represents realm management.  The application would just 
be named "realm-management", just like we already have for "account". 
This way these admin roles to mix or pollute anything user specific.  We 
would also create an application within the "keycloak-admin" realm with 
similar role definitions.

With the above setup, we would have "keycloak-admin" users who would 
have various permissions on *ALL* realms.  And per realm users that have 
permissions for one *specific* realm.  But, there would not be a concept 
of a user that has permissions on a subset of realms.  It could be 
access to 1 realm, or access to all realms.

Does LiveOak need the concept of one user being able to edit only a 
subset of realms?

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

From bburke at redhat.com  Thu Feb 20 11:19:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 11:19:41 -0500
Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
In-Reply-To: <1056701250.13063656.1392912197407.JavaMail.zimbra@redhat.com>
References: <530582B0.5090104@redhat.com> <5305CCA5.4010807@redhat.com>
	<53062397.4080201@redhat.com>
	<1056701250.13063656.1392912197407.JavaMail.zimbra@redhat.com>
Message-ID: <53062B1D.8080506@redhat.com>



On 2/20/2014 11:03 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Thursday, 20 February, 2014 3:47:35 PM
>> Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
>>
>>
>>
>> On 2/20/2014 4:36 AM, Marek Posolda wrote:
>>> Some possible features I can think of:
>>>
>>> -- Clustering support -- For example if I have load-balancer and two
>>> keycloak servers "kc1" and "kc2" and client application doesn't
>>> communicate directly with keycloak servers but it uses loadbalancer.
>>> Then login request could be redirected by loadbalancer to "kc1" where is
>>> created accessCode entry in TokenManager. But when client application
>>> sends another request to load-balancer for exchanging code for
>>> accessToken, it could be served by "kc2", which doesn't have this code
>>> entry --> error. I did not test this scenario, but I am assuming that it
>>> probably won't work due to this... Do we want to support this? I've also
>>> created JIRA https://issues.jboss.org/browse/KEYCLOAK-323 which could be
>>> related to this.
>>>
>>
>> Clustering really f's up the oauth/openid flow.  The only thing I could
>> think of was that the auth-code redirect URL could contain a signed URL
>> where the client goes to turn the code into a token.  I was surprised, I
>> couldn't find anything in the OpenID Connect spec that covered this.
>
> I'm not quite following, can you specify why it f's it up?
>
> Couldn't we encode/encrypt everything in AccessCodeEntry into the code query param? That way it wouldn't matter what instance in the cluster is used.

What screws it up right now, is that our implementation keeps Accesscode 
entries and all their associated information in memory.  You'd have to 
store this information in each page displayed in the authentication 
process, then send an encrypted/signed access code that also contained 
this information when you finally redirect back to the 
application/client.  Each step in the process would have to verify and 
deserialize this information.  This would slow us down on a single 
machine deployment, but would scale and make everything stateless.

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

From stian at redhat.com  Thu Feb 20 11:21:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Feb 2014 11:21:01 -0500 (EST)
Subject: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
In-Reply-To: <5306280D.2030203@redhat.com>
References: <1622166776.12954320.1392908715741.JavaMail.zimbra@redhat.com>
	<5306280D.2030203@redhat.com>
Message-ID: <2071239345.13092688.1392913261011.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 February, 2014 4:06:37 PM
> Subject: Re: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
> 
> 
> 
> On 2/20/2014 10:05 AM, Stian Thorgersen wrote:
> > Currently a user in the 'keycloak-admin' realm with the role 'admin' has
> > full access to all realms. We need to support a bit more fine-grained
> > access control for admin console/endpoints. At the bare minimum we need to
> > be able to have users that can administer only some realms. Further, it
> > would be nice to build this on-top of roles alone and not require an ACL
> > table or something similar.
> >
> > We could start with the following permissions/roles for a realm:
> >
> > * view-realm-config
> > * manage-realm-config
> > * view-users
> > * manage-users
> > * view-applications
> > * manage-applications
> > * view-clients
> > * manage-clients
> > * admin (composite role containing all the above roles)
> >
> > One approach to this would be to create an application per-realm that
> > represents that realm (application name could be 'realm-<realm name>').
> > This would be created automatically when we create a new realm, and it
> > would have the above roles as application roles. Users can then be granted
> > access to individual realms by mapping the roles for the associated
> > application to them.
> >
> > We could also have a composite realm role 'admin' that maps to the 'admin'
> > role in all realm applications. Any user that is granted this role would
> > have full access to all realms.
> >
> > This made me think about the concept of "resources" in Keycloak. A resource
> > is similar to an application except it doesn't have scope mappings, nor
> > does it have credentials. This could be used in the demo for the
> > 'database-service', which would mean we'd have roles associated with the
> > 'database-service' rather than using realm roles. It would also provide an
> > installation file (and wildfly config) where 'bearer-only' is set to
> > 'true'.
> 
> We need to think of this in terms of OAuth grants.  i.e.  You have one
> Keycloak server that wants to export/migrate metadata from its realm(s)
> to another Keycloak server.  You have a service like Aerogear UPS where
> you want to grant it temporary permission to define applications within
> the realm.

I don't see how what I proposed doesn't work with OAuth grants.

> 
> This is why I think the best approach would be to create an application
> per-realm that represents realm management.  The application would just
> be named "realm-management", just like we already have for "account".
> This way these admin roles to mix or pollute anything user specific.  We
> would also create an application within the "keycloak-admin" realm with
> similar role definitions.
> 
> With the above setup, we would have "keycloak-admin" users who would
> have various permissions on *ALL* realms.  And per realm users that have
> permissions for one *specific* realm.  But, there would not be a concept
> of a user that has permissions on a subset of realms.  It could be
> access to 1 realm, or access to all realms.

This sounds messy to me. It means you end up with having to manage access to a realm in two different realms. Also, for admin console you'd have to have an option of selecting what realm to login to. Anyone that is only given access to one or two realms would have to re-login to swap or something.

> 
> Does LiveOak need the concept of one user being able to edit only a
> subset of realms?



> 
> --
> 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 mposolda at redhat.com  Thu Feb 20 11:22:36 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 20 Feb 2014 17:22:36 +0100
Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
In-Reply-To: <53062397.4080201@redhat.com>
References: <530582B0.5090104@redhat.com> <5305CCA5.4010807@redhat.com>
	<53062397.4080201@redhat.com>
Message-ID: <53062BCC.6050909@redhat.com>

On 20.2.2014 16:47, Bill Burke wrote:
>
>
> On 2/20/2014 4:36 AM, Marek Posolda wrote:
>> Some possible features I can think of:
>>
>> -- Clustering support -- For example if I have load-balancer and two
>> keycloak servers "kc1" and "kc2" and client application doesn't
>> communicate directly with keycloak servers but it uses loadbalancer.
>> Then login request could be redirected by loadbalancer to "kc1" where is
>> created accessCode entry in TokenManager. But when client application
>> sends another request to load-balancer for exchanging code for
>> accessToken, it could be served by "kc2", which doesn't have this code
>> entry --> error. I did not test this scenario, but I am assuming that it
>> probably won't work due to this... Do we want to support this? I've also
>> created JIRA https://issues.jboss.org/browse/KEYCLOAK-323 which could be
>> related to this.
>>
>
> Clustering really f's up the oauth/openid flow.  The only thing I 
> could think of was that the auth-code redirect URL could contain a 
> signed URL where the client goes to turn the code into a token.  I was 
> surprised, I couldn't find anything in the OpenID Connect spec that 
> covered this.
hmm... I wonder if KC hosts could be on "internal" hosts and application 
may not directly access them? For example, I have:
loadbalancer on: http://keycloak.public.org
KC worker1 on: http://kc1.internal.org
KC worker2 on: http://kc2.internal.org

Application is somewhere on internet and it can't communicate directly 
with "kc1.internal.org" just with public loadbalancer. So it seems that 
it won't be able to send exchanging request to kc1.internal.org. Or am I 
just misunderstood what you mean?

Maybe it could be hacked somehow at loadbalancer level, but that would 
be likely proprietary solution just for that loadbalancer. Keycloak is 
stateless and doesn't have anything like sticky sessions...

I can imagine that best thing to address this by either use infinispan 
or by remove map entirely from TokenManager and encode whole 
AccessCodeEntry to client, like Stian suggested, so exchanging request 
could be served by any keycloak worker.

Marek



From stian at redhat.com  Thu Feb 20 11:23:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Feb 2014 11:23:53 -0500 (EST)
Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
In-Reply-To: <53062B1D.8080506@redhat.com>
References: <530582B0.5090104@redhat.com> <5305CCA5.4010807@redhat.com>
	<53062397.4080201@redhat.com>
	<1056701250.13063656.1392912197407.JavaMail.zimbra@redhat.com>
	<53062B1D.8080506@redhat.com>
Message-ID: <2027039365.13100567.1392913433844.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 February, 2014 4:19:41 PM
> Subject: Re: [keycloak-dev] clustering Re:  what's next for Alpha 3?
> 
> 
> 
> On 2/20/2014 11:03 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 20 February, 2014 3:47:35 PM
> >> Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
> >>
> >>
> >>
> >> On 2/20/2014 4:36 AM, Marek Posolda wrote:
> >>> Some possible features I can think of:
> >>>
> >>> -- Clustering support -- For example if I have load-balancer and two
> >>> keycloak servers "kc1" and "kc2" and client application doesn't
> >>> communicate directly with keycloak servers but it uses loadbalancer.
> >>> Then login request could be redirected by loadbalancer to "kc1" where is
> >>> created accessCode entry in TokenManager. But when client application
> >>> sends another request to load-balancer for exchanging code for
> >>> accessToken, it could be served by "kc2", which doesn't have this code
> >>> entry --> error. I did not test this scenario, but I am assuming that it
> >>> probably won't work due to this... Do we want to support this? I've also
> >>> created JIRA https://issues.jboss.org/browse/KEYCLOAK-323 which could be
> >>> related to this.
> >>>
> >>
> >> Clustering really f's up the oauth/openid flow.  The only thing I could
> >> think of was that the auth-code redirect URL could contain a signed URL
> >> where the client goes to turn the code into a token.  I was surprised, I
> >> couldn't find anything in the OpenID Connect spec that covered this.
> >
> > I'm not quite following, can you specify why it f's it up?
> >
> > Couldn't we encode/encrypt everything in AccessCodeEntry into the code
> > query param? That way it wouldn't matter what instance in the cluster is
> > used.
> 
> What screws it up right now, is that our implementation keeps Accesscode
> entries and all their associated information in memory.  You'd have to
> store this information in each page displayed in the authentication
> process, then send an encrypted/signed access code that also contained
> this information when you finally redirect back to the
> application/client.  Each step in the process would have to verify and
> deserialize this information.  This would slow us down on a single
> machine deployment, but would scale and make everything stateless.

We could support both approaches and make it configurable. If you have a single server (or you can use sticky sessions), then we only pass a reference as the code. If you have a cluster and can't use sticky session we send the full AccessCodeEntry as the code.

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

From bburke at redhat.com  Thu Feb 20 11:54:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 11:54:28 -0500
Subject: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
In-Reply-To: <2071239345.13092688.1392913261011.JavaMail.zimbra@redhat.com>
References: <1622166776.12954320.1392908715741.JavaMail.zimbra@redhat.com>
	<5306280D.2030203@redhat.com>
	<2071239345.13092688.1392913261011.JavaMail.zimbra@redhat.com>
Message-ID: <53063344.4050202@redhat.com>



On 2/20/2014 11:21 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 20 February, 2014 4:06:37 PM
>> Subject: Re: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
>>
>>
>>
>> On 2/20/2014 10:05 AM, Stian Thorgersen wrote:
>>> Currently a user in the 'keycloak-admin' realm with the role 'admin' has
>>> full access to all realms. We need to support a bit more fine-grained
>>> access control for admin console/endpoints. At the bare minimum we need to
>>> be able to have users that can administer only some realms. Further, it
>>> would be nice to build this on-top of roles alone and not require an ACL
>>> table or something similar.
>>>
>>> We could start with the following permissions/roles for a realm:
>>>
>>> * view-realm-config
>>> * manage-realm-config
>>> * view-users
>>> * manage-users
>>> * view-applications
>>> * manage-applications
>>> * view-clients
>>> * manage-clients
>>> * admin (composite role containing all the above roles)
>>>
>>> One approach to this would be to create an application per-realm that
>>> represents that realm (application name could be 'realm-<realm name>').
>>> This would be created automatically when we create a new realm, and it
>>> would have the above roles as application roles. Users can then be granted
>>> access to individual realms by mapping the roles for the associated
>>> application to them.
>>>
>>> We could also have a composite realm role 'admin' that maps to the 'admin'
>>> role in all realm applications. Any user that is granted this role would
>>> have full access to all realms.
>>>
>>> This made me think about the concept of "resources" in Keycloak. A resource
>>> is similar to an application except it doesn't have scope mappings, nor
>>> does it have credentials. This could be used in the demo for the
>>> 'database-service', which would mean we'd have roles associated with the
>>> 'database-service' rather than using realm roles. It would also provide an
>>> installation file (and wildfly config) where 'bearer-only' is set to
>>> 'true'.
>>
>> We need to think of this in terms of OAuth grants.  i.e.  You have one
>> Keycloak server that wants to export/migrate metadata from its realm(s)
>> to another Keycloak server.  You have a service like Aerogear UPS where
>> you want to grant it temporary permission to define applications within
>> the realm.
>
> I don't see how what I proposed doesn't work with OAuth grants.
>
>>
>> This is why I think the best approach would be to create an application
>> per-realm that represents realm management.  The application would just
>> be named "realm-management", just like we already have for "account".
>> This way these admin roles to mix or pollute anything user specific.  We
>> would also create an application within the "keycloak-admin" realm with
>> similar role definitions.
>>
>> With the above setup, we would have "keycloak-admin" users who would
>> have various permissions on *ALL* realms.  And per realm users that have
>> permissions for one *specific* realm.  But, there would not be a concept
>> of a user that has permissions on a subset of realms.  It could be
>> access to 1 realm, or access to all realms.
>
> This sounds messy to me. It means you end up with having to manage access to a realm in two different realms. Also, for admin console you'd have to have an option of selecting what realm to login to. Anyone that is only given access to one or two realms would have to re-login to swap or something.
>

I was actually agreeing with your original post, but I don't think I 
fully understood your original post! I might understand now.  Is this 
what you mean?

* Create an application within "keycloak-admin" for each new realm
* Under that application create all the roles mentioned in the OP.
* Create a realm level composite role named "superuser".  When a new 
realm is created, associate all those new application roles to this 
superuser composite.

Then, when you log into the admin console, the server just checks which 
roles you have assigned to you to fill the realm selection box on the 
admin console main page.


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

From bburke at redhat.com  Thu Feb 20 11:56:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 11:56:28 -0500
Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
In-Reply-To: <2027039365.13100567.1392913433844.JavaMail.zimbra@redhat.com>
References: <530582B0.5090104@redhat.com> <5305CCA5.4010807@redhat.com>
	<53062397.4080201@redhat.com>
	<1056701250.13063656.1392912197407.JavaMail.zimbra@redhat.com>
	<53062B1D.8080506@redhat.com>
	<2027039365.13100567.1392913433844.JavaMail.zimbra@redhat.com>
Message-ID: <530633BC.2050901@redhat.com>



On 2/20/2014 11:23 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Thursday, 20 February, 2014 4:19:41 PM
>> Subject: Re: [keycloak-dev] clustering Re:  what's next for Alpha 3?
>>
>>
>>
>> On 2/20/2014 11:03 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 20 February, 2014 3:47:35 PM
>>>> Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
>>>>
>>>>
>>>>
>>>> On 2/20/2014 4:36 AM, Marek Posolda wrote:
>>>>> Some possible features I can think of:
>>>>>
>>>>> -- Clustering support -- For example if I have load-balancer and two
>>>>> keycloak servers "kc1" and "kc2" and client application doesn't
>>>>> communicate directly with keycloak servers but it uses loadbalancer.
>>>>> Then login request could be redirected by loadbalancer to "kc1" where is
>>>>> created accessCode entry in TokenManager. But when client application
>>>>> sends another request to load-balancer for exchanging code for
>>>>> accessToken, it could be served by "kc2", which doesn't have this code
>>>>> entry --> error. I did not test this scenario, but I am assuming that it
>>>>> probably won't work due to this... Do we want to support this? I've also
>>>>> created JIRA https://issues.jboss.org/browse/KEYCLOAK-323 which could be
>>>>> related to this.
>>>>>
>>>>
>>>> Clustering really f's up the oauth/openid flow.  The only thing I could
>>>> think of was that the auth-code redirect URL could contain a signed URL
>>>> where the client goes to turn the code into a token.  I was surprised, I
>>>> couldn't find anything in the OpenID Connect spec that covered this.
>>>
>>> I'm not quite following, can you specify why it f's it up?
>>>
>>> Couldn't we encode/encrypt everything in AccessCodeEntry into the code
>>> query param? That way it wouldn't matter what instance in the cluster is
>>> used.
>>
>> What screws it up right now, is that our implementation keeps Accesscode
>> entries and all their associated information in memory.  You'd have to
>> store this information in each page displayed in the authentication
>> process, then send an encrypted/signed access code that also contained
>> this information when you finally redirect back to the
>> application/client.  Each step in the process would have to verify and
>> deserialize this information.  This would slow us down on a single
>> machine deployment, but would scale and make everything stateless.
>
> We could support both approaches and make it configurable. If you have a single server (or you can use sticky sessions), then we only pass a reference as the code. If you have a cluster and can't use sticky session we send the full AccessCodeEntry as the code.
>

We'll profile it.  It just might be that this verification/unmarshalling 
is only a small percentage of each overall request.


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

From stian at redhat.com  Thu Feb 20 12:23:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Feb 2014 12:23:00 -0500 (EST)
Subject: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
In-Reply-To: <53063344.4050202@redhat.com>
References: <1622166776.12954320.1392908715741.JavaMail.zimbra@redhat.com>
	<5306280D.2030203@redhat.com>
	<2071239345.13092688.1392913261011.JavaMail.zimbra@redhat.com>
	<53063344.4050202@redhat.com>
Message-ID: <1609362061.13207830.1392916980949.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, 20 February, 2014 4:54:28 PM
> Subject: Re: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
> 
> 
> 
> On 2/20/2014 11:21 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 20 February, 2014 4:06:37 PM
> >> Subject: Re: [keycloak-dev] Authz for admin console/endpoints
> >> (KEYCLOAK-292)
> >>
> >>
> >>
> >> On 2/20/2014 10:05 AM, Stian Thorgersen wrote:
> >>> Currently a user in the 'keycloak-admin' realm with the role 'admin' has
> >>> full access to all realms. We need to support a bit more fine-grained
> >>> access control for admin console/endpoints. At the bare minimum we need
> >>> to
> >>> be able to have users that can administer only some realms. Further, it
> >>> would be nice to build this on-top of roles alone and not require an ACL
> >>> table or something similar.
> >>>
> >>> We could start with the following permissions/roles for a realm:
> >>>
> >>> * view-realm-config
> >>> * manage-realm-config
> >>> * view-users
> >>> * manage-users
> >>> * view-applications
> >>> * manage-applications
> >>> * view-clients
> >>> * manage-clients
> >>> * admin (composite role containing all the above roles)
> >>>
> >>> One approach to this would be to create an application per-realm that
> >>> represents that realm (application name could be 'realm-<realm name>').
> >>> This would be created automatically when we create a new realm, and it
> >>> would have the above roles as application roles. Users can then be
> >>> granted
> >>> access to individual realms by mapping the roles for the associated
> >>> application to them.
> >>>
> >>> We could also have a composite realm role 'admin' that maps to the
> >>> 'admin'
> >>> role in all realm applications. Any user that is granted this role would
> >>> have full access to all realms.
> >>>
> >>> This made me think about the concept of "resources" in Keycloak. A
> >>> resource
> >>> is similar to an application except it doesn't have scope mappings, nor
> >>> does it have credentials. This could be used in the demo for the
> >>> 'database-service', which would mean we'd have roles associated with the
> >>> 'database-service' rather than using realm roles. It would also provide
> >>> an
> >>> installation file (and wildfly config) where 'bearer-only' is set to
> >>> 'true'.
> >>
> >> We need to think of this in terms of OAuth grants.  i.e.  You have one
> >> Keycloak server that wants to export/migrate metadata from its realm(s)
> >> to another Keycloak server.  You have a service like Aerogear UPS where
> >> you want to grant it temporary permission to define applications within
> >> the realm.
> >
> > I don't see how what I proposed doesn't work with OAuth grants.
> >
> >>
> >> This is why I think the best approach would be to create an application
> >> per-realm that represents realm management.  The application would just
> >> be named "realm-management", just like we already have for "account".
> >> This way these admin roles to mix or pollute anything user specific.  We
> >> would also create an application within the "keycloak-admin" realm with
> >> similar role definitions.
> >>
> >> With the above setup, we would have "keycloak-admin" users who would
> >> have various permissions on *ALL* realms.  And per realm users that have
> >> permissions for one *specific* realm.  But, there would not be a concept
> >> of a user that has permissions on a subset of realms.  It could be
> >> access to 1 realm, or access to all realms.
> >
> > This sounds messy to me. It means you end up with having to manage access
> > to a realm in two different realms. Also, for admin console you'd have to
> > have an option of selecting what realm to login to. Anyone that is only
> > given access to one or two realms would have to re-login to swap or
> > something.
> >
> 
> I was actually agreeing with your original post, but I don't think I
> fully understood your original post! I might understand now.  Is this
> what you mean?
> 
> * Create an application within "keycloak-admin" for each new realm
> * Under that application create all the roles mentioned in the OP.
> * Create a realm level composite role named "superuser".  When a new
> realm is created, associate all those new application roles to this
> superuser composite.
> 
> Then, when you log into the admin console, the server just checks which
> roles you have assigned to you to fill the realm selection box on the
> admin console main page.

Yes, emails can be confusing sometimes ;)

Just to be 100% sure, I'll do an example (should have done this in the first place):

* There's 3 realms: 'keycloak-admin', 'realm-a' and 'realm-b'
* Inside 'keycloak-admin' there's apps 'realm-a-management' and 'realm-b-management' (these are created/deleted as realms are created/deleted)
* Each of 'realm-a-management' and 'realm-b-mananagement' have roles 'view-realm', 'manage-realm', etc.. There's also have an app composite role 'realm-admin' that maps to all the other roles in the app (again these roles are created when a realm is created)
* The 'keycloak-admin' has a single composite role 'realms-admin' that maps to 'realm-admin' roles in both 'realm-a-management' and 'realm-b-management' (again this is updated has realms are created/deleted)

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

From bburke at redhat.com  Thu Feb 20 14:25:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 14:25:24 -0500
Subject: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
In-Reply-To: <1609362061.13207830.1392916980949.JavaMail.zimbra@redhat.com>
References: <1622166776.12954320.1392908715741.JavaMail.zimbra@redhat.com>
	<5306280D.2030203@redhat.com>
	<2071239345.13092688.1392913261011.JavaMail.zimbra@redhat.com>
	<53063344.4050202@redhat.com>
	<1609362061.13207830.1392916980949.JavaMail.zimbra@redhat.com>
Message-ID: <530656A4.1040909@redhat.com>



On 2/20/2014 12:23 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, 20 February, 2014 4:54:28 PM
>> Subject: Re: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
>>
>>
>>
>> On 2/20/2014 11:21 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 20 February, 2014 4:06:37 PM
>>>> Subject: Re: [keycloak-dev] Authz for admin console/endpoints
>>>> (KEYCLOAK-292)
>>>>
>>>>
>>>>
>>>> On 2/20/2014 10:05 AM, Stian Thorgersen wrote:
>>>>> Currently a user in the 'keycloak-admin' realm with the role 'admin' has
>>>>> full access to all realms. We need to support a bit more fine-grained
>>>>> access control for admin console/endpoints. At the bare minimum we need
>>>>> to
>>>>> be able to have users that can administer only some realms. Further, it
>>>>> would be nice to build this on-top of roles alone and not require an ACL
>>>>> table or something similar.
>>>>>
>>>>> We could start with the following permissions/roles for a realm:
>>>>>
>>>>> * view-realm-config
>>>>> * manage-realm-config
>>>>> * view-users
>>>>> * manage-users
>>>>> * view-applications
>>>>> * manage-applications
>>>>> * view-clients
>>>>> * manage-clients
>>>>> * admin (composite role containing all the above roles)
>>>>>
>>>>> One approach to this would be to create an application per-realm that
>>>>> represents that realm (application name could be 'realm-<realm name>').
>>>>> This would be created automatically when we create a new realm, and it
>>>>> would have the above roles as application roles. Users can then be
>>>>> granted
>>>>> access to individual realms by mapping the roles for the associated
>>>>> application to them.
>>>>>
>>>>> We could also have a composite realm role 'admin' that maps to the
>>>>> 'admin'
>>>>> role in all realm applications. Any user that is granted this role would
>>>>> have full access to all realms.
>>>>>
>>>>> This made me think about the concept of "resources" in Keycloak. A
>>>>> resource
>>>>> is similar to an application except it doesn't have scope mappings, nor
>>>>> does it have credentials. This could be used in the demo for the
>>>>> 'database-service', which would mean we'd have roles associated with the
>>>>> 'database-service' rather than using realm roles. It would also provide
>>>>> an
>>>>> installation file (and wildfly config) where 'bearer-only' is set to
>>>>> 'true'.
>>>>
>>>> We need to think of this in terms of OAuth grants.  i.e.  You have one
>>>> Keycloak server that wants to export/migrate metadata from its realm(s)
>>>> to another Keycloak server.  You have a service like Aerogear UPS where
>>>> you want to grant it temporary permission to define applications within
>>>> the realm.
>>>
>>> I don't see how what I proposed doesn't work with OAuth grants.
>>>
>>>>
>>>> This is why I think the best approach would be to create an application
>>>> per-realm that represents realm management.  The application would just
>>>> be named "realm-management", just like we already have for "account".
>>>> This way these admin roles to mix or pollute anything user specific.  We
>>>> would also create an application within the "keycloak-admin" realm with
>>>> similar role definitions.
>>>>
>>>> With the above setup, we would have "keycloak-admin" users who would
>>>> have various permissions on *ALL* realms.  And per realm users that have
>>>> permissions for one *specific* realm.  But, there would not be a concept
>>>> of a user that has permissions on a subset of realms.  It could be
>>>> access to 1 realm, or access to all realms.
>>>
>>> This sounds messy to me. It means you end up with having to manage access
>>> to a realm in two different realms. Also, for admin console you'd have to
>>> have an option of selecting what realm to login to. Anyone that is only
>>> given access to one or two realms would have to re-login to swap or
>>> something.
>>>
>>
>> I was actually agreeing with your original post, but I don't think I
>> fully understood your original post! I might understand now.  Is this
>> what you mean?
>>
>> * Create an application within "keycloak-admin" for each new realm
>> * Under that application create all the roles mentioned in the OP.
>> * Create a realm level composite role named "superuser".  When a new
>> realm is created, associate all those new application roles to this
>> superuser composite.
>>
>> Then, when you log into the admin console, the server just checks which
>> roles you have assigned to you to fill the realm selection box on the
>> admin console main page.
>
> Yes, emails can be confusing sometimes ;)
>
> Just to be 100% sure, I'll do an example (should have done this in the first place):
>
> * There's 3 realms: 'keycloak-admin', 'realm-a' and 'realm-b'
> * Inside 'keycloak-admin' there's apps 'realm-a-management' and 'realm-b-management' (these are created/deleted as realms are created/deleted)
> * Each of 'realm-a-management' and 'realm-b-mananagement' have roles 'view-realm', 'manage-realm', etc.. There's also have an app composite role 'realm-admin' that maps to all the other roles in the app (again these roles are created when a realm is created)
> * The 'keycloak-admin' has a single composite role 'realms-admin' that maps to 'realm-admin' roles in both 'realm-a-management' and 'realm-b-management' (again this is updated has realms are created/deleted)


Very cool!  let me know if you don't have time to work on it and I'll 
head to that after I do refresh tokens.

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

From bburke at redhat.com  Thu Feb 20 15:34:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 15:34:38 -0500
Subject: [keycloak-dev] Why access code is in memory
In-Reply-To: <530633BC.2050901@redhat.com>
References: <530582B0.5090104@redhat.com>
	<5305CCA5.4010807@redhat.com>	<53062397.4080201@redhat.com>	<1056701250.13063656.1392912197407.JavaMail.zimbra@redhat.com>	<53062B1D.8080506@redhat.com>	<2027039365.13100567.1392913433844.JavaMail.zimbra@redhat.com>
	<530633BC.2050901@redhat.com>
Message-ID: <530666DE.8010804@redhat.com>

I remember one of the reasons access code is in memory.  When a code is 
turned into a token, the code is removed.  Thus, the code can only be 
used once and only once to obtain an access token.  This can be 
mitigated of course by timeouts on the access code.

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

From bburke at redhat.com  Thu Feb 20 15:54:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 15:54:01 -0500
Subject: [keycloak-dev] caching
Message-ID: <53066B69.2090201@redhat.com>

What's been brewing around in my mind awhile is optimization of the 
token service.  There's no reason everything couldn't be cached in 
memory for each token service deployed.  Even millions of users could be 
cache.  Memory is cheap.

The cache should be local only and only the Token Service should use it. 
  Admin console, or any other update operations would cause invalidation 
of each cache on each machine by sending invalidation messages.  These 
invalidation messages would be REST invocation secured by Keycloak of 
course!  If we wanted to put in any guarantees, we could back these 
invalidation messages with HornetQ or something.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Feb 20 17:26:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Feb 2014 17:26:05 -0500
Subject: [keycloak-dev] /tokens/access/codes now uses Basic Auth
Message-ID: <530680FD.3070904@redhat.com>

Since we're using client secret now to authenticate clients, I changed 
the protocol to use Basic Auth as per the OAuth and OpenId Connect 
specs.  I updated the javascript adapter to use basic auth (I think), 
but I don't have an app to test against.


P.S.

I hear Marek laughing and/or cursing at me in the background...
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Fri Feb 21 03:12:33 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Feb 2014 09:12:33 +0100
Subject: [keycloak-dev] Why access code is in memory
In-Reply-To: <530666DE.8010804@redhat.com>
References: <530582B0.5090104@redhat.com>	<5305CCA5.4010807@redhat.com>	<53062397.4080201@redhat.com>	<1056701250.13063656.1392912197407.JavaMail.zimbra@redhat.com>	<53062B1D.8080506@redhat.com>	<2027039365.13100567.1392913433844.JavaMail.zimbra@redhat.com>	<530633BC.2050901@redhat.com>
	<530666DE.8010804@redhat.com>
Message-ID: <53070A71.2010500@redhat.com>

ah yes, there is this in OAuth2 specs section 4.1.2:

If an authorization code is used more than
          once, the authorization server MUST deny the request and SHOULD
          revoke (when possible) all tokens previously issued based on
          that authorization code.


I wonder if Infinispan is the way to go? This will address both clustering (replication) and memory leak (expiration). Or you want to avoid this?

Marek


On 20.2.2014 21:34, Bill Burke wrote:
> I remember one of the reasons access code is in memory.  When a code is
> turned into a token, the code is removed.  Thus, the code can only be
> used once and only once to obtain an access token.  This can be
> mitigated of course by timeouts on the access code.
>

From mposolda at redhat.com  Fri Feb 21 03:18:10 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Feb 2014 09:18:10 +0100
Subject: [keycloak-dev] /tokens/access/codes now uses Basic Auth
In-Reply-To: <530680FD.3070904@redhat.com>
References: <530680FD.3070904@redhat.com>
Message-ID: <53070BC2.80307@redhat.com>

On 20.2.2014 23:26, Bill Burke wrote:
> Since we're using client secret now to authenticate clients, I changed
> the protocol to use Basic Auth as per the OAuth and OpenId Connect
> specs.  I updated the javascript adapter to use basic auth (I think),
> but I don't have an app to test against.
>
>
> P.S.
>
> I hear Marek laughing and/or cursing at me in the background...
You say that:-)
For JS apps, we may also need to test cors, which I mentioned in 
https://issues.jboss.org/browse/KEYCLOAK-328

Isn't the app here 
https://github.com/keycloak/keycloak/tree/master/examples/demo-template/customer-app-js 
?

Marek

From stian at redhat.com  Fri Feb 21 04:04:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 21 Feb 2014 04:04:05 -0500 (EST)
Subject: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
In-Reply-To: <530656A4.1040909@redhat.com>
References: <1622166776.12954320.1392908715741.JavaMail.zimbra@redhat.com>
	<5306280D.2030203@redhat.com>
	<2071239345.13092688.1392913261011.JavaMail.zimbra@redhat.com>
	<53063344.4050202@redhat.com>
	<1609362061.13207830.1392916980949.JavaMail.zimbra@redhat.com>
	<530656A4.1040909@redhat.com>
Message-ID: <1063477360.13588244.1392973445240.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, 20 February, 2014 7:25:24 PM
> Subject: Re: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
> 
> 
> 
> On 2/20/2014 12:23 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, 20 February, 2014 4:54:28 PM
> >> Subject: Re: [keycloak-dev] Authz for admin console/endpoints
> >> (KEYCLOAK-292)
> >>
> >>
> >>
> >> On 2/20/2014 11:21 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 20 February, 2014 4:06:37 PM
> >>>> Subject: Re: [keycloak-dev] Authz for admin console/endpoints
> >>>> (KEYCLOAK-292)
> >>>>
> >>>>
> >>>>
> >>>> On 2/20/2014 10:05 AM, Stian Thorgersen wrote:
> >>>>> Currently a user in the 'keycloak-admin' realm with the role 'admin'
> >>>>> has
> >>>>> full access to all realms. We need to support a bit more fine-grained
> >>>>> access control for admin console/endpoints. At the bare minimum we need
> >>>>> to
> >>>>> be able to have users that can administer only some realms. Further, it
> >>>>> would be nice to build this on-top of roles alone and not require an
> >>>>> ACL
> >>>>> table or something similar.
> >>>>>
> >>>>> We could start with the following permissions/roles for a realm:
> >>>>>
> >>>>> * view-realm-config
> >>>>> * manage-realm-config
> >>>>> * view-users
> >>>>> * manage-users
> >>>>> * view-applications
> >>>>> * manage-applications
> >>>>> * view-clients
> >>>>> * manage-clients
> >>>>> * admin (composite role containing all the above roles)
> >>>>>
> >>>>> One approach to this would be to create an application per-realm that
> >>>>> represents that realm (application name could be 'realm-<realm name>').
> >>>>> This would be created automatically when we create a new realm, and it
> >>>>> would have the above roles as application roles. Users can then be
> >>>>> granted
> >>>>> access to individual realms by mapping the roles for the associated
> >>>>> application to them.
> >>>>>
> >>>>> We could also have a composite realm role 'admin' that maps to the
> >>>>> 'admin'
> >>>>> role in all realm applications. Any user that is granted this role
> >>>>> would
> >>>>> have full access to all realms.
> >>>>>
> >>>>> This made me think about the concept of "resources" in Keycloak. A
> >>>>> resource
> >>>>> is similar to an application except it doesn't have scope mappings, nor
> >>>>> does it have credentials. This could be used in the demo for the
> >>>>> 'database-service', which would mean we'd have roles associated with
> >>>>> the
> >>>>> 'database-service' rather than using realm roles. It would also provide
> >>>>> an
> >>>>> installation file (and wildfly config) where 'bearer-only' is set to
> >>>>> 'true'.
> >>>>
> >>>> We need to think of this in terms of OAuth grants.  i.e.  You have one
> >>>> Keycloak server that wants to export/migrate metadata from its realm(s)
> >>>> to another Keycloak server.  You have a service like Aerogear UPS where
> >>>> you want to grant it temporary permission to define applications within
> >>>> the realm.
> >>>
> >>> I don't see how what I proposed doesn't work with OAuth grants.
> >>>
> >>>>
> >>>> This is why I think the best approach would be to create an application
> >>>> per-realm that represents realm management.  The application would just
> >>>> be named "realm-management", just like we already have for "account".
> >>>> This way these admin roles to mix or pollute anything user specific.  We
> >>>> would also create an application within the "keycloak-admin" realm with
> >>>> similar role definitions.
> >>>>
> >>>> With the above setup, we would have "keycloak-admin" users who would
> >>>> have various permissions on *ALL* realms.  And per realm users that have
> >>>> permissions for one *specific* realm.  But, there would not be a concept
> >>>> of a user that has permissions on a subset of realms.  It could be
> >>>> access to 1 realm, or access to all realms.
> >>>
> >>> This sounds messy to me. It means you end up with having to manage access
> >>> to a realm in two different realms. Also, for admin console you'd have to
> >>> have an option of selecting what realm to login to. Anyone that is only
> >>> given access to one or two realms would have to re-login to swap or
> >>> something.
> >>>
> >>
> >> I was actually agreeing with your original post, but I don't think I
> >> fully understood your original post! I might understand now.  Is this
> >> what you mean?
> >>
> >> * Create an application within "keycloak-admin" for each new realm
> >> * Under that application create all the roles mentioned in the OP.
> >> * Create a realm level composite role named "superuser".  When a new
> >> realm is created, associate all those new application roles to this
> >> superuser composite.
> >>
> >> Then, when you log into the admin console, the server just checks which
> >> roles you have assigned to you to fill the realm selection box on the
> >> admin console main page.
> >
> > Yes, emails can be confusing sometimes ;)
> >
> > Just to be 100% sure, I'll do an example (should have done this in the
> > first place):
> >
> > * There's 3 realms: 'keycloak-admin', 'realm-a' and 'realm-b'
> > * Inside 'keycloak-admin' there's apps 'realm-a-management' and
> > 'realm-b-management' (these are created/deleted as realms are
> > created/deleted)
> > * Each of 'realm-a-management' and 'realm-b-mananagement' have roles
> > 'view-realm', 'manage-realm', etc.. There's also have an app composite
> > role 'realm-admin' that maps to all the other roles in the app (again
> > these roles are created when a realm is created)
> > * The 'keycloak-admin' has a single composite role 'realms-admin' that maps
> > to 'realm-admin' roles in both 'realm-a-management' and
> > 'realm-b-management' (again this is updated has realms are
> > created/deleted)
> 
> 
> Very cool!  let me know if you don't have time to work on it and I'll
> head to that after I do refresh tokens.

I thought you where adding the complete OpenID connect spec ;)

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

From stian at redhat.com  Fri Feb 21 04:07:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 21 Feb 2014 04:07:40 -0500 (EST)
Subject: [keycloak-dev] Why access code is in memory
In-Reply-To: <53070A71.2010500@redhat.com>
References: <530582B0.5090104@redhat.com> <53062397.4080201@redhat.com>
	<1056701250.13063656.1392912197407.JavaMail.zimbra@redhat.com>
	<53062B1D.8080506@redhat.com>
	<2027039365.13100567.1392913433844.JavaMail.zimbra@redhat.com>
	<530633BC.2050901@redhat.com> <530666DE.8010804@redhat.com>
	<53070A71.2010500@redhat.com>
Message-ID: <1908966554.13589091.1392973660028.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Friday, 21 February, 2014 8:12:33 AM
> Subject: Re: [keycloak-dev] Why access code is in memory
> 
> ah yes, there is this in OAuth2 specs section 4.1.2:
> 
> If an authorization code is used more than
>           once, the authorization server MUST deny the request and SHOULD
>           revoke (when possible) all tokens previously issued based on
>           that authorization code.
> 
> 
> I wonder if Infinispan is the way to go? This will address both clustering
> (replication) and memory leak (expiration). Or you want to avoid this?

Looks like what we'll need to do, unless we store in DB (but that makes expiration a headache). Sticky sessions probably wouldn't work either as it's not code is given to the browser, and may be swapped to token by a server-side app on a different IP.

> 
> Marek
> 
> 
> On 20.2.2014 21:34, Bill Burke wrote:
> > I remember one of the reasons access code is in memory.  When a code is
> > turned into a token, the code is removed.  Thus, the code can only be
> > used once and only once to obtain an access token.  This can be
> > mitigated of course by timeouts on the access code.
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Feb 21 04:14:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 21 Feb 2014 04:14:41 -0500 (EST)
Subject: [keycloak-dev] caching
In-Reply-To: <53066B69.2090201@redhat.com>
References: <53066B69.2090201@redhat.com>
Message-ID: <1043396288.13591010.1392974081968.JavaMail.zimbra@redhat.com>

Initially I think using Infinispan as a 2nd level cache for JPA would be the way to go. It provides all of this stuff with the minimum fuzz. Later if we can't tune it enough, we could use Infinispan directly.

For really huge deployments I we'd probably need support for sharding as well.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 February, 2014 8:54:01 PM
> Subject: [keycloak-dev] caching
> 
> What's been brewing around in my mind awhile is optimization of the
> token service.  There's no reason everything couldn't be cached in
> memory for each token service deployed.  Even millions of users could be
> cache.  Memory is cheap.
> 
> The cache should be local only and only the Token Service should use it.
>   Admin console, or any other update operations would cause invalidation
> of each cache on each machine by sending invalidation messages.  These
> invalidation messages would be REST invocation secured by Keycloak of
> course!  If we wanted to put in any guarantees, we could back these
> invalidation messages with HornetQ or something.
> --
> 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 Feb 21 05:52:23 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 21 Feb 2014 05:52:23 -0500 (EST)
Subject: [keycloak-dev] /tokens/access/codes now uses Basic Auth
In-Reply-To: <530680FD.3070904@redhat.com>
References: <530680FD.3070904@redhat.com>
Message-ID: <1386159520.13629089.1392979943648.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 February, 2014 10:26:05 PM
> Subject: [keycloak-dev] /tokens/access/codes now uses Basic Auth
> 
> Since we're using client secret now to authenticate clients, I changed
> the protocol to use Basic Auth as per the OAuth and OpenId Connect
> specs.  I updated the javascript adapter to use basic auth (I think),
> but I don't have an app to test against.

Checked and it works fine. 

I added customer-portal-js to example, but didn't get around to updating docs on how to deploy it. Currently you need to edit the html to set the realm, clientId and clientSecret before deploying.

What I've used to test it with is:

<html>
<head>
    <script src="keycloak.js"></script>
</head>
<body>
<button onclick="keycloak.login()">Login</button>

<script>
    var keycloak = Keycloak({ realm: 'test', clientId: 'test', clientSecret: '17c72dd3-a26c-40e7-91a3-cbbb1636789c' });

    keycloak.init(function () {
        console.debug('Token: ' + keycloak.tokenParsed);
        console.debug('Realm access: ' + keycloak.realmAccess);
        console.debug('Resource access: ' + keycloak.resourceAccess);

        keycloak.loadUserProfile(function (profile) {
            console.debug(profile);
        }, function (error) {
            console.debug(error);
        })
    });
</script>
</body>
</html>


> 
> 
> P.S.
> 
> I hear Marek laughing and/or cursing at me in the background...
> --
> 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 Feb 21 08:30:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Feb 2014 08:30:48 -0500
Subject: [keycloak-dev] Why access code is in memory
In-Reply-To: <53070A71.2010500@redhat.com>
References: <530582B0.5090104@redhat.com>	<5305CCA5.4010807@redhat.com>	<53062397.4080201@redhat.com>	<1056701250.13063656.1392912197407.JavaMail.zimbra@redhat.com>	<53062B1D.8080506@redhat.com>	<2027039365.13100567.1392913433844.JavaMail.zimbra@redhat.com>	<530633BC.2050901@redhat.com>
	<530666DE.8010804@redhat.com> <53070A71.2010500@redhat.com>
Message-ID: <53075508.2020704@redhat.com>

OpenID Connect say you SHOULD:

"An Attacker attempts to use a one-time use token such as an 
Authorization Code that has already been used once with the intended 
Resource. To mitigate this threat, the token SHOULD include a timestamp 
and a short validity lifetime. The Relying Party then checks the 
timestamp and lifetime values to ensure that the token is currently valid.

Alternatively, the server MAY record the state of the use of the token 
and check the status for each request."


I don't want to use Infinispan, at least as a distributed cache. 
Because then you have to secure that communication as well and it might 
be a headache in Openshift deployments.

On 2/21/2014 3:12 AM, Marek Posolda wrote:
> ah yes, there is this in OAuth2 specs section 4.1.2:
>
> If an authorization code is used more than
>           once, the authorization server MUST deny the request and SHOULD
>           revoke (when possible) all tokens previously issued based on
>           that authorization code.
>
>
> I wonder if Infinispan is the way to go? This will address both
> clustering (replication) and memory leak (expiration). Or you want to
> avoid this?
>
> Marek
>
>
> On 20.2.2014 21:34, Bill Burke wrote:
>> I remember one of the reasons access code is in memory.  When a code is
>> turned into a token, the code is removed.  Thus, the code can only be
>> used once and only once to obtain an access token.  This can be
>> mitigated of course by timeouts on the access code.
>>

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

From bburke at redhat.com  Fri Feb 21 08:41:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Feb 2014 08:41:52 -0500
Subject: [keycloak-dev] caching
In-Reply-To: <1043396288.13591010.1392974081968.JavaMail.zimbra@redhat.com>
References: <53066B69.2090201@redhat.com>
	<1043396288.13591010.1392974081968.JavaMail.zimbra@redhat.com>
Message-ID: <530757A0.5060102@redhat.com>

I don't want to require a distributed cache.  It may make both securing 
this cache, configuring, and deploying it much more complicated than we 
want it to be.  Especially in an environment like Openshift.  Don't you 
think?  Plus there's things that can be stored in a non-JPA cache.  i.e. 
you can pre-calculate role mappings, scope mappings, access grants. 
Then all you have to do is marshall the tokens into json and sign them.

As far as huge deployments goes, define huge?  Even a realm with 1 
million users would probably be around 10GiG, which is very easy to 
handle for most modern databases.

On 2/21/2014 4:14 AM, Stian Thorgersen wrote:
> Initially I think using Infinispan as a 2nd level cache for JPA would be the way to go. It provides all of this stuff with the minimum fuzz. Later if we can't tune it enough, we could use Infinispan directly.
>
> For really huge deployments I we'd probably need support for sharding as well.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 20 February, 2014 8:54:01 PM
>> Subject: [keycloak-dev] caching
>>
>> What's been brewing around in my mind awhile is optimization of the
>> token service.  There's no reason everything couldn't be cached in
>> memory for each token service deployed.  Even millions of users could be
>> cache.  Memory is cheap.
>>
>> The cache should be local only and only the Token Service should use it.
>>    Admin console, or any other update operations would cause invalidation
>> of each cache on each machine by sending invalidation messages.  These
>> invalidation messages would be REST invocation secured by Keycloak of
>> course!  If we wanted to put in any guarantees, we could back these
>> invalidation messages with HornetQ or something.
>> --
>> 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 Feb 21 08:47:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Feb 2014 08:47:17 -0500
Subject: [keycloak-dev] Authz for admin console/endpoints (KEYCLOAK-292)
In-Reply-To: <1063477360.13588244.1392973445240.JavaMail.zimbra@redhat.com>
References: <1622166776.12954320.1392908715741.JavaMail.zimbra@redhat.com>
	<5306280D.2030203@redhat.com>
	<2071239345.13092688.1392913261011.JavaMail.zimbra@redhat.com>
	<53063344.4050202@redhat.com>
	<1609362061.13207830.1392916980949.JavaMail.zimbra@redhat.com>
	<530656A4.1040909@redhat.com>
	<1063477360.13588244.1392973445240.JavaMail.zimbra@redhat.com>
Message-ID: <530758E5.7060700@redhat.com>



On 2/21/2014 4:04 AM, Stian Thorgersen wrote:
>> Very cool!  let me know if you don't have time to work on it and I'll
>> head to that after I do refresh tokens.
>
> I thought you where adding the complete OpenID connect spec ;)
>

Hey! :)  Yes, I'm going to implement the required parts.  I really don't 
think we're that far off as we already use JWT, JWS, and are based on 
OAuth.  A lot of the fine details of the specification is OPTIONAL.


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

From bburke at redhat.com  Fri Feb 21 08:48:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Feb 2014 08:48:32 -0500
Subject: [keycloak-dev] /tokens/access/codes now uses Basic Auth
In-Reply-To: <53070BC2.80307@redhat.com>
References: <530680FD.3070904@redhat.com> <53070BC2.80307@redhat.com>
Message-ID: <53075930.2000303@redhat.com>



On 2/21/2014 3:18 AM, Marek Posolda wrote:
> On 20.2.2014 23:26, Bill Burke wrote:
>> Since we're using client secret now to authenticate clients, I changed
>> the protocol to use Basic Auth as per the OAuth and OpenId Connect
>> specs.  I updated the javascript adapter to use basic auth (I think),
>> but I don't have an app to test against.
>>
>>
>> P.S.
>>
>> I hear Marek laughing and/or cursing at me in the background...
> You say that:-)
> For JS apps, we may also need to test cors, which I mentioned in
> https://issues.jboss.org/browse/KEYCLOAK-328
>
> Isn't the app here
> https://github.com/keycloak/keycloak/tree/master/examples/demo-template/customer-app-js
> ?
>

BTW, looking at OpenID connect there are multiple options you can 
configure for client authentication, Basic Auth is only one of them.



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

From stian at redhat.com  Fri Feb 21 09:13:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 21 Feb 2014 09:13:39 -0500 (EST)
Subject: [keycloak-dev] caching
In-Reply-To: <530757A0.5060102@redhat.com>
References: <53066B69.2090201@redhat.com>
	<1043396288.13591010.1392974081968.JavaMail.zimbra@redhat.com>
	<530757A0.5060102@redhat.com>
Message-ID: <217493828.13774325.1392992019477.JavaMail.zimbra@redhat.com>

I agree that there are headaches involved in a distributed cache, but they will always be an issue if you have a cache.

You're going to need to have some mechanism to invalidate entries in the cache whenever there's an update to the db. Infinispan provides various mechanisms to expire unused items, and it also has multiple clustering modes where the most interesting to us would be invalidation not replication. In invalidation mode the actual data isn't sent on the network, so should be less risky with regards to security.

I would also hope that Infinispan supports OpenShift, or plans to soon.

Non-JPA cache I agree with is the better option, but it may prove to be a fair amount of work, and possible error-prone. I've done this in the past and it was a real PITA to write and maintain.

>From your previous mail on OpenID connect spec and codes it sounds like it's fine for us to encode/encrypt the full access code entry into the code, as we already have a short lifespan on these. That would mean we'd not need any clustering of that, which would be great. Same goes with SocialManager, we can encode/encrypt everything into the state variable for OAuth2 enabled providers, leaving only Twitter as a problem (we could use a cookie in that case).

With regards to huge deployments, I think the dream figure for LiveOak is millions of developers. For those numbers I think sharding is the only viable option. AFAIK DB doesn't like millions of entries in a table, especially not with joins.

----- 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, 21 February, 2014 1:41:52 PM
> Subject: Re: [keycloak-dev] caching
> 
> I don't want to require a distributed cache.  It may make both securing
> this cache, configuring, and deploying it much more complicated than we
> want it to be.  Especially in an environment like Openshift.  Don't you
> think?  Plus there's things that can be stored in a non-JPA cache.  i.e.
> you can pre-calculate role mappings, scope mappings, access grants.
> Then all you have to do is marshall the tokens into json and sign them.
> 
> As far as huge deployments goes, define huge?  Even a realm with 1
> million users would probably be around 10GiG, which is very easy to
> handle for most modern databases.
> 
> On 2/21/2014 4:14 AM, Stian Thorgersen wrote:
> > Initially I think using Infinispan as a 2nd level cache for JPA would be
> > the way to go. It provides all of this stuff with the minimum fuzz. Later
> > if we can't tune it enough, we could use Infinispan directly.
> >
> > For really huge deployments I we'd probably need support for sharding as
> > well.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 20 February, 2014 8:54:01 PM
> >> Subject: [keycloak-dev] caching
> >>
> >> What's been brewing around in my mind awhile is optimization of the
> >> token service.  There's no reason everything couldn't be cached in
> >> memory for each token service deployed.  Even millions of users could be
> >> cache.  Memory is cheap.
> >>
> >> The cache should be local only and only the Token Service should use it.
> >>    Admin console, or any other update operations would cause invalidation
> >> of each cache on each machine by sending invalidation messages.  These
> >> invalidation messages would be REST invocation secured by Keycloak of
> >> course!  If we wanted to put in any guarantees, we could back these
> >> invalidation messages with HornetQ or something.
> >> --
> >> 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 Feb 21 09:43:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Feb 2014 09:43:15 -0500
Subject: [keycloak-dev] caching
In-Reply-To: <217493828.13774325.1392992019477.JavaMail.zimbra@redhat.com>
References: <53066B69.2090201@redhat.com>
	<1043396288.13591010.1392974081968.JavaMail.zimbra@redhat.com>
	<530757A0.5060102@redhat.com>
	<217493828.13774325.1392992019477.JavaMail.zimbra@redhat.com>
Message-ID: <53076603.5040300@redhat.com>



On 2/21/2014 9:13 AM, Stian Thorgersen wrote:
> I agree that there are headaches involved in a distributed cache, but they will always be an issue if you have a cache.
>
> You're going to need to have some mechanism to invalidate entries in the cache whenever there's an update to the db. Infinispan provides various mechanisms to expire unused items, and it also has multiple clustering modes where the most interesting to us would be invalidation not replication. In invalidation mode the actual data isn't sent on the network, so should be less risky with regards to security.
>

Not sending data is the reason I want to do invalidation.  But again, 
even in that scenario, we have to figure out how to secure Infinispan. 
I'd also like to keep us using HTTP as a primary transport.

> I would also hope that Infinispan supports OpenShift, or plans to soon.
>
> Non-JPA cache I agree with is the better option, but it may prove to be a fair amount of work, and possible error-prone. I've done this in the past and it was a real PITA to write and maintain.
>

I've done it too.  Its not so much of a pain if you're only reading from 
the cache and you're doing invalidation.

If a Keycloak non-jpa cache API existed, then we could also put it in 
front of non-JPA backends, like if we decided to make Picktelink IDM API 
our primary storage backend.

BTW, I don't want to roll my own cache, I'd just like to use a 
local-only deployment of Infinispan or something and write our own 
remote invalidation protocol.

Anyways, this is a few months away, IMO before we even start to consider 
to work on this.  Just something to think about.


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

From stian at redhat.com  Fri Feb 21 09:48:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 21 Feb 2014 09:48:50 -0500 (EST)
Subject: [keycloak-dev] caching
In-Reply-To: <53076603.5040300@redhat.com>
References: <53066B69.2090201@redhat.com>
	<1043396288.13591010.1392974081968.JavaMail.zimbra@redhat.com>
	<530757A0.5060102@redhat.com>
	<217493828.13774325.1392992019477.JavaMail.zimbra@redhat.com>
	<53076603.5040300@redhat.com>
Message-ID: <361590245.13798776.1392994130235.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, 21 February, 2014 2:43:15 PM
> Subject: Re: [keycloak-dev] caching
> 
> 
> 
> On 2/21/2014 9:13 AM, Stian Thorgersen wrote:
> > I agree that there are headaches involved in a distributed cache, but they
> > will always be an issue if you have a cache.
> >
> > You're going to need to have some mechanism to invalidate entries in the
> > cache whenever there's an update to the db. Infinispan provides various
> > mechanisms to expire unused items, and it also has multiple clustering
> > modes where the most interesting to us would be invalidation not
> > replication. In invalidation mode the actual data isn't sent on the
> > network, so should be less risky with regards to security.
> >
> 
> Not sending data is the reason I want to do invalidation.  But again,
> even in that scenario, we have to figure out how to secure Infinispan.
> I'd also like to keep us using HTTP as a primary transport.
> 
> > I would also hope that Infinispan supports OpenShift, or plans to soon.
> >
> > Non-JPA cache I agree with is the better option, but it may prove to be a
> > fair amount of work, and possible error-prone. I've done this in the past
> > and it was a real PITA to write and maintain.
> >
> 
> I've done it too.  Its not so much of a pain if you're only reading from
> the cache and you're doing invalidation.
> 
> If a Keycloak non-jpa cache API existed, then we could also put it in
> front of non-JPA backends, like if we decided to make Picktelink IDM API
> our primary storage backend.
> 
> BTW, I don't want to roll my own cache, I'd just like to use a
> local-only deployment of Infinispan or something and write our own
> remote invalidation protocol.
> 
> Anyways, this is a few months away, IMO before we even start to consider
> to work on this.  Just something to think about.

Definitively, it's an interesting problem though ;)

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

From mposolda at redhat.com  Fri Feb 21 13:07:14 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Feb 2014 19:07:14 +0100
Subject: [keycloak-dev] Semantics of Realm.get***ById()
Message-ID: <530795D2.6080104@redhat.com>

Hi,

Felt into an issue when trying to fix testsuite with Mongo and adding 
more unit tests... Currently when we call realm.getRoleById("123") it 
will always return the role with ID "123" even if this role belongs to 
different realm or it's application role. For JPA model, there is 
usually just call to: RoleEntity entity = em.find(RoleEntity.class, id);

Nothing, which checks that role with this ID belongs to this realm. I am 
not sure how to address this. I can see options:

1) Change the semantics, so that realm.getRoleById("123") will return 
role just in case that it belongs to this realm/application. This means 
that instead of em.find(RoleEntity.class, id) we will need to use named 
query for both roleId and realm. This will affect performance...

2) Move methods like "getRoleById", "getApplicationById", "getUserById" 
etc. from RealmModel to IdentitySession as it would be global search 
(not just in context of the particular Realm). This will require some 
changes in impl, as for example RoleAdapter or ApplicationAdapter wants 
access to RealmModel right now.

3) Keep current behaviour and live with the fact that "get***ById()" may 
return entity from different realm.

To me, it seems that option 3 is fine and won't affect performance, but 
wanted to ask for sure.

Marek

From bburke at redhat.com  Fri Feb 21 13:14:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Feb 2014 13:14:57 -0500
Subject: [keycloak-dev] Semantics of Realm.get***ById()
In-Reply-To: <530795D2.6080104@redhat.com>
References: <530795D2.6080104@redhat.com>
Message-ID: <530797A1.6030406@redhat.com>



On 2/21/2014 1:07 PM, Marek Posolda wrote:
> Hi,
>
> Felt into an issue when trying to fix testsuite with Mongo and adding
> more unit tests... Currently when we call realm.getRoleById("123") it
> will always return the role with ID "123" even if this role belongs to
> different realm or it's application role. For JPA model, there is
> usually just call to: RoleEntity entity = em.find(RoleEntity.class, id);
>
> Nothing, which checks that role with this ID belongs to this realm. I am
> not sure how to address this. I can see options:
>
> 1) Change the semantics, so that realm.getRoleById("123") will return
> role just in case that it belongs to this realm/application. This means
> that instead of em.find(RoleEntity.class, id) we will need to use named
> query for both roleId and realm. This will affect performance...
>
> 2) Move methods like "getRoleById", "getApplicationById", "getUserById"
> etc. from RealmModel to IdentitySession as it would be global search
> (not just in context of the particular Realm). This will require some
> changes in impl, as for example RoleAdapter or ApplicationAdapter wants
> access to RealmModel right now.
>
> 3) Keep current behaviour and live with the fact that "get***ById()" may
> return entity from different realm.
>
> To me, it seems that option 3 is fine and won't affect performance, but
> wanted to ask for sure.
>

4) Add a realm ManyToOne relationship to Role, app, and user.  Return 
null if em.find() returns an entity not defined in the realm?

Bill

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

From mposolda at redhat.com  Fri Feb 21 13:34:14 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Feb 2014 19:34:14 +0100
Subject: [keycloak-dev] Semantics of Realm.get***ById()
In-Reply-To: <530797A1.6030406@redhat.com>
References: <530795D2.6080104@redhat.com> <530797A1.6030406@redhat.com>
Message-ID: <53079C26.8020905@redhat.com>

On 21.2.2014 19:14, Bill Burke wrote:
>
> On 2/21/2014 1:07 PM, Marek Posolda wrote:
>> Hi,
>>
>> Felt into an issue when trying to fix testsuite with Mongo and adding
>> more unit tests... Currently when we call realm.getRoleById("123") it
>> will always return the role with ID "123" even if this role belongs to
>> different realm or it's application role. For JPA model, there is
>> usually just call to: RoleEntity entity = em.find(RoleEntity.class, id);
>>
>> Nothing, which checks that role with this ID belongs to this realm. I am
>> not sure how to address this. I can see options:
>>
>> 1) Change the semantics, so that realm.getRoleById("123") will return
>> role just in case that it belongs to this realm/application. This means
>> that instead of em.find(RoleEntity.class, id) we will need to use named
>> query for both roleId and realm. This will affect performance...
>>
>> 2) Move methods like "getRoleById", "getApplicationById", "getUserById"
>> etc. from RealmModel to IdentitySession as it would be global search
>> (not just in context of the particular Realm). This will require some
>> changes in impl, as for example RoleAdapter or ApplicationAdapter wants
>> access to RealmModel right now.
>>
>> 3) Keep current behaviour and live with the fact that "get***ById()" may
>> return entity from different realm.
>>
>> To me, it seems that option 3 is fine and won't affect performance, but
>> wanted to ask for sure.
>>
> 4) Add a realm ManyToOne relationship to Role, app, and user.  Return
> null if em.find() returns an entity not defined in the realm?
Looks fine, likely also affects performance a bit as it would need to 
join the realm, but likely not much. I will do that and send PR.

Marek




>
> Bill
>


From bburke at redhat.com  Sun Feb 23 11:35:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Sun, 23 Feb 2014 11:35:16 -0500
Subject: [keycloak-dev] social login and remember me
Message-ID: <530A2344.6050006@redhat.com>

I implemented "Remember Me" for regular login.  The problem is, it won't 
work for social because social login using an href so "remember me" 
checkbox will not get propagated.

* Social login links need to be turned into a form containing a img 
submit button for each, correct?
* Where should "Remember Me" go?   Have 2 Remember Me checkboxes?


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

From stian at redhat.com  Mon Feb 24 06:54:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 24 Feb 2014 06:54:06 -0500 (EST)
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <530A2344.6050006@redhat.com>
References: <530A2344.6050006@redhat.com>
Message-ID: <1306764301.14672301.1393242846711.JavaMail.zimbra@redhat.com>

Having more than one "remember me" checkbox on the page would be confusing/messy I think.

Links can be replaced with buttons by simply changing <a class="zocial ${p.id}"> with <button class="zocial ${p.id}">. No need for img buttons as the styling works for buttons as well.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, 23 February, 2014 4:35:16 PM
> Subject: [keycloak-dev] social login and remember me
> 
> I implemented "Remember Me" for regular login.  The problem is, it won't
> work for social because social login using an href so "remember me"
> checkbox will not get propagated.
> 
> * Social login links need to be turned into a form containing a img
> submit button for each, correct?
> * Where should "Remember Me" go?   Have 2 Remember Me checkboxes?
> 
> 
> --
> 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 Feb 24 09:04:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 24 Feb 2014 09:04:36 -0500
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <1306764301.14672301.1393242846711.JavaMail.zimbra@redhat.com>
References: <530A2344.6050006@redhat.com>
	<1306764301.14672301.1393242846711.JavaMail.zimbra@redhat.com>
Message-ID: <530B5174.5050801@redhat.com>

Suggestions on where "remember me" should go then?  Patternfly has it 
under the username/password boxes.

On 2/24/2014 6:54 AM, Stian Thorgersen wrote:
> Having more than one "remember me" checkbox on the page would be confusing/messy I think.
>
> Links can be replaced with buttons by simply changing <a class="zocial ${p.id}"> with <button class="zocial ${p.id}">. No need for img buttons as the styling works for buttons as well.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Sunday, 23 February, 2014 4:35:16 PM
>> Subject: [keycloak-dev] social login and remember me
>>
>> I implemented "Remember Me" for regular login.  The problem is, it won't
>> work for social because social login using an href so "remember me"
>> checkbox will not get propagated.
>>
>> * Social login links need to be turned into a form containing a img
>> submit button for each, correct?
>> * Where should "Remember Me" go?   Have 2 Remember Me checkboxes?
>>
>>
>> --
>> 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 Feb 24 09:05:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 24 Feb 2014 09:05:22 -0500
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <530B5174.5050801@redhat.com>
References: <530A2344.6050006@redhat.com>	<1306764301.14672301.1393242846711.JavaMail.zimbra@redhat.com>
	<530B5174.5050801@redhat.com>
Message-ID: <530B51A2.5050001@redhat.com>

I should rephrase:  Suggestions on wehre "remember me" should go if 
there is a social login?

On 2/24/2014 9:04 AM, Bill Burke wrote:
> Suggestions on where "remember me" should go then?  Patternfly has it
> under the username/password boxes.
>
> On 2/24/2014 6:54 AM, Stian Thorgersen wrote:
>> Having more than one "remember me" checkbox on the page would be confusing/messy I think.
>>
>> Links can be replaced with buttons by simply changing <a class="zocial ${p.id}"> with <button class="zocial ${p.id}">. No need for img buttons as the styling works for buttons as well.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Sunday, 23 February, 2014 4:35:16 PM
>>> Subject: [keycloak-dev] social login and remember me
>>>
>>> I implemented "Remember Me" for regular login.  The problem is, it won't
>>> work for social because social login using an href so "remember me"
>>> checkbox will not get propagated.
>>>
>>> * Social login links need to be turned into a form containing a img
>>> submit button for each, correct?
>>> * Where should "Remember Me" go?   Have 2 Remember Me checkboxes?
>>>
>>>
>>> --
>>> 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  Mon Feb 24 09:22:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 24 Feb 2014 09:22:34 -0500 (EST)
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <530B51A2.5050001@redhat.com>
References: <530A2344.6050006@redhat.com>
	<1306764301.14672301.1393242846711.JavaMail.zimbra@redhat.com>
	<530B5174.5050801@redhat.com> <530B51A2.5050001@redhat.com>
Message-ID: <431697034.14774298.1393251754796.JavaMail.zimbra@redhat.com>

Added Gabriel to see if he has a good idea

With the current L&F I can only think of two solutions (neither of which I particularly like):

1. Have it under username/password - probably means no-one is going to associate it with a social login
2. Have on under username/password and one under all social logins - I think this will look weird, and not convinced people will associate it with a particular login

Is there a way we can not require this for social logins? Social networks would already provide this mechanism so if we can somehow integrate with that, we wouldn't need it. One idea would be to set a cookie when a user has used a social login, then test if they are still logged in with that automatically.

Another thing to consider is when we introduce a "trust this machine" option as well. For example when you use multi-factor auth on Google, and at least a few other sites, they give you an option of trusting a particular machine/device so it won't ask for totp on every login. AFAIK Google asks you again for password after some days (30?!), but never asks for totp again on the same machine.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 24 February, 2014 2:05:22 PM
> Subject: Re: [keycloak-dev] social login and remember me
> 
> I should rephrase:  Suggestions on wehre "remember me" should go if
> there is a social login?
> 
> On 2/24/2014 9:04 AM, Bill Burke wrote:
> > Suggestions on where "remember me" should go then?  Patternfly has it
> > under the username/password boxes.
> >
> > On 2/24/2014 6:54 AM, Stian Thorgersen wrote:
> >> Having more than one "remember me" checkbox on the page would be
> >> confusing/messy I think.
> >>
> >> Links can be replaced with buttons by simply changing <a class="zocial
> >> ${p.id}"> with <button class="zocial ${p.id}">. No need for img buttons
> >> as the styling works for buttons as well.
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Sunday, 23 February, 2014 4:35:16 PM
> >>> Subject: [keycloak-dev] social login and remember me
> >>>
> >>> I implemented "Remember Me" for regular login.  The problem is, it won't
> >>> work for social because social login using an href so "remember me"
> >>> checkbox will not get propagated.
> >>>
> >>> * Social login links need to be turned into a form containing a img
> >>> submit button for each, correct?
> >>> * Where should "Remember Me" go?   Have 2 Remember Me checkboxes?
> >>>
> >>>
> >>> --
> >>> 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  Mon Feb 24 09:36:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 24 Feb 2014 09:36:45 -0500 (EST)
Subject: [keycloak-dev] Update on authz for admin console
In-Reply-To: <1018162552.14777408.1393251885552.JavaMail.zimbra@redhat.com>
Message-ID: <108359556.14798069.1393252605123.JavaMail.zimbra@redhat.com>

I've got fine-grained authz permissions working for the admin console now. There's 4 roles associated with each realm (represented as an app in keycloak-admin realm). These allows users to manage the realm, clients, applications and/or users. The admin console has also been updated to only show the sections a user has permissions to (for example if a user can only manage-users the settings, applications and clients links are not shown). Obviously rest endpoints check for permissions as well.

There's a few issues left that I'm working on:

* Need to fix refresh in admin - I'm hoping to use refresh tokens for this
* Admin needs to log out/log back in after creating realm - An admin (super) has access to all 4 roles for all realms. When a realm is created these roles are created as well, so the current token doesn't contain these roles.

AuthenticationManager was starting to become quite messy, so I extracted methods specific to admin console and account into a separate AppAuthManager. The token in the cookies created for these didn't use to include roles, which I've added to make it simpler to check for permissions.


If anyone wants to have a look at what I've got atm it's at:
https://github.com/stianst/keycloak/tree/admin-access

From bburke at redhat.com  Mon Feb 24 09:48:29 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 24 Feb 2014 09:48:29 -0500
Subject: [keycloak-dev] Update on authz for admin console
In-Reply-To: <108359556.14798069.1393252605123.JavaMail.zimbra@redhat.com>
References: <108359556.14798069.1393252605123.JavaMail.zimbra@redhat.com>
Message-ID: <530B5BBD.2080707@redhat.com>



On 2/24/2014 9:36 AM, Stian Thorgersen wrote:
> I've got fine-grained authz permissions working for the admin console now. There's 4 roles associated with each realm (represented as an app in keycloak-admin realm). These allows users to manage the realm, clients, applications and/or users. The admin console has also been updated to only show the sections a user has permissions to (for example if a user can only manage-users the settings, applications and clients links are not shown). Obviously rest endpoints check for permissions as well.
>
> There's a few issues left that I'm working on:
>
> * Need to fix refresh in admin - I'm hoping to use refresh tokens for this
> * Admin needs to log out/log back in after creating realm - An admin (super) has access to all 4 roles for all realms. When a realm is created these roles are created as well, so the current token doesn't contain these roles.
>

This should be changed to only use an identity token/cookie specific to 
the admin console.  Role mappings can be checked directly by admin REST 
service.  We can still do the regular login flow, but the access token 
we get back should only be used to create an identity cookie, not to 
authorize.


> AuthenticationManager was starting to become quite messy, so I extracted methods specific to admin console and account into a separate AppAuthManager. The token in the cookies created for these didn't use to include roles, which I've added to make it simpler to check for permissions.
>

These tokens don't need to have roles in them!  The admin service can 
check role mappings directly as it has access to database.

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

From bburke at redhat.com  Mon Feb 24 10:28:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 24 Feb 2014 10:28:40 -0500
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <431697034.14774298.1393251754796.JavaMail.zimbra@redhat.com>
References: <530A2344.6050006@redhat.com>
	<1306764301.14672301.1393242846711.JavaMail.zimbra@redhat.com>
	<530B5174.5050801@redhat.com> <530B51A2.5050001@redhat.com>
	<431697034.14774298.1393251754796.JavaMail.zimbra@redhat.com>
Message-ID: <530B6528.1080007@redhat.com>



On 2/24/2014 9:22 AM, Stian Thorgersen wrote:
> Added Gabriel to see if he has a good idea
>
> With the current L&F I can only think of two solutions (neither of which I particularly like):
>
> 1. Have it under username/password - probably means no-one is going to associate it with a social login
> 2. Have on under username/password and one under all social logins - I think this will look weird, and not convinced people will associate it with a particular login
>

Above is why I started this email in the first place :( There is no good 
option with the current L&F.

> Is there a way we can not require this for social logins? Social networks would already provide this mechanism so if we can somehow integrate with that, we wouldn't need it. One idea would be to set a cookie when a user has used a social login, then test if they are still logged in with that automatically.
>

Without "Remember me" the user would have to still be redirected to 
Keycloak login page and click "Google" or whatever.

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

From stian at redhat.com  Mon Feb 24 10:43:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 24 Feb 2014 10:43:20 -0500 (EST)
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <530B6528.1080007@redhat.com>
References: <530A2344.6050006@redhat.com>
	<1306764301.14672301.1393242846711.JavaMail.zimbra@redhat.com>
	<530B5174.5050801@redhat.com> <530B51A2.5050001@redhat.com>
	<431697034.14774298.1393251754796.JavaMail.zimbra@redhat.com>
	<530B6528.1080007@redhat.com>
Message-ID: <317069947.14875727.1393256600919.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Gabriel Cardoso" <gcardoso at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 24 February, 2014 3:28:40 PM
> Subject: Re: [keycloak-dev] social login and remember me
> 
> 
> 
> On 2/24/2014 9:22 AM, Stian Thorgersen wrote:
> > Added Gabriel to see if he has a good idea
> >
> > With the current L&F I can only think of two solutions (neither of which I
> > particularly like):
> >
> > 1. Have it under username/password - probably means no-one is going to
> > associate it with a social login
> > 2. Have on under username/password and one under all social logins - I
> > think this will look weird, and not convinced people will associate it
> > with a particular login
> >
> 
> Above is why I started this email in the first place :( There is no good
> option with the current L&F.
> 
> > Is there a way we can not require this for social logins? Social networks
> > would already provide this mechanism so if we can somehow integrate with
> > that, we wouldn't need it. One idea would be to set a cookie when a user
> > has used a social login, then test if they are still logged in with that
> > automatically.
> >
> 
> Without "Remember me" the user would have to still be redirected to
> Keycloak login page and click "Google" or whatever.

Not necessarily. I was thinking something along the lines of:

* In social callback we set a cookie to remember user last logged in with 'Google'
* On next login we check if this cookie is set, if it's set we automatically redirect to login on 'Google' with 'prompt=none'
* If we get a code from Google, user is logged in and we can redirect with code. If we get an error, then we display login form

Probably to complex, and probably won't work with all providers (as they may not provide prompt=none option). Just thinking out of the box ;)

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

From gcardoso at redhat.com  Mon Feb 24 12:02:46 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Mon, 24 Feb 2014 14:02:46 -0300
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <317069947.14875727.1393256600919.JavaMail.zimbra@redhat.com>
References: <530A2344.6050006@redhat.com>
	<1306764301.14672301.1393242846711.JavaMail.zimbra@redhat.com>
	<530B5174.5050801@redhat.com> <530B51A2.5050001@redhat.com>
	<431697034.14774298.1393251754796.JavaMail.zimbra@redhat.com>
	<530B6528.1080007@redhat.com>
	<317069947.14875727.1393256600919.JavaMail.zimbra@redhat.com>
Message-ID: <F2C758DB-7337-4155-AE40-7F8CE8BC4468@redhat.com>

Services usually don?t have a ?Remember Me? for social logins. Thus, I don?t recall a pattern for this. 

Here is a proposal for where it could be located. We can improve it as the product develops.




What do you think?

Gabriel



On Feb 24, 2014, at 12:43 PM, Stian Thorgersen <stian at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Gabriel Cardoso" <gcardoso at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 24 February, 2014 3:28:40 PM
>> Subject: Re: [keycloak-dev] social login and remember me
>> 
>> 
>> 
>> On 2/24/2014 9:22 AM, Stian Thorgersen wrote:
>>> Added Gabriel to see if he has a good idea
>>> 
>>> With the current L&F I can only think of two solutions (neither of which I
>>> particularly like):
>>> 
>>> 1. Have it under username/password - probably means no-one is going to
>>> associate it with a social login
>>> 2. Have on under username/password and one under all social logins - I
>>> think this will look weird, and not convinced people will associate it
>>> with a particular login
>>> 
>> 
>> Above is why I started this email in the first place :( There is no good
>> option with the current L&F.
>> 
>>> Is there a way we can not require this for social logins? Social networks
>>> would already provide this mechanism so if we can somehow integrate with
>>> that, we wouldn't need it. One idea would be to set a cookie when a user
>>> has used a social login, then test if they are still logged in with that
>>> automatically.
>>> 
>> 
>> Without "Remember me" the user would have to still be redirected to
>> Keycloak login page and click "Google" or whatever.
> 
> Not necessarily. I was thinking something along the lines of:
> 
> * In social callback we set a cookie to remember user last logged in with 'Google'
> * On next login we check if this cookie is set, if it's set we automatically redirect to login on 'Google' with 'prompt=none'
> * If we get a code from Google, user is logged in and we can redirect with code. If we get an error, then we display login form
> 
> Probably to complex, and probably won't work with all providers (as they may not provide prompt=none option). Just thinking out of the box ;)
> 
>> 
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com

---
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140224/66fc97b0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: login-remember-me.png
Type: image/png
Size: 56791 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140224/66fc97b0/attachment-0001.png 

From bburke at redhat.com  Mon Feb 24 12:45:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 24 Feb 2014 12:45:11 -0500
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <F2C758DB-7337-4155-AE40-7F8CE8BC4468@redhat.com>
References: <530A2344.6050006@redhat.com>
	<1306764301.14672301.1393242846711.JavaMail.zimbra@redhat.com>
	<530B5174.5050801@redhat.com> <530B51A2.5050001@redhat.com>
	<431697034.14774298.1393251754796.JavaMail.zimbra@redhat.com>
	<530B6528.1080007@redhat.com>
	<317069947.14875727.1393256600919.JavaMail.zimbra@redhat.com>
	<F2C758DB-7337-4155-AE40-7F8CE8BC4468@redhat.com>
Message-ID: <530B8527.6050100@redhat.com>

That looks good actually.
Can everything be within one <form> (username/password/rememberme/social 
login buttons)?  Or will that screw up formatting?

On 2/24/2014 12:02 PM, Gabriel Cardoso wrote:
> Services usually don?t have a ?Remember Me? for social logins. Thus, I
> don?t recall a pattern for this.
>
> Here is a proposal for where it could be located. We can improve it as
> the product develops.
>
>
>
> What do you think?
>
> Gabriel
>
>
>
> On Feb 24, 2014, at 12:43 PM, Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>> wrote:
>
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>> To: "Stian Thorgersen" <stian at redhat.com <mailto:stian at redhat.com>>,
>>> "Gabriel Cardoso" <gcardoso at redhat.com <mailto:gcardoso at redhat.com>>
>>> Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> Sent: Monday, 24 February, 2014 3:28:40 PM
>>> Subject: Re: [keycloak-dev] social login and remember me
>>>
>>>
>>>
>>> On 2/24/2014 9:22 AM, Stian Thorgersen wrote:
>>>> Added Gabriel to see if he has a good idea
>>>>
>>>> With the current L&F I can only think of two solutions (neither of
>>>> which I
>>>> particularly like):
>>>>
>>>> 1. Have it under username/password - probably means no-one is going to
>>>> associate it with a social login
>>>> 2. Have on under username/password and one under all social logins - I
>>>> think this will look weird, and not convinced people will associate it
>>>> with a particular login
>>>>
>>>
>>> Above is why I started this email in the first place :( There is no good
>>> option with the current L&F.
>>>
>>>> Is there a way we can not require this for social logins? Social
>>>> networks
>>>> would already provide this mechanism so if we can somehow integrate with
>>>> that, we wouldn't need it. One idea would be to set a cookie when a user
>>>> has used a social login, then test if they are still logged in with that
>>>> automatically.
>>>>
>>>
>>> Without "Remember me" the user would have to still be redirected to
>>> Keycloak login page and click "Google" or whatever.
>>
>> Not necessarily. I was thinking something along the lines of:
>>
>> * In social callback we set a cookie to remember user last logged in
>> with 'Google'
>> * On next login we check if this cookie is set, if it's set we
>> automatically redirect to login on 'Google' with 'prompt=none'
>> * If we get a code from Google, user is logged in and we can redirect
>> with code. If we get an error, then we display login form
>>
>> Probably to complex, and probably won't work with all providers (as
>> they may not provide prompt=none option). Just thinking out of the box ;)
>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>

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

From stian at redhat.com  Mon Feb 24 13:05:10 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 24 Feb 2014 13:05:10 -0500 (EST)
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <530B8527.6050100@redhat.com>
References: <530A2344.6050006@redhat.com> <530B5174.5050801@redhat.com>
	<530B51A2.5050001@redhat.com>
	<431697034.14774298.1393251754796.JavaMail.zimbra@redhat.com>
	<530B6528.1080007@redhat.com>
	<317069947.14875727.1393256600919.JavaMail.zimbra@redhat.com>
	<F2C758DB-7337-4155-AE40-7F8CE8BC4468@redhat.com>
	<530B8527.6050100@redhat.com>
Message-ID: <s1krpp2j0ceokewjupkkesb5.1393265106939@email.android.com>

Not sure, try and see ;)

Bill Burke <bburke at redhat.com> wrote:

That looks good actually.
Can everything be within one <form> (username/password/rememberme/social 
login buttons)?  Or will that screw up formatting?

On 2/24/2014 12:02 PM, Gabriel Cardoso wrote:
> Services usually don?t have a ?Remember Me? for social logins. Thus, I
> don?t recall a pattern for this.
>
> Here is a proposal for where it could be located. We can improve it as
> the product develops.
>
>
>
> What do you think?
>
> Gabriel
>
>
>
> On Feb 24, 2014, at 12:43 PM, Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>> wrote:
>
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>> To: "Stian Thorgersen" <stian at redhat.com <mailto:stian at redhat.com>>,
>>> "Gabriel Cardoso" <gcardoso at redhat.com <mailto:gcardoso at redhat.com>>
>>> Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> Sent: Monday, 24 February, 2014 3:28:40 PM
>>> Subject: Re: [keycloak-dev] social login and remember me
>>>
>>>
>>>
>>> On 2/24/2014 9:22 AM, Stian Thorgersen wrote:
>>>> Added Gabriel to see if he has a good idea
>>>>
>>>> With the current L&F I can only think of two solutions (neither of
>>>> which I
>>>> particularly like):
>>>>
>>>> 1. Have it under username/password - probably means no-one is going to
>>>> associate it with a social login
>>>> 2. Have on under username/password and one under all social logins - I
>>>> think this will look weird, and not convinced people will associate it
>>>> with a particular login
>>>>
>>>
>>> Above is why I started this email in the first place :( There is no good
>>> option with the current L&F.
>>>
>>>> Is there a way we can not require this for social logins? Social
>>>> networks
>>>> would already provide this mechanism so if we can somehow integrate with
>>>> that, we wouldn't need it. One idea would be to set a cookie when a user
>>>> has used a social login, then test if they are still logged in with that
>>>> automatically.
>>>>
>>>
>>> Without "Remember me" the user would have to still be redirected to
>>> Keycloak login page and click "Google" or whatever.
>>
>> Not necessarily. I was thinking something along the lines of:
>>
>> * In social callback we set a cookie to remember user last logged in
>> with 'Google'
>> * On next login we check if this cookie is set, if it's set we
>> automatically redirect to login on 'Google' with 'prompt=none'
>> * If we get a code from Google, user is logged in and we can redirect
>> with code. If we get an error, then we display login form
>>
>> Probably to complex, and probably won't work with all providers (as
>> they may not provide prompt=none option). Just thinking out of the box ;)
>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>

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


From bburke at redhat.com  Mon Feb 24 14:06:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 24 Feb 2014 14:06:05 -0500
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <s1krpp2j0ceokewjupkkesb5.1393265106939@email.android.com>
References: <530A2344.6050006@redhat.com> <530B5174.5050801@redhat.com>
	<530B51A2.5050001@redhat.com>
	<431697034.14774298.1393251754796.JavaMail.zimbra@redhat.com>
	<530B6528.1080007@redhat.com>
	<317069947.14875727.1393256600919.JavaMail.zimbra@redhat.com>
	<F2C758DB-7337-4155-AE40-7F8CE8BC4468@redhat.com>
	<530B8527.6050100@redhat.com>
	<s1krpp2j0ceokewjupkkesb5.1393265106939@email.android.com>
Message-ID: <530B981D.7090800@redhat.com>

But...But.... :( ;)

On 2/24/2014 1:05 PM, Stian Thorgersen wrote:
> Not sure, try and see ;)
>
> Bill Burke <bburke at redhat.com> wrote:
>
> That looks good actually.
> Can everything be within one <form> (username/password/rememberme/social
> login buttons)?  Or will that screw up formatting?
>
> On 2/24/2014 12:02 PM, Gabriel Cardoso wrote:
>> Services usually don?t have a ?Remember Me? for social logins. Thus, I
>> don?t recall a pattern for this.
>>
>> Here is a proposal for where it could be located. We can improve it as
>> the product develops.
>>
>>
>>
>> What do you think?
>>
>> Gabriel
>>
>>
>>
>> On Feb 24, 2014, at 12:43 PM, Stian Thorgersen <stian at redhat.com
>> <mailto:stian at redhat.com>> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>>> To: "Stian Thorgersen" <stian at redhat.com <mailto:stian at redhat.com>>,
>>>> "Gabriel Cardoso" <gcardoso at redhat.com <mailto:gcardoso at redhat.com>>
>>>> Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> Sent: Monday, 24 February, 2014 3:28:40 PM
>>>> Subject: Re: [keycloak-dev] social login and remember me
>>>>
>>>>
>>>>
>>>> On 2/24/2014 9:22 AM, Stian Thorgersen wrote:
>>>>> Added Gabriel to see if he has a good idea
>>>>>
>>>>> With the current L&F I can only think of two solutions (neither of
>>>>> which I
>>>>> particularly like):
>>>>>
>>>>> 1. Have it under username/password - probably means no-one is going to
>>>>> associate it with a social login
>>>>> 2. Have on under username/password and one under all social logins - I
>>>>> think this will look weird, and not convinced people will associate it
>>>>> with a particular login
>>>>>
>>>>
>>>> Above is why I started this email in the first place :( There is no good
>>>> option with the current L&F.
>>>>
>>>>> Is there a way we can not require this for social logins? Social
>>>>> networks
>>>>> would already provide this mechanism so if we can somehow integrate with
>>>>> that, we wouldn't need it. One idea would be to set a cookie when a user
>>>>> has used a social login, then test if they are still logged in with that
>>>>> automatically.
>>>>>
>>>>
>>>> Without "Remember me" the user would have to still be redirected to
>>>> Keycloak login page and click "Google" or whatever.
>>>
>>> Not necessarily. I was thinking something along the lines of:
>>>
>>> * In social callback we set a cookie to remember user last logged in
>>> with 'Google'
>>> * On next login we check if this cookie is set, if it's set we
>>> automatically redirect to login on 'Google' with 'prompt=none'
>>> * If we get a code from Google, user is logged in and we can redirect
>>> with code. If we get an error, then we display login form
>>>
>>> Probably to complex, and probably won't work with all providers (as
>>> they may not provide prompt=none option). Just thinking out of the box ;)
>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>>
>> ---
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>>
>

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

From gcardoso at redhat.com  Mon Feb 24 18:15:26 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Mon, 24 Feb 2014 20:15:26 -0300
Subject: [keycloak-dev] social login and remember me
In-Reply-To: <530B981D.7090800@redhat.com>
References: <530A2344.6050006@redhat.com> <530B5174.5050801@redhat.com>
	<530B51A2.5050001@redhat.com>
	<431697034.14774298.1393251754796.JavaMail.zimbra@redhat.com>
	<530B6528.1080007@redhat.com>
	<317069947.14875727.1393256600919.JavaMail.zimbra@redhat.com>
	<F2C758DB-7337-4155-AE40-7F8CE8BC4468@redhat.com>
	<530B8527.6050100@redhat.com>
	<s1krpp2j0ceokewjupkkesb5.1393265106939@email.android.com>
	<530B981D.7090800@redhat.com>
Message-ID: <FD95D4ED-E6AA-4DE1-A418-603867C3B980@redhat.com>

It probably will, but do what you need to do and we can fix it later.

On Feb 24, 2014, at 4:06 PM, Bill Burke <bburke at redhat.com> wrote:

> But...But.... :( ;)
> 
> On 2/24/2014 1:05 PM, Stian Thorgersen wrote:
>> Not sure, try and see ;)
>> 
>> Bill Burke <bburke at redhat.com> wrote:
>> 
>> That looks good actually.
>> Can everything be within one <form> (username/password/rememberme/social
>> login buttons)?  Or will that screw up formatting?
>> 
>> On 2/24/2014 12:02 PM, Gabriel Cardoso wrote:
>>> Services usually don?t have a ?Remember Me? for social logins. Thus, I
>>> don?t recall a pattern for this.
>>> 
>>> Here is a proposal for where it could be located. We can improve it as
>>> the product develops.
>>> 
>>> 
>>> 
>>> What do you think?
>>> 
>>> Gabriel
>>> 
>>> 
>>> 
>>> On Feb 24, 2014, at 12:43 PM, Stian Thorgersen <stian at redhat.com
>>> <mailto:stian at redhat.com>> wrote:
>>> 
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>>>> To: "Stian Thorgersen" <stian at redhat.com <mailto:stian at redhat.com>>,
>>>>> "Gabriel Cardoso" <gcardoso at redhat.com <mailto:gcardoso at redhat.com>>
>>>>> Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> Sent: Monday, 24 February, 2014 3:28:40 PM
>>>>> Subject: Re: [keycloak-dev] social login and remember me
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2/24/2014 9:22 AM, Stian Thorgersen wrote:
>>>>>> Added Gabriel to see if he has a good idea
>>>>>> 
>>>>>> With the current L&F I can only think of two solutions (neither of
>>>>>> which I
>>>>>> particularly like):
>>>>>> 
>>>>>> 1. Have it under username/password - probably means no-one is going to
>>>>>> associate it with a social login
>>>>>> 2. Have on under username/password and one under all social logins - I
>>>>>> think this will look weird, and not convinced people will associate it
>>>>>> with a particular login
>>>>>> 
>>>>> 
>>>>> Above is why I started this email in the first place :( There is no good
>>>>> option with the current L&F.
>>>>> 
>>>>>> Is there a way we can not require this for social logins? Social
>>>>>> networks
>>>>>> would already provide this mechanism so if we can somehow integrate with
>>>>>> that, we wouldn't need it. One idea would be to set a cookie when a user
>>>>>> has used a social login, then test if they are still logged in with that
>>>>>> automatically.
>>>>>> 
>>>>> 
>>>>> Without "Remember me" the user would have to still be redirected to
>>>>> Keycloak login page and click "Google" or whatever.
>>>> 
>>>> Not necessarily. I was thinking something along the lines of:
>>>> 
>>>> * In social callback we set a cookie to remember user last logged in
>>>> with 'Google'
>>>> * On next login we check if this cookie is set, if it's set we
>>>> automatically redirect to login on 'Google' with 'prompt=none'
>>>> * If we get a code from Google, user is logged in and we can redirect
>>>> with code. If we get an error, then we display login form
>>>> 
>>>> Probably to complex, and probably won't work with all providers (as
>>>> they may not provide prompt=none option). Just thinking out of the box ;)
>>>> 
>>>>> 
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>>> 
>>> ---
>>> Gabriel Cardoso
>>> User Experience Designer @ Red Hat
>>> 
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

---
Gabriel Cardoso
User Experience Designer @ Red Hat

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

From bburke at redhat.com  Mon Feb 24 20:37:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 24 Feb 2014 20:37:59 -0500
Subject: [keycloak-dev] remember me/refresh token support in
Message-ID: <530BF3F7.5040002@redhat.com>

* Remember me support is now in.  Only works for non-social logins at 
the moment though.
* admin console can now configure remember me, central login timeout, 
refresh token timeout, access token timeout, and access code timeout
* Refresh token is always sent back with a grant request in the 
AccessTokenResponse.
* Adapters will now check the access token's expiration on each request. 
  If it is stale, it will attempt to refresh it.  BTW, this will fail if 
the access token's roles allowed don't match the users or 
application/oauth client scope anymore and the user will be redirected 
back to the authentication server.
* Javascript adapter was also updated.  I implemented a 
onValidAccessToken(successCallback) method that will check the token, 
refresh it if needed, then invoke a callback.  The customer-app-js 
example was updated to reflect using this callback method.
* I wrote a Javascript adapter docbook chapter and a small chapter on 
what are the best practices for all the token timeout settings.


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

From stian at redhat.com  Tue Feb 25 07:59:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 25 Feb 2014 07:59:39 -0500 (EST)
Subject: [keycloak-dev] Realm admin permissions added
In-Reply-To: <482856042.15784687.1393330727030.JavaMail.zimbra@redhat.com>
Message-ID: <1261348966.15836287.1393333179847.JavaMail.zimbra@redhat.com>

Realm admin permissions added has been added to master.

A quick overview on how it works:

When a realm is created an application is created in the keycloak-admin realm. The application name is '<realm name>-realm'. This application represents the roles associated with the realm, and let's you add role mappings to users as well as scope mappings to apps/clients. A realm app has the following roles:

* manage-realm
* manage-users
* manage-applications
* manage-clients

These roles are all read/write. In the future I imagine we can add some view only roles (view-realm, view-users, view-applications, view-clients). I didn't add it this time around as it would require a fair amount of changes to admin console (everything is forms with buttons at the moment, so would have to add read only views).

When listing realms the admin console will only return the realms where the user has one or more of the above roles. The admin console will also change the menu depending on what roles the user has (for example a user that only has 'manage-clients' and 'manage-users' will not see 'settings' and 'applications').

There's a realm role called 'admin' as well. This is a composite role and when creating a new realm all roles for the new realm are added to it. Only users with this role is allowed to create, import or delete realms.

To create a new realm, with a user that has only 'manage-users' and 'manage-clients' access to this new realm, do the following:

1. Create a new realm called 'test'
2. Navigate to users for 'keycloak-admin' realm (http://localhost:8081/auth/admin/index.html#/realms/keycloak-admin/users)
3. Create new user called 'test' (enable + reset creds)
4. Click on 'Role mappings' 
5. In 'Applications' drop-down select 'test-realm'
6. Select 'manage-users' and 'manage-clients' and click the right-arrow to add mapping
7. Log out of admin console, and login as 'test'

The pages in the admin console themselves haven't been disabled, only the menu to navigate there. You can try opening for example:

http://localhost:8081/auth/admin/index.html#/realms/test/social-settings
http://localhost:8081/auth/admin/index.html#/realms/test/applications

From bburke at redhat.com  Tue Feb 25 10:39:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 25 Feb 2014 10:39:48 -0500
Subject: [keycloak-dev] Aerogear requirements
Message-ID: <530CB944.3040909@redhat.com>

To support the initial integration between Aerogear and Keycloak, we 
need to be able to handle two things:

* figure out bootstrapping on a co-bundled aerogear+keycloak zip distro, 
as well as a co-bundled OpenShift cartridge.
* Be able to brand the admin console using Aerogear styles.  This means 
there can be no mention of "Keycloak" within login screens or within the 
admin console itself.  Keycloak needs to look like it is part of Aerogear.

Last thing is.  We have to have a 1.0 release by June, which means we 
need a major feature cut off sometime in April so we can start working 
on scaling, optimization, code quality, and testing.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue Feb 25 11:51:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 25 Feb 2014 11:51:44 -0500
Subject: [keycloak-dev] 1.0 Final roadmap
Message-ID: <530CCA20.9070006@redhat.com>

What's left for must-have features before we can start pushing for a 
1.0.Final release?  We need to release 1.0 sometime in June.

* Minimal OpenID Connect support
* Import/Export of various items of a realm (for data migration).
* Aerogear bootstrap requirements
* Theme support for admin console so we can brand it.
* Revocation policies.  I'm thinking Not-Before is good enough for a 1.0 
release.  We need to be able to push this to deployed apps.  And also 
maybe piggyback this information in AcessTokenResponse.  This also of 
course needs to be stored within subsystem config too, or maybe we could 
just have adapters pull that information from server at bootup.
* Remember Me for social logins
* Federation of users/credentials with LDAP/AD.  Hopefully through 
Picketlink.
* User session management.  Admin can logout a user.
* Audit log.


Scaling/Optimization:

* Storage cache for the token service so it doesn't hit the database.
* Make token service stateless for clustering environments (maybe don't 
need for 1.0?)


We'll stick with only AS7/EAP/Wildfly adapters for 1st release.  We also 
have to pencil in time for weeks of test writing, benchmarking, and 
documentation.




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

From stian at redhat.com  Tue Feb 25 12:44:16 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 25 Feb 2014 12:44:16 -0500 (EST)
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <530CCA20.9070006@redhat.com>
References: <530CCA20.9070006@redhat.com>
Message-ID: <474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>

See comments in-line

Mobile adapters would be really good to have. If we can get help from the AeroGear team to do these, maybe we could include this as well? For simplicity we could just aim for a working Cordova example, but Android and iOS adapters would be great.

It would also be nice to make Keycloak more "embeddable". I'd like to be able to improve how Keycloak is embedded into LiveOak, but there's also the issue around WildFly console needing to embed it. Let's have a separate thread on this, but my current (updated) thinking is to utilize RestEasy, but to remove use of servlets

There's a whole bunch of JIRA issues with fix for beta1. In the effort to prune this list a bit, here's some I think we can postpone to later:

KEYCLOAK-313 Manage devices
KEYCLOAK-311 Custom user profiles
KEYCLOAK-310 SPI for multi-factor authentication
KEYCLOAK-308 Cordova adapter
KEYCLOAK-307 iPhone adapter
KEYCLOAK-306 Android adapter
KEYCLOAK-301 Internationalization support
KEYCLOAK-300 Auto configuration of MySQL or PostgreSQL in OpenShift cartridge
KEYCLOAK-266 Integrated help in admin console
KEYCLOAK-265 Optional instructions to social providers
KEYCLOAK-242 Add remember machine option for two factor authentication
KEYCLOAK-182 List applications on account management
KEYCLOAK-161 Allow users to create oauth clients through account pages
KEYCLOAK-57 Mobile example application

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 25 February, 2014 4:51:44 PM
> Subject: [keycloak-dev] 1.0 Final roadmap
> 
> What's left for must-have features before we can start pushing for a
> 1.0.Final release?  We need to release 1.0 sometime in June.

Any particular reason for June?

> 
> * Minimal OpenID Connect support
> * Import/Export of various items of a realm (for data migration).
> * Aerogear bootstrap requirements
> * Theme support for admin console so we can brand it.
> * Revocation policies.  I'm thinking Not-Before is good enough for a 1.0
> release.  We need to be able to push this to deployed apps.  And also
> maybe piggyback this information in AcessTokenResponse.  This also of
> course needs to be stored within subsystem config too, or maybe we could
> just have adapters pull that information from server at bootup.

We probably need a separate thread to discuss this, but it's important that users can view what applications can currently access their account and revoke access to individual apps. This means we need to know what refresh tokens are valid, and which have been revoked by a user.

> * Remember Me for social logins
> * Federation of users/credentials with LDAP/AD.  Hopefully through
> Picketlink.

Is this really required for the first release?

> * User session management.  Admin can logout a user.
> * Audit log.

Related things we'll need are brute force protection (including max failed login attempt before locking a users account) and email notifications on certain events.

> 
> 
> Scaling/Optimization:
> 
> * Storage cache for the token service so it doesn't hit the database.
> * Make token service stateless for clustering environments (maybe don't
> need for 1.0?)
> 
> 
> We'll stick with only AS7/EAP/Wildfly adapters for 1st release.  We also
> have to pencil in time for weeks of test writing, benchmarking, and
> documentation.
> 
> 
> 
> 
> --
> 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 matzew at apache.org  Tue Feb 25 12:57:02 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 25 Feb 2014 18:57:02 +0100
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
Message-ID: <CAAg5f2T=wQoYMJ3XQc+HifX-7wrKLD24ZThzBw2CsvQAk5_Qug@mail.gmail.com>

On Tuesday, February 25, 2014, Stian Thorgersen <stian at redhat.com> wrote:

> See comments in-line
>
> Mobile adapters would be really good to have. If we can get help from the
> AeroGear team to do these, maybe we could include this as well? For
> simplicity we could just aim for a working Cordova example, but Android and
> iOS adapters would be great.



We have OAuth2 (JS/iOS - Android coming).
Could give that a shot;

-Matthias


>
> It would also be nice to make Keycloak more "embeddable". I'd like to be
> able to improve how Keycloak is embedded into LiveOak, but there's also the
> issue around WildFly console needing to embed it. Let's have a separate
> thread on this, but my current (updated) thinking is to utilize RestEasy,
> but to remove use of servlets
>
> There's a whole bunch of JIRA issues with fix for beta1. In the effort to
> prune this list a bit, here's some I think we can postpone to later:
>
> KEYCLOAK-313 Manage devices
> KEYCLOAK-311 Custom user profiles
> KEYCLOAK-310 SPI for multi-factor authentication
> KEYCLOAK-308 Cordova adapter
> KEYCLOAK-307 iPhone adapter
> KEYCLOAK-306 Android adapter
> KEYCLOAK-301 Internationalization support
> KEYCLOAK-300 Auto configuration of MySQL or PostgreSQL in OpenShift
> cartridge
> KEYCLOAK-266 Integrated help in admin console
> KEYCLOAK-265 Optional instructions to social providers
> KEYCLOAK-242 Add remember machine option for two factor authentication
> KEYCLOAK-182 List applications on account management
> KEYCLOAK-161 Allow users to create oauth clients through account pages
> KEYCLOAK-57 Mobile example application
>
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com <javascript:;>>
> > To: keycloak-dev at lists.jboss.org <javascript:;>
> > Sent: Tuesday, 25 February, 2014 4:51:44 PM
> > Subject: [keycloak-dev] 1.0 Final roadmap
> >
> > What's left for must-have features before we can start pushing for a
> > 1.0.Final release?  We need to release 1.0 sometime in June.
>
> Any particular reason for June?
>
> >
> > * Minimal OpenID Connect support
> > * Import/Export of various items of a realm (for data migration).
> > * Aerogear bootstrap requirements
> > * Theme support for admin console so we can brand it.
> > * Revocation policies.  I'm thinking Not-Before is good enough for a 1.0
> > release.  We need to be able to push this to deployed apps.  And also
> > maybe piggyback this information in AcessTokenResponse.  This also of
> > course needs to be stored within subsystem config too, or maybe we could
> > just have adapters pull that information from server at bootup.
>
> We probably need a separate thread to discuss this, but it's important
> that users can view what applications can currently access their account
> and revoke access to individual apps. This means we need to know what
> refresh tokens are valid, and which have been revoked by a user.
>
> > * Remember Me for social logins
> > * Federation of users/credentials with LDAP/AD.  Hopefully through
> > Picketlink.
>
> Is this really required for the first release?
>
> > * User session management.  Admin can logout a user.
> > * Audit log.
>
> Related things we'll need are brute force protection (including max failed
> login attempt before locking a users account) and email notifications on
> certain events.
>
> >
> >
> > Scaling/Optimization:
> >
> > * Storage cache for the token service so it doesn't hit the database.
> > * Make token service stateless for clustering environments (maybe don't
> > need for 1.0?)
> >
> >
> > We'll stick with only AS7/EAP/Wildfly adapters for 1st release.  We also
> > have to pencil in time for weeks of test writing, benchmarking, and
> > documentation.
> >
> >
> >
> >
> > --
> > 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
> >
> _______________________________________________
> 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/20140225/2d0ce0fb/attachment.html 

From bburke at redhat.com  Tue Feb 25 19:40:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 25 Feb 2014 19:40:32 -0500
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
Message-ID: <530D3800.3010900@redhat.com>



On 2/25/2014 12:44 PM, Stian Thorgersen wrote:
> See comments in-line
>
> Mobile adapters would be really good to have. If we can get help from the AeroGear team to do these, maybe we could include this as well? For simplicity we could just aim for a working Cordova example, but Android and iOS adapters would be great.
>

Unless we get a community submission for mobile adapters, this is going 
to have to wait as I'm not sure we have time.  I also wanted Tomcat, 
Jetty, Node.js, and JIRA adapters too, but those I think might have to wait.

> It would also be nice to make Keycloak more "embeddable". I'd like to be able to improve how Keycloak is embedded into LiveOak, but there's also the issue around WildFly console needing to embed it. Let's have a separate thread on this, but my current (updated) thinking is to utilize RestEasy, but to remove use of servlets
>
> There's a whole bunch of JIRA issues with fix for beta1. In the effort to prune this list a bit, here's some I think we can postpone to later:
>

I vote we keep everything in JIRA until we start running out of time, 
then we'll defer.

>
> Any particular reason for June?
>

Aerogear requirement to get us in product.  Which is a good thing. :)

>
> We probably need a separate thread to discuss this, but it's important that users can view what applications can currently access their account and revoke access to individual apps. This means we need to know what refresh tokens are valid, and which have been revoked by a user.
>

Crap.  I forgot about this.  Thanks for reminding me.

>> * Remember Me for social logins
>> * Federation of users/credentials with LDAP/AD.  Hopefully through
>> Picketlink.
>
> Is this really required for the first release?

If we want to be considered in Middleware BU as an SSO solution, we need 
this.  Also will relieve some tensions with PL team hopefully if we 
leverage their stuff.

>
>> * User session management.  Admin can logout a user.
>> * Audit log.
>
> Related things we'll need are brute force protection (including max failed login attempt before locking a users account) and email notifications on certain events.
>

Wouldn't it be better just to add a 1 second sleep?  Checking max failed 
logins would require persistence per authentication.

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

From bruno at abstractj.org  Wed Feb 26 09:26:18 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 26 Feb 2014 11:26:18 -0300
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <530D3800.3010900@redhat.com>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
	<530D3800.3010900@redhat.com>
Message-ID: <etPan.530df98a.327b23c6.4da@animus>

Hi Bill, I?m not sure if this is planned, but don?t hurt to ask. For Aerogear we have the following needs and I would like to help if it's planned for Keycloak (I don't want to create overlappings)

- Data sync

Scenario: user must update the data on the server, but it must be stored encrypted.

I'm considering to generate a key pair during the "handshake" between client and server and send client's public key to the server. In this way prevent user's data violation.

- Unified push server?

Currently the Push server requires a passphrase for iOS variants, something like (borrowed from https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/README.md):?

curl -3 -v -b cookies.txt -c cookies.txt
? -i -H "Accept: application/json" -H "Content-type: multipart/form-data"
? -F "certificate=@/Users/matzew/Desktop/MyProdCert.p12"
? -F "passphrase=TopSecret"
? -F "production=true" ?// make sure you have Production certificate and Provisioning Profile

? -X POST https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/iOS

The passphrase is sent over the wire in raw text because that's required by Apple (thanks Apple). To prevent exposing user's passphrase. I was wondering about a key agreement to stabilish a shared secret between client/server, into this way the client could send that passphrase encrypted and the server decrypts it on the fly to send push messages.

Do you guys have something similar like that, planned? Or totally out of the scope? I could help.

- Legacy authentication

Currently we have basic/digest supported on the client side (yep, they are pretty much unsafe, but, legacies...). Is it something planned to be supported on Keycloak? What would be the alternatives?

Regarding the adapters, we could help with it for sure.

--  
abstractj

On February 25, 2014 at 9:40:38 PM, Bill Burke (bburke at redhat.com) wrote:
>  
>  
>  
> On 2/25/2014 12:44 PM, Stian Thorgersen wrote:
> > See comments in-line
> >
> > Mobile adapters would be really good to have. If we can get help  
> from the AeroGear team to do these, maybe we could include this  
> as well? For simplicity we could just aim for a working Cordova  
> example, but Android and iOS adapters would be great.
> >
>  
> Unless we get a community submission for mobile adapters, this  
> is going
> to have to wait as I'm not sure we have time. I also wanted Tomcat,  
> Jetty, Node.js, and JIRA adapters too, but those I think might  
> have to wait.
>  
> > It would also be nice to make Keycloak more "embeddable". I'd  
> like to be able to improve how Keycloak is embedded into LiveOak,  
> but there's also the issue around WildFly console needing to  
> embed it. Let's have a separate thread on this, but my current  
> (updated) thinking is to utilize RestEasy, but to remove use  
> of servlets
> >
> > There's a whole bunch of JIRA issues with fix for beta1. In the  
> effort to prune this list a bit, here's some I think we can postpone  
> to later:
> >
>  
> I vote we keep everything in JIRA until we start running out of  
> time,
> then we'll defer.
>  
> >
> > Any particular reason for June?
> >
>  
> Aerogear requirement to get us in product. Which is a good thing.  
> :)
>  
> >
> > We probably need a separate thread to discuss this, but it's  
> important that users can view what applications can currently  
> access their account and revoke access to individual apps. This  
> means we need to know what refresh tokens are valid, and which  
> have been revoked by a user.
> >
>  
> Crap. I forgot about this. Thanks for reminding me.
>  
> >> * Remember Me for social logins
> >> * Federation of users/credentials with LDAP/AD. Hopefully  
> through
> >> Picketlink.
> >
> > Is this really required for the first release?
>  
> If we want to be considered in Middleware BU as an SSO solution,  
> we need
> this. Also will relieve some tensions with PL team hopefully  
> if we
> leverage their stuff.
>  
> >
> >> * User session management. Admin can logout a user.
> >> * Audit log.
> >
> > Related things we'll need are brute force protection (including  
> max failed login attempt before locking a users account) and  
> email notifications on certain events.
> >
>  
> Wouldn't it be better just to add a 1 second sleep? Checking max  
> failed
> logins would require persistence per authentication.
>  
> --
> 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 Feb 26 09:33:37 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 26 Feb 2014 09:33:37 -0500 (EST)
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <CAAg5f2T=wQoYMJ3XQc+HifX-7wrKLD24ZThzBw2CsvQAk5_Qug@mail.gmail.com>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
	<CAAg5f2T=wQoYMJ3XQc+HifX-7wrKLD24ZThzBw2CsvQAk5_Qug@mail.gmail.com>
Message-ID: <264770035.17005170.1393425217696.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Matthias Wessendorf" <matzew at apache.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 25 February, 2014 5:57:02 PM
> Subject: Re: [keycloak-dev] 1.0 Final roadmap
> 
> On Tuesday, February 25, 2014, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > See comments in-line
> >
> > Mobile adapters would be really good to have. If we can get help from the
> > AeroGear team to do these, maybe we could include this as well? For
> > simplicity we could just aim for a working Cordova example, but Android and
> > iOS adapters would be great.
> 
> 
> 
> We have OAuth2 (JS/iOS - Android coming).
> Could give that a shot;

We have a working JS, but would be interesting to checkout yours. I assume it's the JS version that is used with Cordova apps?

Any chance someone from AeroGear can try out Keycloak with the iOS adapter? I don't have any iOS devices available :/

What's the ETA for Android?

> 
> -Matthias
> 
> 
> >
> > It would also be nice to make Keycloak more "embeddable". I'd like to be
> > able to improve how Keycloak is embedded into LiveOak, but there's also the
> > issue around WildFly console needing to embed it. Let's have a separate
> > thread on this, but my current (updated) thinking is to utilize RestEasy,
> > but to remove use of servlets
> >
> > There's a whole bunch of JIRA issues with fix for beta1. In the effort to
> > prune this list a bit, here's some I think we can postpone to later:
> >
> > KEYCLOAK-313 Manage devices
> > KEYCLOAK-311 Custom user profiles
> > KEYCLOAK-310 SPI for multi-factor authentication
> > KEYCLOAK-308 Cordova adapter
> > KEYCLOAK-307 iPhone adapter
> > KEYCLOAK-306 Android adapter
> > KEYCLOAK-301 Internationalization support
> > KEYCLOAK-300 Auto configuration of MySQL or PostgreSQL in OpenShift
> > cartridge
> > KEYCLOAK-266 Integrated help in admin console
> > KEYCLOAK-265 Optional instructions to social providers
> > KEYCLOAK-242 Add remember machine option for two factor authentication
> > KEYCLOAK-182 List applications on account management
> > KEYCLOAK-161 Allow users to create oauth clients through account pages
> > KEYCLOAK-57 Mobile example application
> >
> > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com <javascript:;>>
> > > To: keycloak-dev at lists.jboss.org <javascript:;>
> > > Sent: Tuesday, 25 February, 2014 4:51:44 PM
> > > Subject: [keycloak-dev] 1.0 Final roadmap
> > >
> > > What's left for must-have features before we can start pushing for a
> > > 1.0.Final release?  We need to release 1.0 sometime in June.
> >
> > Any particular reason for June?
> >
> > >
> > > * Minimal OpenID Connect support
> > > * Import/Export of various items of a realm (for data migration).
> > > * Aerogear bootstrap requirements
> > > * Theme support for admin console so we can brand it.
> > > * Revocation policies.  I'm thinking Not-Before is good enough for a 1.0
> > > release.  We need to be able to push this to deployed apps.  And also
> > > maybe piggyback this information in AcessTokenResponse.  This also of
> > > course needs to be stored within subsystem config too, or maybe we could
> > > just have adapters pull that information from server at bootup.
> >
> > We probably need a separate thread to discuss this, but it's important
> > that users can view what applications can currently access their account
> > and revoke access to individual apps. This means we need to know what
> > refresh tokens are valid, and which have been revoked by a user.
> >
> > > * Remember Me for social logins
> > > * Federation of users/credentials with LDAP/AD.  Hopefully through
> > > Picketlink.
> >
> > Is this really required for the first release?
> >
> > > * User session management.  Admin can logout a user.
> > > * Audit log.
> >
> > Related things we'll need are brute force protection (including max failed
> > login attempt before locking a users account) and email notifications on
> > certain events.
> >
> > >
> > >
> > > Scaling/Optimization:
> > >
> > > * Storage cache for the token service so it doesn't hit the database.
> > > * Make token service stateless for clustering environments (maybe don't
> > > need for 1.0?)
> > >
> > >
> > > We'll stick with only AS7/EAP/Wildfly adapters for 1st release.  We also
> > > have to pencil in time for weeks of test writing, benchmarking, and
> > > documentation.
> > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org <javascript:;>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> 
> --
> Sent from Gmail Mobile
> 

From bburke at redhat.com  Wed Feb 26 09:39:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 26 Feb 2014 09:39:40 -0500
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <etPan.530df98a.327b23c6.4da@animus>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
	<530D3800.3010900@redhat.com> <etPan.530df98a.327b23c6.4da@animus>
Message-ID: <530DFCAC.2040605@redhat.com>



On 2/26/2014 9:26 AM, Bruno Oliveira wrote:
> Hi Bill, I?m not sure if this is planned, but don?t hurt to ask. For Aerogear we have the following needs and I would like to help if it's planned for Keycloak (I don't want to create overlappings)
>
> - Data sync
>
> Scenario: user must update the data on the server, but it must be stored encrypted.
>
> I'm considering to generate a key pair during the "handshake" between client and server and send client's public key to the server. In this way prevent user's data violation.
>

Does the keypair belong to the user?  Currently I'm implementing OpenID 
Connect's IDToken and having a screen that can say which ID "claims" an 
application or oauth client is allowed to view.  We could add custom 
user attributes and the ability to request a claim for them.

> - Unified push server
>
> The passphrase is sent over the wire in raw text because that's required by Apple (thanks Apple). To prevent exposing user's passphrase. I was wondering about a key agreement to stabilish a shared secret between client/server, into this way the client could send that passphrase encrypted and the server decrypts it on the fly to send push messages.
>
> Do you guys have something similar like that, planned? Or totally out of the scope? I could help.
>

See above.

> - Legacy authentication
>
> Currently we have basic/digest supported on the client side (yep, they are pretty much unsafe, but, legacies...). Is it something planned to be supported on Keycloak? What would be the alternatives?
>

Not sure how Keycloak fits with basic/digest protocols.  You want the 
application to handle login input and just delegate to Keycloak like you 
would any other JBoss/Wildfly security domain?  We could provide that 
feature, but then you end up with not using 90% of Keycloak's features. 
  Is that what you mean?

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

From stian at redhat.com  Wed Feb 26 09:42:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 26 Feb 2014 09:42:59 -0500 (EST)
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <530D3800.3010900@redhat.com>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
	<530D3800.3010900@redhat.com>
Message-ID: <1836173211.17019003.1393425779357.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: Wednesday, 26 February, 2014 12:40:32 AM
> Subject: Re: [keycloak-dev] 1.0 Final roadmap
> 
> 
> 
> On 2/25/2014 12:44 PM, Stian Thorgersen wrote:
> > See comments in-line
> >
> > Mobile adapters would be really good to have. If we can get help from the
> > AeroGear team to do these, maybe we could include this as well? For
> > simplicity we could just aim for a working Cordova example, but Android
> > and iOS adapters would be great.
> >
> 
> Unless we get a community submission for mobile adapters, this is going
> to have to wait as I'm not sure we have time.  I also wanted Tomcat,
> Jetty, Node.js, and JIRA adapters too, but those I think might have to wait.
> 
> > It would also be nice to make Keycloak more "embeddable". I'd like to be
> > able to improve how Keycloak is embedded into LiveOak, but there's also
> > the issue around WildFly console needing to embed it. Let's have a
> > separate thread on this, but my current (updated) thinking is to utilize
> > RestEasy, but to remove use of servlets
> >
> > There's a whole bunch of JIRA issues with fix for beta1. In the effort to
> > prune this list a bit, here's some I think we can postpone to later:
> >
> 
> I vote we keep everything in JIRA until we start running out of time,
> then we'll defer.
> 
> >
> > Any particular reason for June?
> >
> 
> Aerogear requirement to get us in product.  Which is a good thing. :)

Nice :)

> 
> >
> > We probably need a separate thread to discuss this, but it's important that
> > users can view what applications can currently access their account and
> > revoke access to individual apps. This means we need to know what refresh
> > tokens are valid, and which have been revoked by a user.
> >
> 
> Crap.  I forgot about this.  Thanks for reminding me.
> 
> >> * Remember Me for social logins
> >> * Federation of users/credentials with LDAP/AD.  Hopefully through
> >> Picketlink.
> >
> > Is this really required for the first release?
> 
> If we want to be considered in Middleware BU as an SSO solution, we need
> this.  Also will relieve some tensions with PL team hopefully if we
> leverage their stuff.

Makes sense

> 
> >
> >> * User session management.  Admin can logout a user.
> >> * Audit log.
> >
> > Related things we'll need are brute force protection (including max failed
> > login attempt before locking a users account) and email notifications on
> > certain events.
> >
> 
> Wouldn't it be better just to add a 1 second sleep?  Checking max failed
> logins would require persistence per authentication.

I think it's something that's a hard-requirement for anyone with really strong security needs. I'd assume it would be an optional feature.

For audit we'll need to persist failed logins, maybe also last logins. We can piggy-back on that.

Admins should be able to go to the admin console and view the recent audit logs. Users should also be able to see events related to their account.

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

From corinnekrych at gmail.com  Wed Feb 26 10:09:43 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Wed, 26 Feb 2014 16:09:43 +0100
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <1836173211.17019003.1393425779357.JavaMail.zimbra@redhat.com>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
	<530D3800.3010900@redhat.com>
	<1836173211.17019003.1393425779357.JavaMail.zimbra@redhat.com>
Message-ID: <CAL8vO=d1S3mPXQSSvVKe8htE2y7VWsXFnXUVqK4ZdDC3BqhdOA@mail.gmail.com>

On 26 February 2014 15:42, Stian Thorgersen <stian at redhat.com> 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: Wednesday, 26 February, 2014 12:40:32 AM
> > Subject: Re: [keycloak-dev] 1.0 Final roadmap
> >
> >
> >
> > On 2/25/2014 12:44 PM, Stian Thorgersen wrote:
> > > See comments in-line
> > >
> > > Mobile adapters would be really good to have. If we can get help from
> the
> > > AeroGear team to do these, maybe we could include this as well? For
> > > simplicity we could just aim for a working Cordova example, but Android
> > > and iOS adapters would be great.
>

Sure, we could give it a trial with our iOS adapter.
Android one is not yet available.



> > >
> >
> > Unless we get a community submission for mobile adapters, this is going
> > to have to wait as I'm not sure we have time.  I also wanted Tomcat,
> > Jetty, Node.js, and JIRA adapters too, but those I think might have to
> wait.
> >
> > > It would also be nice to make Keycloak more "embeddable". I'd like to
> be
> > > able to improve how Keycloak is embedded into LiveOak, but there's also
> > > the issue around WildFly console needing to embed it. Let's have a
> > > separate thread on this, but my current (updated) thinking is to
> utilize
> > > RestEasy, but to remove use of servlets
> > >
> > > There's a whole bunch of JIRA issues with fix for beta1. In the effort
> to
> > > prune this list a bit, here's some I think we can postpone to later:
> > >
> >
> > I vote we keep everything in JIRA until we start running out of time,
> > then we'll defer.
> >
> > >
> > > Any particular reason for June?
> > >
> >
> > Aerogear requirement to get us in product.  Which is a good thing. :)
>
> Nice :)
>
> >
> > >
> > > We probably need a separate thread to discuss this, but it's important
> that
> > > users can view what applications can currently access their account and
> > > revoke access to individual apps. This means we need to know what
> refresh
> > > tokens are valid, and which have been revoked by a user.
> > >
> >
> > Crap.  I forgot about this.  Thanks for reminding me.
> >
> > >> * Remember Me for social logins
> > >> * Federation of users/credentials with LDAP/AD.  Hopefully through
> > >> Picketlink.
> > >
> > > Is this really required for the first release?
> >
> > If we want to be considered in Middleware BU as an SSO solution, we need
> > this.  Also will relieve some tensions with PL team hopefully if we
> > leverage their stuff.
>
> Makes sense
>
> >
> > >
> > >> * User session management.  Admin can logout a user.
> > >> * Audit log.
> > >
> > > Related things we'll need are brute force protection (including max
> failed
> > > login attempt before locking a users account) and email notifications
> on
> > > certain events.
> > >
> >
> > Wouldn't it be better just to add a 1 second sleep?  Checking max failed
> > logins would require persistence per authentication.
>
> I think it's something that's a hard-requirement for anyone with really
> strong security needs. I'd assume it would be an optional feature.
>
> For audit we'll need to persist failed logins, maybe also last logins. We
> can piggy-back on that.
>
> Admins should be able to go to the admin console and view the recent audit
> logs. Users should also be able to see events related to their account.
>
> >
> > --
> > 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/20140226/59a06557/attachment.html 

From bruno at abstractj.org  Wed Feb 26 11:46:21 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 26 Feb 2014 13:46:21 -0300
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <530DFCAC.2040605@redhat.com>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
	<530D3800.3010900@redhat.com> <etPan.530df98a.327b23c6.4da@animus>
	<530DFCAC.2040605@redhat.com>
Message-ID: <etPan.530e1a5e.19495cff.4da@animus>

Hi Bill,

On February 26, 2014 at 11:39:45 AM, Bill Burke (bburke at redhat.com) wrote:
> 
> Does the keypair belong to the user? Currently I'm implementing 
> OpenID
> Connect's IDToken and having a screen that can say which ID "claims" 
> an
> application or oauth client is allowed to view. We could add custom 
> user attributes and the ability to request a claim for them.

So the server could make use of that for public key encryption? If yes, that would be very handy.

> 
> > - Unified push server
> >
> > The passphrase is sent over the wire in raw text because that's 
> required by Apple (thanks Apple). To prevent exposing user's 
> passphrase. I was wondering about a key agreement to stabilish 
> a shared secret between client/server, into this way the client 
> could send that passphrase encrypted and the server decrypts 
> it on the fly to send push messages.
> >
> > Do you guys have something similar like that, planned? Or totally 
> out of the scope? I could help.
> >
> 
> See above.

That might work to this scenario too.

> 
> > - Legacy authentication
> >
> > Currently we have basic/digest supported on the client side 
> (yep, they are pretty much unsafe, but, legacies...). Is it something 
> planned to be supported on Keycloak? What would be the alternatives? 
> >
> 
> Not sure how Keycloak fits with basic/digest protocols. You 
> want the
> application to handle login input and just delegate to Keycloak 
> like you
> would any other JBoss/Wildfly security domain? We could provide 
> that
> feature, but then you end up with not using 90% of Keycloak's features. 
> Is that what you mean?

Me neither, currently we do it with PicketLink using servlet filters, and I think we can just use Wildfly support because lose Keycloak features would be bad. The idea about basic/digest on AeroGear was to support legacy systems outside there, we can figure this out.

Thanks Bill.

From stian at redhat.com  Wed Feb 26 11:53:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 26 Feb 2014 11:53:59 -0500 (EST)
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <CAL8vO=d1S3mPXQSSvVKe8htE2y7VWsXFnXUVqK4ZdDC3BqhdOA@mail.gmail.com>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
	<530D3800.3010900@redhat.com>
	<1836173211.17019003.1393425779357.JavaMail.zimbra@redhat.com>
	<CAL8vO=d1S3mPXQSSvVKe8htE2y7VWsXFnXUVqK4ZdDC3BqhdOA@mail.gmail.com>
Message-ID: <1834451760.17153056.1393433639439.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Corinne Krych" <corinnekrych at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 26 February, 2014 3:09:43 PM
> Subject: Re: [keycloak-dev] 1.0 Final roadmap
> 
> On 26 February 2014 15:42, Stian Thorgersen <stian at redhat.com> 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: Wednesday, 26 February, 2014 12:40:32 AM
> > > Subject: Re: [keycloak-dev] 1.0 Final roadmap
> > >
> > >
> > >
> > > On 2/25/2014 12:44 PM, Stian Thorgersen wrote:
> > > > See comments in-line
> > > >
> > > > Mobile adapters would be really good to have. If we can get help from
> > the
> > > > AeroGear team to do these, maybe we could include this as well? For
> > > > simplicity we could just aim for a working Cordova example, but Android
> > > > and iOS adapters would be great.
> >
> 
> Sure, we could give it a trial with our iOS adapter.
> Android one is not yet available.

That would be great - let me know if you have any problems and I'll fix asap

Any rough idea when an Android one would be available?

> 
> 
> 
> > > >
> > >
> > > Unless we get a community submission for mobile adapters, this is going
> > > to have to wait as I'm not sure we have time.  I also wanted Tomcat,
> > > Jetty, Node.js, and JIRA adapters too, but those I think might have to
> > wait.
> > >
> > > > It would also be nice to make Keycloak more "embeddable". I'd like to
> > be
> > > > able to improve how Keycloak is embedded into LiveOak, but there's also
> > > > the issue around WildFly console needing to embed it. Let's have a
> > > > separate thread on this, but my current (updated) thinking is to
> > utilize
> > > > RestEasy, but to remove use of servlets
> > > >
> > > > There's a whole bunch of JIRA issues with fix for beta1. In the effort
> > to
> > > > prune this list a bit, here's some I think we can postpone to later:
> > > >
> > >
> > > I vote we keep everything in JIRA until we start running out of time,
> > > then we'll defer.
> > >
> > > >
> > > > Any particular reason for June?
> > > >
> > >
> > > Aerogear requirement to get us in product.  Which is a good thing. :)
> >
> > Nice :)
> >
> > >
> > > >
> > > > We probably need a separate thread to discuss this, but it's important
> > that
> > > > users can view what applications can currently access their account and
> > > > revoke access to individual apps. This means we need to know what
> > refresh
> > > > tokens are valid, and which have been revoked by a user.
> > > >
> > >
> > > Crap.  I forgot about this.  Thanks for reminding me.
> > >
> > > >> * Remember Me for social logins
> > > >> * Federation of users/credentials with LDAP/AD.  Hopefully through
> > > >> Picketlink.
> > > >
> > > > Is this really required for the first release?
> > >
> > > If we want to be considered in Middleware BU as an SSO solution, we need
> > > this.  Also will relieve some tensions with PL team hopefully if we
> > > leverage their stuff.
> >
> > Makes sense
> >
> > >
> > > >
> > > >> * User session management.  Admin can logout a user.
> > > >> * Audit log.
> > > >
> > > > Related things we'll need are brute force protection (including max
> > failed
> > > > login attempt before locking a users account) and email notifications
> > on
> > > > certain events.
> > > >
> > >
> > > Wouldn't it be better just to add a 1 second sleep?  Checking max failed
> > > logins would require persistence per authentication.
> >
> > I think it's something that's a hard-requirement for anyone with really
> > strong security needs. I'd assume it would be an optional feature.
> >
> > For audit we'll need to persist failed logins, maybe also last logins. We
> > can piggy-back on that.
> >
> > Admins should be able to go to the admin console and view the recent audit
> > logs. Users should also be able to see events related to their account.
> >
> > >
> > > --
> > > 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 Feb 26 12:41:23 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 26 Feb 2014 12:41:23 -0500 (EST)
Subject: [keycloak-dev] Realm admin permissions added
In-Reply-To: <1261348966.15836287.1393333179847.JavaMail.zimbra@redhat.com>
References: <1261348966.15836287.1393333179847.JavaMail.zimbra@redhat.com>
Message-ID: <460655170.17190999.1393436483825.JavaMail.zimbra@redhat.com>

Added view roles as well. Admin console has been updated to make forms read-only if user only has view role (there's a few widgets it doesn't work for, but should be fixed soon).

The new roles are:

* view-realm
* view-users
* view-applications
* view-clients

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 25 February, 2014 12:59:39 PM
> Subject: [keycloak-dev] Realm admin permissions added
> 
> Realm admin permissions added has been added to master.
> 
> A quick overview on how it works:
> 
> When a realm is created an application is created in the keycloak-admin
> realm. The application name is '<realm name>-realm'. This application
> represents the roles associated with the realm, and let's you add role
> mappings to users as well as scope mappings to apps/clients. A realm app has
> the following roles:
> 
> * manage-realm
> * manage-users
> * manage-applications
> * manage-clients
> 
> These roles are all read/write. In the future I imagine we can add some view
> only roles (view-realm, view-users, view-applications, view-clients). I
> didn't add it this time around as it would require a fair amount of changes
> to admin console (everything is forms with buttons at the moment, so would
> have to add read only views).
> 
> When listing realms the admin console will only return the realms where the
> user has one or more of the above roles. The admin console will also change
> the menu depending on what roles the user has (for example a user that only
> has 'manage-clients' and 'manage-users' will not see 'settings' and
> 'applications').
> 
> There's a realm role called 'admin' as well. This is a composite role and
> when creating a new realm all roles for the new realm are added to it. Only
> users with this role is allowed to create, import or delete realms.
> 
> To create a new realm, with a user that has only 'manage-users' and
> 'manage-clients' access to this new realm, do the following:
> 
> 1. Create a new realm called 'test'
> 2. Navigate to users for 'keycloak-admin' realm
> (http://localhost:8081/auth/admin/index.html#/realms/keycloak-admin/users)
> 3. Create new user called 'test' (enable + reset creds)
> 4. Click on 'Role mappings'
> 5. In 'Applications' drop-down select 'test-realm'
> 6. Select 'manage-users' and 'manage-clients' and click the right-arrow to
> add mapping
> 7. Log out of admin console, and login as 'test'
> 
> The pages in the admin console themselves haven't been disabled, only the
> menu to navigate there. You can try opening for example:
> 
> http://localhost:8081/auth/admin/index.html#/realms/test/social-settings
> http://localhost:8081/auth/admin/index.html#/realms/test/applications
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Wed Feb 26 14:11:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 26 Feb 2014 14:11:54 -0500
Subject: [keycloak-dev] Realm admin permissions added
In-Reply-To: <460655170.17190999.1393436483825.JavaMail.zimbra@redhat.com>
References: <1261348966.15836287.1393333179847.JavaMail.zimbra@redhat.com>
	<460655170.17190999.1393436483825.JavaMail.zimbra@redhat.com>
Message-ID: <530E3C7A.4010007@redhat.com>

Very nice.

On 2/26/2014 12:41 PM, Stian Thorgersen wrote:
> Added view roles as well. Admin console has been updated to make forms read-only if user only has view role (there's a few widgets it doesn't work for, but should be fixed soon).
>
> The new roles are:
>
> * view-realm
> * view-users
> * view-applications
> * view-clients
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 25 February, 2014 12:59:39 PM
>> Subject: [keycloak-dev] Realm admin permissions added
>>
>> Realm admin permissions added has been added to master.
>>
>> A quick overview on how it works:
>>
>> When a realm is created an application is created in the keycloak-admin
>> realm. The application name is '<realm name>-realm'. This application
>> represents the roles associated with the realm, and let's you add role
>> mappings to users as well as scope mappings to apps/clients. A realm app has
>> the following roles:
>>
>> * manage-realm
>> * manage-users
>> * manage-applications
>> * manage-clients
>>
>> These roles are all read/write. In the future I imagine we can add some view
>> only roles (view-realm, view-users, view-applications, view-clients). I
>> didn't add it this time around as it would require a fair amount of changes
>> to admin console (everything is forms with buttons at the moment, so would
>> have to add read only views).
>>
>> When listing realms the admin console will only return the realms where the
>> user has one or more of the above roles. The admin console will also change
>> the menu depending on what roles the user has (for example a user that only
>> has 'manage-clients' and 'manage-users' will not see 'settings' and
>> 'applications').
>>
>> There's a realm role called 'admin' as well. This is a composite role and
>> when creating a new realm all roles for the new realm are added to it. Only
>> users with this role is allowed to create, import or delete realms.
>>
>> To create a new realm, with a user that has only 'manage-users' and
>> 'manage-clients' access to this new realm, do the following:
>>
>> 1. Create a new realm called 'test'
>> 2. Navigate to users for 'keycloak-admin' realm
>> (http://localhost:8081/auth/admin/index.html#/realms/keycloak-admin/users)
>> 3. Create new user called 'test' (enable + reset creds)
>> 4. Click on 'Role mappings'
>> 5. In 'Applications' drop-down select 'test-realm'
>> 6. Select 'manage-users' and 'manage-clients' and click the right-arrow to
>> add mapping
>> 7. Log out of admin console, and login as 'test'
>>
>> The pages in the admin console themselves haven't been disabled, only the
>> menu to navigate there. You can try opening for example:
>>
>> http://localhost:8081/auth/admin/index.html#/realms/test/social-settings
>> http://localhost:8081/auth/admin/index.html#/realms/test/applications
>> _______________________________________________
>> 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 bburke at redhat.com  Wed Feb 26 19:40:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 26 Feb 2014 19:40:55 -0500
Subject: [keycloak-dev] IDToken and claims implemented
Message-ID: <530E8997.4080807@redhat.com>

OpenID Connect IDToken and claims are implemented:

* IDToken is now added to AccessTokenResponse.  I think we pass the 
minimal OpenID Connect requirements now.
* You can configured allowed claims per application and oauth client.
* Allowed claims are now added to IDToken and Access Token.  You can now 
get the username, name, email, etc. through them.  The demo 
customer-portal shows this.
* I still need to add claim permission to the OAuth Grant Page.

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

From bburke at redhat.com  Wed Feb 26 19:43:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 26 Feb 2014 19:43:35 -0500
Subject: [keycloak-dev] Refactoring Model
Message-ID: <530E8A37.10004@redhat.com>

I'm refactoring ApplicationModel and OAuthClientModel to inherit from 
the same interface, ClientModel.  I'm moving all the app/client specific 
attributes out of UserModel and into ClientModel.

I also want the TokenService to be dealing with ClientModel instead of 
putzing around with UserModels and figuring out if they are apps or not. 
  right now, if you change an application name it can screw up 
everything when generating a token.

So, expect some changes in this area this week.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Feb 26 22:08:13 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 26 Feb 2014 22:08:13 -0500
Subject: [keycloak-dev] Refactoring Model
In-Reply-To: <530E8A37.10004@redhat.com>
References: <530E8A37.10004@redhat.com>
Message-ID: <530EAC1D.90201@redhat.com>

Ok, I did the first phase of this.  Most code is now dealing with 
ClientModel rather than UserModel in the TokenService, et. al.

I hope nobody is working on anything major :) I'm just trying to avoid 
duplicating a lot of code.  I"d also like to eventually not use a User 
to model any type of client as I'm worried about username clashes and such.

On 2/26/2014 7:43 PM, Bill Burke wrote:
> I'm refactoring ApplicationModel and OAuthClientModel to inherit from
> the same interface, ClientModel.  I'm moving all the app/client specific
> attributes out of UserModel and into ClientModel.
>
> I also want the TokenService to be dealing with ClientModel instead of
> putzing around with UserModels and figuring out if they are apps or not.
>    right now, if you change an application name it can screw up
> everything when generating a token.
>
> So, expect some changes in this area this week.
>

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

From bburke at redhat.com  Wed Feb 26 22:21:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 26 Feb 2014 22:21:19 -0500
Subject: [keycloak-dev] Refresh requird to view all admin console tabs
Message-ID: <530EAF2F.4040006@redhat.com>

When you import a realm from json, then click on it in the list, it 
brings you to the realm page of that realm.  But the Links on the left 
menu don't show up unless you refresh the page.

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

From bburke at redhat.com  Wed Feb 26 22:22:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 26 Feb 2014 22:22:44 -0500
Subject: [keycloak-dev] formatting messed up a little
Message-ID: <530EAF84.406@redhat.com>

Formatting on the login and oauth screens is screwed up a little. 
Buttons are on top of one another.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu Feb 27 04:16:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 27 Feb 2014 04:16:43 -0500 (EST)
Subject: [keycloak-dev] Refresh requird to view all admin console tabs
In-Reply-To: <530EAF2F.4040006@redhat.com>
References: <530EAF2F.4040006@redhat.com>
Message-ID: <502901992.17549780.1393492603409.JavaMail.zimbra@redhat.com>

I'll fix it. It's because it doesn't think the user has the required permissions to see the new realm.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 27 February, 2014 3:21:19 AM
> Subject: [keycloak-dev] Refresh requird to view all admin console tabs
> 
> When you import a realm from json, then click on it in the list, it
> brings you to the realm page of that realm.  But the Links on the left
> menu don't show up unless you refresh the page.
> 
> --
> 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 Feb 27 04:45:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 27 Feb 2014 04:45:27 -0500 (EST)
Subject: [keycloak-dev] Refactoring Model
In-Reply-To: <530EAC1D.90201@redhat.com>
References: <530E8A37.10004@redhat.com> <530EAC1D.90201@redhat.com>
Message-ID: <1490821016.17564160.1393494327885.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 27 February, 2014 3:08:13 AM
> Subject: Re: [keycloak-dev] Refactoring Model
> 
> Ok, I did the first phase of this.  Most code is now dealing with
> ClientModel rather than UserModel in the TokenService, et. al.
> 
> I hope nobody is working on anything major :) I'm just trying to avoid
> duplicating a lot of code.  I"d also like to eventually not use a User
> to model any type of client as I'm worried about username clashes and such.

+1 Assuming you're talking about getting rid of ClientModel.get/setAgent and just pulling all required fields from UserModel into ClientModel. It would also be nice to remove the "special" roles we have (KEYCLOAK_APPLICATION and KEYCLOAK_IDENTITY_REQUESTER).

One idea I had was to rename ApplicationModel to ResourceModel. A resource would only have name and roles. No web-origins, redirect-uris, secret or scope mapping. Then we'd add an option to ClientModel to automatically grant access instead. I think that makes the distinction clearer. Basically if your modelling something that is accessed through roles, you create a resource. If you're modelling something that wants to login users you create a client. And as some clients would be "internal" they have the option of automatically being granted permissions.

> 
> On 2/26/2014 7:43 PM, Bill Burke wrote:
> > I'm refactoring ApplicationModel and OAuthClientModel to inherit from
> > the same interface, ClientModel.  I'm moving all the app/client specific
> > attributes out of UserModel and into ClientModel.
> >
> > I also want the TokenService to be dealing with ClientModel instead of
> > putzing around with UserModels and figuring out if they are apps or not.
> >    right now, if you change an application name it can screw up
> > everything when generating a token.
> >
> > So, expect some changes in this area this week.
> >
> 
> --
> 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 Feb 27 06:12:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 27 Feb 2014 06:12:30 -0500 (EST)
Subject: [keycloak-dev] Realm admin permissions added
In-Reply-To: <530E3C7A.4010007@redhat.com>
References: <1261348966.15836287.1393333179847.JavaMail.zimbra@redhat.com>
	<460655170.17190999.1393436483825.JavaMail.zimbra@redhat.com>
	<530E3C7A.4010007@redhat.com>
Message-ID: <1757445325.17616670.1393499550833.JavaMail.zimbra@redhat.com>

Added one more role create-realm. This is handy as it allows adding users that can create new realms without giving them permissions to everything. When a realm is created and the user is not an admin the user will be given all roles for that realm. As a side-effect this also let's you have a SaaS type solution where self-registered users can create and manage their own realms, but not access other realms.

Now it's only a bit more testing + documentation left for this

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 26 February, 2014 7:11:54 PM
> Subject: Re: [keycloak-dev] Realm admin permissions added
> 
> Very nice.
> 
> On 2/26/2014 12:41 PM, Stian Thorgersen wrote:
> > Added view roles as well. Admin console has been updated to make forms
> > read-only if user only has view role (there's a few widgets it doesn't
> > work for, but should be fixed soon).
> >
> > The new roles are:
> >
> > * view-realm
> > * view-users
> > * view-applications
> > * view-clients
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 25 February, 2014 12:59:39 PM
> >> Subject: [keycloak-dev] Realm admin permissions added
> >>
> >> Realm admin permissions added has been added to master.
> >>
> >> A quick overview on how it works:
> >>
> >> When a realm is created an application is created in the keycloak-admin
> >> realm. The application name is '<realm name>-realm'. This application
> >> represents the roles associated with the realm, and let's you add role
> >> mappings to users as well as scope mappings to apps/clients. A realm app
> >> has
> >> the following roles:
> >>
> >> * manage-realm
> >> * manage-users
> >> * manage-applications
> >> * manage-clients
> >>
> >> These roles are all read/write. In the future I imagine we can add some
> >> view
> >> only roles (view-realm, view-users, view-applications, view-clients). I
> >> didn't add it this time around as it would require a fair amount of
> >> changes
> >> to admin console (everything is forms with buttons at the moment, so would
> >> have to add read only views).
> >>
> >> When listing realms the admin console will only return the realms where
> >> the
> >> user has one or more of the above roles. The admin console will also
> >> change
> >> the menu depending on what roles the user has (for example a user that
> >> only
> >> has 'manage-clients' and 'manage-users' will not see 'settings' and
> >> 'applications').
> >>
> >> There's a realm role called 'admin' as well. This is a composite role and
> >> when creating a new realm all roles for the new realm are added to it.
> >> Only
> >> users with this role is allowed to create, import or delete realms.
> >>
> >> To create a new realm, with a user that has only 'manage-users' and
> >> 'manage-clients' access to this new realm, do the following:
> >>
> >> 1. Create a new realm called 'test'
> >> 2. Navigate to users for 'keycloak-admin' realm
> >> (http://localhost:8081/auth/admin/index.html#/realms/keycloak-admin/users)
> >> 3. Create new user called 'test' (enable + reset creds)
> >> 4. Click on 'Role mappings'
> >> 5. In 'Applications' drop-down select 'test-realm'
> >> 6. Select 'manage-users' and 'manage-clients' and click the right-arrow to
> >> add mapping
> >> 7. Log out of admin console, and login as 'test'
> >>
> >> The pages in the admin console themselves haven't been disabled, only the
> >> menu to navigate there. You can try opening for example:
> >>
> >> http://localhost:8081/auth/admin/index.html#/realms/test/social-settings
> >> http://localhost:8081/auth/admin/index.html#/realms/test/applications
> >> _______________________________________________
> >> 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 Feb 27 09:19:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 27 Feb 2014 09:19:53 -0500
Subject: [keycloak-dev] Realm admin permissions added
In-Reply-To: <1757445325.17616670.1393499550833.JavaMail.zimbra@redhat.com>
References: <1261348966.15836287.1393333179847.JavaMail.zimbra@redhat.com>
	<460655170.17190999.1393436483825.JavaMail.zimbra@redhat.com>
	<530E3C7A.4010007@redhat.com>
	<1757445325.17616670.1393499550833.JavaMail.zimbra@redhat.com>
Message-ID: <530F4989.5050307@redhat.com>



On 2/27/2014 6:12 AM, Stian Thorgersen wrote:
> Added one more role create-realm. This is handy as it allows adding users that can create new realms without giving them permissions to everything. When a realm is created and the user is not an admin the user will be given all roles for that realm. As a side-effect this also let's you have a SaaS type solution where self-registered users can create and manage their own realms, but not access other realms.
>
> Now it's only a bit more testing + documentation left for this
>

Awesome!  You figured out the chicken and egg problem with SaaS that 
baffled me for awhile.  Very cool Stian.

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

From bburke at redhat.com  Thu Feb 27 09:34:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 27 Feb 2014 09:34:41 -0500
Subject: [keycloak-dev] Refactoring Model
In-Reply-To: <1490821016.17564160.1393494327885.JavaMail.zimbra@redhat.com>
References: <530E8A37.10004@redhat.com> <530EAC1D.90201@redhat.com>
	<1490821016.17564160.1393494327885.JavaMail.zimbra@redhat.com>
Message-ID: <530F4D01.20707@redhat.com>



On 2/27/2014 4:45 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 27 February, 2014 3:08:13 AM
>> Subject: Re: [keycloak-dev] Refactoring Model
>>
>> Ok, I did the first phase of this.  Most code is now dealing with
>> ClientModel rather than UserModel in the TokenService, et. al.
>>
>> I hope nobody is working on anything major :) I'm just trying to avoid
>> duplicating a lot of code.  I"d also like to eventually not use a User
>> to model any type of client as I'm worried about username clashes and such.
>
> +1 Assuming you're talking about getting rid of ClientModel.get/setAgent and just pulling all required fields from UserModel into ClientModel. It would also be nice to remove the "special" roles we have (KEYCLOAK_APPLICATION and KEYCLOAK_IDENTITY_REQUESTER).
>

I'll do a 2nd rev of this refactoring today and get rid of the 
ClientModel.agent and special roles too.

> One idea I had was to rename ApplicationModel to ResourceModel. A resource would only have name and roles. No web-origins, redirect-uris, secret or scope mapping. Then we'd add an option to ClientModel to automatically grant access instead. I think that makes the distinction clearer. Basically if your modelling something that is accessed through roles, you create a resource. If you're modelling something that wants to login users you create a client. And as some clients would be "internal" they have the option of automatically being granted permissions.
>

I like that for an implementation detail at least.  Not sure about 
propagating that idea to the admin console though.

Applications have always been special in that they don't require an 
oauth grant page, can be administered, you can log out of them, and 
eventually we'll have screens for session management and stuff and 
things like that for them.  For clustering, at least for Wildfly/JBoss, 
I don't even think it makes sense to have the idea of a "deployment" as 
I believe cluster nodes would get the same configuration from the domain 
controller (client_id, secret, etc.).  What we can do for a cluster is 
make Admin URl a Set<URI> maybe even the same with Redirect URI.

I do think I want to rename OAuth Client to Client though.

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

From stian at redhat.com  Thu Feb 27 11:45:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 27 Feb 2014 11:45:15 -0500 (EST)
Subject: [keycloak-dev] Refactoring Model
In-Reply-To: <530F4D01.20707@redhat.com>
References: <530E8A37.10004@redhat.com> <530EAC1D.90201@redhat.com>
	<1490821016.17564160.1393494327885.JavaMail.zimbra@redhat.com>
	<530F4D01.20707@redhat.com>
Message-ID: <1716126282.17907970.1393519515874.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, 27 February, 2014 2:34:41 PM
> Subject: Re: [keycloak-dev] Refactoring Model
> 
> 
> 
> On 2/27/2014 4:45 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 27 February, 2014 3:08:13 AM
> >> Subject: Re: [keycloak-dev] Refactoring Model
> >>
> >> Ok, I did the first phase of this.  Most code is now dealing with
> >> ClientModel rather than UserModel in the TokenService, et. al.
> >>
> >> I hope nobody is working on anything major :) I'm just trying to avoid
> >> duplicating a lot of code.  I"d also like to eventually not use a User
> >> to model any type of client as I'm worried about username clashes and
> >> such.
> >
> > +1 Assuming you're talking about getting rid of ClientModel.get/setAgent
> > and just pulling all required fields from UserModel into ClientModel. It
> > would also be nice to remove the "special" roles we have
> > (KEYCLOAK_APPLICATION and KEYCLOAK_IDENTITY_REQUESTER).
> >
> 
> I'll do a 2nd rev of this refactoring today and get rid of the
> ClientModel.agent and special roles too.
> 
> > One idea I had was to rename ApplicationModel to ResourceModel. A resource
> > would only have name and roles. No web-origins, redirect-uris, secret or
> > scope mapping. Then we'd add an option to ClientModel to automatically
> > grant access instead. I think that makes the distinction clearer.
> > Basically if your modelling something that is accessed through roles, you
> > create a resource. If you're modelling something that wants to login users
> > you create a client. And as some clients would be "internal" they have the
> > option of automatically being granted permissions.
> >
> 
> I like that for an implementation detail at least.  Not sure about
> propagating that idea to the admin console though.
> 
> Applications have always been special in that they don't require an
> oauth grant page, can be administered, you can log out of them, and
> eventually we'll have screens for session management and stuff and
> things like that for them.  For clustering, at least for Wildfly/JBoss,
> I don't even think it makes sense to have the idea of a "deployment" as
> I believe cluster nodes would get the same configuration from the domain
> controller (client_id, secret, etc.).  What we can do for a cluster is
> make Admin URl a Set<URI> maybe even the same with Redirect URI.

Didn't think of all that. Needs some rethinking. I still think it would be nice to have something to represent resources. For example the database service from the example, and the realm-admin apps. It doesn't make sense that they have credentials, redirect-uris and scopes. They will never request a login, only parse bearer tokens.

> 
> I do think I want to rename OAuth Client to Client though.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From vrockai at redhat.com  Thu Feb 27 12:40:45 2014
From: vrockai at redhat.com (Viliam Rockai)
Date: Thu, 27 Feb 2014 18:40:45 +0100
Subject: [keycloak-dev] formatting messed up a little
In-Reply-To: <530EAF84.406@redhat.com>
References: <530EAF84.406@redhat.com>
Message-ID: <1393522845.15208.9.camel@vrockai-laptop>

On Wed, 2014-02-26 at 22:22 -0500, Bill Burke wrote:
> Formatting on the login and oauth screens is screwed up a little. 

What should I do/change in config to see it? 

> Buttons are on top of one another.



From bruno at abstractj.org  Fri Feb 28 06:37:37 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 28 Feb 2014 08:37:37 -0300
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <1834451760.17153056.1393433639439.JavaMail.zimbra@redhat.com>
References: <530CCA20.9070006@redhat.com>
	<474850688.16177876.1393350256430.JavaMail.zimbra@redhat.com>
	<530D3800.3010900@redhat.com>
	<1836173211.17019003.1393425779357.JavaMail.zimbra@redhat.com>
	<CAL8vO=d1S3mPXQSSvVKe8htE2y7VWsXFnXUVqK4ZdDC3BqhdOA@mail.gmail.com>
	<1834451760.17153056.1393433639439.JavaMail.zimbra@redhat.com>
Message-ID: <etPan.53107501.327b23c6.cba@animus>

Hi Stian, we need to discuss with the Android team and make sure that it will be included into their roadmap.

-- 
abstractj

On February 26, 2014 at 1:54:03 PM, Stian Thorgersen (stian at redhat.com) wrote:
> > That would be great - let me know if you have any problems and I'll 
> fix asap
> 
> Any rough idea when an Android one would be available?


From bburke at redhat.com  Fri Feb 28 09:08:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Feb 2014 09:08:44 -0500
Subject: [keycloak-dev] formatting messed up a little
In-Reply-To: <1393522845.15208.9.camel@vrockai-laptop>
References: <530EAF84.406@redhat.com> <1393522845.15208.9.camel@vrockai-laptop>
Message-ID: <5310986C.2060801@redhat.com>

login to the admin console on firefox?  Login button is over the cancel 
button.

On 2/27/2014 12:40 PM, Viliam Rockai wrote:
> On Wed, 2014-02-26 at 22:22 -0500, Bill Burke wrote:
>> Formatting on the login and oauth screens is screwed up a little.
>
> What should I do/change in config to see it?
>
>> Buttons are on top of one another.
>
>

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

From bburke at redhat.com  Fri Feb 28 09:15:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Feb 2014 09:15:53 -0500
Subject: [keycloak-dev] Refactoring Model
In-Reply-To: <1716126282.17907970.1393519515874.JavaMail.zimbra@redhat.com>
References: <530E8A37.10004@redhat.com> <530EAC1D.90201@redhat.com>
	<1490821016.17564160.1393494327885.JavaMail.zimbra@redhat.com>
	<530F4D01.20707@redhat.com>
	<1716126282.17907970.1393519515874.JavaMail.zimbra@redhat.com>
Message-ID: <53109A19.9040301@redhat.com>



On 2/27/2014 11:45 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, 27 February, 2014 2:34:41 PM
>> Subject: Re: [keycloak-dev] Refactoring Model
>>
>>
>>
>> On 2/27/2014 4:45 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 27 February, 2014 3:08:13 AM
>>>> Subject: Re: [keycloak-dev] Refactoring Model
>>>>
>>>> Ok, I did the first phase of this.  Most code is now dealing with
>>>> ClientModel rather than UserModel in the TokenService, et. al.
>>>>
>>>> I hope nobody is working on anything major :) I'm just trying to avoid
>>>> duplicating a lot of code.  I"d also like to eventually not use a User
>>>> to model any type of client as I'm worried about username clashes and
>>>> such.
>>>
>>> +1 Assuming you're talking about getting rid of ClientModel.get/setAgent
>>> and just pulling all required fields from UserModel into ClientModel. It
>>> would also be nice to remove the "special" roles we have
>>> (KEYCLOAK_APPLICATION and KEYCLOAK_IDENTITY_REQUESTER).
>>>
>>
>> I'll do a 2nd rev of this refactoring today and get rid of the
>> ClientModel.agent and special roles too.
>>
>>> One idea I had was to rename ApplicationModel to ResourceModel. A resource
>>> would only have name and roles. No web-origins, redirect-uris, secret or
>>> scope mapping. Then we'd add an option to ClientModel to automatically
>>> grant access instead. I think that makes the distinction clearer.
>>> Basically if your modelling something that is accessed through roles, you
>>> create a resource. If you're modelling something that wants to login users
>>> you create a client. And as some clients would be "internal" they have the
>>> option of automatically being granted permissions.
>>>
>>
>> I like that for an implementation detail at least.  Not sure about
>> propagating that idea to the admin console though.
>>
>> Applications have always been special in that they don't require an
>> oauth grant page, can be administered, you can log out of them, and
>> eventually we'll have screens for session management and stuff and
>> things like that for them.  For clustering, at least for Wildfly/JBoss,
>> I don't even think it makes sense to have the idea of a "deployment" as
>> I believe cluster nodes would get the same configuration from the domain
>> controller (client_id, secret, etc.).  What we can do for a cluster is
>> make Admin URl a Set<URI> maybe even the same with Redirect URI.
>
> Didn't think of all that. Needs some rethinking. I still think it would be nice to have something to represent resources. For example the database service from the example, and the realm-admin apps. It doesn't make sense that they have credentials, redirect-uris and scopes. They will never request a login, only parse bearer tokens.
>

Currently, the database service doesn't need any registration in the 
admin console (and isn't registered in the admin console).  All it is 
doing is verifying tokens so all it needs is the public key of the 
realm.  In the future, the only reason to register it with the admin 
console is to provide an admin URL so the keycloak server can push 
revocation policies or get access stats.


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

From stian at redhat.com  Fri Feb 28 09:29:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 28 Feb 2014 09:29:45 -0500 (EST)
Subject: [keycloak-dev] Refactoring Model
In-Reply-To: <53109A19.9040301@redhat.com>
References: <530E8A37.10004@redhat.com> <530EAC1D.90201@redhat.com>
	<1490821016.17564160.1393494327885.JavaMail.zimbra@redhat.com>
	<530F4D01.20707@redhat.com>
	<1716126282.17907970.1393519515874.JavaMail.zimbra@redhat.com>
	<53109A19.9040301@redhat.com>
Message-ID: <338009493.18568497.1393597785968.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, 28 February, 2014 2:15:53 PM
> Subject: Re: [keycloak-dev] Refactoring Model
> 
> 
> 
> On 2/27/2014 11:45 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, 27 February, 2014 2:34:41 PM
> >> Subject: Re: [keycloak-dev] Refactoring Model
> >>
> >>
> >>
> >> On 2/27/2014 4:45 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 27 February, 2014 3:08:13 AM
> >>>> Subject: Re: [keycloak-dev] Refactoring Model
> >>>>
> >>>> Ok, I did the first phase of this.  Most code is now dealing with
> >>>> ClientModel rather than UserModel in the TokenService, et. al.
> >>>>
> >>>> I hope nobody is working on anything major :) I'm just trying to avoid
> >>>> duplicating a lot of code.  I"d also like to eventually not use a User
> >>>> to model any type of client as I'm worried about username clashes and
> >>>> such.
> >>>
> >>> +1 Assuming you're talking about getting rid of ClientModel.get/setAgent
> >>> and just pulling all required fields from UserModel into ClientModel. It
> >>> would also be nice to remove the "special" roles we have
> >>> (KEYCLOAK_APPLICATION and KEYCLOAK_IDENTITY_REQUESTER).
> >>>
> >>
> >> I'll do a 2nd rev of this refactoring today and get rid of the
> >> ClientModel.agent and special roles too.
> >>
> >>> One idea I had was to rename ApplicationModel to ResourceModel. A
> >>> resource
> >>> would only have name and roles. No web-origins, redirect-uris, secret or
> >>> scope mapping. Then we'd add an option to ClientModel to automatically
> >>> grant access instead. I think that makes the distinction clearer.
> >>> Basically if your modelling something that is accessed through roles, you
> >>> create a resource. If you're modelling something that wants to login
> >>> users
> >>> you create a client. And as some clients would be "internal" they have
> >>> the
> >>> option of automatically being granted permissions.
> >>>
> >>
> >> I like that for an implementation detail at least.  Not sure about
> >> propagating that idea to the admin console though.
> >>
> >> Applications have always been special in that they don't require an
> >> oauth grant page, can be administered, you can log out of them, and
> >> eventually we'll have screens for session management and stuff and
> >> things like that for them.  For clustering, at least for Wildfly/JBoss,
> >> I don't even think it makes sense to have the idea of a "deployment" as
> >> I believe cluster nodes would get the same configuration from the domain
> >> controller (client_id, secret, etc.).  What we can do for a cluster is
> >> make Admin URl a Set<URI> maybe even the same with Redirect URI.
> >
> > Didn't think of all that. Needs some rethinking. I still think it would be
> > nice to have something to represent resources. For example the database
> > service from the example, and the realm-admin apps. It doesn't make sense
> > that they have credentials, redirect-uris and scopes. They will never
> > request a login, only parse bearer tokens.
> >
> 
> Currently, the database service doesn't need any registration in the
> admin console (and isn't registered in the admin console).  All it is
> doing is verifying tokens so all it needs is the public key of the
> realm.  In the future, the only reason to register it with the admin
> console is to provide an admin URL so the keycloak server can push
> revocation policies or get access stats.

Yes, but that's because it uses realm roles instead of roles associated with the database service. If you want to have roles specific to a service you need to create an app to represent it so you can setup role/scope mappings

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

From stian at redhat.com  Fri Feb 28 09:34:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 28 Feb 2014 09:34:45 -0500 (EST)
Subject: [keycloak-dev] formatting messed up a little
In-Reply-To: <5310986C.2060801@redhat.com>
References: <530EAF84.406@redhat.com> <1393522845.15208.9.camel@vrockai-laptop>
	<5310986C.2060801@redhat.com>
Message-ID: <1436462437.18572613.1393598085972.JavaMail.zimbra@redhat.com>

Like in the attached image?

It happens at certain screen resolutions as the login form is now adaptive depending on the width of the page. If you make it really narrow you'll notice it change quite a lot. It can certainly do with a bit more tweaking to optimize certain widths.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Viliam Rockai" <vrockai at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 28 February, 2014 2:08:44 PM
> Subject: Re: [keycloak-dev] formatting messed up a little
> 
> login to the admin console on firefox?  Login button is over the cancel
> button.
> 
> On 2/27/2014 12:40 PM, Viliam Rockai wrote:
> > On Wed, 2014-02-26 at 22:22 -0500, Bill Burke wrote:
> >> Formatting on the login and oauth screens is screwed up a little.
> >
> > What should I do/change in config to see it?
> >
> >> Buttons are on top of one another.
> >
> >
> 
> --
> 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 --------------
A non-text attachment was scrubbed...
Name: login.png
Type: image/png
Size: 18773 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140228/80720dbb/attachment-0001.png 

From bburke at redhat.com  Fri Feb 28 09:51:09 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Feb 2014 09:51:09 -0500
Subject: [keycloak-dev] formatting messed up a little
In-Reply-To: <1436462437.18572613.1393598085972.JavaMail.zimbra@redhat.com>
References: <530EAF84.406@redhat.com> <1393522845.15208.9.camel@vrockai-laptop>
	<5310986C.2060801@redhat.com>
	<1436462437.18572613.1393598085972.JavaMail.zimbra@redhat.com>
Message-ID: <5310A25D.6030809@redhat.com>

Its weird, it varies as I widen the browser page.  Sometimes the buttons 
are positioned correctly sometimes not.  Sometimes "username or" is 
positioned over "email" sometimes it isn't.  I can make this happen with 
as large as 1000 pixel width browser page.

On 2/28/2014 9:34 AM, Stian Thorgersen wrote:
> Like in the attached image?
>
> It happens at certain screen resolutions as the login form is now adaptive depending on the width of the page. If you make it really narrow you'll notice it change quite a lot. It can certainly do with a bit more tweaking to optimize certain widths.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Viliam Rockai" <vrockai at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 28 February, 2014 2:08:44 PM
>> Subject: Re: [keycloak-dev] formatting messed up a little
>>
>> login to the admin console on firefox?  Login button is over the cancel
>> button.
>>
>> On 2/27/2014 12:40 PM, Viliam Rockai wrote:
>>> On Wed, 2014-02-26 at 22:22 -0500, Bill Burke wrote:
>>>> Formatting on the login and oauth screens is screwed up a little.
>>>
>>> What should I do/change in config to see it?
>>>
>>>> Buttons are on top of one another.
>>>
>>>
>>
>> --
>> 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 Feb 28 10:16:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 28 Feb 2014 10:16:38 -0500 (EST)
Subject: [keycloak-dev] formatting messed up a little
In-Reply-To: <5310A25D.6030809@redhat.com>
References: <530EAF84.406@redhat.com> <1393522845.15208.9.camel@vrockai-laptop>
	<5310986C.2060801@redhat.com>
	<1436462437.18572613.1393598085972.JavaMail.zimbra@redhat.com>
	<5310A25D.6030809@redhat.com>
Message-ID: <1923517041.18629700.1393600598055.JavaMail.zimbra@redhat.com>

Oki, as I messed it up in the first place I'll look at it ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Viliam Rockai" <vrockai at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Friday, 28 February, 2014 2:51:09 PM
> Subject: Re: [keycloak-dev] formatting messed up a little
> 
> Its weird, it varies as I widen the browser page.  Sometimes the buttons
> are positioned correctly sometimes not.  Sometimes "username or" is
> positioned over "email" sometimes it isn't.  I can make this happen with
> as large as 1000 pixel width browser page.
> 
> On 2/28/2014 9:34 AM, Stian Thorgersen wrote:
> > Like in the attached image?
> >
> > It happens at certain screen resolutions as the login form is now adaptive
> > depending on the width of the page. If you make it really narrow you'll
> > notice it change quite a lot. It can certainly do with a bit more tweaking
> > to optimize certain widths.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Viliam Rockai" <vrockai at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 28 February, 2014 2:08:44 PM
> >> Subject: Re: [keycloak-dev] formatting messed up a little
> >>
> >> login to the admin console on firefox?  Login button is over the cancel
> >> button.
> >>
> >> On 2/27/2014 12:40 PM, Viliam Rockai wrote:
> >>> On Wed, 2014-02-26 at 22:22 -0500, Bill Burke wrote:
> >>>> Formatting on the login and oauth screens is screwed up a little.
> >>>
> >>> What should I do/change in config to see it?
> >>>
> >>>> Buttons are on top of one another.
> >>>
> >>>
> >>
> >> --
> >> 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  Fri Feb 28 11:40:16 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Fri, 28 Feb 2014 13:40:16 -0300
Subject: [keycloak-dev] formatting messed up a little
In-Reply-To: <1923517041.18629700.1393600598055.JavaMail.zimbra@redhat.com>
References: <530EAF84.406@redhat.com> <1393522845.15208.9.camel@vrockai-laptop>
	<5310986C.2060801@redhat.com>
	<1436462437.18572613.1393598085972.JavaMail.zimbra@redhat.com>
	<5310A25D.6030809@redhat.com>
	<1923517041.18629700.1393600598055.JavaMail.zimbra@redhat.com>
Message-ID: <29EB8F6B-DC9B-45DB-8A06-391D9A33D740@redhat.com>

Stian, let me know when you finish your changes. I?d like to see how the page behaves after that.

Also, why is ?New User? Register? together with the login form?

Thanks,
Gabriel

On Feb 28, 2014, at 12:16 PM, Stian Thorgersen <stian at redhat.com> wrote:

> Oki, as I messed it up in the first place I'll look at it ;)
> 
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Viliam Rockai" <vrockai at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Friday, 28 February, 2014 2:51:09 PM
>> Subject: Re: [keycloak-dev] formatting messed up a little
>> 
>> Its weird, it varies as I widen the browser page.  Sometimes the buttons
>> are positioned correctly sometimes not.  Sometimes "username or" is
>> positioned over "email" sometimes it isn't.  I can make this happen with
>> as large as 1000 pixel width browser page.
>> 
>> On 2/28/2014 9:34 AM, Stian Thorgersen wrote:
>>> Like in the attached image?
>>> 
>>> It happens at certain screen resolutions as the login form is now adaptive
>>> depending on the width of the page. If you make it really narrow you'll
>>> notice it change quite a lot. It can certainly do with a bit more tweaking
>>> to optimize certain widths.
>>> 
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Viliam Rockai" <vrockai at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 28 February, 2014 2:08:44 PM
>>>> Subject: Re: [keycloak-dev] formatting messed up a little
>>>> 
>>>> login to the admin console on firefox?  Login button is over the cancel
>>>> button.
>>>> 
>>>> On 2/27/2014 12:40 PM, Viliam Rockai wrote:
>>>>> On Wed, 2014-02-26 at 22:22 -0500, Bill Burke wrote:
>>>>>> Formatting on the login and oauth screens is screwed up a little.
>>>>> 
>>>>> What should I do/change in config to see it?
>>>>> 
>>>>>> Buttons are on top of one another.
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> 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

---
Gabriel Cardoso
User Experience Designer @ Red Hat

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

From cvasilak at gmail.com  Fri Feb 28 11:58:44 2014
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Fri, 28 Feb 2014 18:58:44 +0200
Subject: [keycloak-dev] iOS Keycloak demo
Message-ID: <D80D9939-29F7-42BD-8C82-CC59901AC203@gmail.com>

Hi everyone,

worked out a simple application that utilises AeroGear iOS OAuth2 adapter to go against a Keycloak server. You can find the source code here[1] and a small video demonstration here[2]. 

Overall it worked great but needed to make some small adjustments on the library which I would like your feedback. Two issues that raised are in the request parameters:

- the ?scope? parameter on the request needed to be in a specific format "realm": [ ?user?, .. ]. Needed to include ?realm? and a list of separated names. Not sure if this is the same as the ?scope? parameter in OAuth2 where just a space delimited strings are required. Further,  the scope needed to be base64 url encoded in order for the server to parse it.
- the ?client_secret? parameter needed to be encoded as ?secret?.

Note that this was my first experience with keycloak and possible I am missing some details, but would be really happy to hear your thoughts and suggestions.

As a final note, I really like the ?Installation? JSON copy paste on the examples and have the client lib work out the details. I think on the iOS side we can offer similar experience where the user installs the *.json and have the library pick up the configuration details. Something to look at.

Keep up the good work!

Thanks
Christos

[1] https://github.com/cvasilak/KeycloakDemo
[2] https://vimeo.com/87862111



From bburke at redhat.com  Fri Feb 28 12:26:37 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Feb 2014 12:26:37 -0500
Subject: [keycloak-dev] iOS Keycloak demo
In-Reply-To: <D80D9939-29F7-42BD-8C82-CC59901AC203@gmail.com>
References: <D80D9939-29F7-42BD-8C82-CC59901AC203@gmail.com>
Message-ID: <5310C6CD.7040008@redhat.com>



On 2/28/2014 11:58 AM, Christos Vasilakis wrote:
> Hi everyone,
>
> worked out a simple application that utilises AeroGear iOS OAuth2 adapter to go against a Keycloak server. You can find the source code here[1] and a small video demonstration here[2].
>

Great work!

> Overall it worked great but needed to make some small adjustments on the library which I would like your feedback. Two issues that raised are in the request parameters:
>
> - the ?scope? parameter on the request needed to be in a specific format "realm": [ ?user?, .. ]. Needed to include ?realm? and a list of separated names. Not sure if this is the same as the ?scope? parameter in OAuth2 where just a space delimited strings are required. Further,  the scope needed to be base64 url encoded in order for the server to parse it.

Scope parameter is optional.  We also need to get rid of what we have 
anyways as its incompatible with OpenID Connect.

> - the ?client_secret? parameter needed to be encoded as ?secret?.
>

We changed client auth to Basic Auth to match Oauth Spec.



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

From bburke at redhat.com  Fri Feb 28 15:24:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Feb 2014 15:24:51 -0500
Subject: [keycloak-dev] ng-disabled no longer works
Message-ID: <5310F093.8020802@redhat.com>

Can you think of any reason ng-disabled no longer works?  i.e. on 
application-credentials.html page?

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