From bburke at redhat.com  Mon Dec  1 09:45:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 01 Dec 2014 09:45:57 -0500
Subject: [keycloak-dev] Intermittent failures in ProxyTest
In-Reply-To: <193038929.6358957.1417078138742.JavaMail.zimbra@redhat.com>
References: <854422299.6358837.1417078112607.JavaMail.zimbra@redhat.com>
	<193038929.6358957.1417078138742.JavaMail.zimbra@redhat.com>
Message-ID: <547C7F25.1040101@redhat.com>

I'm hoping upgrading to Undertow 1.1.1 will fix it.  I couldn't upgrade 
to 1.1.0 because of a bug in Undertow.

On 11/27/2014 3:48 AM, Stian Thorgersen wrote:
> Sent to early, here's the test output:
>
>
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.499 sec <<< FAILURE! - in org.keycloak.testsuite.ProxyTest
> testHttp(org.keycloak.testsuite.ProxyTest)  Time elapsed: 0.108 sec  <<< FAILURE!
> java.lang.AssertionError: null
> 	at org.junit.Assert.fail(Assert.java:86)
> 	at org.junit.Assert.assertTrue(Assert.java:41)
> 	at org.junit.Assert.assertTrue(Assert.java:52)
> 	at org.keycloak.testsuite.ProxyTest.testit(ProxyTest.java:223)
> 	at org.keycloak.testsuite.ProxyTest.testHttp(ProxyTest.java:194)
>
>
> Results :
>
> Failed tests:
>    ProxyTest.testHttp:194->testit:223 null
>
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 27 November, 2014 9:48:32 AM
>> Subject: Intermittent failures in ProxyTest
>>
>> I'm getting intermittent failures in ProxyTest.
>>
> _______________________________________________
> 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 Dec  1 09:53:54 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 01 Dec 2014 15:53:54 +0100
Subject: [keycloak-dev] Osgi bundling for Karaf/Fuse
Message-ID: <547C8102.4070001@redhat.com>

I've added Osgi bundle for Karaf/Fuse into Keycloak distribution. For 
now there is bundle with core adapter libraries and bundle with JAAS 
used for authentication to admin services like hawtio, SSH and JMX over 
RMI. Previously I had the bundling in my hawtio fork, but I think that 
it would be better to have it in keycloak codebase itself because of 
better reusability by other osgi services and components of fuse.

Next step would be to add bundle for Jetty adapter to secure Apache CXF 
and Camel applications.

I've added wiki with some notes 
https://github.com/keycloak/keycloak/wiki/Fuse-integration with what is 
done and what is still on todo list for Fuse integration. Feel free to 
add more things if I missed something. I think that admin services 
(hawtio, SSH, JMX) should be quite done now.

Marek

From mposolda at redhat.com  Mon Dec  1 09:59:11 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 01 Dec 2014 15:59:11 +0100
Subject: [keycloak-dev] Status Report - Week 48 2014
Message-ID: <547C823F.3010908@redhat.com>

Accomplishments and key updates:
- Keycloak and hawtio integration working and shared with hawtio team 
https://github.com/hawtio/hawtio/issues/1779
- SSH and JMX authentication to Fuse with keycloak credentials

Next steps:
- Prepare for local JBug about Keycloak on WEdnesday
- Research for f2f
- Continue with keycloak & JBoss Fuse. Next step will be likely Jetty 
adapter for securing CXF and Camel applications.

Marek

From mposolda at redhat.com  Mon Dec  1 10:03:12 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 01 Dec 2014 16:03:12 +0100
Subject: [keycloak-dev] Status Report - Week 48 2014
In-Reply-To: <547C823F.3010908@redhat.com>
References: <547C823F.3010908@redhat.com>
Message-ID: <547C8330.9050205@redhat.com>

Wrong ML. I am sorry for the spam

On 1.12.2014 15:59, Marek Posolda wrote:
> Accomplishments and key updates:
> - Keycloak and hawtio integration working and shared with hawtio team
> https://github.com/hawtio/hawtio/issues/1779
> - SSH and JMX authentication to Fuse with keycloak credentials
>
> Next steps:
> - Prepare for local JBug about Keycloak on WEdnesday
> - Research for f2f
> - Continue with keycloak & JBoss Fuse. Next step will be likely Jetty
> adapter for securing CXF and Camel applications.
>
> 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 Dec  1 10:07:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 01 Dec 2014 10:07:07 -0500
Subject: [keycloak-dev] passport node.js feedhenry
Message-ID: <547C841B.7090705@redhat.com>

Anybody looking into this?  If not, I'll take a look this week.  Looks 
like it might be a short task that I could do prior to our F2F.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon Dec  1 10:08:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 01 Dec 2014 10:08:22 -0500
Subject: [keycloak-dev] release?  Stan?
Message-ID: <547C8466.4050103@redhat.com>

So, is EAP subsystem complete?  Documented?  Can we do a Beta2 release 
this week?


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

From ssilvert at redhat.com  Mon Dec  1 10:53:47 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 01 Dec 2014 10:53:47 -0500
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547C8466.4050103@redhat.com>
References: <547C8466.4050103@redhat.com>
Message-ID: <547C8F0B.4060904@redhat.com>

On 12/1/2014 10:08 AM, Bill Burke wrote:
> So, is EAP subsystem complete?  Documented?  Can we do a Beta2 release
> this week?
>
>
Yes.  All merged.  Docs are updated.  Should be ready to go.

From bruno at abstractj.org  Mon Dec  1 13:18:43 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 1 Dec 2014 16:18:43 -0200
Subject: [keycloak-dev] passport node.js feedhenry
In-Reply-To: <547C841B.7090705@redhat.com>
References: <547C841B.7090705@redhat.com>
Message-ID: <20141201181843.GA65250@abstractj.org>

Hi Bill, we discussed it during our meeting today on AeroGear
(http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-01-15.00.html).

We're planning to provide adapters for KC this week, but if it's quicker for you,
that's ok.

On 2014-12-01, Bill Burke wrote:
> Anybody looking into this?  If not, I'll take a look this week.  Looks
> like it might be a short task that I could do prior to our F2F.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Mon Dec  1 13:53:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 01 Dec 2014 13:53:47 -0500
Subject: [keycloak-dev] passport node.js feedhenry
In-Reply-To: <20141201181843.GA65250@abstractj.org>
References: <547C841B.7090705@redhat.com>
	<20141201181843.GA65250@abstractj.org>
Message-ID: <547CB93B.5050404@redhat.com>

If you want to do it, fine wiht me :)

On 12/1/2014 1:18 PM, Bruno Oliveira wrote:
> Hi Bill, we discussed it during our meeting today on AeroGear
> (http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-01-15.00.html).
>
> We're planning to provide adapters for KC this week, but if it's quicker for you,
> that's ok.
>
> On 2014-12-01, Bill Burke wrote:
>> Anybody looking into this?  If not, I'll take a look this week.  Looks
>> like it might be a short task that I could do prior to our F2F.
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
>
> abstractj
> PGP: 0x84DC9914
>

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

From bruno at abstractj.org  Mon Dec  1 14:05:15 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 1 Dec 2014 17:05:15 -0200
Subject: [keycloak-dev] passport node.js feedhenry
In-Reply-To: <547CB93B.5050404@redhat.com>
References: <547C841B.7090705@redhat.com>
	<20141201181843.GA65250@abstractj.org>
	<547CB93B.5050404@redhat.com>
Message-ID: <CAM5SUC7AMw-mKsgT-iwOsEPEX2yyOv_JJpBqEFUbZkLvJVyamQ@mail.gmail.com>

I created the following Jira for tracking the issue
https://issues.jboss.org/browse/KEYCLOAK-864. Only double checking, I think
for Node.js adapters authorization grant type is the best fit, right?

On Mon, Dec 1, 2014 at 4:53 PM, Bill Burke <bburke at redhat.com> wrote:

> If you want to do it, fine wiht me :)
>
>
> On 12/1/2014 1:18 PM, Bruno Oliveira wrote:
>
>> Hi Bill, we discussed it during our meeting today on AeroGear
>> (http://transcripts.jboss.org/meeting/irc.freenode.org/
>> aerogear/2014/aerogear.2014-12-01-15.00.html).
>>
>> We're planning to provide adapters for KC this week, but if it's quicker
>> for you,
>> that's ok.
>>
>> On 2014-12-01, Bill Burke wrote:
>>
>>> Anybody looking into this?  If not, I'll take a look this week.  Looks
>>> like it might be a short task that I could do prior to our F2F.
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>>
>>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>



-- 

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141201/57644b00/attachment.html 

From bburke at redhat.com  Mon Dec  1 15:39:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 01 Dec 2014 15:39:27 -0500
Subject: [keycloak-dev] passport node.js feedhenry
In-Reply-To: <CAM5SUC7AMw-mKsgT-iwOsEPEX2yyOv_JJpBqEFUbZkLvJVyamQ@mail.gmail.com>
References: <547C841B.7090705@redhat.com>
	<20141201181843.GA65250@abstractj.org>
	<547CB93B.5050404@redhat.com>
	<CAM5SUC7AMw-mKsgT-iwOsEPEX2yyOv_JJpBqEFUbZkLvJVyamQ@mail.gmail.com>
Message-ID: <547CD1FF.4000809@redhat.com>

Not sure what you mean.  Auth-code-grant and bearer auth should be for 
Node.js server.  Same as servlet containers.  I was hoping for a plugin 
to Passport [1].  A lot could be borrowed from keycloak.js browser 
javascript adapter.

[1] http://passportjs.org/

On 12/1/2014 2:05 PM, Bruno Oliveira wrote:
> I created the following Jira for tracking the issue
> https://issues.jboss.org/browse/KEYCLOAK-864. Only double checking, I
> think for Node.js adapters authorization grant type is the best fit, right?
>
> On Mon, Dec 1, 2014 at 4:53 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     If you want to do it, fine wiht me :)
>
>
>     On 12/1/2014 1:18 PM, Bruno Oliveira wrote:
>
>         Hi Bill, we discussed it during our meeting today on AeroGear
>         (http://transcripts.jboss.org/__meeting/irc.freenode.org/__aerogear/2014/aerogear.2014-__12-01-15.00.html
>         <http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-12-01-15.00.html>).
>
>         We're planning to provide adapters for KC this week, but if it's
>         quicker for you,
>         that's ok.
>
>         On 2014-12-01, Bill Burke wrote:
>
>             Anybody looking into this?  If not, I'll take a look this
>             week.  Looks
>             like it might be a short task that I could do prior to our F2F.
>             --
>             Bill Burke
>             JBoss, a division of Red Hat
>             http://bill.burkecentral.com
>             _________________________________________________
>             keycloak-dev mailing list
>             keycloak-dev at lists.jboss.org
>             <mailto:keycloak-dev at lists.jboss.org>
>             https://lists.jboss.org/__mailman/listinfo/keycloak-dev
>             <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>         --
>
>         abstractj
>         PGP: 0x84DC9914
>
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>
>
>
> --
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile

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

From bruno at abstractj.org  Mon Dec  1 19:44:52 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 1 Dec 2014 22:44:52 -0200
Subject: [keycloak-dev] passport node.js feedhenry
In-Reply-To: <547CD1FF.4000809@redhat.com>
References: <547C841B.7090705@redhat.com>
	<20141201181843.GA65250@abstractj.org>
	<547CB93B.5050404@redhat.com>
	<CAM5SUC7AMw-mKsgT-iwOsEPEX2yyOv_JJpBqEFUbZkLvJVyamQ@mail.gmail.com>
	<547CD1FF.4000809@redhat.com>
Message-ID: <CAM5SUC5MNbJtbad6OiZHB0UDH-HMwv4JoFy3SVPoJ2HpnzvA0A@mail.gmail.com>

That's what I meant, thanks Bill.

On Mon, Dec 1, 2014 at 6:39 PM, Bill Burke <bburke at redhat.com> wrote:

> Not sure what you mean.  Auth-code-grant and bearer auth should be for
> Node.js server.  Same as servlet containers.  I was hoping for a plugin to
> Passport [1].  A lot could be borrowed from keycloak.js browser javascript
> adapter.
>
> [1] http://passportjs.org/
>
> On 12/1/2014 2:05 PM, Bruno Oliveira wrote:
>
>> I created the following Jira for tracking the issue
>> https://issues.jboss.org/browse/KEYCLOAK-864. Only double checking, I
>> think for Node.js adapters authorization grant type is the best fit,
>> right?
>>
>> On Mon, Dec 1, 2014 at 4:53 PM, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>>     If you want to do it, fine wiht me :)
>>
>>
>>     On 12/1/2014 1:18 PM, Bruno Oliveira wrote:
>>
>>         Hi Bill, we discussed it during our meeting today on AeroGear
>>         (http://transcripts.jboss.org/__meeting/irc.freenode.org/__
>> aerogear/2014/aerogear.2014-__12-01-15.00.html
>>         <http://transcripts.jboss.org/meeting/irc.freenode.org/
>> aerogear/2014/aerogear.2014-12-01-15.00.html>).
>>
>>         We're planning to provide adapters for KC this week, but if it's
>>         quicker for you,
>>         that's ok.
>>
>>         On 2014-12-01, Bill Burke wrote:
>>
>>             Anybody looking into this?  If not, I'll take a look this
>>             week.  Looks
>>             like it might be a short task that I could do prior to our
>> F2F.
>>             --
>>             Bill Burke
>>             JBoss, a division of Red Hat
>>             http://bill.burkecentral.com
>>             _________________________________________________
>>             keycloak-dev mailing list
>>             keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             https://lists.jboss.org/__mailman/listinfo/keycloak-dev
>>             <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>>         --
>>
>>         abstractj
>>         PGP: 0x84DC9914
>>
>>
>>     --
>>     Bill Burke
>>     JBoss, a division of Red Hat
>>     http://bill.burkecentral.com
>>
>>
>>
>>
>> --
>>
>> --
>> "The measure of a man is what he does with power" - Plato
>> -
>> @abstractj
>> -
>> Volenti Nihil Difficile
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>



-- 

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141201/4fea4a12/attachment-0001.html 

From stian at redhat.com  Tue Dec  2 04:52:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 04:52:12 -0500 (EST)
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547C8F0B.4060904@redhat.com>
References: <547C8466.4050103@redhat.com> <547C8F0B.4060904@redhat.com>
Message-ID: <1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>

Should we upgrade to WF 8.2 and also do some changes to the distro before release?

With regards to distro we should move the adapters and examples into separate downloads. Also, we should move the examples into a separate github project (keycloak/keycloak-examples). This will make it easier for those that wants to fork the examples separately. 

Also, we should consider a download based on the web-lite profile. For non-JavaEE apps, containers (Docker) and those that want to run a standalone KC server it would be nice to have a small as possible distro.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 1 December, 2014 4:53:47 PM
> Subject: Re: [keycloak-dev] release?  Stan?
> 
> On 12/1/2014 10:08 AM, Bill Burke wrote:
> > So, is EAP subsystem complete?  Documented?  Can we do a Beta2 release
> > this week?
> >
> >
> Yes.  All merged.  Docs are updated.  Should be ready to go.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From psilva at redhat.com  Tue Dec  2 06:22:21 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 2 Dec 2014 06:22:21 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1709556791.20804905.1417129298254.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<546CE3F8.7020007@redhat.com>
	<1127040296.16584360.1416425278565.JavaMail.zimbra@redhat.com>
	<1332181380.2499178.1416473745773.JavaMail.zimbra@redhat.com>
	<546E1978.7000902@redhat.com> <546E1B71.8000807@redhat.com>
	<1709556791.20804905.1417129298254.JavaMail.zimbra@redhat.com>
Message-ID: <1648216531.22628862.1417519341632.JavaMail.zimbra@redhat.com>

Hi,

    Anyone know where I can get the icons images for social providers ? It seems zocial defines them encoded in some way in CSS. I need that to provide default images if user does not specify their own.

    Or is still possible to use zocial ones ?

Regards.

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Thursday, November 27, 2014 9:01:38 PM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker

Hi guys,

   I've done some initial work covering both persistence and brokering. No UI, yet. I'm focused on the model, rest api and brokering functionality for now.

   What I have is enough to decide if we are aligned about this functionality. So you can understand how the model (and persistence), rest api and brokering functionality looks like. Can we schedule a meeting ?

   Btw, my branch is here [1].

[1] https://github.com/pedroigor/keycloak/tree/authentication-broker2

Regards.
Pedro Igor

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Thursday, November 20, 2014 2:48:49 PM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker

Currently adapters can only make authz decisions (@RolesAllowed) based 
on either realm roles or the roles of one specific application.  This is 
related to 1) too.

On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> 1) Sounds like something definitely worth aiming for.
>
> On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
>> I just wanted to quickly list the additional work we discussed so everyone can think about it (in no particular order):
>>
>> 1) Mapping of tokens - how do we deal with mapping of an external token to a KC token? For example an external token with attribute 'group' that contains 'sales' and 'manager' could be mapped to 'manager' role for 'sales app in a KC token. Could we use Drools? This could also be used in user federation to allow more complex mapping of roles/groups than a simple 1-1
>> 2) Retrieving tokens - if an application wants to retrieve the external token (for example to view Facebook friends if user logged in with Facebook)
>> 3) Configure scope - currently for social we only request a very limited scope (basic profile and email), to for example view Facebook friends we'd need to ask for that as well
>> 4) Selecting provider - currently in social (and for first pass of brokering) we have an icon user has to select, but can we select the provider in a different way (for example ask user for email, and select based on email domain)
>> 5) Gateway - don't create a KC token, but just forward the external token
>>
>> IMO 1) is a killer feature, as it would allow companies to add external users without having to modify their applications. Issue with 5) is that applications need to understand more than one token, which would require rewriting applications.
>>
>> This work is also somewhat related to other authentication mechanisms (for example Kerberos ticket, LDAP and passwordless).
>>
>> ----- Original Message -----
>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>> To: "Bill Burke" <bburke at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>>
>>>>
>>>>
>>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
>>>>> Hi,
>>>>>
>>>>>        Would like to start a discussion about how to enable KC as an
>>>>>        Authentication Broker in order to supported Chained Federation and
>>>>>        also Identity Federation. First of all, some background about what
>>>>>        this is all about.
>>>>>
>>>>>        Currently KeyCloak provides two basic types of authentication
>>>>>        (correct
>>>>>        me if I'm wrong, please):
>>>>>
>>>>>            1) Local authentication (based on some credential type enabled
>>>>>            to
>>>>>            a realm)
>>>>>            2) Social authentication
>>>>>
>>>>>        Local authentication is about authenticating the user locally using
>>>>>        KC's own identity store. Nothing special here. And Social
>>>>>        Authentication which allows users to choose the Social IdP they want
>>>>>        to authenticate with. In this case, the IdP is always one of the
>>>>>        built-in social providers supported by KC such as Facebook, Google,
>>>>>        Twitter, Github and so forth.
>>>>>
>>>>>        When doing social, the user is automatically provisioned in KC
>>>>>        identity store after a successful authentication. The user does not
>>>>>        need to fill a registration form and can access the application very
>>>>>        quickly. During the provisioning some basic information is retrieved
>>>>>        from the social provider such as email, firstname and so forth.
>>>>>        These
>>>>>        are very basic information, any other information such as those
>>>>>        related with authorization policies - eg.: roles and groups - must
>>>>>        be
>>>>>        defined later via KC's admin console.
>>>>>
>>>>>        Another important characteristic of social authentication is that
>>>>>        the
>>>>>        application receives a KC token and not the token that was issued by
>>>>>        the social IdP during the authentication process. If the application
>>>>>        wants to consume resources from the resource provider he was
>>>>>        authenticated it must obtain the access token(again) by itself prior
>>>>>        to invoke the resource provider API. Assuming all those social
>>>>>        providers are based on oAuth 1.0 or 2.0.
>>>>>
>>>>>        That said, the Authentication Broker functionality aims to cover the
>>>>>        same use cases but with a lot of more flexibility on how you setup
>>>>>        identity providers(not only social ones) and the different
>>>>>        federation
>>>>>        protocols they may support such as SAML, OpenID, oAuth and so forth.
>>>>>        This is useful when an enterprise is providing services to different
>>>>>        customers(IdP) and does not want to manage many to many
>>>>>        relationships. When using a broker, the authentication steps are
>>>>>        pretty much the same when you are using social authentication, with
>>>>>        important differences on how you support different identity
>>>>>        providers, different federation protocols, how users are provisioned
>>>>>        and how claims and attributes are resolved.
>>>>>
>>>>>        The brokering functionality can be done in two ways depending if the
>>>>>        broker service is acting as a gateway or not. When acting as a
>>>>>        gateway, the broker will respond to the application the same token
>>>>>        issued by the trusted identity provider. For instance, if the user
>>>>>        selects a SAML IdP to authenticate with, the application will
>>>>>        receive
>>>>>        a SAML Response. In this case, the application must also be prepared
>>>>>        to handle a specific federation protocol.
>>>>>
>>>>>        However, the broker service can also be used to completely abstract
>>>>>        from the application the protocol used to authenticate an user. In
>>>>>        this case, the application will just receive an ordinary KC token
>>>>>        after a successful authentication.
>>>>>
>>>>>        In both cases, the broker acts as an intermediary where specific
>>>>>        security policies can be applied when users try to authenticate
>>>>>        themselves against a 3rd party IdP. That brings a lot of value when
>>>>>        you think about auditing, authorization and how users are
>>>>>        provisioned
>>>>>        when federation of identities is needed. This also allows existing
>>>>>        security infrastructures (eg.: SAML-based infrastructures) to
>>>>>        benefit
>>>>>        from KC's support for cloud, rest and mobile use cases.
>>>>>
>>>>>        I think this is enough to start a discussion. I've an initial
>>>>>        discussion with Stian about all that and we agreed that abstract the
>>>>>        protocol from applications should be prioritized. The main reason is
>>>>>        that it makes life easier for applications so they only need to know
>>>>>        about KC tokens and nothing else. However that brings some new
>>>>>        requirements around user provisioning and claim/attribute resolution
>>>>>        or mapping. But that would be another thread.
>>>>>
>>>>
>>>> Can you elaborate on "abstract the protocol from applications"?  Not
>>>> sure what you mean by that.  IDP federation should be configured at the
>>>> realm level and really has nothing to do with applications.
>>>>
>>>> I'm really happy that somebody is doing this.  We're getting a real
>>>> impressive feature set!
>>>
>>> Sure. What I meant was that the application only knows about KC tokens
>>> nothing else. It will always receive a KC token regardless the protocol used
>>> to authenticate the user against a 3rd party IdP (saml, oidc, whatever). The
>>> example I gave was about an user trying to authenticate against a SAML IdP.
>>> In this case, after a successful authentication on the IdP, the IdP will
>>> issue a token to KC. Then KC will validate the token, perform trust and
>>> security checks, do user provisioning and attribute/claim resolution to
>>> finally issue a KC token and redirect the user to the application. If the
>>> app is configured to use openid in KC then it will receive a openid token
>>> from KC, not saml ...
>>>
>>> The other scenario is pretty much the same. The difference is that KC will
>>> not issue its own token but just replay the token issued by the 3rd party
>>> IdP to the service provider.
>>>
>>> I agree that this config goes at the realm level. For instance, to create and
>>> enable providers for being used. However, I think we would need some
>>> specific configuration for applications as well. Specially when defining
>>> default roles, mapping attributes. Another example of application config is
>>> when using a OIDC/oAuth IdP. You may want to define scopes per-application.
>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> 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

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Tue Dec  2 06:34:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 06:34:45 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1648216531.22628862.1417519341632.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<546CE3F8.7020007@redhat.com>
	<1127040296.16584360.1416425278565.JavaMail.zimbra@redhat.com>
	<1332181380.2499178.1416473745773.JavaMail.zimbra@redhat.com>
	<546E1978.7000902@redhat.com> <546E1B71.8000807@redhat.com>
	<1709556791.20804905.1417129298254.JavaMail.zimbra@redhat.com>
	<1648216531.22628862.1417519341632.JavaMail.zimbra@redhat.com>
Message-ID: <732604538.8590377.1417520085671.JavaMail.zimbra@redhat.com>

You shouldn't have icon images for social providers. They should be specified as part of the theme in CSS as is now.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 12:22:21 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Hi,
> 
>     Anyone know where I can get the icons images for social providers ? It
>     seems zocial defines them encoded in some way in CSS. I need that to
>     provide default images if user does not specify their own.
> 
>     Or is still possible to use zocial ones ?
> 
> Regards.
> 
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, November 27, 2014 9:01:38 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Hi guys,
> 
>    I've done some initial work covering both persistence and brokering. No
>    UI, yet. I'm focused on the model, rest api and brokering functionality
>    for now.
> 
>    What I have is enough to decide if we are aligned about this
>    functionality. So you can understand how the model (and persistence),
>    rest api and brokering functionality looks like. Can we schedule a
>    meeting ?
> 
>    Btw, my branch is here [1].
> 
> [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2
> 
> Regards.
> Pedro Igor
> 
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, November 20, 2014 2:48:49 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Currently adapters can only make authz decisions (@RolesAllowed) based
> on either realm roles or the roles of one specific application.  This is
> related to 1) too.
> 
> On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > 1) Sounds like something definitely worth aiming for.
> >
> > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> >> I just wanted to quickly list the additional work we discussed so everyone
> >> can think about it (in no particular order):
> >>
> >> 1) Mapping of tokens - how do we deal with mapping of an external token to
> >> a KC token? For example an external token with attribute 'group' that
> >> contains 'sales' and 'manager' could be mapped to 'manager' role for
> >> 'sales app in a KC token. Could we use Drools? This could also be used in
> >> user federation to allow more complex mapping of roles/groups than a
> >> simple 1-1
> >> 2) Retrieving tokens - if an application wants to retrieve the external
> >> token (for example to view Facebook friends if user logged in with
> >> Facebook)
> >> 3) Configure scope - currently for social we only request a very limited
> >> scope (basic profile and email), to for example view Facebook friends
> >> we'd need to ask for that as well
> >> 4) Selecting provider - currently in social (and for first pass of
> >> brokering) we have an icon user has to select, but can we select the
> >> provider in a different way (for example ask user for email, and select
> >> based on email domain)
> >> 5) Gateway - don't create a KC token, but just forward the external token
> >>
> >> IMO 1) is a killer feature, as it would allow companies to add external
> >> users without having to modify their applications. Issue with 5) is that
> >> applications need to understand more than one token, which would require
> >> rewriting applications.
> >>
> >> This work is also somewhat related to other authentication mechanisms (for
> >> example Kerberos ticket, LDAP and passwordless).
> >>
> >> ----- Original Message -----
> >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>> To: "Bill Burke" <bburke at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>>>
> >>>>
> >>>>
> >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> >>>>> Hi,
> >>>>>
> >>>>>        Would like to start a discussion about how to enable KC as an
> >>>>>        Authentication Broker in order to supported Chained Federation
> >>>>>        and
> >>>>>        also Identity Federation. First of all, some background about
> >>>>>        what
> >>>>>        this is all about.
> >>>>>
> >>>>>        Currently KeyCloak provides two basic types of authentication
> >>>>>        (correct
> >>>>>        me if I'm wrong, please):
> >>>>>
> >>>>>            1) Local authentication (based on some credential type
> >>>>>            enabled
> >>>>>            to
> >>>>>            a realm)
> >>>>>            2) Social authentication
> >>>>>
> >>>>>        Local authentication is about authenticating the user locally
> >>>>>        using
> >>>>>        KC's own identity store. Nothing special here. And Social
> >>>>>        Authentication which allows users to choose the Social IdP they
> >>>>>        want
> >>>>>        to authenticate with. In this case, the IdP is always one of the
> >>>>>        built-in social providers supported by KC such as Facebook,
> >>>>>        Google,
> >>>>>        Twitter, Github and so forth.
> >>>>>
> >>>>>        When doing social, the user is automatically provisioned in KC
> >>>>>        identity store after a successful authentication. The user does
> >>>>>        not
> >>>>>        need to fill a registration form and can access the application
> >>>>>        very
> >>>>>        quickly. During the provisioning some basic information is
> >>>>>        retrieved
> >>>>>        from the social provider such as email, firstname and so forth.
> >>>>>        These
> >>>>>        are very basic information, any other information such as those
> >>>>>        related with authorization policies - eg.: roles and groups -
> >>>>>        must
> >>>>>        be
> >>>>>        defined later via KC's admin console.
> >>>>>
> >>>>>        Another important characteristic of social authentication is
> >>>>>        that
> >>>>>        the
> >>>>>        application receives a KC token and not the token that was
> >>>>>        issued by
> >>>>>        the social IdP during the authentication process. If the
> >>>>>        application
> >>>>>        wants to consume resources from the resource provider he was
> >>>>>        authenticated it must obtain the access token(again) by itself
> >>>>>        prior
> >>>>>        to invoke the resource provider API. Assuming all those social
> >>>>>        providers are based on oAuth 1.0 or 2.0.
> >>>>>
> >>>>>        That said, the Authentication Broker functionality aims to cover
> >>>>>        the
> >>>>>        same use cases but with a lot of more flexibility on how you
> >>>>>        setup
> >>>>>        identity providers(not only social ones) and the different
> >>>>>        federation
> >>>>>        protocols they may support such as SAML, OpenID, oAuth and so
> >>>>>        forth.
> >>>>>        This is useful when an enterprise is providing services to
> >>>>>        different
> >>>>>        customers(IdP) and does not want to manage many to many
> >>>>>        relationships. When using a broker, the authentication steps are
> >>>>>        pretty much the same when you are using social authentication,
> >>>>>        with
> >>>>>        important differences on how you support different identity
> >>>>>        providers, different federation protocols, how users are
> >>>>>        provisioned
> >>>>>        and how claims and attributes are resolved.
> >>>>>
> >>>>>        The brokering functionality can be done in two ways depending if
> >>>>>        the
> >>>>>        broker service is acting as a gateway or not. When acting as a
> >>>>>        gateway, the broker will respond to the application the same
> >>>>>        token
> >>>>>        issued by the trusted identity provider. For instance, if the
> >>>>>        user
> >>>>>        selects a SAML IdP to authenticate with, the application will
> >>>>>        receive
> >>>>>        a SAML Response. In this case, the application must also be
> >>>>>        prepared
> >>>>>        to handle a specific federation protocol.
> >>>>>
> >>>>>        However, the broker service can also be used to completely
> >>>>>        abstract
> >>>>>        from the application the protocol used to authenticate an user.
> >>>>>        In
> >>>>>        this case, the application will just receive an ordinary KC
> >>>>>        token
> >>>>>        after a successful authentication.
> >>>>>
> >>>>>        In both cases, the broker acts as an intermediary where specific
> >>>>>        security policies can be applied when users try to authenticate
> >>>>>        themselves against a 3rd party IdP. That brings a lot of value
> >>>>>        when
> >>>>>        you think about auditing, authorization and how users are
> >>>>>        provisioned
> >>>>>        when federation of identities is needed. This also allows
> >>>>>        existing
> >>>>>        security infrastructures (eg.: SAML-based infrastructures) to
> >>>>>        benefit
> >>>>>        from KC's support for cloud, rest and mobile use cases.
> >>>>>
> >>>>>        I think this is enough to start a discussion. I've an initial
> >>>>>        discussion with Stian about all that and we agreed that abstract
> >>>>>        the
> >>>>>        protocol from applications should be prioritized. The main
> >>>>>        reason is
> >>>>>        that it makes life easier for applications so they only need to
> >>>>>        know
> >>>>>        about KC tokens and nothing else. However that brings some new
> >>>>>        requirements around user provisioning and claim/attribute
> >>>>>        resolution
> >>>>>        or mapping. But that would be another thread.
> >>>>>
> >>>>
> >>>> Can you elaborate on "abstract the protocol from applications"?  Not
> >>>> sure what you mean by that.  IDP federation should be configured at the
> >>>> realm level and really has nothing to do with applications.
> >>>>
> >>>> I'm really happy that somebody is doing this.  We're getting a real
> >>>> impressive feature set!
> >>>
> >>> Sure. What I meant was that the application only knows about KC tokens
> >>> nothing else. It will always receive a KC token regardless the protocol
> >>> used
> >>> to authenticate the user against a 3rd party IdP (saml, oidc, whatever).
> >>> The
> >>> example I gave was about an user trying to authenticate against a SAML
> >>> IdP.
> >>> In this case, after a successful authentication on the IdP, the IdP will
> >>> issue a token to KC. Then KC will validate the token, perform trust and
> >>> security checks, do user provisioning and attribute/claim resolution to
> >>> finally issue a KC token and redirect the user to the application. If the
> >>> app is configured to use openid in KC then it will receive a openid token
> >>> from KC, not saml ...
> >>>
> >>> The other scenario is pretty much the same. The difference is that KC
> >>> will
> >>> not issue its own token but just replay the token issued by the 3rd party
> >>> IdP to the service provider.
> >>>
> >>> I agree that this config goes at the realm level. For instance, to create
> >>> and
> >>> enable providers for being used. However, I think we would need some
> >>> specific configuration for applications as well. Specially when defining
> >>> default roles, mapping attributes. Another example of application config
> >>> is
> >>> when using a OIDC/oAuth IdP. You may want to define scopes
> >>> per-application.
> >>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>> _______________________________________________
> >>> 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
> 
> _______________________________________________
> 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 Dec  2 06:42:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 06:42:15 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <732604538.8590377.1417520085671.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1127040296.16584360.1416425278565.JavaMail.zimbra@redhat.com>
	<1332181380.2499178.1416473745773.JavaMail.zimbra@redhat.com>
	<546E1978.7000902@redhat.com> <546E1B71.8000807@redhat.com>
	<1709556791.20804905.1417129298254.JavaMail.zimbra@redhat.com>
	<1648216531.22628862.1417519341632.JavaMail.zimbra@redhat.com>
	<732604538.8590377.1417520085671.JavaMail.zimbra@redhat.com>
Message-ID: <917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>

All look and feel related things including images and stylesheets should be part of themes. This is to allow customizing them in the theme. Also, an image is not the correct way to render a button, it should be defined in CSS.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 12:34:45 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> You shouldn't have icon images for social providers. They should be specified
> as part of the theme in CSS as is now.
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Hi,
> > 
> >     Anyone know where I can get the icons images for social providers ? It
> >     seems zocial defines them encoded in some way in CSS. I need that to
> >     provide default images if user does not specify their own.
> > 
> >     Or is still possible to use zocial ones ?
> > 
> > Regards.
> > 
> > ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, November 27, 2014 9:01:38 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Hi guys,
> > 
> >    I've done some initial work covering both persistence and brokering. No
> >    UI, yet. I'm focused on the model, rest api and brokering functionality
> >    for now.
> > 
> >    What I have is enough to decide if we are aligned about this
> >    functionality. So you can understand how the model (and persistence),
> >    rest api and brokering functionality looks like. Can we schedule a
> >    meeting ?
> > 
> >    Btw, my branch is here [1].
> > 
> > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > 
> > Regards.
> > Pedro Igor
> > 
> > ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, November 20, 2014 2:48:49 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Currently adapters can only make authz decisions (@RolesAllowed) based
> > on either realm roles or the roles of one specific application.  This is
> > related to 1) too.
> > 
> > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > 1) Sounds like something definitely worth aiming for.
> > >
> > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > >> I just wanted to quickly list the additional work we discussed so
> > >> everyone
> > >> can think about it (in no particular order):
> > >>
> > >> 1) Mapping of tokens - how do we deal with mapping of an external token
> > >> to
> > >> a KC token? For example an external token with attribute 'group' that
> > >> contains 'sales' and 'manager' could be mapped to 'manager' role for
> > >> 'sales app in a KC token. Could we use Drools? This could also be used
> > >> in
> > >> user federation to allow more complex mapping of roles/groups than a
> > >> simple 1-1
> > >> 2) Retrieving tokens - if an application wants to retrieve the external
> > >> token (for example to view Facebook friends if user logged in with
> > >> Facebook)
> > >> 3) Configure scope - currently for social we only request a very limited
> > >> scope (basic profile and email), to for example view Facebook friends
> > >> we'd need to ask for that as well
> > >> 4) Selecting provider - currently in social (and for first pass of
> > >> brokering) we have an icon user has to select, but can we select the
> > >> provider in a different way (for example ask user for email, and select
> > >> based on email domain)
> > >> 5) Gateway - don't create a KC token, but just forward the external
> > >> token
> > >>
> > >> IMO 1) is a killer feature, as it would allow companies to add external
> > >> users without having to modify their applications. Issue with 5) is that
> > >> applications need to understand more than one token, which would require
> > >> rewriting applications.
> > >>
> > >> This work is also somewhat related to other authentication mechanisms
> > >> (for
> > >> example Kerberos ticket, LDAP and passwordless).
> > >>
> > >> ----- Original Message -----
> > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > >>> To: "Bill Burke" <bburke at redhat.com>
> > >>> Cc: keycloak-dev at lists.jboss.org
> > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > >>> Broker
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: keycloak-dev at lists.jboss.org
> > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > >>>> Broker
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>>        Would like to start a discussion about how to enable KC as an
> > >>>>>        Authentication Broker in order to supported Chained Federation
> > >>>>>        and
> > >>>>>        also Identity Federation. First of all, some background about
> > >>>>>        what
> > >>>>>        this is all about.
> > >>>>>
> > >>>>>        Currently KeyCloak provides two basic types of authentication
> > >>>>>        (correct
> > >>>>>        me if I'm wrong, please):
> > >>>>>
> > >>>>>            1) Local authentication (based on some credential type
> > >>>>>            enabled
> > >>>>>            to
> > >>>>>            a realm)
> > >>>>>            2) Social authentication
> > >>>>>
> > >>>>>        Local authentication is about authenticating the user locally
> > >>>>>        using
> > >>>>>        KC's own identity store. Nothing special here. And Social
> > >>>>>        Authentication which allows users to choose the Social IdP
> > >>>>>        they
> > >>>>>        want
> > >>>>>        to authenticate with. In this case, the IdP is always one of
> > >>>>>        the
> > >>>>>        built-in social providers supported by KC such as Facebook,
> > >>>>>        Google,
> > >>>>>        Twitter, Github and so forth.
> > >>>>>
> > >>>>>        When doing social, the user is automatically provisioned in KC
> > >>>>>        identity store after a successful authentication. The user
> > >>>>>        does
> > >>>>>        not
> > >>>>>        need to fill a registration form and can access the
> > >>>>>        application
> > >>>>>        very
> > >>>>>        quickly. During the provisioning some basic information is
> > >>>>>        retrieved
> > >>>>>        from the social provider such as email, firstname and so
> > >>>>>        forth.
> > >>>>>        These
> > >>>>>        are very basic information, any other information such as
> > >>>>>        those
> > >>>>>        related with authorization policies - eg.: roles and groups -
> > >>>>>        must
> > >>>>>        be
> > >>>>>        defined later via KC's admin console.
> > >>>>>
> > >>>>>        Another important characteristic of social authentication is
> > >>>>>        that
> > >>>>>        the
> > >>>>>        application receives a KC token and not the token that was
> > >>>>>        issued by
> > >>>>>        the social IdP during the authentication process. If the
> > >>>>>        application
> > >>>>>        wants to consume resources from the resource provider he was
> > >>>>>        authenticated it must obtain the access token(again) by itself
> > >>>>>        prior
> > >>>>>        to invoke the resource provider API. Assuming all those social
> > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > >>>>>
> > >>>>>        That said, the Authentication Broker functionality aims to
> > >>>>>        cover
> > >>>>>        the
> > >>>>>        same use cases but with a lot of more flexibility on how you
> > >>>>>        setup
> > >>>>>        identity providers(not only social ones) and the different
> > >>>>>        federation
> > >>>>>        protocols they may support such as SAML, OpenID, oAuth and so
> > >>>>>        forth.
> > >>>>>        This is useful when an enterprise is providing services to
> > >>>>>        different
> > >>>>>        customers(IdP) and does not want to manage many to many
> > >>>>>        relationships. When using a broker, the authentication steps
> > >>>>>        are
> > >>>>>        pretty much the same when you are using social authentication,
> > >>>>>        with
> > >>>>>        important differences on how you support different identity
> > >>>>>        providers, different federation protocols, how users are
> > >>>>>        provisioned
> > >>>>>        and how claims and attributes are resolved.
> > >>>>>
> > >>>>>        The brokering functionality can be done in two ways depending
> > >>>>>        if
> > >>>>>        the
> > >>>>>        broker service is acting as a gateway or not. When acting as a
> > >>>>>        gateway, the broker will respond to the application the same
> > >>>>>        token
> > >>>>>        issued by the trusted identity provider. For instance, if the
> > >>>>>        user
> > >>>>>        selects a SAML IdP to authenticate with, the application will
> > >>>>>        receive
> > >>>>>        a SAML Response. In this case, the application must also be
> > >>>>>        prepared
> > >>>>>        to handle a specific federation protocol.
> > >>>>>
> > >>>>>        However, the broker service can also be used to completely
> > >>>>>        abstract
> > >>>>>        from the application the protocol used to authenticate an
> > >>>>>        user.
> > >>>>>        In
> > >>>>>        this case, the application will just receive an ordinary KC
> > >>>>>        token
> > >>>>>        after a successful authentication.
> > >>>>>
> > >>>>>        In both cases, the broker acts as an intermediary where
> > >>>>>        specific
> > >>>>>        security policies can be applied when users try to
> > >>>>>        authenticate
> > >>>>>        themselves against a 3rd party IdP. That brings a lot of value
> > >>>>>        when
> > >>>>>        you think about auditing, authorization and how users are
> > >>>>>        provisioned
> > >>>>>        when federation of identities is needed. This also allows
> > >>>>>        existing
> > >>>>>        security infrastructures (eg.: SAML-based infrastructures) to
> > >>>>>        benefit
> > >>>>>        from KC's support for cloud, rest and mobile use cases.
> > >>>>>
> > >>>>>        I think this is enough to start a discussion. I've an initial
> > >>>>>        discussion with Stian about all that and we agreed that
> > >>>>>        abstract
> > >>>>>        the
> > >>>>>        protocol from applications should be prioritized. The main
> > >>>>>        reason is
> > >>>>>        that it makes life easier for applications so they only need
> > >>>>>        to
> > >>>>>        know
> > >>>>>        about KC tokens and nothing else. However that brings some new
> > >>>>>        requirements around user provisioning and claim/attribute
> > >>>>>        resolution
> > >>>>>        or mapping. But that would be another thread.
> > >>>>>
> > >>>>
> > >>>> Can you elaborate on "abstract the protocol from applications"?  Not
> > >>>> sure what you mean by that.  IDP federation should be configured at
> > >>>> the
> > >>>> realm level and really has nothing to do with applications.
> > >>>>
> > >>>> I'm really happy that somebody is doing this.  We're getting a real
> > >>>> impressive feature set!
> > >>>
> > >>> Sure. What I meant was that the application only knows about KC tokens
> > >>> nothing else. It will always receive a KC token regardless the protocol
> > >>> used
> > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > >>> whatever).
> > >>> The
> > >>> example I gave was about an user trying to authenticate against a SAML
> > >>> IdP.
> > >>> In this case, after a successful authentication on the IdP, the IdP
> > >>> will
> > >>> issue a token to KC. Then KC will validate the token, perform trust and
> > >>> security checks, do user provisioning and attribute/claim resolution to
> > >>> finally issue a KC token and redirect the user to the application. If
> > >>> the
> > >>> app is configured to use openid in KC then it will receive a openid
> > >>> token
> > >>> from KC, not saml ...
> > >>>
> > >>> The other scenario is pretty much the same. The difference is that KC
> > >>> will
> > >>> not issue its own token but just replay the token issued by the 3rd
> > >>> party
> > >>> IdP to the service provider.
> > >>>
> > >>> I agree that this config goes at the realm level. For instance, to
> > >>> create
> > >>> and
> > >>> enable providers for being used. However, I think we would need some
> > >>> specific configuration for applications as well. Specially when
> > >>> defining
> > >>> default roles, mapping attributes. Another example of application
> > >>> config
> > >>> is
> > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > >>> per-application.
> > >>>
> > >>>>
> > >>>> --
> > >>>> Bill Burke
> > >>>> JBoss, a division of Red Hat
> > >>>> http://bill.burkecentral.com
> > >>>> _______________________________________________
> > >>>> keycloak-dev mailing list
> > >>>> keycloak-dev at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>>
> > >>> _______________________________________________
> > >>> 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
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Tue Dec  2 06:55:21 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 2 Dec 2014 06:55:21 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1332181380.2499178.1416473745773.JavaMail.zimbra@redhat.com>
	<546E1978.7000902@redhat.com> <546E1B71.8000807@redhat.com>
	<1709556791.20804905.1417129298254.JavaMail.zimbra@redhat.com>
	<1648216531.22628862.1417519341632.JavaMail.zimbra@redhat.com>
	<732604538.8590377.1417520085671.JavaMail.zimbra@redhat.com>
	<917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>
Message-ID: <247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>

Users can now specify a Icon Url to be rendered on the login page when social or any other identity provider is configured. So we just load the image the url entered by the user.

Are you saying that users should change the theme or customize css if they only want to change an icon for a provider ?

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Tuesday, December 2, 2014 9:42:15 AM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker

All look and feel related things including images and stylesheets should be part of themes. This is to allow customizing them in the theme. Also, an image is not the correct way to render a button, it should be defined in CSS.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 12:34:45 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> You shouldn't have icon images for social providers. They should be specified
> as part of the theme in CSS as is now.
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Hi,
> > 
> >     Anyone know where I can get the icons images for social providers ? It
> >     seems zocial defines them encoded in some way in CSS. I need that to
> >     provide default images if user does not specify their own.
> > 
> >     Or is still possible to use zocial ones ?
> > 
> > Regards.
> > 
> > ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, November 27, 2014 9:01:38 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Hi guys,
> > 
> >    I've done some initial work covering both persistence and brokering. No
> >    UI, yet. I'm focused on the model, rest api and brokering functionality
> >    for now.
> > 
> >    What I have is enough to decide if we are aligned about this
> >    functionality. So you can understand how the model (and persistence),
> >    rest api and brokering functionality looks like. Can we schedule a
> >    meeting ?
> > 
> >    Btw, my branch is here [1].
> > 
> > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > 
> > Regards.
> > Pedro Igor
> > 
> > ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, November 20, 2014 2:48:49 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Currently adapters can only make authz decisions (@RolesAllowed) based
> > on either realm roles or the roles of one specific application.  This is
> > related to 1) too.
> > 
> > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > 1) Sounds like something definitely worth aiming for.
> > >
> > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > >> I just wanted to quickly list the additional work we discussed so
> > >> everyone
> > >> can think about it (in no particular order):
> > >>
> > >> 1) Mapping of tokens - how do we deal with mapping of an external token
> > >> to
> > >> a KC token? For example an external token with attribute 'group' that
> > >> contains 'sales' and 'manager' could be mapped to 'manager' role for
> > >> 'sales app in a KC token. Could we use Drools? This could also be used
> > >> in
> > >> user federation to allow more complex mapping of roles/groups than a
> > >> simple 1-1
> > >> 2) Retrieving tokens - if an application wants to retrieve the external
> > >> token (for example to view Facebook friends if user logged in with
> > >> Facebook)
> > >> 3) Configure scope - currently for social we only request a very limited
> > >> scope (basic profile and email), to for example view Facebook friends
> > >> we'd need to ask for that as well
> > >> 4) Selecting provider - currently in social (and for first pass of
> > >> brokering) we have an icon user has to select, but can we select the
> > >> provider in a different way (for example ask user for email, and select
> > >> based on email domain)
> > >> 5) Gateway - don't create a KC token, but just forward the external
> > >> token
> > >>
> > >> IMO 1) is a killer feature, as it would allow companies to add external
> > >> users without having to modify their applications. Issue with 5) is that
> > >> applications need to understand more than one token, which would require
> > >> rewriting applications.
> > >>
> > >> This work is also somewhat related to other authentication mechanisms
> > >> (for
> > >> example Kerberos ticket, LDAP and passwordless).
> > >>
> > >> ----- Original Message -----
> > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > >>> To: "Bill Burke" <bburke at redhat.com>
> > >>> Cc: keycloak-dev at lists.jboss.org
> > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > >>> Broker
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: keycloak-dev at lists.jboss.org
> > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > >>>> Broker
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>>        Would like to start a discussion about how to enable KC as an
> > >>>>>        Authentication Broker in order to supported Chained Federation
> > >>>>>        and
> > >>>>>        also Identity Federation. First of all, some background about
> > >>>>>        what
> > >>>>>        this is all about.
> > >>>>>
> > >>>>>        Currently KeyCloak provides two basic types of authentication
> > >>>>>        (correct
> > >>>>>        me if I'm wrong, please):
> > >>>>>
> > >>>>>            1) Local authentication (based on some credential type
> > >>>>>            enabled
> > >>>>>            to
> > >>>>>            a realm)
> > >>>>>            2) Social authentication
> > >>>>>
> > >>>>>        Local authentication is about authenticating the user locally
> > >>>>>        using
> > >>>>>        KC's own identity store. Nothing special here. And Social
> > >>>>>        Authentication which allows users to choose the Social IdP
> > >>>>>        they
> > >>>>>        want
> > >>>>>        to authenticate with. In this case, the IdP is always one of
> > >>>>>        the
> > >>>>>        built-in social providers supported by KC such as Facebook,
> > >>>>>        Google,
> > >>>>>        Twitter, Github and so forth.
> > >>>>>
> > >>>>>        When doing social, the user is automatically provisioned in KC
> > >>>>>        identity store after a successful authentication. The user
> > >>>>>        does
> > >>>>>        not
> > >>>>>        need to fill a registration form and can access the
> > >>>>>        application
> > >>>>>        very
> > >>>>>        quickly. During the provisioning some basic information is
> > >>>>>        retrieved
> > >>>>>        from the social provider such as email, firstname and so
> > >>>>>        forth.
> > >>>>>        These
> > >>>>>        are very basic information, any other information such as
> > >>>>>        those
> > >>>>>        related with authorization policies - eg.: roles and groups -
> > >>>>>        must
> > >>>>>        be
> > >>>>>        defined later via KC's admin console.
> > >>>>>
> > >>>>>        Another important characteristic of social authentication is
> > >>>>>        that
> > >>>>>        the
> > >>>>>        application receives a KC token and not the token that was
> > >>>>>        issued by
> > >>>>>        the social IdP during the authentication process. If the
> > >>>>>        application
> > >>>>>        wants to consume resources from the resource provider he was
> > >>>>>        authenticated it must obtain the access token(again) by itself
> > >>>>>        prior
> > >>>>>        to invoke the resource provider API. Assuming all those social
> > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > >>>>>
> > >>>>>        That said, the Authentication Broker functionality aims to
> > >>>>>        cover
> > >>>>>        the
> > >>>>>        same use cases but with a lot of more flexibility on how you
> > >>>>>        setup
> > >>>>>        identity providers(not only social ones) and the different
> > >>>>>        federation
> > >>>>>        protocols they may support such as SAML, OpenID, oAuth and so
> > >>>>>        forth.
> > >>>>>        This is useful when an enterprise is providing services to
> > >>>>>        different
> > >>>>>        customers(IdP) and does not want to manage many to many
> > >>>>>        relationships. When using a broker, the authentication steps
> > >>>>>        are
> > >>>>>        pretty much the same when you are using social authentication,
> > >>>>>        with
> > >>>>>        important differences on how you support different identity
> > >>>>>        providers, different federation protocols, how users are
> > >>>>>        provisioned
> > >>>>>        and how claims and attributes are resolved.
> > >>>>>
> > >>>>>        The brokering functionality can be done in two ways depending
> > >>>>>        if
> > >>>>>        the
> > >>>>>        broker service is acting as a gateway or not. When acting as a
> > >>>>>        gateway, the broker will respond to the application the same
> > >>>>>        token
> > >>>>>        issued by the trusted identity provider. For instance, if the
> > >>>>>        user
> > >>>>>        selects a SAML IdP to authenticate with, the application will
> > >>>>>        receive
> > >>>>>        a SAML Response. In this case, the application must also be
> > >>>>>        prepared
> > >>>>>        to handle a specific federation protocol.
> > >>>>>
> > >>>>>        However, the broker service can also be used to completely
> > >>>>>        abstract
> > >>>>>        from the application the protocol used to authenticate an
> > >>>>>        user.
> > >>>>>        In
> > >>>>>        this case, the application will just receive an ordinary KC
> > >>>>>        token
> > >>>>>        after a successful authentication.
> > >>>>>
> > >>>>>        In both cases, the broker acts as an intermediary where
> > >>>>>        specific
> > >>>>>        security policies can be applied when users try to
> > >>>>>        authenticate
> > >>>>>        themselves against a 3rd party IdP. That brings a lot of value
> > >>>>>        when
> > >>>>>        you think about auditing, authorization and how users are
> > >>>>>        provisioned
> > >>>>>        when federation of identities is needed. This also allows
> > >>>>>        existing
> > >>>>>        security infrastructures (eg.: SAML-based infrastructures) to
> > >>>>>        benefit
> > >>>>>        from KC's support for cloud, rest and mobile use cases.
> > >>>>>
> > >>>>>        I think this is enough to start a discussion. I've an initial
> > >>>>>        discussion with Stian about all that and we agreed that
> > >>>>>        abstract
> > >>>>>        the
> > >>>>>        protocol from applications should be prioritized. The main
> > >>>>>        reason is
> > >>>>>        that it makes life easier for applications so they only need
> > >>>>>        to
> > >>>>>        know
> > >>>>>        about KC tokens and nothing else. However that brings some new
> > >>>>>        requirements around user provisioning and claim/attribute
> > >>>>>        resolution
> > >>>>>        or mapping. But that would be another thread.
> > >>>>>
> > >>>>
> > >>>> Can you elaborate on "abstract the protocol from applications"?  Not
> > >>>> sure what you mean by that.  IDP federation should be configured at
> > >>>> the
> > >>>> realm level and really has nothing to do with applications.
> > >>>>
> > >>>> I'm really happy that somebody is doing this.  We're getting a real
> > >>>> impressive feature set!
> > >>>
> > >>> Sure. What I meant was that the application only knows about KC tokens
> > >>> nothing else. It will always receive a KC token regardless the protocol
> > >>> used
> > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > >>> whatever).
> > >>> The
> > >>> example I gave was about an user trying to authenticate against a SAML
> > >>> IdP.
> > >>> In this case, after a successful authentication on the IdP, the IdP
> > >>> will
> > >>> issue a token to KC. Then KC will validate the token, perform trust and
> > >>> security checks, do user provisioning and attribute/claim resolution to
> > >>> finally issue a KC token and redirect the user to the application. If
> > >>> the
> > >>> app is configured to use openid in KC then it will receive a openid
> > >>> token
> > >>> from KC, not saml ...
> > >>>
> > >>> The other scenario is pretty much the same. The difference is that KC
> > >>> will
> > >>> not issue its own token but just replay the token issued by the 3rd
> > >>> party
> > >>> IdP to the service provider.
> > >>>
> > >>> I agree that this config goes at the realm level. For instance, to
> > >>> create
> > >>> and
> > >>> enable providers for being used. However, I think we would need some
> > >>> specific configuration for applications as well. Specially when
> > >>> defining
> > >>> default roles, mapping attributes. Another example of application
> > >>> config
> > >>> is
> > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > >>> per-application.
> > >>>
> > >>>>
> > >>>> --
> > >>>> Bill Burke
> > >>>> JBoss, a division of Red Hat
> > >>>> http://bill.burkecentral.com
> > >>>> _______________________________________________
> > >>>> keycloak-dev mailing list
> > >>>> keycloak-dev at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>>
> > >>> _______________________________________________
> > >>> 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
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Tue Dec  2 07:04:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 07:04:33 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<546E1978.7000902@redhat.com> <546E1B71.8000807@redhat.com>
	<1709556791.20804905.1417129298254.JavaMail.zimbra@redhat.com>
	<1648216531.22628862.1417519341632.JavaMail.zimbra@redhat.com>
	<732604538.8590377.1417520085671.JavaMail.zimbra@redhat.com>
	<917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>
	<247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>
Message-ID: <1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>


----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 12:55:21 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Users can now specify a Icon Url to be rendered on the login page when social
> or any other identity provider is configured. So we just load the image the
> url entered by the user.
> 
> Are you saying that users should change the theme or customize css if they
> only want to change an icon for a provider ?

Yes, there's many issues with having a icon url:

* Won't work for internationalization - we don't have this now, but we will
* Image is not a good button - CSS is much better
* Doesn't support themes - we allow users to switch l&f by switching themes, but that won't work for a icon url. In the future we may also support multiple themes per-realm, for example to depending on the devices (one theme for mobiles, one for desktops, etc)
* Requires the URL to be hosted somewhere - why require a separate call to download an image (to a separate server maybe) if it can simply be defined in a single CSS file?

Rather than add additional places to define look and feel components we should in the future make it easier to add/customize themes.

> 
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, December 2, 2014 9:42:15 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> All look and feel related things including images and stylesheets should be
> part of themes. This is to allow customizing them in the theme. Also, an
> image is not the correct way to render a button, it should be defined in
> CSS.
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > You shouldn't have icon images for social providers. They should be
> > specified
> > as part of the theme in CSS as is now.
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Bill Burke" <bburke at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Hi,
> > > 
> > >     Anyone know where I can get the icons images for social providers ?
> > >     It
> > >     seems zocial defines them encoded in some way in CSS. I need that to
> > >     provide default images if user does not specify their own.
> > > 
> > >     Or is still possible to use zocial ones ?
> > > 
> > > Regards.
> > > 
> > > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Bill Burke" <bburke at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Hi guys,
> > > 
> > >    I've done some initial work covering both persistence and brokering.
> > >    No
> > >    UI, yet. I'm focused on the model, rest api and brokering
> > >    functionality
> > >    for now.
> > > 
> > >    What I have is enough to decide if we are aligned about this
> > >    functionality. So you can understand how the model (and persistence),
> > >    rest api and brokering functionality looks like. Can we schedule a
> > >    meeting ?
> > > 
> > >    Btw, my branch is here [1].
> > > 
> > > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > 
> > > Regards.
> > > Pedro Igor
> > > 
> > > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Currently adapters can only make authz decisions (@RolesAllowed) based
> > > on either realm roles or the roles of one specific application.  This is
> > > related to 1) too.
> > > 
> > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > 1) Sounds like something definitely worth aiming for.
> > > >
> > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > >> I just wanted to quickly list the additional work we discussed so
> > > >> everyone
> > > >> can think about it (in no particular order):
> > > >>
> > > >> 1) Mapping of tokens - how do we deal with mapping of an external
> > > >> token
> > > >> to
> > > >> a KC token? For example an external token with attribute 'group' that
> > > >> contains 'sales' and 'manager' could be mapped to 'manager' role for
> > > >> 'sales app in a KC token. Could we use Drools? This could also be used
> > > >> in
> > > >> user federation to allow more complex mapping of roles/groups than a
> > > >> simple 1-1
> > > >> 2) Retrieving tokens - if an application wants to retrieve the
> > > >> external
> > > >> token (for example to view Facebook friends if user logged in with
> > > >> Facebook)
> > > >> 3) Configure scope - currently for social we only request a very
> > > >> limited
> > > >> scope (basic profile and email), to for example view Facebook friends
> > > >> we'd need to ask for that as well
> > > >> 4) Selecting provider - currently in social (and for first pass of
> > > >> brokering) we have an icon user has to select, but can we select the
> > > >> provider in a different way (for example ask user for email, and
> > > >> select
> > > >> based on email domain)
> > > >> 5) Gateway - don't create a KC token, but just forward the external
> > > >> token
> > > >>
> > > >> IMO 1) is a killer feature, as it would allow companies to add
> > > >> external
> > > >> users without having to modify their applications. Issue with 5) is
> > > >> that
> > > >> applications need to understand more than one token, which would
> > > >> require
> > > >> rewriting applications.
> > > >>
> > > >> This work is also somewhat related to other authentication mechanisms
> > > >> (for
> > > >> example Kerberos ticket, LDAP and passwordless).
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > >>> Cc: keycloak-dev at lists.jboss.org
> > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > >>> Broker
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > >>>> To: keycloak-dev at lists.jboss.org
> > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > >>>> Broker
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>>        Would like to start a discussion about how to enable KC as
> > > >>>>>        an
> > > >>>>>        Authentication Broker in order to supported Chained
> > > >>>>>        Federation
> > > >>>>>        and
> > > >>>>>        also Identity Federation. First of all, some background
> > > >>>>>        about
> > > >>>>>        what
> > > >>>>>        this is all about.
> > > >>>>>
> > > >>>>>        Currently KeyCloak provides two basic types of
> > > >>>>>        authentication
> > > >>>>>        (correct
> > > >>>>>        me if I'm wrong, please):
> > > >>>>>
> > > >>>>>            1) Local authentication (based on some credential type
> > > >>>>>            enabled
> > > >>>>>            to
> > > >>>>>            a realm)
> > > >>>>>            2) Social authentication
> > > >>>>>
> > > >>>>>        Local authentication is about authenticating the user
> > > >>>>>        locally
> > > >>>>>        using
> > > >>>>>        KC's own identity store. Nothing special here. And Social
> > > >>>>>        Authentication which allows users to choose the Social IdP
> > > >>>>>        they
> > > >>>>>        want
> > > >>>>>        to authenticate with. In this case, the IdP is always one of
> > > >>>>>        the
> > > >>>>>        built-in social providers supported by KC such as Facebook,
> > > >>>>>        Google,
> > > >>>>>        Twitter, Github and so forth.
> > > >>>>>
> > > >>>>>        When doing social, the user is automatically provisioned in
> > > >>>>>        KC
> > > >>>>>        identity store after a successful authentication. The user
> > > >>>>>        does
> > > >>>>>        not
> > > >>>>>        need to fill a registration form and can access the
> > > >>>>>        application
> > > >>>>>        very
> > > >>>>>        quickly. During the provisioning some basic information is
> > > >>>>>        retrieved
> > > >>>>>        from the social provider such as email, firstname and so
> > > >>>>>        forth.
> > > >>>>>        These
> > > >>>>>        are very basic information, any other information such as
> > > >>>>>        those
> > > >>>>>        related with authorization policies - eg.: roles and groups
> > > >>>>>        -
> > > >>>>>        must
> > > >>>>>        be
> > > >>>>>        defined later via KC's admin console.
> > > >>>>>
> > > >>>>>        Another important characteristic of social authentication is
> > > >>>>>        that
> > > >>>>>        the
> > > >>>>>        application receives a KC token and not the token that was
> > > >>>>>        issued by
> > > >>>>>        the social IdP during the authentication process. If the
> > > >>>>>        application
> > > >>>>>        wants to consume resources from the resource provider he was
> > > >>>>>        authenticated it must obtain the access token(again) by
> > > >>>>>        itself
> > > >>>>>        prior
> > > >>>>>        to invoke the resource provider API. Assuming all those
> > > >>>>>        social
> > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > >>>>>
> > > >>>>>        That said, the Authentication Broker functionality aims to
> > > >>>>>        cover
> > > >>>>>        the
> > > >>>>>        same use cases but with a lot of more flexibility on how you
> > > >>>>>        setup
> > > >>>>>        identity providers(not only social ones) and the different
> > > >>>>>        federation
> > > >>>>>        protocols they may support such as SAML, OpenID, oAuth and
> > > >>>>>        so
> > > >>>>>        forth.
> > > >>>>>        This is useful when an enterprise is providing services to
> > > >>>>>        different
> > > >>>>>        customers(IdP) and does not want to manage many to many
> > > >>>>>        relationships. When using a broker, the authentication steps
> > > >>>>>        are
> > > >>>>>        pretty much the same when you are using social
> > > >>>>>        authentication,
> > > >>>>>        with
> > > >>>>>        important differences on how you support different identity
> > > >>>>>        providers, different federation protocols, how users are
> > > >>>>>        provisioned
> > > >>>>>        and how claims and attributes are resolved.
> > > >>>>>
> > > >>>>>        The brokering functionality can be done in two ways
> > > >>>>>        depending
> > > >>>>>        if
> > > >>>>>        the
> > > >>>>>        broker service is acting as a gateway or not. When acting as
> > > >>>>>        a
> > > >>>>>        gateway, the broker will respond to the application the same
> > > >>>>>        token
> > > >>>>>        issued by the trusted identity provider. For instance, if
> > > >>>>>        the
> > > >>>>>        user
> > > >>>>>        selects a SAML IdP to authenticate with, the application
> > > >>>>>        will
> > > >>>>>        receive
> > > >>>>>        a SAML Response. In this case, the application must also be
> > > >>>>>        prepared
> > > >>>>>        to handle a specific federation protocol.
> > > >>>>>
> > > >>>>>        However, the broker service can also be used to completely
> > > >>>>>        abstract
> > > >>>>>        from the application the protocol used to authenticate an
> > > >>>>>        user.
> > > >>>>>        In
> > > >>>>>        this case, the application will just receive an ordinary KC
> > > >>>>>        token
> > > >>>>>        after a successful authentication.
> > > >>>>>
> > > >>>>>        In both cases, the broker acts as an intermediary where
> > > >>>>>        specific
> > > >>>>>        security policies can be applied when users try to
> > > >>>>>        authenticate
> > > >>>>>        themselves against a 3rd party IdP. That brings a lot of
> > > >>>>>        value
> > > >>>>>        when
> > > >>>>>        you think about auditing, authorization and how users are
> > > >>>>>        provisioned
> > > >>>>>        when federation of identities is needed. This also allows
> > > >>>>>        existing
> > > >>>>>        security infrastructures (eg.: SAML-based infrastructures)
> > > >>>>>        to
> > > >>>>>        benefit
> > > >>>>>        from KC's support for cloud, rest and mobile use cases.
> > > >>>>>
> > > >>>>>        I think this is enough to start a discussion. I've an
> > > >>>>>        initial
> > > >>>>>        discussion with Stian about all that and we agreed that
> > > >>>>>        abstract
> > > >>>>>        the
> > > >>>>>        protocol from applications should be prioritized. The main
> > > >>>>>        reason is
> > > >>>>>        that it makes life easier for applications so they only need
> > > >>>>>        to
> > > >>>>>        know
> > > >>>>>        about KC tokens and nothing else. However that brings some
> > > >>>>>        new
> > > >>>>>        requirements around user provisioning and claim/attribute
> > > >>>>>        resolution
> > > >>>>>        or mapping. But that would be another thread.
> > > >>>>>
> > > >>>>
> > > >>>> Can you elaborate on "abstract the protocol from applications"?  Not
> > > >>>> sure what you mean by that.  IDP federation should be configured at
> > > >>>> the
> > > >>>> realm level and really has nothing to do with applications.
> > > >>>>
> > > >>>> I'm really happy that somebody is doing this.  We're getting a real
> > > >>>> impressive feature set!
> > > >>>
> > > >>> Sure. What I meant was that the application only knows about KC
> > > >>> tokens
> > > >>> nothing else. It will always receive a KC token regardless the
> > > >>> protocol
> > > >>> used
> > > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > > >>> whatever).
> > > >>> The
> > > >>> example I gave was about an user trying to authenticate against a
> > > >>> SAML
> > > >>> IdP.
> > > >>> In this case, after a successful authentication on the IdP, the IdP
> > > >>> will
> > > >>> issue a token to KC. Then KC will validate the token, perform trust
> > > >>> and
> > > >>> security checks, do user provisioning and attribute/claim resolution
> > > >>> to
> > > >>> finally issue a KC token and redirect the user to the application. If
> > > >>> the
> > > >>> app is configured to use openid in KC then it will receive a openid
> > > >>> token
> > > >>> from KC, not saml ...
> > > >>>
> > > >>> The other scenario is pretty much the same. The difference is that KC
> > > >>> will
> > > >>> not issue its own token but just replay the token issued by the 3rd
> > > >>> party
> > > >>> IdP to the service provider.
> > > >>>
> > > >>> I agree that this config goes at the realm level. For instance, to
> > > >>> create
> > > >>> and
> > > >>> enable providers for being used. However, I think we would need some
> > > >>> specific configuration for applications as well. Specially when
> > > >>> defining
> > > >>> default roles, mapping attributes. Another example of application
> > > >>> config
> > > >>> is
> > > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > > >>> per-application.
> > > >>>
> > > >>>>
> > > >>>> --
> > > >>>> Bill Burke
> > > >>>> JBoss, a division of Red Hat
> > > >>>> http://bill.burkecentral.com
> > > >>>> _______________________________________________
> > > >>>> keycloak-dev mailing list
> > > >>>> keycloak-dev at lists.jboss.org
> > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>>>
> > > >>> _______________________________________________
> > > >>> 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
> > > 
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From psilva at redhat.com  Tue Dec  2 07:13:08 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 2 Dec 2014 07:13:08 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<546E1B71.8000807@redhat.com>
	<1709556791.20804905.1417129298254.JavaMail.zimbra@redhat.com>
	<1648216531.22628862.1417519341632.JavaMail.zimbra@redhat.com>
	<732604538.8590377.1417520085671.JavaMail.zimbra@redhat.com>
	<917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>
	<247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>
	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
Message-ID: <2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>

I'll go for it then. Will remove the icon url from the model and leave that for users if they want to provide icons for their identity providers.

My point is that icons can be usually served by the same server/application or proxy, so download images are not such a big deal. Also, the icon url is part of the freemarker model and people can do what ever they want with it. What I think will also help in your future plans.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Tuesday, December 2, 2014 10:04:33 AM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker


----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 12:55:21 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Users can now specify a Icon Url to be rendered on the login page when social
> or any other identity provider is configured. So we just load the image the
> url entered by the user.
> 
> Are you saying that users should change the theme or customize css if they
> only want to change an icon for a provider ?

Yes, there's many issues with having a icon url:

* Won't work for internationalization - we don't have this now, but we will
* Image is not a good button - CSS is much better
* Doesn't support themes - we allow users to switch l&f by switching themes, but that won't work for a icon url. In the future we may also support multiple themes per-realm, for example to depending on the devices (one theme for mobiles, one for desktops, etc)
* Requires the URL to be hosted somewhere - why require a separate call to download an image (to a separate server maybe) if it can simply be defined in a single CSS file?

Rather than add additional places to define look and feel components we should in the future make it easier to add/customize themes.

> 
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, December 2, 2014 9:42:15 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> All look and feel related things including images and stylesheets should be
> part of themes. This is to allow customizing them in the theme. Also, an
> image is not the correct way to render a button, it should be defined in
> CSS.
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > You shouldn't have icon images for social providers. They should be
> > specified
> > as part of the theme in CSS as is now.
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Bill Burke" <bburke at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Hi,
> > > 
> > >     Anyone know where I can get the icons images for social providers ?
> > >     It
> > >     seems zocial defines them encoded in some way in CSS. I need that to
> > >     provide default images if user does not specify their own.
> > > 
> > >     Or is still possible to use zocial ones ?
> > > 
> > > Regards.
> > > 
> > > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Bill Burke" <bburke at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Hi guys,
> > > 
> > >    I've done some initial work covering both persistence and brokering.
> > >    No
> > >    UI, yet. I'm focused on the model, rest api and brokering
> > >    functionality
> > >    for now.
> > > 
> > >    What I have is enough to decide if we are aligned about this
> > >    functionality. So you can understand how the model (and persistence),
> > >    rest api and brokering functionality looks like. Can we schedule a
> > >    meeting ?
> > > 
> > >    Btw, my branch is here [1].
> > > 
> > > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > 
> > > Regards.
> > > Pedro Igor
> > > 
> > > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Currently adapters can only make authz decisions (@RolesAllowed) based
> > > on either realm roles or the roles of one specific application.  This is
> > > related to 1) too.
> > > 
> > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > 1) Sounds like something definitely worth aiming for.
> > > >
> > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > >> I just wanted to quickly list the additional work we discussed so
> > > >> everyone
> > > >> can think about it (in no particular order):
> > > >>
> > > >> 1) Mapping of tokens - how do we deal with mapping of an external
> > > >> token
> > > >> to
> > > >> a KC token? For example an external token with attribute 'group' that
> > > >> contains 'sales' and 'manager' could be mapped to 'manager' role for
> > > >> 'sales app in a KC token. Could we use Drools? This could also be used
> > > >> in
> > > >> user federation to allow more complex mapping of roles/groups than a
> > > >> simple 1-1
> > > >> 2) Retrieving tokens - if an application wants to retrieve the
> > > >> external
> > > >> token (for example to view Facebook friends if user logged in with
> > > >> Facebook)
> > > >> 3) Configure scope - currently for social we only request a very
> > > >> limited
> > > >> scope (basic profile and email), to for example view Facebook friends
> > > >> we'd need to ask for that as well
> > > >> 4) Selecting provider - currently in social (and for first pass of
> > > >> brokering) we have an icon user has to select, but can we select the
> > > >> provider in a different way (for example ask user for email, and
> > > >> select
> > > >> based on email domain)
> > > >> 5) Gateway - don't create a KC token, but just forward the external
> > > >> token
> > > >>
> > > >> IMO 1) is a killer feature, as it would allow companies to add
> > > >> external
> > > >> users without having to modify their applications. Issue with 5) is
> > > >> that
> > > >> applications need to understand more than one token, which would
> > > >> require
> > > >> rewriting applications.
> > > >>
> > > >> This work is also somewhat related to other authentication mechanisms
> > > >> (for
> > > >> example Kerberos ticket, LDAP and passwordless).
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > >>> Cc: keycloak-dev at lists.jboss.org
> > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > >>> Broker
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > >>>> To: keycloak-dev at lists.jboss.org
> > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > >>>> Broker
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>>        Would like to start a discussion about how to enable KC as
> > > >>>>>        an
> > > >>>>>        Authentication Broker in order to supported Chained
> > > >>>>>        Federation
> > > >>>>>        and
> > > >>>>>        also Identity Federation. First of all, some background
> > > >>>>>        about
> > > >>>>>        what
> > > >>>>>        this is all about.
> > > >>>>>
> > > >>>>>        Currently KeyCloak provides two basic types of
> > > >>>>>        authentication
> > > >>>>>        (correct
> > > >>>>>        me if I'm wrong, please):
> > > >>>>>
> > > >>>>>            1) Local authentication (based on some credential type
> > > >>>>>            enabled
> > > >>>>>            to
> > > >>>>>            a realm)
> > > >>>>>            2) Social authentication
> > > >>>>>
> > > >>>>>        Local authentication is about authenticating the user
> > > >>>>>        locally
> > > >>>>>        using
> > > >>>>>        KC's own identity store. Nothing special here. And Social
> > > >>>>>        Authentication which allows users to choose the Social IdP
> > > >>>>>        they
> > > >>>>>        want
> > > >>>>>        to authenticate with. In this case, the IdP is always one of
> > > >>>>>        the
> > > >>>>>        built-in social providers supported by KC such as Facebook,
> > > >>>>>        Google,
> > > >>>>>        Twitter, Github and so forth.
> > > >>>>>
> > > >>>>>        When doing social, the user is automatically provisioned in
> > > >>>>>        KC
> > > >>>>>        identity store after a successful authentication. The user
> > > >>>>>        does
> > > >>>>>        not
> > > >>>>>        need to fill a registration form and can access the
> > > >>>>>        application
> > > >>>>>        very
> > > >>>>>        quickly. During the provisioning some basic information is
> > > >>>>>        retrieved
> > > >>>>>        from the social provider such as email, firstname and so
> > > >>>>>        forth.
> > > >>>>>        These
> > > >>>>>        are very basic information, any other information such as
> > > >>>>>        those
> > > >>>>>        related with authorization policies - eg.: roles and groups
> > > >>>>>        -
> > > >>>>>        must
> > > >>>>>        be
> > > >>>>>        defined later via KC's admin console.
> > > >>>>>
> > > >>>>>        Another important characteristic of social authentication is
> > > >>>>>        that
> > > >>>>>        the
> > > >>>>>        application receives a KC token and not the token that was
> > > >>>>>        issued by
> > > >>>>>        the social IdP during the authentication process. If the
> > > >>>>>        application
> > > >>>>>        wants to consume resources from the resource provider he was
> > > >>>>>        authenticated it must obtain the access token(again) by
> > > >>>>>        itself
> > > >>>>>        prior
> > > >>>>>        to invoke the resource provider API. Assuming all those
> > > >>>>>        social
> > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > >>>>>
> > > >>>>>        That said, the Authentication Broker functionality aims to
> > > >>>>>        cover
> > > >>>>>        the
> > > >>>>>        same use cases but with a lot of more flexibility on how you
> > > >>>>>        setup
> > > >>>>>        identity providers(not only social ones) and the different
> > > >>>>>        federation
> > > >>>>>        protocols they may support such as SAML, OpenID, oAuth and
> > > >>>>>        so
> > > >>>>>        forth.
> > > >>>>>        This is useful when an enterprise is providing services to
> > > >>>>>        different
> > > >>>>>        customers(IdP) and does not want to manage many to many
> > > >>>>>        relationships. When using a broker, the authentication steps
> > > >>>>>        are
> > > >>>>>        pretty much the same when you are using social
> > > >>>>>        authentication,
> > > >>>>>        with
> > > >>>>>        important differences on how you support different identity
> > > >>>>>        providers, different federation protocols, how users are
> > > >>>>>        provisioned
> > > >>>>>        and how claims and attributes are resolved.
> > > >>>>>
> > > >>>>>        The brokering functionality can be done in two ways
> > > >>>>>        depending
> > > >>>>>        if
> > > >>>>>        the
> > > >>>>>        broker service is acting as a gateway or not. When acting as
> > > >>>>>        a
> > > >>>>>        gateway, the broker will respond to the application the same
> > > >>>>>        token
> > > >>>>>        issued by the trusted identity provider. For instance, if
> > > >>>>>        the
> > > >>>>>        user
> > > >>>>>        selects a SAML IdP to authenticate with, the application
> > > >>>>>        will
> > > >>>>>        receive
> > > >>>>>        a SAML Response. In this case, the application must also be
> > > >>>>>        prepared
> > > >>>>>        to handle a specific federation protocol.
> > > >>>>>
> > > >>>>>        However, the broker service can also be used to completely
> > > >>>>>        abstract
> > > >>>>>        from the application the protocol used to authenticate an
> > > >>>>>        user.
> > > >>>>>        In
> > > >>>>>        this case, the application will just receive an ordinary KC
> > > >>>>>        token
> > > >>>>>        after a successful authentication.
> > > >>>>>
> > > >>>>>        In both cases, the broker acts as an intermediary where
> > > >>>>>        specific
> > > >>>>>        security policies can be applied when users try to
> > > >>>>>        authenticate
> > > >>>>>        themselves against a 3rd party IdP. That brings a lot of
> > > >>>>>        value
> > > >>>>>        when
> > > >>>>>        you think about auditing, authorization and how users are
> > > >>>>>        provisioned
> > > >>>>>        when federation of identities is needed. This also allows
> > > >>>>>        existing
> > > >>>>>        security infrastructures (eg.: SAML-based infrastructures)
> > > >>>>>        to
> > > >>>>>        benefit
> > > >>>>>        from KC's support for cloud, rest and mobile use cases.
> > > >>>>>
> > > >>>>>        I think this is enough to start a discussion. I've an
> > > >>>>>        initial
> > > >>>>>        discussion with Stian about all that and we agreed that
> > > >>>>>        abstract
> > > >>>>>        the
> > > >>>>>        protocol from applications should be prioritized. The main
> > > >>>>>        reason is
> > > >>>>>        that it makes life easier for applications so they only need
> > > >>>>>        to
> > > >>>>>        know
> > > >>>>>        about KC tokens and nothing else. However that brings some
> > > >>>>>        new
> > > >>>>>        requirements around user provisioning and claim/attribute
> > > >>>>>        resolution
> > > >>>>>        or mapping. But that would be another thread.
> > > >>>>>
> > > >>>>
> > > >>>> Can you elaborate on "abstract the protocol from applications"?  Not
> > > >>>> sure what you mean by that.  IDP federation should be configured at
> > > >>>> the
> > > >>>> realm level and really has nothing to do with applications.
> > > >>>>
> > > >>>> I'm really happy that somebody is doing this.  We're getting a real
> > > >>>> impressive feature set!
> > > >>>
> > > >>> Sure. What I meant was that the application only knows about KC
> > > >>> tokens
> > > >>> nothing else. It will always receive a KC token regardless the
> > > >>> protocol
> > > >>> used
> > > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > > >>> whatever).
> > > >>> The
> > > >>> example I gave was about an user trying to authenticate against a
> > > >>> SAML
> > > >>> IdP.
> > > >>> In this case, after a successful authentication on the IdP, the IdP
> > > >>> will
> > > >>> issue a token to KC. Then KC will validate the token, perform trust
> > > >>> and
> > > >>> security checks, do user provisioning and attribute/claim resolution
> > > >>> to
> > > >>> finally issue a KC token and redirect the user to the application. If
> > > >>> the
> > > >>> app is configured to use openid in KC then it will receive a openid
> > > >>> token
> > > >>> from KC, not saml ...
> > > >>>
> > > >>> The other scenario is pretty much the same. The difference is that KC
> > > >>> will
> > > >>> not issue its own token but just replay the token issued by the 3rd
> > > >>> party
> > > >>> IdP to the service provider.
> > > >>>
> > > >>> I agree that this config goes at the realm level. For instance, to
> > > >>> create
> > > >>> and
> > > >>> enable providers for being used. However, I think we would need some
> > > >>> specific configuration for applications as well. Specially when
> > > >>> defining
> > > >>> default roles, mapping attributes. Another example of application
> > > >>> config
> > > >>> is
> > > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > > >>> per-application.
> > > >>>
> > > >>>>
> > > >>>> --
> > > >>>> Bill Burke
> > > >>>> JBoss, a division of Red Hat
> > > >>>> http://bill.burkecentral.com
> > > >>>> _______________________________________________
> > > >>>> keycloak-dev mailing list
> > > >>>> keycloak-dev at lists.jboss.org
> > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>>>
> > > >>> _______________________________________________
> > > >>> 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
> > > 
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From stian at redhat.com  Tue Dec  2 07:23:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 07:23:24 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1709556791.20804905.1417129298254.JavaMail.zimbra@redhat.com>
	<1648216531.22628862.1417519341632.JavaMail.zimbra@redhat.com>
	<732604538.8590377.1417520085671.JavaMail.zimbra@redhat.com>
	<917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>
	<247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>
	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
Message-ID: <1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 1:13:08 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> I'll go for it then. Will remove the icon url from the model and leave that
> for users if they want to provide icons for their identity providers.
> 
> My point is that icons can be usually served by the same server/application
> or proxy, so download images are not such a big deal. Also, the icon url is
> part of the freemarker model and people can do what ever they want with it.
> What I think will also help in your future plans.

I'm not following. Are you saying that if a named image 'my-provider.png' is loaded from a theme, then you can override it in another theme?

If so, that's basically the same as having a css class 'my-provider' in a theme. With the exception that with an image you end up with having to require a image per provider per theme per language, which could be a lot of images for a single provider. Also, buttons for accessibility should be defined with text and css, not images that can't be interpreted. You also still need to modify the theme, so I don't see any benefits.

> 
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, December 2, 2014 10:04:33 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Users can now specify a Icon Url to be rendered on the login page when
> > social
> > or any other identity provider is configured. So we just load the image the
> > url entered by the user.
> > 
> > Are you saying that users should change the theme or customize css if they
> > only want to change an icon for a provider ?
> 
> Yes, there's many issues with having a icon url:
> 
> * Won't work for internationalization - we don't have this now, but we will
> * Image is not a good button - CSS is much better
> * Doesn't support themes - we allow users to switch l&f by switching themes,
> but that won't work for a icon url. In the future we may also support
> multiple themes per-realm, for example to depending on the devices (one
> theme for mobiles, one for desktops, etc)
> * Requires the URL to be hosted somewhere - why require a separate call to
> download an image (to a separate server maybe) if it can simply be defined
> in a single CSS file?
> 
> Rather than add additional places to define look and feel components we
> should in the future make it easier to add/customize themes.
> 
> > 
> > ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > All look and feel related things including images and stylesheets should be
> > part of themes. This is to allow customizing them in the theme. Also, an
> > image is not the correct way to render a button, it should be defined in
> > CSS.
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > You shouldn't have icon images for social providers. They should be
> > > specified
> > > as part of the theme in CSS as is now.
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Bill Burke" <bburke at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Hi,
> > > > 
> > > >     Anyone know where I can get the icons images for social providers ?
> > > >     It
> > > >     seems zocial defines them encoded in some way in CSS. I need that
> > > >     to
> > > >     provide default images if user does not specify their own.
> > > > 
> > > >     Or is still possible to use zocial ones ?
> > > > 
> > > > Regards.
> > > > 
> > > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Bill Burke" <bburke at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Hi guys,
> > > > 
> > > >    I've done some initial work covering both persistence and brokering.
> > > >    No
> > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > >    functionality
> > > >    for now.
> > > > 
> > > >    What I have is enough to decide if we are aligned about this
> > > >    functionality. So you can understand how the model (and
> > > >    persistence),
> > > >    rest api and brokering functionality looks like. Can we schedule a
> > > >    meeting ?
> > > > 
> > > >    Btw, my branch is here [1].
> > > > 
> > > > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > 
> > > > Regards.
> > > > Pedro Igor
> > > > 
> > > > ----- Original Message -----
> > > > From: "Bill Burke" <bburke at redhat.com>
> > > > To: keycloak-dev at lists.jboss.org
> > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Currently adapters can only make authz decisions (@RolesAllowed) based
> > > > on either realm roles or the roles of one specific application.  This
> > > > is
> > > > related to 1) too.
> > > > 
> > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > 1) Sounds like something definitely worth aiming for.
> > > > >
> > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > >> I just wanted to quickly list the additional work we discussed so
> > > > >> everyone
> > > > >> can think about it (in no particular order):
> > > > >>
> > > > >> 1) Mapping of tokens - how do we deal with mapping of an external
> > > > >> token
> > > > >> to
> > > > >> a KC token? For example an external token with attribute 'group'
> > > > >> that
> > > > >> contains 'sales' and 'manager' could be mapped to 'manager' role for
> > > > >> 'sales app in a KC token. Could we use Drools? This could also be
> > > > >> used
> > > > >> in
> > > > >> user federation to allow more complex mapping of roles/groups than a
> > > > >> simple 1-1
> > > > >> 2) Retrieving tokens - if an application wants to retrieve the
> > > > >> external
> > > > >> token (for example to view Facebook friends if user logged in with
> > > > >> Facebook)
> > > > >> 3) Configure scope - currently for social we only request a very
> > > > >> limited
> > > > >> scope (basic profile and email), to for example view Facebook
> > > > >> friends
> > > > >> we'd need to ask for that as well
> > > > >> 4) Selecting provider - currently in social (and for first pass of
> > > > >> brokering) we have an icon user has to select, but can we select the
> > > > >> provider in a different way (for example ask user for email, and
> > > > >> select
> > > > >> based on email domain)
> > > > >> 5) Gateway - don't create a KC token, but just forward the external
> > > > >> token
> > > > >>
> > > > >> IMO 1) is a killer feature, as it would allow companies to add
> > > > >> external
> > > > >> users without having to modify their applications. Issue with 5) is
> > > > >> that
> > > > >> applications need to understand more than one token, which would
> > > > >> require
> > > > >> rewriting applications.
> > > > >>
> > > > >> This work is also somewhat related to other authentication
> > > > >> mechanisms
> > > > >> (for
> > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > >>> Broker
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > >>>> Broker
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > >>>>> Hi,
> > > > >>>>>
> > > > >>>>>        Would like to start a discussion about how to enable KC as
> > > > >>>>>        an
> > > > >>>>>        Authentication Broker in order to supported Chained
> > > > >>>>>        Federation
> > > > >>>>>        and
> > > > >>>>>        also Identity Federation. First of all, some background
> > > > >>>>>        about
> > > > >>>>>        what
> > > > >>>>>        this is all about.
> > > > >>>>>
> > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > >>>>>        authentication
> > > > >>>>>        (correct
> > > > >>>>>        me if I'm wrong, please):
> > > > >>>>>
> > > > >>>>>            1) Local authentication (based on some credential type
> > > > >>>>>            enabled
> > > > >>>>>            to
> > > > >>>>>            a realm)
> > > > >>>>>            2) Social authentication
> > > > >>>>>
> > > > >>>>>        Local authentication is about authenticating the user
> > > > >>>>>        locally
> > > > >>>>>        using
> > > > >>>>>        KC's own identity store. Nothing special here. And Social
> > > > >>>>>        Authentication which allows users to choose the Social IdP
> > > > >>>>>        they
> > > > >>>>>        want
> > > > >>>>>        to authenticate with. In this case, the IdP is always one
> > > > >>>>>        of
> > > > >>>>>        the
> > > > >>>>>        built-in social providers supported by KC such as
> > > > >>>>>        Facebook,
> > > > >>>>>        Google,
> > > > >>>>>        Twitter, Github and so forth.
> > > > >>>>>
> > > > >>>>>        When doing social, the user is automatically provisioned
> > > > >>>>>        in
> > > > >>>>>        KC
> > > > >>>>>        identity store after a successful authentication. The user
> > > > >>>>>        does
> > > > >>>>>        not
> > > > >>>>>        need to fill a registration form and can access the
> > > > >>>>>        application
> > > > >>>>>        very
> > > > >>>>>        quickly. During the provisioning some basic information is
> > > > >>>>>        retrieved
> > > > >>>>>        from the social provider such as email, firstname and so
> > > > >>>>>        forth.
> > > > >>>>>        These
> > > > >>>>>        are very basic information, any other information such as
> > > > >>>>>        those
> > > > >>>>>        related with authorization policies - eg.: roles and
> > > > >>>>>        groups
> > > > >>>>>        -
> > > > >>>>>        must
> > > > >>>>>        be
> > > > >>>>>        defined later via KC's admin console.
> > > > >>>>>
> > > > >>>>>        Another important characteristic of social authentication
> > > > >>>>>        is
> > > > >>>>>        that
> > > > >>>>>        the
> > > > >>>>>        application receives a KC token and not the token that was
> > > > >>>>>        issued by
> > > > >>>>>        the social IdP during the authentication process. If the
> > > > >>>>>        application
> > > > >>>>>        wants to consume resources from the resource provider he
> > > > >>>>>        was
> > > > >>>>>        authenticated it must obtain the access token(again) by
> > > > >>>>>        itself
> > > > >>>>>        prior
> > > > >>>>>        to invoke the resource provider API. Assuming all those
> > > > >>>>>        social
> > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > >>>>>
> > > > >>>>>        That said, the Authentication Broker functionality aims to
> > > > >>>>>        cover
> > > > >>>>>        the
> > > > >>>>>        same use cases but with a lot of more flexibility on how
> > > > >>>>>        you
> > > > >>>>>        setup
> > > > >>>>>        identity providers(not only social ones) and the different
> > > > >>>>>        federation
> > > > >>>>>        protocols they may support such as SAML, OpenID, oAuth and
> > > > >>>>>        so
> > > > >>>>>        forth.
> > > > >>>>>        This is useful when an enterprise is providing services to
> > > > >>>>>        different
> > > > >>>>>        customers(IdP) and does not want to manage many to many
> > > > >>>>>        relationships. When using a broker, the authentication
> > > > >>>>>        steps
> > > > >>>>>        are
> > > > >>>>>        pretty much the same when you are using social
> > > > >>>>>        authentication,
> > > > >>>>>        with
> > > > >>>>>        important differences on how you support different
> > > > >>>>>        identity
> > > > >>>>>        providers, different federation protocols, how users are
> > > > >>>>>        provisioned
> > > > >>>>>        and how claims and attributes are resolved.
> > > > >>>>>
> > > > >>>>>        The brokering functionality can be done in two ways
> > > > >>>>>        depending
> > > > >>>>>        if
> > > > >>>>>        the
> > > > >>>>>        broker service is acting as a gateway or not. When acting
> > > > >>>>>        as
> > > > >>>>>        a
> > > > >>>>>        gateway, the broker will respond to the application the
> > > > >>>>>        same
> > > > >>>>>        token
> > > > >>>>>        issued by the trusted identity provider. For instance, if
> > > > >>>>>        the
> > > > >>>>>        user
> > > > >>>>>        selects a SAML IdP to authenticate with, the application
> > > > >>>>>        will
> > > > >>>>>        receive
> > > > >>>>>        a SAML Response. In this case, the application must also
> > > > >>>>>        be
> > > > >>>>>        prepared
> > > > >>>>>        to handle a specific federation protocol.
> > > > >>>>>
> > > > >>>>>        However, the broker service can also be used to completely
> > > > >>>>>        abstract
> > > > >>>>>        from the application the protocol used to authenticate an
> > > > >>>>>        user.
> > > > >>>>>        In
> > > > >>>>>        this case, the application will just receive an ordinary
> > > > >>>>>        KC
> > > > >>>>>        token
> > > > >>>>>        after a successful authentication.
> > > > >>>>>
> > > > >>>>>        In both cases, the broker acts as an intermediary where
> > > > >>>>>        specific
> > > > >>>>>        security policies can be applied when users try to
> > > > >>>>>        authenticate
> > > > >>>>>        themselves against a 3rd party IdP. That brings a lot of
> > > > >>>>>        value
> > > > >>>>>        when
> > > > >>>>>        you think about auditing, authorization and how users are
> > > > >>>>>        provisioned
> > > > >>>>>        when federation of identities is needed. This also allows
> > > > >>>>>        existing
> > > > >>>>>        security infrastructures (eg.: SAML-based infrastructures)
> > > > >>>>>        to
> > > > >>>>>        benefit
> > > > >>>>>        from KC's support for cloud, rest and mobile use cases.
> > > > >>>>>
> > > > >>>>>        I think this is enough to start a discussion. I've an
> > > > >>>>>        initial
> > > > >>>>>        discussion with Stian about all that and we agreed that
> > > > >>>>>        abstract
> > > > >>>>>        the
> > > > >>>>>        protocol from applications should be prioritized. The main
> > > > >>>>>        reason is
> > > > >>>>>        that it makes life easier for applications so they only
> > > > >>>>>        need
> > > > >>>>>        to
> > > > >>>>>        know
> > > > >>>>>        about KC tokens and nothing else. However that brings some
> > > > >>>>>        new
> > > > >>>>>        requirements around user provisioning and claim/attribute
> > > > >>>>>        resolution
> > > > >>>>>        or mapping. But that would be another thread.
> > > > >>>>>
> > > > >>>>
> > > > >>>> Can you elaborate on "abstract the protocol from applications"?
> > > > >>>> Not
> > > > >>>> sure what you mean by that.  IDP federation should be configured
> > > > >>>> at
> > > > >>>> the
> > > > >>>> realm level and really has nothing to do with applications.
> > > > >>>>
> > > > >>>> I'm really happy that somebody is doing this.  We're getting a
> > > > >>>> real
> > > > >>>> impressive feature set!
> > > > >>>
> > > > >>> Sure. What I meant was that the application only knows about KC
> > > > >>> tokens
> > > > >>> nothing else. It will always receive a KC token regardless the
> > > > >>> protocol
> > > > >>> used
> > > > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > > > >>> whatever).
> > > > >>> The
> > > > >>> example I gave was about an user trying to authenticate against a
> > > > >>> SAML
> > > > >>> IdP.
> > > > >>> In this case, after a successful authentication on the IdP, the IdP
> > > > >>> will
> > > > >>> issue a token to KC. Then KC will validate the token, perform trust
> > > > >>> and
> > > > >>> security checks, do user provisioning and attribute/claim
> > > > >>> resolution
> > > > >>> to
> > > > >>> finally issue a KC token and redirect the user to the application.
> > > > >>> If
> > > > >>> the
> > > > >>> app is configured to use openid in KC then it will receive a openid
> > > > >>> token
> > > > >>> from KC, not saml ...
> > > > >>>
> > > > >>> The other scenario is pretty much the same. The difference is that
> > > > >>> KC
> > > > >>> will
> > > > >>> not issue its own token but just replay the token issued by the 3rd
> > > > >>> party
> > > > >>> IdP to the service provider.
> > > > >>>
> > > > >>> I agree that this config goes at the realm level. For instance, to
> > > > >>> create
> > > > >>> and
> > > > >>> enable providers for being used. However, I think we would need
> > > > >>> some
> > > > >>> specific configuration for applications as well. Specially when
> > > > >>> defining
> > > > >>> default roles, mapping attributes. Another example of application
> > > > >>> config
> > > > >>> is
> > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > > > >>> per-application.
> > > > >>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> Bill Burke
> > > > >>>> JBoss, a division of Red Hat
> > > > >>>> http://bill.burkecentral.com
> > > > >>>> _______________________________________________
> > > > >>>> keycloak-dev mailing list
> > > > >>>> keycloak-dev at lists.jboss.org
> > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >>>>
> > > > >>> _______________________________________________
> > > > >>> 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
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 


From psilva at redhat.com  Tue Dec  2 07:42:11 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 2 Dec 2014 07:42:11 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1648216531.22628862.1417519341632.JavaMail.zimbra@redhat.com>
	<732604538.8590377.1417520085671.JavaMail.zimbra@redhat.com>
	<917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>
	<247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>
	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
Message-ID: <1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, December 2, 2014 10:23:24 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > I'll go for it then. Will remove the icon url from the model and leave that
> > for users if they want to provide icons for their identity providers.
> > 
> > My point is that icons can be usually served by the same server/application
> > or proxy, so download images are not such a big deal. Also, the icon url is
> > part of the freemarker model and people can do what ever they want with it.
> > What I think will also help in your future plans.
> 
> I'm not following. Are you saying that if a named image 'my-provider.png' is
> loaded from a theme, then you can override it in another theme?
> 
> If so, that's basically the same as having a css class 'my-provider' in a
> theme. With the exception that with an image you end up with having to
> require a image per provider per theme per language, which could be a lot of
> images for a single provider. Also, buttons for accessibility should be
> defined with text and css, not images that can't be interpreted. You also
> still need to modify the theme, so I don't see any benefits.

You are right. Having a icon url per provider does not makes sense if there are requirements to change images accordingly to a theme or language. CSS makes life easier.

Will remove that property from the model.

> 
> > 
> > ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Users can now specify a Icon Url to be rendered on the login page when
> > > social
> > > or any other identity provider is configured. So we just load the image
> > > the
> > > url entered by the user.
> > > 
> > > Are you saying that users should change the theme or customize css if
> > > they
> > > only want to change an icon for a provider ?
> > 
> > Yes, there's many issues with having a icon url:
> > 
> > * Won't work for internationalization - we don't have this now, but we will
> > * Image is not a good button - CSS is much better
> > * Doesn't support themes - we allow users to switch l&f by switching
> > themes,
> > but that won't work for a icon url. In the future we may also support
> > multiple themes per-realm, for example to depending on the devices (one
> > theme for mobiles, one for desktops, etc)
> > * Requires the URL to be hosted somewhere - why require a separate call to
> > download an image (to a separate server maybe) if it can simply be defined
> > in a single CSS file?
> > 
> > Rather than add additional places to define look and feel components we
> > should in the future make it easier to add/customize themes.
> > 
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > All look and feel related things including images and stylesheets should
> > > be
> > > part of themes. This is to allow customizing them in the theme. Also, an
> > > image is not the correct way to render a button, it should be defined in
> > > CSS.
> > > 
> > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > You shouldn't have icon images for social providers. They should be
> > > > specified
> > > > as part of the theme in CSS as is now.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Hi,
> > > > > 
> > > > >     Anyone know where I can get the icons images for social providers
> > > > >     ?
> > > > >     It
> > > > >     seems zocial defines them encoded in some way in CSS. I need that
> > > > >     to
> > > > >     provide default images if user does not specify their own.
> > > > > 
> > > > >     Or is still possible to use zocial ones ?
> > > > > 
> > > > > Regards.
> > > > > 
> > > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Hi guys,
> > > > > 
> > > > >    I've done some initial work covering both persistence and
> > > > >    brokering.
> > > > >    No
> > > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > > >    functionality
> > > > >    for now.
> > > > > 
> > > > >    What I have is enough to decide if we are aligned about this
> > > > >    functionality. So you can understand how the model (and
> > > > >    persistence),
> > > > >    rest api and brokering functionality looks like. Can we schedule a
> > > > >    meeting ?
> > > > > 
> > > > >    Btw, my branch is here [1].
> > > > > 
> > > > > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > 
> > > > > Regards.
> > > > > Pedro Igor
> > > > > 
> > > > > ----- Original Message -----
> > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > To: keycloak-dev at lists.jboss.org
> > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Currently adapters can only make authz decisions (@RolesAllowed)
> > > > > based
> > > > > on either realm roles or the roles of one specific application.  This
> > > > > is
> > > > > related to 1) too.
> > > > > 
> > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > >
> > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > >> I just wanted to quickly list the additional work we discussed so
> > > > > >> everyone
> > > > > >> can think about it (in no particular order):
> > > > > >>
> > > > > >> 1) Mapping of tokens - how do we deal with mapping of an external
> > > > > >> token
> > > > > >> to
> > > > > >> a KC token? For example an external token with attribute 'group'
> > > > > >> that
> > > > > >> contains 'sales' and 'manager' could be mapped to 'manager' role
> > > > > >> for
> > > > > >> 'sales app in a KC token. Could we use Drools? This could also be
> > > > > >> used
> > > > > >> in
> > > > > >> user federation to allow more complex mapping of roles/groups than
> > > > > >> a
> > > > > >> simple 1-1
> > > > > >> 2) Retrieving tokens - if an application wants to retrieve the
> > > > > >> external
> > > > > >> token (for example to view Facebook friends if user logged in with
> > > > > >> Facebook)
> > > > > >> 3) Configure scope - currently for social we only request a very
> > > > > >> limited
> > > > > >> scope (basic profile and email), to for example view Facebook
> > > > > >> friends
> > > > > >> we'd need to ask for that as well
> > > > > >> 4) Selecting provider - currently in social (and for first pass of
> > > > > >> brokering) we have an icon user has to select, but can we select
> > > > > >> the
> > > > > >> provider in a different way (for example ask user for email, and
> > > > > >> select
> > > > > >> based on email domain)
> > > > > >> 5) Gateway - don't create a KC token, but just forward the
> > > > > >> external
> > > > > >> token
> > > > > >>
> > > > > >> IMO 1) is a killer feature, as it would allow companies to add
> > > > > >> external
> > > > > >> users without having to modify their applications. Issue with 5)
> > > > > >> is
> > > > > >> that
> > > > > >> applications need to understand more than one token, which would
> > > > > >> require
> > > > > >> rewriting applications.
> > > > > >>
> > > > > >> This work is also somewhat related to other authentication
> > > > > >> mechanisms
> > > > > >> (for
> > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > >>> Broker
> > > > > >>>
> > > > > >>> ----- Original Message -----
> > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > >>>> Authentication
> > > > > >>>> Broker
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > >>>>> Hi,
> > > > > >>>>>
> > > > > >>>>>        Would like to start a discussion about how to enable KC
> > > > > >>>>>        as
> > > > > >>>>>        an
> > > > > >>>>>        Authentication Broker in order to supported Chained
> > > > > >>>>>        Federation
> > > > > >>>>>        and
> > > > > >>>>>        also Identity Federation. First of all, some background
> > > > > >>>>>        about
> > > > > >>>>>        what
> > > > > >>>>>        this is all about.
> > > > > >>>>>
> > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > >>>>>        authentication
> > > > > >>>>>        (correct
> > > > > >>>>>        me if I'm wrong, please):
> > > > > >>>>>
> > > > > >>>>>            1) Local authentication (based on some credential
> > > > > >>>>>            type
> > > > > >>>>>            enabled
> > > > > >>>>>            to
> > > > > >>>>>            a realm)
> > > > > >>>>>            2) Social authentication
> > > > > >>>>>
> > > > > >>>>>        Local authentication is about authenticating the user
> > > > > >>>>>        locally
> > > > > >>>>>        using
> > > > > >>>>>        KC's own identity store. Nothing special here. And
> > > > > >>>>>        Social
> > > > > >>>>>        Authentication which allows users to choose the Social
> > > > > >>>>>        IdP
> > > > > >>>>>        they
> > > > > >>>>>        want
> > > > > >>>>>        to authenticate with. In this case, the IdP is always
> > > > > >>>>>        one
> > > > > >>>>>        of
> > > > > >>>>>        the
> > > > > >>>>>        built-in social providers supported by KC such as
> > > > > >>>>>        Facebook,
> > > > > >>>>>        Google,
> > > > > >>>>>        Twitter, Github and so forth.
> > > > > >>>>>
> > > > > >>>>>        When doing social, the user is automatically provisioned
> > > > > >>>>>        in
> > > > > >>>>>        KC
> > > > > >>>>>        identity store after a successful authentication. The
> > > > > >>>>>        user
> > > > > >>>>>        does
> > > > > >>>>>        not
> > > > > >>>>>        need to fill a registration form and can access the
> > > > > >>>>>        application
> > > > > >>>>>        very
> > > > > >>>>>        quickly. During the provisioning some basic information
> > > > > >>>>>        is
> > > > > >>>>>        retrieved
> > > > > >>>>>        from the social provider such as email, firstname and so
> > > > > >>>>>        forth.
> > > > > >>>>>        These
> > > > > >>>>>        are very basic information, any other information such
> > > > > >>>>>        as
> > > > > >>>>>        those
> > > > > >>>>>        related with authorization policies - eg.: roles and
> > > > > >>>>>        groups
> > > > > >>>>>        -
> > > > > >>>>>        must
> > > > > >>>>>        be
> > > > > >>>>>        defined later via KC's admin console.
> > > > > >>>>>
> > > > > >>>>>        Another important characteristic of social
> > > > > >>>>>        authentication
> > > > > >>>>>        is
> > > > > >>>>>        that
> > > > > >>>>>        the
> > > > > >>>>>        application receives a KC token and not the token that
> > > > > >>>>>        was
> > > > > >>>>>        issued by
> > > > > >>>>>        the social IdP during the authentication process. If the
> > > > > >>>>>        application
> > > > > >>>>>        wants to consume resources from the resource provider he
> > > > > >>>>>        was
> > > > > >>>>>        authenticated it must obtain the access token(again) by
> > > > > >>>>>        itself
> > > > > >>>>>        prior
> > > > > >>>>>        to invoke the resource provider API. Assuming all those
> > > > > >>>>>        social
> > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > >>>>>
> > > > > >>>>>        That said, the Authentication Broker functionality aims
> > > > > >>>>>        to
> > > > > >>>>>        cover
> > > > > >>>>>        the
> > > > > >>>>>        same use cases but with a lot of more flexibility on how
> > > > > >>>>>        you
> > > > > >>>>>        setup
> > > > > >>>>>        identity providers(not only social ones) and the
> > > > > >>>>>        different
> > > > > >>>>>        federation
> > > > > >>>>>        protocols they may support such as SAML, OpenID, oAuth
> > > > > >>>>>        and
> > > > > >>>>>        so
> > > > > >>>>>        forth.
> > > > > >>>>>        This is useful when an enterprise is providing services
> > > > > >>>>>        to
> > > > > >>>>>        different
> > > > > >>>>>        customers(IdP) and does not want to manage many to many
> > > > > >>>>>        relationships. When using a broker, the authentication
> > > > > >>>>>        steps
> > > > > >>>>>        are
> > > > > >>>>>        pretty much the same when you are using social
> > > > > >>>>>        authentication,
> > > > > >>>>>        with
> > > > > >>>>>        important differences on how you support different
> > > > > >>>>>        identity
> > > > > >>>>>        providers, different federation protocols, how users are
> > > > > >>>>>        provisioned
> > > > > >>>>>        and how claims and attributes are resolved.
> > > > > >>>>>
> > > > > >>>>>        The brokering functionality can be done in two ways
> > > > > >>>>>        depending
> > > > > >>>>>        if
> > > > > >>>>>        the
> > > > > >>>>>        broker service is acting as a gateway or not. When
> > > > > >>>>>        acting
> > > > > >>>>>        as
> > > > > >>>>>        a
> > > > > >>>>>        gateway, the broker will respond to the application the
> > > > > >>>>>        same
> > > > > >>>>>        token
> > > > > >>>>>        issued by the trusted identity provider. For instance,
> > > > > >>>>>        if
> > > > > >>>>>        the
> > > > > >>>>>        user
> > > > > >>>>>        selects a SAML IdP to authenticate with, the application
> > > > > >>>>>        will
> > > > > >>>>>        receive
> > > > > >>>>>        a SAML Response. In this case, the application must also
> > > > > >>>>>        be
> > > > > >>>>>        prepared
> > > > > >>>>>        to handle a specific federation protocol.
> > > > > >>>>>
> > > > > >>>>>        However, the broker service can also be used to
> > > > > >>>>>        completely
> > > > > >>>>>        abstract
> > > > > >>>>>        from the application the protocol used to authenticate
> > > > > >>>>>        an
> > > > > >>>>>        user.
> > > > > >>>>>        In
> > > > > >>>>>        this case, the application will just receive an ordinary
> > > > > >>>>>        KC
> > > > > >>>>>        token
> > > > > >>>>>        after a successful authentication.
> > > > > >>>>>
> > > > > >>>>>        In both cases, the broker acts as an intermediary where
> > > > > >>>>>        specific
> > > > > >>>>>        security policies can be applied when users try to
> > > > > >>>>>        authenticate
> > > > > >>>>>        themselves against a 3rd party IdP. That brings a lot of
> > > > > >>>>>        value
> > > > > >>>>>        when
> > > > > >>>>>        you think about auditing, authorization and how users
> > > > > >>>>>        are
> > > > > >>>>>        provisioned
> > > > > >>>>>        when federation of identities is needed. This also
> > > > > >>>>>        allows
> > > > > >>>>>        existing
> > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > >>>>>        infrastructures)
> > > > > >>>>>        to
> > > > > >>>>>        benefit
> > > > > >>>>>        from KC's support for cloud, rest and mobile use cases.
> > > > > >>>>>
> > > > > >>>>>        I think this is enough to start a discussion. I've an
> > > > > >>>>>        initial
> > > > > >>>>>        discussion with Stian about all that and we agreed that
> > > > > >>>>>        abstract
> > > > > >>>>>        the
> > > > > >>>>>        protocol from applications should be prioritized. The
> > > > > >>>>>        main
> > > > > >>>>>        reason is
> > > > > >>>>>        that it makes life easier for applications so they only
> > > > > >>>>>        need
> > > > > >>>>>        to
> > > > > >>>>>        know
> > > > > >>>>>        about KC tokens and nothing else. However that brings
> > > > > >>>>>        some
> > > > > >>>>>        new
> > > > > >>>>>        requirements around user provisioning and
> > > > > >>>>>        claim/attribute
> > > > > >>>>>        resolution
> > > > > >>>>>        or mapping. But that would be another thread.
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> Can you elaborate on "abstract the protocol from applications"?
> > > > > >>>> Not
> > > > > >>>> sure what you mean by that.  IDP federation should be configured
> > > > > >>>> at
> > > > > >>>> the
> > > > > >>>> realm level and really has nothing to do with applications.
> > > > > >>>>
> > > > > >>>> I'm really happy that somebody is doing this.  We're getting a
> > > > > >>>> real
> > > > > >>>> impressive feature set!
> > > > > >>>
> > > > > >>> Sure. What I meant was that the application only knows about KC
> > > > > >>> tokens
> > > > > >>> nothing else. It will always receive a KC token regardless the
> > > > > >>> protocol
> > > > > >>> used
> > > > > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > > > > >>> whatever).
> > > > > >>> The
> > > > > >>> example I gave was about an user trying to authenticate against a
> > > > > >>> SAML
> > > > > >>> IdP.
> > > > > >>> In this case, after a successful authentication on the IdP, the
> > > > > >>> IdP
> > > > > >>> will
> > > > > >>> issue a token to KC. Then KC will validate the token, perform
> > > > > >>> trust
> > > > > >>> and
> > > > > >>> security checks, do user provisioning and attribute/claim
> > > > > >>> resolution
> > > > > >>> to
> > > > > >>> finally issue a KC token and redirect the user to the
> > > > > >>> application.
> > > > > >>> If
> > > > > >>> the
> > > > > >>> app is configured to use openid in KC then it will receive a
> > > > > >>> openid
> > > > > >>> token
> > > > > >>> from KC, not saml ...
> > > > > >>>
> > > > > >>> The other scenario is pretty much the same. The difference is
> > > > > >>> that
> > > > > >>> KC
> > > > > >>> will
> > > > > >>> not issue its own token but just replay the token issued by the
> > > > > >>> 3rd
> > > > > >>> party
> > > > > >>> IdP to the service provider.
> > > > > >>>
> > > > > >>> I agree that this config goes at the realm level. For instance,
> > > > > >>> to
> > > > > >>> create
> > > > > >>> and
> > > > > >>> enable providers for being used. However, I think we would need
> > > > > >>> some
> > > > > >>> specific configuration for applications as well. Specially when
> > > > > >>> defining
> > > > > >>> default roles, mapping attributes. Another example of application
> > > > > >>> config
> > > > > >>> is
> > > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > > > > >>> per-application.
> > > > > >>>
> > > > > >>>>
> > > > > >>>> --
> > > > > >>>> Bill Burke
> > > > > >>>> JBoss, a division of Red Hat
> > > > > >>>> http://bill.burkecentral.com
> > > > > >>>> _______________________________________________
> > > > > >>>> keycloak-dev mailing list
> > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > >>>>
> > > > > >>> _______________________________________________
> > > > > >>> 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
> > > > > 
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > 
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 


From ssilvert at redhat.com  Tue Dec  2 07:55:03 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 02 Dec 2014 07:55:03 -0500
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com> <547C8F0B.4060904@redhat.com>
	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
Message-ID: <547DB6A7.8040200@redhat.com>

On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
> Should we upgrade to WF 8.2 and also do some changes to the distro before release?
I don't see a reason not to go to WF 8.2.  If we do that, let me know so 
I can run a quick smoke test on the subsystem before we release.
>
> With regards to distro we should move the adapters and examples into separate downloads. Also, we should move the examples into a separate github project (keycloak/keycloak-examples). This will make it easier for those that wants to fork the examples separately.
>
> Also, we should consider a download based on the web-lite profile. For non-JavaEE apps, containers (Docker) and those that want to run a standalone KC server it would be nice to have a small as possible distro.
Depending on how the feature pack turns out, we might be able to offer 
many flavors of the appliance distro without any additional effort.  We 
could have:
EAP6 + Keycloak
AS7 + Keycloak
WF8 (web) + Keycloak
WF8 (full) + Keycloak
WF 9 beta (web) + Keycloak
WF 9 beta (full) + Keycloak
etc.

I wonder, should we do that?  We need to think about how the world looks 
now that a componentized server becomes a reality.
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 1 December, 2014 4:53:47 PM
>> Subject: Re: [keycloak-dev] release?  Stan?
>>
>> On 12/1/2014 10:08 AM, Bill Burke wrote:
>>> So, is EAP subsystem complete?  Documented?  Can we do a Beta2 release
>>> this week?
>>>
>>>
>> Yes.  All merged.  Docs are updated.  Should be ready to go.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Tue Dec  2 08:38:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Dec 2014 08:38:32 -0500
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547DB6A7.8040200@redhat.com>
References: <547C8466.4050103@redhat.com>
	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
	<547DB6A7.8040200@redhat.com>
Message-ID: <547DC0D8.9000404@redhat.com>



On 12/2/2014 7:55 AM, Stan Silvert wrote:
> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>> Should we upgrade to WF 8.2 and also do some changes to the distro before release?
> I don't see a reason not to go to WF 8.2.  If we do that, let me know so
> I can run a quick smoke test on the subsystem before we release.
>>
>> With regards to distro we should move the adapters and examples into separate downloads. Also, we should move the examples into a separate github project (keycloak/keycloak-examples). This will make it easier for those that wants to fork the examples separately.
>>
>> Also, we should consider a download based on the web-lite profile. For non-JavaEE apps, containers (Docker) and those that want to run a standalone KC server it would be nice to have a small as possible distro.
> Depending on how the feature pack turns out, we might be able to offer
> many flavors of the appliance distro without any additional effort.  We
> could have:
> EAP6 + Keycloak
> AS7 + Keycloak
> WF8 (web) + Keycloak
> WF8 (full) + Keycloak
> WF 9 beta (web) + Keycloak
> WF 9 beta (full) + Keycloak
> etc.
>

IMO, we just need:
* war-dist
* appliance-dist

Appliance distribution would have the most stable platform available. 
Since we can't distribute EAP, then it would be the most stable and 
maintained version of Wildfly that allows us to cluster and deploy Keycloak.


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

From stian at redhat.com  Tue Dec  2 09:02:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 09:02:02 -0500 (EST)
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547DC0D8.9000404@redhat.com>
References: <547C8466.4050103@redhat.com> <547C8F0B.4060904@redhat.com>
	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
	<547DB6A7.8040200@redhat.com> <547DC0D8.9000404@redhat.com>
Message-ID: <2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 2:38:32 PM
> Subject: Re: [keycloak-dev] release?  Stan?
> 
> 
> 
> On 12/2/2014 7:55 AM, Stan Silvert wrote:
> > On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
> >> Should we upgrade to WF 8.2 and also do some changes to the distro before
> >> release?
> > I don't see a reason not to go to WF 8.2.  If we do that, let me know so
> > I can run a quick smoke test on the subsystem before we release.
> >>
> >> With regards to distro we should move the adapters and examples into
> >> separate downloads. Also, we should move the examples into a separate
> >> github project (keycloak/keycloak-examples). This will make it easier for
> >> those that wants to fork the examples separately.
> >>
> >> Also, we should consider a download based on the web-lite profile. For
> >> non-JavaEE apps, containers (Docker) and those that want to run a
> >> standalone KC server it would be nice to have a small as possible distro.
> > Depending on how the feature pack turns out, we might be able to offer
> > many flavors of the appliance distro without any additional effort.  We
> > could have:
> > EAP6 + Keycloak
> > AS7 + Keycloak
> > WF8 (web) + Keycloak
> > WF8 (full) + Keycloak
> > WF 9 beta (web) + Keycloak
> > WF 9 beta (full) + Keycloak
> > etc.
> >
> 
> IMO, we just need:
> * war-dist
> * appliance-dist
> 
> Appliance distribution would have the most stable platform available.
> Since we can't distribute EAP, then it would be the most stable and
> maintained version of Wildfly that allows us to cluster and deploy Keycloak.

Our download at the moment is 160MB and is really aimed at the first-time JavaEE user (bundled with examples and documentation). Why should we require someone that just wants to upgrade their server to download all of that? There'll also be loads of people that don't need the JavaEE parts, a NodeJS developer or deploying to cloud for example. I think we could easily have a standalone Keycloak server download that'd be around 30MB.

IMO we should have:

* Minimal server (based on WildFly web/core)
* Full server (based on WildFly full)
* Feature pack - to easily install onto other version of WF, EAP, etc.

Neither of those downloads should include docs or examples. As we don't really support installing onto Tomcat or Jetty, why have a war-dist?

> 
> 
> --
> 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 alain at rexorient.com  Tue Dec  2 09:04:50 2014
From: alain at rexorient.com (Alain Penders)
Date: Tue, 2 Dec 2014 07:04:50 -0700
Subject: [keycloak-dev] Fwd: Preflight for token refresh
In-Reply-To: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>
References: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>
Message-ID: <CAMtP742bwv57MmMnBjwH7hJZrGFWThO_dGsFK_oUp_mz-JW9xw@mail.gmail.com>

Hi all,

I'm building a new app using GWT 2.7 using the Keycloak javascript adapter
and GWT jsInterop. This works extremely well.

The problem I ran into is if I walk away for 5 minutes and then try to do
something, the token refresh fails on preflight.   As shown in the
documentation, I call keycloak.updateToken(30) to refresh the base token in
case it has expired.  Since in this case it has indeed expired, keycloak
makes a call to /auth/realms/<myrealm>/tokens/refresh.    The OPTIONS call
to this location doesn't contain the Accept headers, and my app ends up
dead in the water.

To fix this, I added the following code to OpenIDConnectService:

/**
 * CORS preflight path for refresh token requests
 *
 * @return
 */
@Path("refresh")
@OPTIONS
@Produces(MediaType.APPLICATION_JSON)
public Response refreshAccessTokenPreflight() {
    if (logger.isDebugEnabled()) {
        logger.debugv("cors request from: {0}",
request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
    }
    return Cors.add(request, Response.ok()).auth().preflight().build();
}

If this wasn't the correct solution for my problem, I'd enjoy hearing where
I went wrong.

Thanks,
Alain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141202/b7b577b4/attachment.html 

From stian at redhat.com  Tue Dec  2 09:32:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 09:32:21 -0500 (EST)
Subject: [keycloak-dev] Fwd: Preflight for token refresh
In-Reply-To: <CAMtP742bwv57MmMnBjwH7hJZrGFWThO_dGsFK_oUp_mz-JW9xw@mail.gmail.com>
References: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>
	<CAMtP742bwv57MmMnBjwH7hJZrGFWThO_dGsFK_oUp_mz-JW9xw@mail.gmail.com>
Message-ID: <1967599145.8787926.1417530741784.JavaMail.zimbra@redhat.com>

It's the correct approach to add the preflight. Please send a PR and we'll merge it.

Out of curiosity do you know why it's sending a preflight in your app? It doesn't when I test it out here, which AFAIK is correct according to spec (content-type is application/x-www-form-urlencoded and there's no custom headers set).

----- Original Message -----
> From: "Alain Penders" <alain at rexorient.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 3:04:50 PM
> Subject: [keycloak-dev] Fwd: Preflight for token refresh
> 
> Hi all,
> 
> I'm building a new app using GWT 2.7 using the Keycloak javascript adapter
> and GWT jsInterop. This works extremely well.
> 
> The problem I ran into is if I walk away for 5 minutes and then try to do
> something, the token refresh fails on preflight. As shown in the
> documentation, I call keycloak.updateToken(30) to refresh the base token in
> case it has expired. Since in this case it has indeed expired, keycloak
> makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS call to
> this location doesn't contain the Accept headers, and my app ends up dead in
> the water.
> 
> To fix this, I added the following code to OpenIDConnectService:
> 
> /**
> * CORS preflight path for refresh token requests
> *
> * @return
> */
> @Path("refresh")
> @OPTIONS
> @Produces(MediaType.APPLICATION_JSON)
> public Response refreshAccessTokenPreflight() {
> if (logger.isDebugEnabled()) {
> logger.debugv("cors request from: {0}",
> request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> }
> return Cors.add(request, Response.ok()).auth().preflight().build();
> }
> 
> If this wasn't the correct solution for my problem, I'd enjoy hearing where I
> went wrong.
> 
> Thanks,
> Alain
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From alain at rexorient.com  Tue Dec  2 09:43:13 2014
From: alain at rexorient.com (Alain Penders)
Date: Tue, 2 Dec 2014 07:43:13 -0700
Subject: [keycloak-dev] Fwd: Preflight for token refresh
In-Reply-To: <1967599145.8787926.1417530741784.JavaMail.zimbra@redhat.com>
References: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>
	<CAMtP742bwv57MmMnBjwH7hJZrGFWThO_dGsFK_oUp_mz-JW9xw@mail.gmail.com>
	<1967599145.8787926.1417530741784.JavaMail.zimbra@redhat.com>
Message-ID: <CAMtP742pazk9OrG90J9tL1aMMfWib4aK9h4EkTO-ARFpn0N=VA@mail.gmail.com>

I'm testing my UI using GWTs Super Dev Mode, which means its origin is set
to http://127.0.0.1:8888.    Keycloak runs on http://127.0.0.1:8080/auth.

On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian at redhat.com> wrote:

> It's the correct approach to add the preflight. Please send a PR and we'll
> merge it.
>
> Out of curiosity do you know why it's sending a preflight in your app? It
> doesn't when I test it out here, which AFAIK is correct according to spec
> (content-type is application/x-www-form-urlencoded and there's no custom
> headers set).
>
> ----- Original Message -----
> > From: "Alain Penders" <alain at rexorient.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 3:04:50 PM
> > Subject: [keycloak-dev] Fwd: Preflight for token refresh
> >
> > Hi all,
> >
> > I'm building a new app using GWT 2.7 using the Keycloak javascript
> adapter
> > and GWT jsInterop. This works extremely well.
> >
> > The problem I ran into is if I walk away for 5 minutes and then try to do
> > something, the token refresh fails on preflight. As shown in the
> > documentation, I call keycloak.updateToken(30) to refresh the base token
> in
> > case it has expired. Since in this case it has indeed expired, keycloak
> > makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS call
> to
> > this location doesn't contain the Accept headers, and my app ends up
> dead in
> > the water.
> >
> > To fix this, I added the following code to OpenIDConnectService:
> >
> > /**
> > * CORS preflight path for refresh token requests
> > *
> > * @return
> > */
> > @Path("refresh")
> > @OPTIONS
> > @Produces(MediaType.APPLICATION_JSON)
> > public Response refreshAccessTokenPreflight() {
> > if (logger.isDebugEnabled()) {
> > logger.debugv("cors request from: {0}",
> > request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> > }
> > return Cors.add(request, Response.ok()).auth().preflight().build();
> > }
> >
> > If this wasn't the correct solution for my problem, I'd enjoy hearing
> where I
> > went wrong.
> >
> > Thanks,
> > Alain
> >
> >
> > _______________________________________________
> > 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/20141202/cde00ee4/attachment.html 

From stian at redhat.com  Tue Dec  2 09:49:28 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 09:49:28 -0500 (EST)
Subject: [keycloak-dev] Fwd: Preflight for token refresh
In-Reply-To: <CAMtP742pazk9OrG90J9tL1aMMfWib4aK9h4EkTO-ARFpn0N=VA@mail.gmail.com>
References: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>
	<CAMtP742bwv57MmMnBjwH7hJZrGFWThO_dGsFK_oUp_mz-JW9xw@mail.gmail.com>
	<1967599145.8787926.1417530741784.JavaMail.zimbra@redhat.com>
	<CAMtP742pazk9OrG90J9tL1aMMfWib4aK9h4EkTO-ARFpn0N=VA@mail.gmail.com>
Message-ID: <1932903918.8811689.1417531768234.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Alain Penders" <alain at rexorient.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 3:43:13 PM
> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> 
> I'm testing my UI using GWTs Super Dev Mode, which means its origin is set
> to http://127.0.0.1:8888.    Keycloak runs on http://127.0.0.1:8080/auth.

Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT request. My guess is that "GWTs Super Dev Mode" sets some custom headers on all requests.

> 
> On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > It's the correct approach to add the preflight. Please send a PR and we'll
> > merge it.
> >
> > Out of curiosity do you know why it's sending a preflight in your app? It
> > doesn't when I test it out here, which AFAIK is correct according to spec
> > (content-type is application/x-www-form-urlencoded and there's no custom
> > headers set).
> >
> > ----- Original Message -----
> > > From: "Alain Penders" <alain at rexorient.com>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 3:04:50 PM
> > > Subject: [keycloak-dev] Fwd: Preflight for token refresh
> > >
> > > Hi all,
> > >
> > > I'm building a new app using GWT 2.7 using the Keycloak javascript
> > adapter
> > > and GWT jsInterop. This works extremely well.
> > >
> > > The problem I ran into is if I walk away for 5 minutes and then try to do
> > > something, the token refresh fails on preflight. As shown in the
> > > documentation, I call keycloak.updateToken(30) to refresh the base token
> > in
> > > case it has expired. Since in this case it has indeed expired, keycloak
> > > makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS call
> > to
> > > this location doesn't contain the Accept headers, and my app ends up
> > dead in
> > > the water.
> > >
> > > To fix this, I added the following code to OpenIDConnectService:
> > >
> > > /**
> > > * CORS preflight path for refresh token requests
> > > *
> > > * @return
> > > */
> > > @Path("refresh")
> > > @OPTIONS
> > > @Produces(MediaType.APPLICATION_JSON)
> > > public Response refreshAccessTokenPreflight() {
> > > if (logger.isDebugEnabled()) {
> > > logger.debugv("cors request from: {0}",
> > > request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> > > }
> > > return Cors.add(request, Response.ok()).auth().preflight().build();
> > > }
> > >
> > > If this wasn't the correct solution for my problem, I'd enjoy hearing
> > where I
> > > went wrong.
> > >
> > > Thanks,
> > > Alain
> > >
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 

From alain at rexorient.com  Tue Dec  2 10:02:15 2014
From: alain at rexorient.com (Alain Penders)
Date: Tue, 2 Dec 2014 08:02:15 -0700
Subject: [keycloak-dev] Fwd: Preflight for token refresh
In-Reply-To: <1932903918.8811689.1417531768234.JavaMail.zimbra@redhat.com>
References: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>
	<CAMtP742bwv57MmMnBjwH7hJZrGFWThO_dGsFK_oUp_mz-JW9xw@mail.gmail.com>
	<1967599145.8787926.1417530741784.JavaMail.zimbra@redhat.com>
	<CAMtP742pazk9OrG90J9tL1aMMfWib4aK9h4EkTO-ARFpn0N=VA@mail.gmail.com>
	<1932903918.8811689.1417531768234.JavaMail.zimbra@redhat.com>
Message-ID: <CAMtP741HU9eaAbeHowFEEyQp9R+S=ZfXxfh=rWjdKwRpf6t78A@mail.gmail.com>

Not really.  It needs CORS for every URI it hits.  Refresh is a different
URI from the code->token exchange one it uses initially.

When Keycloak redirects back to the GWT app and the code is exchanged for
the tokens, I see this in the Network trace:

First an OPTIONS request:


   1. Remote Address:
   127.0.0.1:8080
   2. Request URL:
   http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
   3. Request Method:
   OPTIONS
   4. Status Code:
   200 OK
   5. Request Headersview source
      1. Accept:
      */*
      2. Accept-Encoding:
      gzip, deflate, sdch
      3. Accept-Language:
      en-US,en;q=0.8
      4. Access-Control-Request-Headers:
      authorization, content-type
      5. Access-Control-Request-Method:
      POST
      6. Connection:
      keep-alive
      7. Host:
      localhost:8080
      8. Origin:
      http://127.0.0.1:8888
      9. Referer:
      http://127.0.0.1:8888/Main.html
      10. User-Agent:
      Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
      Gecko) Chrome/39.0.2171.71 Safari/537.36
      6. Response Headersview source
      1. Access-Control-Allow-Credentials:
      true
      2. Access-Control-Allow-Headers:
      Origin, Accept, X-Requested-With, Content-Type,
      Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
      3. Access-Control-Allow-Methods:
      GET, HEAD, OPTIONS
      4. Access-Control-Allow-Origin:
      http://127.0.0.1:8888
      5. Access-Control-Max-Age:
      3600
      6. Connection:
      keep-alive
      7. Content-Length:
      0
      8. Date:
      Tue, 02 Dec 2014 14:51:47 GMT
      9. Server:
      WildFly/8
      10. X-Powered-By:
      Undertow/1


Then the actual code exchange request:


   1. Remote Address:
   127.0.0.1:8080
   2. Request URL:
   http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
   3. Request Method:
   POST
   4. Status Code:
   200 OK
   5. Request Headersview source
      1. Accept:
      */*
      2. Accept-Encoding:
      gzip, deflate
      3. Accept-Language:
      en-US,en;q=0.8
      4. Authorization:
      Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
      5. Connection:
      keep-alive
      6. Content-Length:
      85
      7. Content-type:
      application/x-www-form-urlencoded
      8. Cookie:
      KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
      KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
      KEYCLOAK_REMEMBER_ME=username:alain
      9. Host:
      localhost:8080
      10. Origin:
      http://127.0.0.1:8888
      11. Referer:
      http://127.0.0.1:8888/Main.html
      12. User-Agent:
      Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
      Gecko) Chrome/39.0.2171.71 Safari/537.36
      6. Form Dataview sourceview URL encoded
      1. code:

      sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
      7. Response Headersview source
      1. Access-Control-Allow-Credentials:
      true
      2. Access-Control-Allow-Headers:
      Origin, Accept, X-Requested-With, Content-Type,
      Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
      3. Access-Control-Allow-Methods:
      POST
      4. Access-Control-Allow-Origin:
      http://127.0.0.1:8888
      5. Access-Control-Expose-Headers:
      Access-Control-Allow-Methods
      6. Access-Control-Max-Age:
      3600
      7. Connection:
      keep-alive
      8. Content-Type:
      application/json
      9. Date:
      Tue, 02 Dec 2014 14:51:47 GMT
      10. Server:
      WildFly/8
      11. Transfer-Encoding:
      chunked
      12. X-Powered-By:
      Undertow/1


Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
this uses the refresh URI for the first time, Chrome performs a preflight
check:


   1. Remote Address:
   127.0.0.1:8080
   2. Request URL:
   http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
   3. Request Method:
   OPTIONS
   4. Status Code:
   200 OK
   5. Request Headersview source
      1. Accept:
      */*
      2. Accept-Encoding:
      gzip, deflate, sdch
      3. Accept-Language:
      en-US,en;q=0.8
      4. Access-Control-Request-Headers:
      authorization, content-type
      5. Access-Control-Request-Method:
      POST
      6. Connection:
      keep-alive
      7. Host:
      localhost:8080
      8. Origin:
      http://127.0.0.1:8888
      9. Referer:
      http://127.0.0.1:8888/Main.html
      10. User-Agent:
      Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
      Gecko) Chrome/39.0.2171.71 Safari/537.36
      6. Response Headersview source
      1. Access-Control-Allow-Credentials:
      true
      2. Access-Control-Allow-Headers:
      Origin, Accept, X-Requested-With, Content-Type,
      Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
      3. Access-Control-Allow-Methods:
      GET, HEAD, OPTIONS
      4. Access-Control-Allow-Origin:
      http://127.0.0.1:8888
      5. Access-Control-Max-Age:
      3600
      6. Connection:
      keep-alive
      7. Content-Length:
      0
      8. Date:
      Tue, 02 Dec 2014 15:00:32 GMT
      9. Server:
      WildFly/8
      10. X-Powered-By:
      Undertow/1


Followed by the actual refresh:


   1. Remote Address:
   127.0.0.1:8080
   2. Request URL:
   http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
   3. Request Method:
   POST
   4. Status Code:
   200 OK
   5. Request Headersview source
      1. Accept:
      */*
      2. Accept-Encoding:
      gzip, deflate
      3. Accept-Language:
      en-US,en;q=0.8
      4. Authorization:
      Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
      5. Connection:
      keep-alive
      6. Content-Length:
      699
      7. Content-type:
      application/x-www-form-urlencoded
      8. Host:
      localhost:8080
      9. Origin:
      http://127.0.0.1:8888
      10. Referer:
      http://127.0.0.1:8888/Main.html
      11. User-Agent:
      Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
      Gecko) Chrome/39.0.2171.71 Safari/537.36
      6. Form Dataview sourceview URL encoded
      1. grant_type:
      refresh_token
      2. refresh_token:

      eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
      7. Response Headersview source
      1. Access-Control-Allow-Credentials:
      true
      2. Access-Control-Allow-Headers:
      Origin, Accept, X-Requested-With, Content-Type,
      Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
      3. Access-Control-Allow-Methods:
      POST
      4. Access-Control-Allow-Origin:
      http://127.0.0.1:8888
      5. Access-Control-Expose-Headers:
      Access-Control-Allow-Methods
      6. Access-Control-Max-Age:
      3600
      7. Connection:
      keep-alive
      8. Content-Type:
      application/json
      9. Date:
      Tue, 02 Dec 2014 15:00:32 GMT
      10. Server:
      WildFly/8
      11. Transfer-Encoding:
      chunked
      12. X-Powered-By:
      Undertow/1




On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen <stian at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Alain Penders" <alain at rexorient.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 3:43:13 PM
> > Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> >
> > I'm testing my UI using GWTs Super Dev Mode, which means its origin is
> set
> > to http://127.0.0.1:8888.    Keycloak runs on http://127.0.0.1:8080/auth
> .
>
> Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
> request. My guess is that "GWTs Super Dev Mode" sets some custom headers on
> all requests.
>
> >
> > On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian at redhat.com>
> wrote:
> >
> > > It's the correct approach to add the preflight. Please send a PR and
> we'll
> > > merge it.
> > >
> > > Out of curiosity do you know why it's sending a preflight in your app?
> It
> > > doesn't when I test it out here, which AFAIK is correct according to
> spec
> > > (content-type is application/x-www-form-urlencoded and there's no
> custom
> > > headers set).
> > >
> > > ----- Original Message -----
> > > > From: "Alain Penders" <alain at rexorient.com>
> > > > To: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, 2 December, 2014 3:04:50 PM
> > > > Subject: [keycloak-dev] Fwd: Preflight for token refresh
> > > >
> > > > Hi all,
> > > >
> > > > I'm building a new app using GWT 2.7 using the Keycloak javascript
> > > adapter
> > > > and GWT jsInterop. This works extremely well.
> > > >
> > > > The problem I ran into is if I walk away for 5 minutes and then try
> to do
> > > > something, the token refresh fails on preflight. As shown in the
> > > > documentation, I call keycloak.updateToken(30) to refresh the base
> token
> > > in
> > > > case it has expired. Since in this case it has indeed expired,
> keycloak
> > > > makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS
> call
> > > to
> > > > this location doesn't contain the Accept headers, and my app ends up
> > > dead in
> > > > the water.
> > > >
> > > > To fix this, I added the following code to OpenIDConnectService:
> > > >
> > > > /**
> > > > * CORS preflight path for refresh token requests
> > > > *
> > > > * @return
> > > > */
> > > > @Path("refresh")
> > > > @OPTIONS
> > > > @Produces(MediaType.APPLICATION_JSON)
> > > > public Response refreshAccessTokenPreflight() {
> > > > if (logger.isDebugEnabled()) {
> > > > logger.debugv("cors request from: {0}",
> > > > request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> > > > }
> > > > return Cors.add(request, Response.ok()).auth().preflight().build();
> > > > }
> > > >
> > > > If this wasn't the correct solution for my problem, I'd enjoy hearing
> > > where I
> > > > went wrong.
> > > >
> > > > Thanks,
> > > > Alain
> > > >
> > > >
> > > > _______________________________________________
> > > > 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/20141202/15ab7f95/attachment-0001.html 

From stian at redhat.com  Tue Dec  2 10:10:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 10:10:01 -0500 (EST)
Subject: [keycloak-dev] Fwd: Preflight for token refresh
In-Reply-To: <CAMtP741HU9eaAbeHowFEEyQp9R+S=ZfXxfh=rWjdKwRpf6t78A@mail.gmail.com>
References: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>
	<CAMtP742bwv57MmMnBjwH7hJZrGFWThO_dGsFK_oUp_mz-JW9xw@mail.gmail.com>
	<1967599145.8787926.1417530741784.JavaMail.zimbra@redhat.com>
	<CAMtP742pazk9OrG90J9tL1aMMfWib4aK9h4EkTO-ARFpn0N=VA@mail.gmail.com>
	<1932903918.8811689.1417531768234.JavaMail.zimbra@redhat.com>
	<CAMtP741HU9eaAbeHowFEEyQp9R+S=ZfXxfh=rWjdKwRpf6t78A@mail.gmail.com>
Message-ID: <1718295184.8837465.1417533001973.JavaMail.zimbra@redhat.com>

The code->token and refresh token requests are being pre-flighted because there's a 'Authorization: Basic' header in there. For a GWT app you should use the confidential application type, which doesn't require a secret.

----- Original Message -----
> From: "Alain Penders" <alain at rexorient.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 4:02:15 PM
> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> 
> Not really.  It needs CORS for every URI it hits.  Refresh is a different
> URI from the code->token exchange one it uses initially.
> 
> When Keycloak redirects back to the GWT app and the code is exchanged for
> the tokens, I see this in the Network trace:
> 
> First an OPTIONS request:
> 
> 
>    1. Remote Address:
>    127.0.0.1:8080
>    2. Request URL:
>    http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
>    3. Request Method:
>    OPTIONS
>    4. Status Code:
>    200 OK
>    5. Request Headersview source
>       1. Accept:
>       */*
>       2. Accept-Encoding:
>       gzip, deflate, sdch
>       3. Accept-Language:
>       en-US,en;q=0.8
>       4. Access-Control-Request-Headers:
>       authorization, content-type
>       5. Access-Control-Request-Method:
>       POST
>       6. Connection:
>       keep-alive
>       7. Host:
>       localhost:8080
>       8. Origin:
>       http://127.0.0.1:8888
>       9. Referer:
>       http://127.0.0.1:8888/Main.html
>       10. User-Agent:
>       Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>       Gecko) Chrome/39.0.2171.71 Safari/537.36
>       6. Response Headersview source
>       1. Access-Control-Allow-Credentials:
>       true
>       2. Access-Control-Allow-Headers:
>       Origin, Accept, X-Requested-With, Content-Type,
>       Access-Control-Request-Method, Access-Control-Request-Headers,
> Authorization
>       3. Access-Control-Allow-Methods:
>       GET, HEAD, OPTIONS
>       4. Access-Control-Allow-Origin:
>       http://127.0.0.1:8888
>       5. Access-Control-Max-Age:
>       3600
>       6. Connection:
>       keep-alive
>       7. Content-Length:
>       0
>       8. Date:
>       Tue, 02 Dec 2014 14:51:47 GMT
>       9. Server:
>       WildFly/8
>       10. X-Powered-By:
>       Undertow/1
> 
> 
> Then the actual code exchange request:
> 
> 
>    1. Remote Address:
>    127.0.0.1:8080
>    2. Request URL:
>    http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
>    3. Request Method:
>    POST
>    4. Status Code:
>    200 OK
>    5. Request Headersview source
>       1. Accept:
>       */*
>       2. Accept-Encoding:
>       gzip, deflate
>       3. Accept-Language:
>       en-US,en;q=0.8
>       4. Authorization:
>       Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
>       5. Connection:
>       keep-alive
>       6. Content-Length:
>       85
>       7. Content-type:
>       application/x-www-form-urlencoded
>       8. Cookie:
>       KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
>       KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
>       KEYCLOAK_REMEMBER_ME=username:alain
>       9. Host:
>       localhost:8080
>       10. Origin:
>       http://127.0.0.1:8888
>       11. Referer:
>       http://127.0.0.1:8888/Main.html
>       12. User-Agent:
>       Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>       Gecko) Chrome/39.0.2171.71 Safari/537.36
>       6. Form Dataview sourceview URL encoded
>       1. code:
> 
>       sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
>       7. Response Headersview source
>       1. Access-Control-Allow-Credentials:
>       true
>       2. Access-Control-Allow-Headers:
>       Origin, Accept, X-Requested-With, Content-Type,
>       Access-Control-Request-Method, Access-Control-Request-Headers,
> Authorization
>       3. Access-Control-Allow-Methods:
>       POST
>       4. Access-Control-Allow-Origin:
>       http://127.0.0.1:8888
>       5. Access-Control-Expose-Headers:
>       Access-Control-Allow-Methods
>       6. Access-Control-Max-Age:
>       3600
>       7. Connection:
>       keep-alive
>       8. Content-Type:
>       application/json
>       9. Date:
>       Tue, 02 Dec 2014 14:51:47 GMT
>       10. Server:
>       WildFly/8
>       11. Transfer-Encoding:
>       chunked
>       12. X-Powered-By:
>       Undertow/1
> 
> 
> Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
> this uses the refresh URI for the first time, Chrome performs a preflight
> check:
> 
> 
>    1. Remote Address:
>    127.0.0.1:8080
>    2. Request URL:
>    http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
>    3. Request Method:
>    OPTIONS
>    4. Status Code:
>    200 OK
>    5. Request Headersview source
>       1. Accept:
>       */*
>       2. Accept-Encoding:
>       gzip, deflate, sdch
>       3. Accept-Language:
>       en-US,en;q=0.8
>       4. Access-Control-Request-Headers:
>       authorization, content-type
>       5. Access-Control-Request-Method:
>       POST
>       6. Connection:
>       keep-alive
>       7. Host:
>       localhost:8080
>       8. Origin:
>       http://127.0.0.1:8888
>       9. Referer:
>       http://127.0.0.1:8888/Main.html
>       10. User-Agent:
>       Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>       Gecko) Chrome/39.0.2171.71 Safari/537.36
>       6. Response Headersview source
>       1. Access-Control-Allow-Credentials:
>       true
>       2. Access-Control-Allow-Headers:
>       Origin, Accept, X-Requested-With, Content-Type,
>       Access-Control-Request-Method, Access-Control-Request-Headers,
> Authorization
>       3. Access-Control-Allow-Methods:
>       GET, HEAD, OPTIONS
>       4. Access-Control-Allow-Origin:
>       http://127.0.0.1:8888
>       5. Access-Control-Max-Age:
>       3600
>       6. Connection:
>       keep-alive
>       7. Content-Length:
>       0
>       8. Date:
>       Tue, 02 Dec 2014 15:00:32 GMT
>       9. Server:
>       WildFly/8
>       10. X-Powered-By:
>       Undertow/1
> 
> 
> Followed by the actual refresh:
> 
> 
>    1. Remote Address:
>    127.0.0.1:8080
>    2. Request URL:
>    http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
>    3. Request Method:
>    POST
>    4. Status Code:
>    200 OK
>    5. Request Headersview source
>       1. Accept:
>       */*
>       2. Accept-Encoding:
>       gzip, deflate
>       3. Accept-Language:
>       en-US,en;q=0.8
>       4. Authorization:
>       Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
>       5. Connection:
>       keep-alive
>       6. Content-Length:
>       699
>       7. Content-type:
>       application/x-www-form-urlencoded
>       8. Host:
>       localhost:8080
>       9. Origin:
>       http://127.0.0.1:8888
>       10. Referer:
>       http://127.0.0.1:8888/Main.html
>       11. User-Agent:
>       Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>       Gecko) Chrome/39.0.2171.71 Safari/537.36
>       6. Form Dataview sourceview URL encoded
>       1. grant_type:
>       refresh_token
>       2. refresh_token:
> 
>       eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
>       7. Response Headersview source
>       1. Access-Control-Allow-Credentials:
>       true
>       2. Access-Control-Allow-Headers:
>       Origin, Accept, X-Requested-With, Content-Type,
>       Access-Control-Request-Method, Access-Control-Request-Headers,
> Authorization
>       3. Access-Control-Allow-Methods:
>       POST
>       4. Access-Control-Allow-Origin:
>       http://127.0.0.1:8888
>       5. Access-Control-Expose-Headers:
>       Access-Control-Allow-Methods
>       6. Access-Control-Max-Age:
>       3600
>       7. Connection:
>       keep-alive
>       8. Content-Type:
>       application/json
>       9. Date:
>       Tue, 02 Dec 2014 15:00:32 GMT
>       10. Server:
>       WildFly/8
>       11. Transfer-Encoding:
>       chunked
>       12. X-Powered-By:
>       Undertow/1
> 
> 
> 
> 
> On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > From: "Alain Penders" <alain at rexorient.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 3:43:13 PM
> > > Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> > >
> > > I'm testing my UI using GWTs Super Dev Mode, which means its origin is
> > set
> > > to http://127.0.0.1:8888.    Keycloak runs on http://127.0.0.1:8080/auth
> > .
> >
> > Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
> > request. My guess is that "GWTs Super Dev Mode" sets some custom headers on
> > all requests.
> >
> > >
> > > On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian at redhat.com>
> > wrote:
> > >
> > > > It's the correct approach to add the preflight. Please send a PR and
> > we'll
> > > > merge it.
> > > >
> > > > Out of curiosity do you know why it's sending a preflight in your app?
> > It
> > > > doesn't when I test it out here, which AFAIK is correct according to
> > spec
> > > > (content-type is application/x-www-form-urlencoded and there's no
> > custom
> > > > headers set).
> > > >
> > > > ----- Original Message -----
> > > > > From: "Alain Penders" <alain at rexorient.com>
> > > > > To: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, 2 December, 2014 3:04:50 PM
> > > > > Subject: [keycloak-dev] Fwd: Preflight for token refresh
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I'm building a new app using GWT 2.7 using the Keycloak javascript
> > > > adapter
> > > > > and GWT jsInterop. This works extremely well.
> > > > >
> > > > > The problem I ran into is if I walk away for 5 minutes and then try
> > to do
> > > > > something, the token refresh fails on preflight. As shown in the
> > > > > documentation, I call keycloak.updateToken(30) to refresh the base
> > token
> > > > in
> > > > > case it has expired. Since in this case it has indeed expired,
> > keycloak
> > > > > makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS
> > call
> > > > to
> > > > > this location doesn't contain the Accept headers, and my app ends up
> > > > dead in
> > > > > the water.
> > > > >
> > > > > To fix this, I added the following code to OpenIDConnectService:
> > > > >
> > > > > /**
> > > > > * CORS preflight path for refresh token requests
> > > > > *
> > > > > * @return
> > > > > */
> > > > > @Path("refresh")
> > > > > @OPTIONS
> > > > > @Produces(MediaType.APPLICATION_JSON)
> > > > > public Response refreshAccessTokenPreflight() {
> > > > > if (logger.isDebugEnabled()) {
> > > > > logger.debugv("cors request from: {0}",
> > > > > request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> > > > > }
> > > > > return Cors.add(request, Response.ok()).auth().preflight().build();
> > > > > }
> > > > >
> > > > > If this wasn't the correct solution for my problem, I'd enjoy hearing
> > > > where I
> > > > > went wrong.
> > > > >
> > > > > Thanks,
> > > > > Alain
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > >
> >
> 

From bburke at redhat.com  Tue Dec  2 10:11:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Dec 2014 10:11:19 -0500
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com> <547C8F0B.4060904@redhat.com>
	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
	<547DB6A7.8040200@redhat.com> <547DC0D8.9000404@redhat.com>
	<2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
Message-ID: <547DD697.5030909@redhat.com>



On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 2 December, 2014 2:38:32 PM
>> Subject: Re: [keycloak-dev] release?  Stan?
>>
>>
>>
>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>> Should we upgrade to WF 8.2 and also do some changes to the distro before
>>>> release?
>>> I don't see a reason not to go to WF 8.2.  If we do that, let me know so
>>> I can run a quick smoke test on the subsystem before we release.
>>>>
>>>> With regards to distro we should move the adapters and examples into
>>>> separate downloads. Also, we should move the examples into a separate
>>>> github project (keycloak/keycloak-examples). This will make it easier for
>>>> those that wants to fork the examples separately.
>>>>
>>>> Also, we should consider a download based on the web-lite profile. For
>>>> non-JavaEE apps, containers (Docker) and those that want to run a
>>>> standalone KC server it would be nice to have a small as possible distro.
>>> Depending on how the feature pack turns out, we might be able to offer
>>> many flavors of the appliance distro without any additional effort.  We
>>> could have:
>>> EAP6 + Keycloak
>>> AS7 + Keycloak
>>> WF8 (web) + Keycloak
>>> WF8 (full) + Keycloak
>>> WF 9 beta (web) + Keycloak
>>> WF 9 beta (full) + Keycloak
>>> etc.
>>>
>>
>> IMO, we just need:
>> * war-dist
>> * appliance-dist
>>
>> Appliance distribution would have the most stable platform available.
>> Since we can't distribute EAP, then it would be the most stable and
>> maintained version of Wildfly that allows us to cluster and deploy Keycloak.
>
> Our download at the moment is 160MB and is really aimed at the first-time JavaEE user (bundled with examples and documentation). Why should we require someone that just wants to upgrade their server to download all of that? There'll also be loads of people that don't need the JavaEE parts, a NodeJS developer or deploying to cloud for example. I think we could easily have a standalone Keycloak server download that'd be around 30MB.
>
> IMO we should have:
>
> * Minimal server (based on WildFly web/core)
> * Full server (based on WildFly full)
> * Feature pack - to easily install onto other version of WF, EAP, etc.
>
> Neither of those downloads should include docs or examples. As we don't really support installing onto Tomcat or Jetty, why have a war-dist?
>

I disagree.  At least one download should have everything:  docs, 
examples, and a distro that can run the examples.  Reducing even simple 
steps for 1st time users is crucial to adoption.  How fast a first time 
user can get "hello world" running is crucial.  BTW, That's a major 
reason why your suggestion earlier of having examples on Github is not a 
great idea.

Why have a war-dist?  So we can deploy to EAP 6.  AFAIK, EAP 6 doesn't 
support feature packs.  war-dist could change to subsystem-dist I guess 
since, as you said, we don't really support installing into tomcat or jetty.


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

From bburke at redhat.com  Tue Dec  2 10:24:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Dec 2014 10:24:25 -0500
Subject: [keycloak-dev] Fwd: Preflight for token refresh
In-Reply-To: <1718295184.8837465.1417533001973.JavaMail.zimbra@redhat.com>
References: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>	<CAMtP742bwv57MmMnBjwH7hJZrGFWThO_dGsFK_oUp_mz-JW9xw@mail.gmail.com>	<1967599145.8787926.1417530741784.JavaMail.zimbra@redhat.com>	<CAMtP742pazk9OrG90J9tL1aMMfWib4aK9h4EkTO-ARFpn0N=VA@mail.gmail.com>	<1932903918.8811689.1417531768234.JavaMail.zimbra@redhat.com>	<CAMtP741HU9eaAbeHowFEEyQp9R+S=ZfXxfh=rWjdKwRpf6t78A@mail.gmail.com>
	<1718295184.8837465.1417533001973.JavaMail.zimbra@redhat.com>
Message-ID: <547DD9A9.6040204@redhat.com>

You mean the "public" application type.

On 12/2/2014 10:10 AM, Stian Thorgersen wrote:
> The code->token and refresh token requests are being pre-flighted because there's a 'Authorization: Basic' header in there. For a GWT app you should use the confidential application type, which doesn't require a secret.
>
> ----- Original Message -----
>> From: "Alain Penders" <alain at rexorient.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 2 December, 2014 4:02:15 PM
>> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
>>
>> Not really.  It needs CORS for every URI it hits.  Refresh is a different
>> URI from the code->token exchange one it uses initially.
>>
>> When Keycloak redirects back to the GWT app and the code is exchanged for
>> the tokens, I see this in the Network trace:
>>
>> First an OPTIONS request:
>>
>>
>>     1. Remote Address:
>>     127.0.0.1:8080
>>     2. Request URL:
>>     http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
>>     3. Request Method:
>>     OPTIONS
>>     4. Status Code:
>>     200 OK
>>     5. Request Headersview source
>>        1. Accept:
>>        */*
>>        2. Accept-Encoding:
>>        gzip, deflate, sdch
>>        3. Accept-Language:
>>        en-US,en;q=0.8
>>        4. Access-Control-Request-Headers:
>>        authorization, content-type
>>        5. Access-Control-Request-Method:
>>        POST
>>        6. Connection:
>>        keep-alive
>>        7. Host:
>>        localhost:8080
>>        8. Origin:
>>        http://127.0.0.1:8888
>>        9. Referer:
>>        http://127.0.0.1:8888/Main.html
>>        10. User-Agent:
>>        Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>>        Gecko) Chrome/39.0.2171.71 Safari/537.36
>>        6. Response Headersview source
>>        1. Access-Control-Allow-Credentials:
>>        true
>>        2. Access-Control-Allow-Headers:
>>        Origin, Accept, X-Requested-With, Content-Type,
>>        Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>>        3. Access-Control-Allow-Methods:
>>        GET, HEAD, OPTIONS
>>        4. Access-Control-Allow-Origin:
>>        http://127.0.0.1:8888
>>        5. Access-Control-Max-Age:
>>        3600
>>        6. Connection:
>>        keep-alive
>>        7. Content-Length:
>>        0
>>        8. Date:
>>        Tue, 02 Dec 2014 14:51:47 GMT
>>        9. Server:
>>        WildFly/8
>>        10. X-Powered-By:
>>        Undertow/1
>>
>>
>> Then the actual code exchange request:
>>
>>
>>     1. Remote Address:
>>     127.0.0.1:8080
>>     2. Request URL:
>>     http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
>>     3. Request Method:
>>     POST
>>     4. Status Code:
>>     200 OK
>>     5. Request Headersview source
>>        1. Accept:
>>        */*
>>        2. Accept-Encoding:
>>        gzip, deflate
>>        3. Accept-Language:
>>        en-US,en;q=0.8
>>        4. Authorization:
>>        Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
>>        5. Connection:
>>        keep-alive
>>        6. Content-Length:
>>        85
>>        7. Content-type:
>>        application/x-www-form-urlencoded
>>        8. Cookie:
>>        KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
>>        KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
>>        KEYCLOAK_REMEMBER_ME=username:alain
>>        9. Host:
>>        localhost:8080
>>        10. Origin:
>>        http://127.0.0.1:8888
>>        11. Referer:
>>        http://127.0.0.1:8888/Main.html
>>        12. User-Agent:
>>        Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>>        Gecko) Chrome/39.0.2171.71 Safari/537.36
>>        6. Form Dataview sourceview URL encoded
>>        1. code:
>>
>>        sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
>>        7. Response Headersview source
>>        1. Access-Control-Allow-Credentials:
>>        true
>>        2. Access-Control-Allow-Headers:
>>        Origin, Accept, X-Requested-With, Content-Type,
>>        Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>>        3. Access-Control-Allow-Methods:
>>        POST
>>        4. Access-Control-Allow-Origin:
>>        http://127.0.0.1:8888
>>        5. Access-Control-Expose-Headers:
>>        Access-Control-Allow-Methods
>>        6. Access-Control-Max-Age:
>>        3600
>>        7. Connection:
>>        keep-alive
>>        8. Content-Type:
>>        application/json
>>        9. Date:
>>        Tue, 02 Dec 2014 14:51:47 GMT
>>        10. Server:
>>        WildFly/8
>>        11. Transfer-Encoding:
>>        chunked
>>        12. X-Powered-By:
>>        Undertow/1
>>
>>
>> Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
>> this uses the refresh URI for the first time, Chrome performs a preflight
>> check:
>>
>>
>>     1. Remote Address:
>>     127.0.0.1:8080
>>     2. Request URL:
>>     http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
>>     3. Request Method:
>>     OPTIONS
>>     4. Status Code:
>>     200 OK
>>     5. Request Headersview source
>>        1. Accept:
>>        */*
>>        2. Accept-Encoding:
>>        gzip, deflate, sdch
>>        3. Accept-Language:
>>        en-US,en;q=0.8
>>        4. Access-Control-Request-Headers:
>>        authorization, content-type
>>        5. Access-Control-Request-Method:
>>        POST
>>        6. Connection:
>>        keep-alive
>>        7. Host:
>>        localhost:8080
>>        8. Origin:
>>        http://127.0.0.1:8888
>>        9. Referer:
>>        http://127.0.0.1:8888/Main.html
>>        10. User-Agent:
>>        Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>>        Gecko) Chrome/39.0.2171.71 Safari/537.36
>>        6. Response Headersview source
>>        1. Access-Control-Allow-Credentials:
>>        true
>>        2. Access-Control-Allow-Headers:
>>        Origin, Accept, X-Requested-With, Content-Type,
>>        Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>>        3. Access-Control-Allow-Methods:
>>        GET, HEAD, OPTIONS
>>        4. Access-Control-Allow-Origin:
>>        http://127.0.0.1:8888
>>        5. Access-Control-Max-Age:
>>        3600
>>        6. Connection:
>>        keep-alive
>>        7. Content-Length:
>>        0
>>        8. Date:
>>        Tue, 02 Dec 2014 15:00:32 GMT
>>        9. Server:
>>        WildFly/8
>>        10. X-Powered-By:
>>        Undertow/1
>>
>>
>> Followed by the actual refresh:
>>
>>
>>     1. Remote Address:
>>     127.0.0.1:8080
>>     2. Request URL:
>>     http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
>>     3. Request Method:
>>     POST
>>     4. Status Code:
>>     200 OK
>>     5. Request Headersview source
>>        1. Accept:
>>        */*
>>        2. Accept-Encoding:
>>        gzip, deflate
>>        3. Accept-Language:
>>        en-US,en;q=0.8
>>        4. Authorization:
>>        Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
>>        5. Connection:
>>        keep-alive
>>        6. Content-Length:
>>        699
>>        7. Content-type:
>>        application/x-www-form-urlencoded
>>        8. Host:
>>        localhost:8080
>>        9. Origin:
>>        http://127.0.0.1:8888
>>        10. Referer:
>>        http://127.0.0.1:8888/Main.html
>>        11. User-Agent:
>>        Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>>        Gecko) Chrome/39.0.2171.71 Safari/537.36
>>        6. Form Dataview sourceview URL encoded
>>        1. grant_type:
>>        refresh_token
>>        2. refresh_token:
>>
>>        eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
>>        7. Response Headersview source
>>        1. Access-Control-Allow-Credentials:
>>        true
>>        2. Access-Control-Allow-Headers:
>>        Origin, Accept, X-Requested-With, Content-Type,
>>        Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>>        3. Access-Control-Allow-Methods:
>>        POST
>>        4. Access-Control-Allow-Origin:
>>        http://127.0.0.1:8888
>>        5. Access-Control-Expose-Headers:
>>        Access-Control-Allow-Methods
>>        6. Access-Control-Max-Age:
>>        3600
>>        7. Connection:
>>        keep-alive
>>        8. Content-Type:
>>        application/json
>>        9. Date:
>>        Tue, 02 Dec 2014 15:00:32 GMT
>>        10. Server:
>>        WildFly/8
>>        11. Transfer-Encoding:
>>        chunked
>>        12. X-Powered-By:
>>        Undertow/1
>>
>>
>>
>>
>> On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen <stian at redhat.com> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Alain Penders" <alain at rexorient.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 2 December, 2014 3:43:13 PM
>>>> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
>>>>
>>>> I'm testing my UI using GWTs Super Dev Mode, which means its origin is
>>> set
>>>> to http://127.0.0.1:8888.    Keycloak runs on http://127.0.0.1:8080/auth
>>> .
>>>
>>> Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
>>> request. My guess is that "GWTs Super Dev Mode" sets some custom headers on
>>> all requests.
>>>
>>>>
>>>> On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian at redhat.com>
>>> wrote:
>>>>
>>>>> It's the correct approach to add the preflight. Please send a PR and
>>> we'll
>>>>> merge it.
>>>>>
>>>>> Out of curiosity do you know why it's sending a preflight in your app?
>>> It
>>>>> doesn't when I test it out here, which AFAIK is correct according to
>>> spec
>>>>> (content-type is application/x-www-form-urlencoded and there's no
>>> custom
>>>>> headers set).
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Alain Penders" <alain at rexorient.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Tuesday, 2 December, 2014 3:04:50 PM
>>>>>> Subject: [keycloak-dev] Fwd: Preflight for token refresh
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm building a new app using GWT 2.7 using the Keycloak javascript
>>>>> adapter
>>>>>> and GWT jsInterop. This works extremely well.
>>>>>>
>>>>>> The problem I ran into is if I walk away for 5 minutes and then try
>>> to do
>>>>>> something, the token refresh fails on preflight. As shown in the
>>>>>> documentation, I call keycloak.updateToken(30) to refresh the base
>>> token
>>>>> in
>>>>>> case it has expired. Since in this case it has indeed expired,
>>> keycloak
>>>>>> makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS
>>> call
>>>>> to
>>>>>> this location doesn't contain the Accept headers, and my app ends up
>>>>> dead in
>>>>>> the water.
>>>>>>
>>>>>> To fix this, I added the following code to OpenIDConnectService:
>>>>>>
>>>>>> /**
>>>>>> * CORS preflight path for refresh token requests
>>>>>> *
>>>>>> * @return
>>>>>> */
>>>>>> @Path("refresh")
>>>>>> @OPTIONS
>>>>>> @Produces(MediaType.APPLICATION_JSON)
>>>>>> public Response refreshAccessTokenPreflight() {
>>>>>> if (logger.isDebugEnabled()) {
>>>>>> logger.debugv("cors request from: {0}",
>>>>>> request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
>>>>>> }
>>>>>> return Cors.add(request, Response.ok()).auth().preflight().build();
>>>>>> }
>>>>>>
>>>>>> If this wasn't the correct solution for my problem, I'd enjoy hearing
>>>>> where I
>>>>>> went wrong.
>>>>>>
>>>>>> Thanks,
>>>>>> Alain
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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  Tue Dec  2 10:31:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Dec 2014 10:31:40 -0500
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547DD697.5030909@redhat.com>
References: <547C8466.4050103@redhat.com>
	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com>	<2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
	<547DD697.5030909@redhat.com>
Message-ID: <547DDB5C.7010806@redhat.com>



On 12/2/2014 10:11 AM, Bill Burke wrote:
>
>
> On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 2 December, 2014 2:38:32 PM
>>> Subject: Re: [keycloak-dev] release?  Stan?
>>>
>>>
>>>
>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro before
>>>>> release?
>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me know so
>>>> I can run a quick smoke test on the subsystem before we release.
>>>>>
>>>>> With regards to distro we should move the adapters and examples into
>>>>> separate downloads. Also, we should move the examples into a separate
>>>>> github project (keycloak/keycloak-examples). This will make it easier for
>>>>> those that wants to fork the examples separately.
>>>>>
>>>>> Also, we should consider a download based on the web-lite profile. For
>>>>> non-JavaEE apps, containers (Docker) and those that want to run a
>>>>> standalone KC server it would be nice to have a small as possible distro.
>>>> Depending on how the feature pack turns out, we might be able to offer
>>>> many flavors of the appliance distro without any additional effort.  We
>>>> could have:
>>>> EAP6 + Keycloak
>>>> AS7 + Keycloak
>>>> WF8 (web) + Keycloak
>>>> WF8 (full) + Keycloak
>>>> WF 9 beta (web) + Keycloak
>>>> WF 9 beta (full) + Keycloak
>>>> etc.
>>>>
>>>
>>> IMO, we just need:
>>> * war-dist
>>> * appliance-dist
>>>
>>> Appliance distribution would have the most stable platform available.
>>> Since we can't distribute EAP, then it would be the most stable and
>>> maintained version of Wildfly that allows us to cluster and deploy Keycloak.
>>
>> Our download at the moment is 160MB and is really aimed at the first-time JavaEE user (bundled with examples and documentation). Why should we require someone that just wants to upgrade their server to download all of that? There'll also be loads of people that don't need the JavaEE parts, a NodeJS developer or deploying to cloud for example. I think we could easily have a standalone Keycloak server download that'd be around 30MB.
>>
>> IMO we should have:
>>
>> * Minimal server (based on WildFly web/core)
>> * Full server (based on WildFly full)
>> * Feature pack - to easily install onto other version of WF, EAP, etc.
>>
>> Neither of those downloads should include docs or examples. As we don't really support installing onto Tomcat or Jetty, why have a war-dist?
>>
>
> I disagree.  At least one download should have everything:  docs,
> examples, and a distro that can run the examples.  Reducing even simple
> steps for 1st time users is crucial to adoption.  How fast a first time
> user can get "hello world" running is crucial.  BTW, That's a major
> reason why your suggestion earlier of having examples on Github is not a
> great idea.
>
> Why have a war-dist?  So we can deploy to EAP 6.  AFAIK, EAP 6 doesn't
> support feature packs.  war-dist could change to subsystem-dist I guess
> since, as you said, we don't really support installing into tomcat or jetty.
>

One more thing.  A server/appliance distro should be clusterable and be 
able to run in domain mode.  Also, IMO, if the download size between 
minimal and full server is not significant then we don't have a minimal 
server distro.  i.e. 160M vs. 30M is one thing...but if its 160M vs. 
120M I don't see much difference there.   Reduction in the number of 
options a user has to make a decision on is always a good thing.  Most 
users will want us to make the decisions for them.


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

From alain at rexorient.com  Tue Dec  2 10:33:54 2014
From: alain at rexorient.com (Alain Penders)
Date: Tue, 2 Dec 2014 08:33:54 -0700
Subject: [keycloak-dev] Fwd: Preflight for token refresh
In-Reply-To: <547DD9A9.6040204@redhat.com>
References: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>
	<CAMtP742bwv57MmMnBjwH7hJZrGFWThO_dGsFK_oUp_mz-JW9xw@mail.gmail.com>
	<1967599145.8787926.1417530741784.JavaMail.zimbra@redhat.com>
	<CAMtP742pazk9OrG90J9tL1aMMfWib4aK9h4EkTO-ARFpn0N=VA@mail.gmail.com>
	<1932903918.8811689.1417531768234.JavaMail.zimbra@redhat.com>
	<CAMtP741HU9eaAbeHowFEEyQp9R+S=ZfXxfh=rWjdKwRpf6t78A@mail.gmail.com>
	<1718295184.8837465.1417533001973.JavaMail.zimbra@redhat.com>
	<547DD9A9.6040204@redhat.com>
Message-ID: <CAMtP740DdF+O33+=RqKNDmX+BX=_ZE_jPrRMuE-KU5ODnNvk2w@mail.gmail.com>

I was about to say "I am using confidential".   Switching to public does
indeed drop the need for preflight.  Learned something new :-)

Still want me to submit a PR for the refresh preflight?   Obviously using
confidential doesn't add any security here, but I don't think supporting it
can hurt either (and the JavaScript code supports it already.)


On Tue, Dec 2, 2014 at 8:24 AM, Bill Burke <bburke at redhat.com> wrote:

> You mean the "public" application type.
>
> On 12/2/2014 10:10 AM, Stian Thorgersen wrote:
> > The code->token and refresh token requests are being pre-flighted
> because there's a 'Authorization: Basic' header in there. For a GWT app you
> should use the confidential application type, which doesn't require a
> secret.
> >
> > ----- Original Message -----
> >> From: "Alain Penders" <alain at rexorient.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 2 December, 2014 4:02:15 PM
> >> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> >>
> >> Not really.  It needs CORS for every URI it hits.  Refresh is a
> different
> >> URI from the code->token exchange one it uses initially.
> >>
> >> When Keycloak redirects back to the GWT app and the code is exchanged
> for
> >> the tokens, I see this in the Network trace:
> >>
> >> First an OPTIONS request:
> >>
> >>
> >>     1. Remote Address:
> >>     127.0.0.1:8080
> >>     2. Request URL:
> >>     http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
> >>     3. Request Method:
> >>     OPTIONS
> >>     4. Status Code:
> >>     200 OK
> >>     5. Request Headersview source
> >>        1. Accept:
> >>        */*
> >>        2. Accept-Encoding:
> >>        gzip, deflate, sdch
> >>        3. Accept-Language:
> >>        en-US,en;q=0.8
> >>        4. Access-Control-Request-Headers:
> >>        authorization, content-type
> >>        5. Access-Control-Request-Method:
> >>        POST
> >>        6. Connection:
> >>        keep-alive
> >>        7. Host:
> >>        localhost:8080
> >>        8. Origin:
> >>        http://127.0.0.1:8888
> >>        9. Referer:
> >>        http://127.0.0.1:8888/Main.html
> >>        10. User-Agent:
> >>        Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML,
> like
> >>        Gecko) Chrome/39.0.2171.71 Safari/537.36
> >>        6. Response Headersview source
> >>        1. Access-Control-Allow-Credentials:
> >>        true
> >>        2. Access-Control-Allow-Headers:
> >>        Origin, Accept, X-Requested-With, Content-Type,
> >>        Access-Control-Request-Method, Access-Control-Request-Headers,
> >> Authorization
> >>        3. Access-Control-Allow-Methods:
> >>        GET, HEAD, OPTIONS
> >>        4. Access-Control-Allow-Origin:
> >>        http://127.0.0.1:8888
> >>        5. Access-Control-Max-Age:
> >>        3600
> >>        6. Connection:
> >>        keep-alive
> >>        7. Content-Length:
> >>        0
> >>        8. Date:
> >>        Tue, 02 Dec 2014 14:51:47 GMT
> >>        9. Server:
> >>        WildFly/8
> >>        10. X-Powered-By:
> >>        Undertow/1
> >>
> >>
> >> Then the actual code exchange request:
> >>
> >>
> >>     1. Remote Address:
> >>     127.0.0.1:8080
> >>     2. Request URL:
> >>     http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
> >>     3. Request Method:
> >>     POST
> >>     4. Status Code:
> >>     200 OK
> >>     5. Request Headersview source
> >>        1. Accept:
> >>        */*
> >>        2. Accept-Encoding:
> >>        gzip, deflate
> >>        3. Accept-Language:
> >>        en-US,en;q=0.8
> >>        4. Authorization:
> >>        Basic
> R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
> >>        5. Connection:
> >>        keep-alive
> >>        6. Content-Length:
> >>        85
> >>        7. Content-type:
> >>        application/x-www-form-urlencoded
> >>        8. Cookie:
> >>
> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
> >>
> KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
> >>        KEYCLOAK_REMEMBER_ME=username:alain
> >>        9. Host:
> >>        localhost:8080
> >>        10. Origin:
> >>        http://127.0.0.1:8888
> >>        11. Referer:
> >>        http://127.0.0.1:8888/Main.html
> >>        12. User-Agent:
> >>        Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML,
> like
> >>        Gecko) Chrome/39.0.2171.71 Safari/537.36
> >>        6. Form Dataview sourceview URL encoded
> >>        1. code:
> >>
> >>
> sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
> >>        7. Response Headersview source
> >>        1. Access-Control-Allow-Credentials:
> >>        true
> >>        2. Access-Control-Allow-Headers:
> >>        Origin, Accept, X-Requested-With, Content-Type,
> >>        Access-Control-Request-Method, Access-Control-Request-Headers,
> >> Authorization
> >>        3. Access-Control-Allow-Methods:
> >>        POST
> >>        4. Access-Control-Allow-Origin:
> >>        http://127.0.0.1:8888
> >>        5. Access-Control-Expose-Headers:
> >>        Access-Control-Allow-Methods
> >>        6. Access-Control-Max-Age:
> >>        3600
> >>        7. Connection:
> >>        keep-alive
> >>        8. Content-Type:
> >>        application/json
> >>        9. Date:
> >>        Tue, 02 Dec 2014 14:51:47 GMT
> >>        10. Server:
> >>        WildFly/8
> >>        11. Transfer-Encoding:
> >>        chunked
> >>        12. X-Powered-By:
> >>        Undertow/1
> >>
> >>
> >> Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
> >> this uses the refresh URI for the first time, Chrome performs a
> preflight
> >> check:
> >>
> >>
> >>     1. Remote Address:
> >>     127.0.0.1:8080
> >>     2. Request URL:
> >>     http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
> >>     3. Request Method:
> >>     OPTIONS
> >>     4. Status Code:
> >>     200 OK
> >>     5. Request Headersview source
> >>        1. Accept:
> >>        */*
> >>        2. Accept-Encoding:
> >>        gzip, deflate, sdch
> >>        3. Accept-Language:
> >>        en-US,en;q=0.8
> >>        4. Access-Control-Request-Headers:
> >>        authorization, content-type
> >>        5. Access-Control-Request-Method:
> >>        POST
> >>        6. Connection:
> >>        keep-alive
> >>        7. Host:
> >>        localhost:8080
> >>        8. Origin:
> >>        http://127.0.0.1:8888
> >>        9. Referer:
> >>        http://127.0.0.1:8888/Main.html
> >>        10. User-Agent:
> >>        Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML,
> like
> >>        Gecko) Chrome/39.0.2171.71 Safari/537.36
> >>        6. Response Headersview source
> >>        1. Access-Control-Allow-Credentials:
> >>        true
> >>        2. Access-Control-Allow-Headers:
> >>        Origin, Accept, X-Requested-With, Content-Type,
> >>        Access-Control-Request-Method, Access-Control-Request-Headers,
> >> Authorization
> >>        3. Access-Control-Allow-Methods:
> >>        GET, HEAD, OPTIONS
> >>        4. Access-Control-Allow-Origin:
> >>        http://127.0.0.1:8888
> >>        5. Access-Control-Max-Age:
> >>        3600
> >>        6. Connection:
> >>        keep-alive
> >>        7. Content-Length:
> >>        0
> >>        8. Date:
> >>        Tue, 02 Dec 2014 15:00:32 GMT
> >>        9. Server:
> >>        WildFly/8
> >>        10. X-Powered-By:
> >>        Undertow/1
> >>
> >>
> >> Followed by the actual refresh:
> >>
> >>
> >>     1. Remote Address:
> >>     127.0.0.1:8080
> >>     2. Request URL:
> >>     http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
> >>     3. Request Method:
> >>     POST
> >>     4. Status Code:
> >>     200 OK
> >>     5. Request Headersview source
> >>        1. Accept:
> >>        */*
> >>        2. Accept-Encoding:
> >>        gzip, deflate
> >>        3. Accept-Language:
> >>        en-US,en;q=0.8
> >>        4. Authorization:
> >>        Basic
> R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
> >>        5. Connection:
> >>        keep-alive
> >>        6. Content-Length:
> >>        699
> >>        7. Content-type:
> >>        application/x-www-form-urlencoded
> >>        8. Host:
> >>        localhost:8080
> >>        9. Origin:
> >>        http://127.0.0.1:8888
> >>        10. Referer:
> >>        http://127.0.0.1:8888/Main.html
> >>        11. User-Agent:
> >>        Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML,
> like
> >>        Gecko) Chrome/39.0.2171.71 Safari/537.36
> >>        6. Form Dataview sourceview URL encoded
> >>        1. grant_type:
> >>        refresh_token
> >>        2. refresh_token:
> >>
> >>
> eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
> >>        7. Response Headersview source
> >>        1. Access-Control-Allow-Credentials:
> >>        true
> >>        2. Access-Control-Allow-Headers:
> >>        Origin, Accept, X-Requested-With, Content-Type,
> >>        Access-Control-Request-Method, Access-Control-Request-Headers,
> >> Authorization
> >>        3. Access-Control-Allow-Methods:
> >>        POST
> >>        4. Access-Control-Allow-Origin:
> >>        http://127.0.0.1:8888
> >>        5. Access-Control-Expose-Headers:
> >>        Access-Control-Allow-Methods
> >>        6. Access-Control-Max-Age:
> >>        3600
> >>        7. Connection:
> >>        keep-alive
> >>        8. Content-Type:
> >>        application/json
> >>        9. Date:
> >>        Tue, 02 Dec 2014 15:00:32 GMT
> >>        10. Server:
> >>        WildFly/8
> >>        11. Transfer-Encoding:
> >>        chunked
> >>        12. X-Powered-By:
> >>        Undertow/1
> >>
> >>
> >>
> >>
> >> On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen <stian at redhat.com>
> wrote:
> >>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Alain Penders" <alain at rexorient.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 2 December, 2014 3:43:13 PM
> >>>> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> >>>>
> >>>> I'm testing my UI using GWTs Super Dev Mode, which means its origin is
> >>> set
> >>>> to http://127.0.0.1:8888.    Keycloak runs on
> http://127.0.0.1:8080/auth
> >>> .
> >>>
> >>> Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
> >>> request. My guess is that "GWTs Super Dev Mode" sets some custom
> headers on
> >>> all requests.
> >>>
> >>>>
> >>>> On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian at redhat.com>
> >>> wrote:
> >>>>
> >>>>> It's the correct approach to add the preflight. Please send a PR and
> >>> we'll
> >>>>> merge it.
> >>>>>
> >>>>> Out of curiosity do you know why it's sending a preflight in your
> app?
> >>> It
> >>>>> doesn't when I test it out here, which AFAIK is correct according to
> >>> spec
> >>>>> (content-type is application/x-www-form-urlencoded and there's no
> >>> custom
> >>>>> headers set).
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Alain Penders" <alain at rexorient.com>
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Tuesday, 2 December, 2014 3:04:50 PM
> >>>>>> Subject: [keycloak-dev] Fwd: Preflight for token refresh
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I'm building a new app using GWT 2.7 using the Keycloak javascript
> >>>>> adapter
> >>>>>> and GWT jsInterop. This works extremely well.
> >>>>>>
> >>>>>> The problem I ran into is if I walk away for 5 minutes and then try
> >>> to do
> >>>>>> something, the token refresh fails on preflight. As shown in the
> >>>>>> documentation, I call keycloak.updateToken(30) to refresh the base
> >>> token
> >>>>> in
> >>>>>> case it has expired. Since in this case it has indeed expired,
> >>> keycloak
> >>>>>> makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS
> >>> call
> >>>>> to
> >>>>>> this location doesn't contain the Accept headers, and my app ends up
> >>>>> dead in
> >>>>>> the water.
> >>>>>>
> >>>>>> To fix this, I added the following code to OpenIDConnectService:
> >>>>>>
> >>>>>> /**
> >>>>>> * CORS preflight path for refresh token requests
> >>>>>> *
> >>>>>> * @return
> >>>>>> */
> >>>>>> @Path("refresh")
> >>>>>> @OPTIONS
> >>>>>> @Produces(MediaType.APPLICATION_JSON)
> >>>>>> public Response refreshAccessTokenPreflight() {
> >>>>>> if (logger.isDebugEnabled()) {
> >>>>>> logger.debugv("cors request from: {0}",
> >>>>>> request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> >>>>>> }
> >>>>>> return Cors.add(request, Response.ok()).auth().preflight().build();
> >>>>>> }
> >>>>>>
> >>>>>> If this wasn't the correct solution for my problem, I'd enjoy
> hearing
> >>>>> where I
> >>>>>> went wrong.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Alain
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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/20141202/66486019/attachment-0001.html 

From stian at redhat.com  Tue Dec  2 10:40:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 10:40:34 -0500 (EST)
Subject: [keycloak-dev] Fwd: Preflight for token refresh
In-Reply-To: <CAMtP740DdF+O33+=RqKNDmX+BX=_ZE_jPrRMuE-KU5ODnNvk2w@mail.gmail.com>
References: <CAMtP741XmZQiVYMBh6WaEaiYbrm5C7wPf+VAFY9VS92QTZOA_w@mail.gmail.com>
	<1967599145.8787926.1417530741784.JavaMail.zimbra@redhat.com>
	<CAMtP742pazk9OrG90J9tL1aMMfWib4aK9h4EkTO-ARFpn0N=VA@mail.gmail.com>
	<1932903918.8811689.1417531768234.JavaMail.zimbra@redhat.com>
	<CAMtP741HU9eaAbeHowFEEyQp9R+S=ZfXxfh=rWjdKwRpf6t78A@mail.gmail.com>
	<1718295184.8837465.1417533001973.JavaMail.zimbra@redhat.com>
	<547DD9A9.6040204@redhat.com>
	<CAMtP740DdF+O33+=RqKNDmX+BX=_ZE_jPrRMuE-KU5ODnNvk2w@mail.gmail.com>
Message-ID: <1667749226.8880098.1417534834964.JavaMail.zimbra@redhat.com>

Yes, I meant public ;)

Yes, please do the PR. I can't see any harm in supporting PREFLIGHT, in fact we already do for code->token.

----- Original Message -----
> From: "Alain Penders" <alain at rexorient.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 4:33:54 PM
> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> 
> I was about to say "I am using confidential". Switching to public does indeed
> drop the need for preflight. Learned something new :-)
> 
> Still want me to submit a PR for the refresh preflight? Obviously using
> confidential doesn't add any security here, but I don't think supporting it
> can hurt either (and the JavaScript code supports it already.)
> 
> 
> On Tue, Dec 2, 2014 at 8:24 AM, Bill Burke < bburke at redhat.com > wrote:
> 
> 
> You mean the "public" application type.
> 
> On 12/2/2014 10:10 AM, Stian Thorgersen wrote:
> > The code->token and refresh token requests are being pre-flighted because
> > there's a 'Authorization: Basic' header in there. For a GWT app you should
> > use the confidential application type, which doesn't require a secret.
> > 
> > ----- Original Message -----
> >> From: "Alain Penders" < alain at rexorient.com >
> >> To: "Stian Thorgersen" < stian at redhat.com >
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 2 December, 2014 4:02:15 PM
> >> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> >> 
> >> Not really. It needs CORS for every URI it hits. Refresh is a different
> >> URI from the code->token exchange one it uses initially.
> >> 
> >> When Keycloak redirects back to the GWT app and the code is exchanged for
> >> the tokens, I see this in the Network trace:
> >> 
> >> First an OPTIONS request:
> >> 
> >> 
> >> 1. Remote Address:
> >> 127.0.0.1:8080
> >> 2. Request URL:
> >> http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
> >> 3. Request Method:
> >> OPTIONS
> >> 4. Status Code:
> >> 200 OK
> >> 5. Request Headersview source
> >> 1. Accept:
> >> */*
> >> 2. Accept-Encoding:
> >> gzip, deflate, sdch
> >> 3. Accept-Language:
> >> en-US,en;q=0.8
> >> 4. Access-Control-Request-Headers:
> >> authorization, content-type
> >> 5. Access-Control-Request-Method:
> >> POST
> >> 6. Connection:
> >> keep-alive
> >> 7. Host:
> >> localhost:8080
> >> 8. Origin:
> >> http://127.0.0.1:8888
> >> 9. Referer:
> >> http://127.0.0.1:8888/Main.html
> >> 10. User-Agent:
> >> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
> >> Gecko) Chrome/39.0.2171.71 Safari/537.36
> >> 6. Response Headersview source
> >> 1. Access-Control-Allow-Credentials:
> >> true
> >> 2. Access-Control-Allow-Headers:
> >> Origin, Accept, X-Requested-With, Content-Type,
> >> Access-Control-Request-Method, Access-Control-Request-Headers,
> >> Authorization
> >> 3. Access-Control-Allow-Methods:
> >> GET, HEAD, OPTIONS
> >> 4. Access-Control-Allow-Origin:
> >> http://127.0.0.1:8888
> >> 5. Access-Control-Max-Age:
> >> 3600
> >> 6. Connection:
> >> keep-alive
> >> 7. Content-Length:
> >> 0
> >> 8. Date:
> >> Tue, 02 Dec 2014 14:51:47 GMT
> >> 9. Server:
> >> WildFly/8
> >> 10. X-Powered-By:
> >> Undertow/1
> >> 
> >> 
> >> Then the actual code exchange request:
> >> 
> >> 
> >> 1. Remote Address:
> >> 127.0.0.1:8080
> >> 2. Request URL:
> >> http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
> >> 3. Request Method:
> >> POST
> >> 4. Status Code:
> >> 200 OK
> >> 5. Request Headersview source
> >> 1. Accept:
> >> */*
> >> 2. Accept-Encoding:
> >> gzip, deflate
> >> 3. Accept-Language:
> >> en-US,en;q=0.8
> >> 4. Authorization:
> >> Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
> >> 5. Connection:
> >> keep-alive
> >> 6. Content-Length:
> >> 85
> >> 7. Content-type:
> >> application/x-www-form-urlencoded
> >> 8. Cookie:
> >> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
> >> KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
> >> KEYCLOAK_REMEMBER_ME=username:alain
> >> 9. Host:
> >> localhost:8080
> >> 10. Origin:
> >> http://127.0.0.1:8888
> >> 11. Referer:
> >> http://127.0.0.1:8888/Main.html
> >> 12. User-Agent:
> >> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
> >> Gecko) Chrome/39.0.2171.71 Safari/537.36
> >> 6. Form Dataview sourceview URL encoded
> >> 1. code:
> >> 
> >> sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
> >> 7. Response Headersview source
> >> 1. Access-Control-Allow-Credentials:
> >> true
> >> 2. Access-Control-Allow-Headers:
> >> Origin, Accept, X-Requested-With, Content-Type,
> >> Access-Control-Request-Method, Access-Control-Request-Headers,
> >> Authorization
> >> 3. Access-Control-Allow-Methods:
> >> POST
> >> 4. Access-Control-Allow-Origin:
> >> http://127.0.0.1:8888
> >> 5. Access-Control-Expose-Headers:
> >> Access-Control-Allow-Methods
> >> 6. Access-Control-Max-Age:
> >> 3600
> >> 7. Connection:
> >> keep-alive
> >> 8. Content-Type:
> >> application/json
> >> 9. Date:
> >> Tue, 02 Dec 2014 14:51:47 GMT
> >> 10. Server:
> >> WildFly/8
> >> 11. Transfer-Encoding:
> >> chunked
> >> 12. X-Powered-By:
> >> Undertow/1
> >> 
> >> 
> >> Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
> >> this uses the refresh URI for the first time, Chrome performs a preflight
> >> check:
> >> 
> >> 
> >> 1. Remote Address:
> >> 127.0.0.1:8080
> >> 2. Request URL:
> >> http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
> >> 3. Request Method:
> >> OPTIONS
> >> 4. Status Code:
> >> 200 OK
> >> 5. Request Headersview source
> >> 1. Accept:
> >> */*
> >> 2. Accept-Encoding:
> >> gzip, deflate, sdch
> >> 3. Accept-Language:
> >> en-US,en;q=0.8
> >> 4. Access-Control-Request-Headers:
> >> authorization, content-type
> >> 5. Access-Control-Request-Method:
> >> POST
> >> 6. Connection:
> >> keep-alive
> >> 7. Host:
> >> localhost:8080
> >> 8. Origin:
> >> http://127.0.0.1:8888
> >> 9. Referer:
> >> http://127.0.0.1:8888/Main.html
> >> 10. User-Agent:
> >> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
> >> Gecko) Chrome/39.0.2171.71 Safari/537.36
> >> 6. Response Headersview source
> >> 1. Access-Control-Allow-Credentials:
> >> true
> >> 2. Access-Control-Allow-Headers:
> >> Origin, Accept, X-Requested-With, Content-Type,
> >> Access-Control-Request-Method, Access-Control-Request-Headers,
> >> Authorization
> >> 3. Access-Control-Allow-Methods:
> >> GET, HEAD, OPTIONS
> >> 4. Access-Control-Allow-Origin:
> >> http://127.0.0.1:8888
> >> 5. Access-Control-Max-Age:
> >> 3600
> >> 6. Connection:
> >> keep-alive
> >> 7. Content-Length:
> >> 0
> >> 8. Date:
> >> Tue, 02 Dec 2014 15:00:32 GMT
> >> 9. Server:
> >> WildFly/8
> >> 10. X-Powered-By:
> >> Undertow/1
> >> 
> >> 
> >> Followed by the actual refresh:
> >> 
> >> 
> >> 1. Remote Address:
> >> 127.0.0.1:8080
> >> 2. Request URL:
> >> http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
> >> 3. Request Method:
> >> POST
> >> 4. Status Code:
> >> 200 OK
> >> 5. Request Headersview source
> >> 1. Accept:
> >> */*
> >> 2. Accept-Encoding:
> >> gzip, deflate
> >> 3. Accept-Language:
> >> en-US,en;q=0.8
> >> 4. Authorization:
> >> Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
> >> 5. Connection:
> >> keep-alive
> >> 6. Content-Length:
> >> 699
> >> 7. Content-type:
> >> application/x-www-form-urlencoded
> >> 8. Host:
> >> localhost:8080
> >> 9. Origin:
> >> http://127.0.0.1:8888
> >> 10. Referer:
> >> http://127.0.0.1:8888/Main.html
> >> 11. User-Agent:
> >> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
> >> Gecko) Chrome/39.0.2171.71 Safari/537.36
> >> 6. Form Dataview sourceview URL encoded
> >> 1. grant_type:
> >> refresh_token
> >> 2. refresh_token:
> >> 
> >> eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
> >> 7. Response Headersview source
> >> 1. Access-Control-Allow-Credentials:
> >> true
> >> 2. Access-Control-Allow-Headers:
> >> Origin, Accept, X-Requested-With, Content-Type,
> >> Access-Control-Request-Method, Access-Control-Request-Headers,
> >> Authorization
> >> 3. Access-Control-Allow-Methods:
> >> POST
> >> 4. Access-Control-Allow-Origin:
> >> http://127.0.0.1:8888
> >> 5. Access-Control-Expose-Headers:
> >> Access-Control-Allow-Methods
> >> 6. Access-Control-Max-Age:
> >> 3600
> >> 7. Connection:
> >> keep-alive
> >> 8. Content-Type:
> >> application/json
> >> 9. Date:
> >> Tue, 02 Dec 2014 15:00:32 GMT
> >> 10. Server:
> >> WildFly/8
> >> 11. Transfer-Encoding:
> >> chunked
> >> 12. X-Powered-By:
> >> Undertow/1
> >> 
> >> 
> >> 
> >> 
> >> On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen < stian at redhat.com >
> >> wrote:
> >> 
> >>> 
> >>> 
> >>> ----- Original Message -----
> >>>> From: "Alain Penders" < alain at rexorient.com >
> >>>> To: "Stian Thorgersen" < stian at redhat.com >
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 2 December, 2014 3:43:13 PM
> >>>> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> >>>> 
> >>>> I'm testing my UI using GWTs Super Dev Mode, which means its origin is
> >>> set
> >>>> to http://127.0.0.1:8888 . Keycloak runs on http://127.0.0.1:8080/auth
> >>> .
> >>> 
> >>> Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
> >>> request. My guess is that "GWTs Super Dev Mode" sets some custom headers
> >>> on
> >>> all requests.
> >>> 
> >>>> 
> >>>> On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen < stian at redhat.com >
> >>> wrote:
> >>>> 
> >>>>> It's the correct approach to add the preflight. Please send a PR and
> >>> we'll
> >>>>> merge it.
> >>>>> 
> >>>>> Out of curiosity do you know why it's sending a preflight in your app?
> >>> It
> >>>>> doesn't when I test it out here, which AFAIK is correct according to
> >>> spec
> >>>>> (content-type is application/x-www-form-urlencoded and there's no
> >>> custom
> >>>>> headers set).
> >>>>> 
> >>>>> ----- Original Message -----
> >>>>>> From: "Alain Penders" < alain at rexorient.com >
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Tuesday, 2 December, 2014 3:04:50 PM
> >>>>>> Subject: [keycloak-dev] Fwd: Preflight for token refresh
> >>>>>> 
> >>>>>> Hi all,
> >>>>>> 
> >>>>>> I'm building a new app using GWT 2.7 using the Keycloak javascript
> >>>>> adapter
> >>>>>> and GWT jsInterop. This works extremely well.
> >>>>>> 
> >>>>>> The problem I ran into is if I walk away for 5 minutes and then try
> >>> to do
> >>>>>> something, the token refresh fails on preflight. As shown in the
> >>>>>> documentation, I call keycloak.updateToken(30) to refresh the base
> >>> token
> >>>>> in
> >>>>>> case it has expired. Since in this case it has indeed expired,
> >>> keycloak
> >>>>>> makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS
> >>> call
> >>>>> to
> >>>>>> this location doesn't contain the Accept headers, and my app ends up
> >>>>> dead in
> >>>>>> the water.
> >>>>>> 
> >>>>>> To fix this, I added the following code to OpenIDConnectService:
> >>>>>> 
> >>>>>> /**
> >>>>>> * CORS preflight path for refresh token requests
> >>>>>> *
> >>>>>> * @return
> >>>>>> */
> >>>>>> @Path("refresh")
> >>>>>> @OPTIONS
> >>>>>> @Produces(MediaType.APPLICATION_JSON)
> >>>>>> public Response refreshAccessTokenPreflight() {
> >>>>>> if (logger.isDebugEnabled()) {
> >>>>>> logger.debugv("cors request from: {0}",
> >>>>>> request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> >>>>>> }
> >>>>>> return Cors.add(request, Response.ok()).auth().preflight().build();
> >>>>>> }
> >>>>>> 
> >>>>>> If this wasn't the correct solution for my problem, I'd enjoy hearing
> >>>>> where I
> >>>>>> went wrong.
> >>>>>> 
> >>>>>> Thanks,
> >>>>>> Alain
> >>>>>> 
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> 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
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Tue Dec  2 10:53:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 10:53:11 -0500 (EST)
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547DD697.5030909@redhat.com>
References: <547C8466.4050103@redhat.com> <547C8F0B.4060904@redhat.com>
	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
	<547DB6A7.8040200@redhat.com> <547DC0D8.9000404@redhat.com>
	<2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
	<547DD697.5030909@redhat.com>
Message-ID: <1850709811.8894994.1417535591934.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, 2 December, 2014 4:11:19 PM
> Subject: Re: [keycloak-dev] release?  Stan?
> 
> 
> 
> On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 2 December, 2014 2:38:32 PM
> >> Subject: Re: [keycloak-dev] release?  Stan?
> >>
> >>
> >>
> >> On 12/2/2014 7:55 AM, Stan Silvert wrote:
> >>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
> >>>> Should we upgrade to WF 8.2 and also do some changes to the distro
> >>>> before
> >>>> release?
> >>> I don't see a reason not to go to WF 8.2.  If we do that, let me know so
> >>> I can run a quick smoke test on the subsystem before we release.
> >>>>
> >>>> With regards to distro we should move the adapters and examples into
> >>>> separate downloads. Also, we should move the examples into a separate
> >>>> github project (keycloak/keycloak-examples). This will make it easier
> >>>> for
> >>>> those that wants to fork the examples separately.
> >>>>
> >>>> Also, we should consider a download based on the web-lite profile. For
> >>>> non-JavaEE apps, containers (Docker) and those that want to run a
> >>>> standalone KC server it would be nice to have a small as possible
> >>>> distro.
> >>> Depending on how the feature pack turns out, we might be able to offer
> >>> many flavors of the appliance distro without any additional effort.  We
> >>> could have:
> >>> EAP6 + Keycloak
> >>> AS7 + Keycloak
> >>> WF8 (web) + Keycloak
> >>> WF8 (full) + Keycloak
> >>> WF 9 beta (web) + Keycloak
> >>> WF 9 beta (full) + Keycloak
> >>> etc.
> >>>
> >>
> >> IMO, we just need:
> >> * war-dist
> >> * appliance-dist
> >>
> >> Appliance distribution would have the most stable platform available.
> >> Since we can't distribute EAP, then it would be the most stable and
> >> maintained version of Wildfly that allows us to cluster and deploy
> >> Keycloak.
> >
> > Our download at the moment is 160MB and is really aimed at the first-time
> > JavaEE user (bundled with examples and documentation). Why should we
> > require someone that just wants to upgrade their server to download all of
> > that? There'll also be loads of people that don't need the JavaEE parts, a
> > NodeJS developer or deploying to cloud for example. I think we could
> > easily have a standalone Keycloak server download that'd be around 30MB.
> >
> > IMO we should have:
> >
> > * Minimal server (based on WildFly web/core)
> > * Full server (based on WildFly full)
> > * Feature pack - to easily install onto other version of WF, EAP, etc.
> >
> > Neither of those downloads should include docs or examples. As we don't
> > really support installing onto Tomcat or Jetty, why have a war-dist?
> >
> 
> I disagree.  At least one download should have everything:  docs,
> examples, and a distro that can run the examples.  Reducing even simple
> steps for 1st time users is crucial to adoption.  How fast a first time
> user can get "hello world" running is crucial.  BTW, That's a major
> reason why your suggestion earlier of having examples on Github is not a
> great idea.

WildFly, PicketLink, Infinispan, etc. all use the same approach for quickstarts. They're in GitHub in a separate project, which can easily be forked/cloned by users. This is IMO a much better way to get started than downloading a zip. Problem is that currently we don't cater for those that want to fork/clone the examples as they have to do everything, which would at least stop me from doing it. If we put it in a separate project that doesn't stop us from releasing a bundle with everything in it. It just adds an extra step to the releasing, which could be automated with a script.

Personally, I download servers then read docs online and clone/fork examples/quickstarts. Second time around I don't need examples/quickstarts and it annoys me that I have to get a bundle with everything, when all I want is the server.

> 
> Why have a war-dist?  So we can deploy to EAP 6.  AFAIK, EAP 6 doesn't
> support feature packs.  war-dist could change to subsystem-dist I guess
> since, as you said, we don't really support installing into tomcat or jetty.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Tue Dec  2 10:55:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 10:55:17 -0500 (EST)
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <1850709811.8894994.1417535591934.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com> <547C8F0B.4060904@redhat.com>
	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
	<547DB6A7.8040200@redhat.com> <547DC0D8.9000404@redhat.com>
	<2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
	<547DD697.5030909@redhat.com>
	<1850709811.8894994.1417535591934.JavaMail.zimbra@redhat.com>
Message-ID: <771491386.8896925.1417535717882.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 4:53:11 PM
> Subject: Re: [keycloak-dev] release?  Stan?
> 
> 
> 
> ----- 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, 2 December, 2014 4:11:19 PM
> > Subject: Re: [keycloak-dev] release?  Stan?
> > 
> > 
> > 
> > On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: keycloak-dev at lists.jboss.org
> > >> Sent: Tuesday, 2 December, 2014 2:38:32 PM
> > >> Subject: Re: [keycloak-dev] release?  Stan?
> > >>
> > >>
> > >>
> > >> On 12/2/2014 7:55 AM, Stan Silvert wrote:
> > >>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
> > >>>> Should we upgrade to WF 8.2 and also do some changes to the distro
> > >>>> before
> > >>>> release?
> > >>> I don't see a reason not to go to WF 8.2.  If we do that, let me know
> > >>> so
> > >>> I can run a quick smoke test on the subsystem before we release.
> > >>>>
> > >>>> With regards to distro we should move the adapters and examples into
> > >>>> separate downloads. Also, we should move the examples into a separate
> > >>>> github project (keycloak/keycloak-examples). This will make it easier
> > >>>> for
> > >>>> those that wants to fork the examples separately.
> > >>>>
> > >>>> Also, we should consider a download based on the web-lite profile. For
> > >>>> non-JavaEE apps, containers (Docker) and those that want to run a
> > >>>> standalone KC server it would be nice to have a small as possible
> > >>>> distro.
> > >>> Depending on how the feature pack turns out, we might be able to offer
> > >>> many flavors of the appliance distro without any additional effort.  We
> > >>> could have:
> > >>> EAP6 + Keycloak
> > >>> AS7 + Keycloak
> > >>> WF8 (web) + Keycloak
> > >>> WF8 (full) + Keycloak
> > >>> WF 9 beta (web) + Keycloak
> > >>> WF 9 beta (full) + Keycloak
> > >>> etc.
> > >>>
> > >>
> > >> IMO, we just need:
> > >> * war-dist
> > >> * appliance-dist
> > >>
> > >> Appliance distribution would have the most stable platform available.
> > >> Since we can't distribute EAP, then it would be the most stable and
> > >> maintained version of Wildfly that allows us to cluster and deploy
> > >> Keycloak.
> > >
> > > Our download at the moment is 160MB and is really aimed at the first-time
> > > JavaEE user (bundled with examples and documentation). Why should we
> > > require someone that just wants to upgrade their server to download all
> > > of
> > > that? There'll also be loads of people that don't need the JavaEE parts,
> > > a
> > > NodeJS developer or deploying to cloud for example. I think we could
> > > easily have a standalone Keycloak server download that'd be around 30MB.
> > >
> > > IMO we should have:
> > >
> > > * Minimal server (based on WildFly web/core)
> > > * Full server (based on WildFly full)
> > > * Feature pack - to easily install onto other version of WF, EAP, etc.
> > >
> > > Neither of those downloads should include docs or examples. As we don't
> > > really support installing onto Tomcat or Jetty, why have a war-dist?
> > >
> > 
> > I disagree.  At least one download should have everything:  docs,
> > examples, and a distro that can run the examples.  Reducing even simple
> > steps for 1st time users is crucial to adoption.  How fast a first time
> > user can get "hello world" running is crucial.  BTW, That's a major
> > reason why your suggestion earlier of having examples on Github is not a
> > great idea.
> 
> WildFly, PicketLink, Infinispan, etc. all use the same approach for
> quickstarts. They're in GitHub in a separate project, which can easily be
> forked/cloned by users. This is IMO a much better way to get started than
> downloading a zip. Problem is that currently we don't cater for those that
> want to fork/clone the examples as they have to do everything, which would
> at least stop me from doing it. If we put it in a separate project that
> doesn't stop us from releasing a bundle with everything in it. It just adds
> an extra step to the releasing, which could be automated with a script.
> 
> Personally, I download servers then read docs online and clone/fork
> examples/quickstarts. Second time around I don't need examples/quickstarts
> and it annoys me that I have to get a bundle with everything, when all I
> want is the server.

Oh and I also want the download to be available in both zip and tgz ;)

> 
> > 
> > Why have a war-dist?  So we can deploy to EAP 6.  AFAIK, EAP 6 doesn't
> > support feature packs.  war-dist could change to subsystem-dist I guess
> > since, as you said, we don't really support installing into tomcat or
> > jetty.
> > 
> > 
> > --
> > 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 Dec  2 11:31:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Dec 2014 11:31:12 -0500
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <1850709811.8894994.1417535591934.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com> <547C8F0B.4060904@redhat.com>
	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
	<547DB6A7.8040200@redhat.com> <547DC0D8.9000404@redhat.com>
	<2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
	<547DD697.5030909@redhat.com>
	<1850709811.8894994.1417535591934.JavaMail.zimbra@redhat.com>
Message-ID: <547DE950.4020702@redhat.com>



On 12/2/2014 10:53 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 2 December, 2014 4:11:19 PM
>> Subject: Re: [keycloak-dev] release?  Stan?
>>
>>
>>
>> On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 2 December, 2014 2:38:32 PM
>>>> Subject: Re: [keycloak-dev] release?  Stan?
>>>>
>>>>
>>>>
>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
>>>>>> before
>>>>>> release?
>>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me know so
>>>>> I can run a quick smoke test on the subsystem before we release.
>>>>>>
>>>>>> With regards to distro we should move the adapters and examples into
>>>>>> separate downloads. Also, we should move the examples into a separate
>>>>>> github project (keycloak/keycloak-examples). This will make it easier
>>>>>> for
>>>>>> those that wants to fork the examples separately.
>>>>>>
>>>>>> Also, we should consider a download based on the web-lite profile. For
>>>>>> non-JavaEE apps, containers (Docker) and those that want to run a
>>>>>> standalone KC server it would be nice to have a small as possible
>>>>>> distro.
>>>>> Depending on how the feature pack turns out, we might be able to offer
>>>>> many flavors of the appliance distro without any additional effort.  We
>>>>> could have:
>>>>> EAP6 + Keycloak
>>>>> AS7 + Keycloak
>>>>> WF8 (web) + Keycloak
>>>>> WF8 (full) + Keycloak
>>>>> WF 9 beta (web) + Keycloak
>>>>> WF 9 beta (full) + Keycloak
>>>>> etc.
>>>>>
>>>>
>>>> IMO, we just need:
>>>> * war-dist
>>>> * appliance-dist
>>>>
>>>> Appliance distribution would have the most stable platform available.
>>>> Since we can't distribute EAP, then it would be the most stable and
>>>> maintained version of Wildfly that allows us to cluster and deploy
>>>> Keycloak.
>>>
>>> Our download at the moment is 160MB and is really aimed at the first-time
>>> JavaEE user (bundled with examples and documentation). Why should we
>>> require someone that just wants to upgrade their server to download all of
>>> that? There'll also be loads of people that don't need the JavaEE parts, a
>>> NodeJS developer or deploying to cloud for example. I think we could
>>> easily have a standalone Keycloak server download that'd be around 30MB.
>>>
>>> IMO we should have:
>>>
>>> * Minimal server (based on WildFly web/core)
>>> * Full server (based on WildFly full)
>>> * Feature pack - to easily install onto other version of WF, EAP, etc.
>>>
>>> Neither of those downloads should include docs or examples. As we don't
>>> really support installing onto Tomcat or Jetty, why have a war-dist?
>>>
>>
>> I disagree.  At least one download should have everything:  docs,
>> examples, and a distro that can run the examples.  Reducing even simple
>> steps for 1st time users is crucial to adoption.  How fast a first time
>> user can get "hello world" running is crucial.  BTW, That's a major
>> reason why your suggestion earlier of having examples on Github is not a
>> great idea.
>
> WildFly, PicketLink, Infinispan, etc. all use the same approach for quickstarts. They're in GitHub in a separate project, which can easily be forked/cloned by users. This is IMO a much better way to get started than downloading a zip. Problem is that currently we don't cater for those that want to fork/clone the examples as they have to do everything, which would at least stop me from doing it. If we put it in a separate project that doesn't stop us from releasing a bundle with everything in it. It just adds an extra step to the releasing, which could be automated with a script.
>

Just because everybody does it doesn't mean it is a good idea.  I really 
hate that they do that and have run into problems.  Let me give more 
reasons why it is a bad idea:

* A user may never have used github
* There may be an incompatibility with the version developer is using 
vs. the master example branch.
* Requires user to either edit example pom to point to desired project 
version or to checkout correct tag.
* Keycloak examples are currently active modules in our main git repo. 
They load up as a module in our IDE.  Examples are targeted for refactor 
events just like any other project.
* Keycloak examples are built with build.  Thus catching any compiler 
bugs that often happen when refactoring Keycloak SPIs, APIs, or whatever.

> Personally, I download servers then read docs online and clone/fork examples/quickstarts. Second time around I don't need examples/quickstarts and it annoys me that I have to get a bundle with everything, when all I want is the server.
>

The extra few seconds it takes to download and extract really bothers 
you that much?


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

From christian.beikov at gmail.com  Tue Dec  2 12:58:42 2014
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 02 Dec 2014 18:58:42 +0100
Subject: [keycloak-dev] Login with Access Token
Message-ID: <547DFDD2.4080500@gmail.com>

Hello!

I am new to OAuth so sorry if my question is dumb.
I have an App which wants to provide a custom and Facebook login. Since 
many people already have the Facebook App installed, I thought it might 
be better to give them the native experience and use the Facebook SDK to 
implement the login.
The problem now is, that I have the Access Token from the successful 
Facebook login, but don't know how to properly login at the Keycloak 
server with that.

Any ideas on how to do that? Or is that even stupid and is there a 
better way?
-- 

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141202/df4ab469/attachment.html 

From mposolda at redhat.com  Tue Dec  2 14:37:14 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 02 Dec 2014 20:37:14 +0100
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547DC0D8.9000404@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com>
Message-ID: <547E14EA.4040706@redhat.com>

One slightly related issue. I just did some testing and figured that 
eap6.3 and as7 distribution were broken as they excluded 
keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. But on 
AS 7.1.1 the keycloak-subsystem doesn't work and I have:

Caused by: java.lang.ClassNotFoundException: 
org.jboss.as.controller.OperationDefinition from [Module 
"org.keycloak.keycloak-subsystem:main"

I am seeing options like:
1) Drop AS7 support
2) Revert AS7 specific subsystem
3) Do some hack in keycloak-subsystem to have it working on AS 7.1.1 (is 
it doable?)

Anything else I am missing?

Marek

On 2.12.2014 14:38, Bill Burke wrote:
>
> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>> Should we upgrade to WF 8.2 and also do some changes to the distro before release?
>> I don't see a reason not to go to WF 8.2.  If we do that, let me know so
>> I can run a quick smoke test on the subsystem before we release.
>>> With regards to distro we should move the adapters and examples into separate downloads. Also, we should move the examples into a separate github project (keycloak/keycloak-examples). This will make it easier for those that wants to fork the examples separately.
>>>
>>> Also, we should consider a download based on the web-lite profile. For non-JavaEE apps, containers (Docker) and those that want to run a standalone KC server it would be nice to have a small as possible distro.
>> Depending on how the feature pack turns out, we might be able to offer
>> many flavors of the appliance distro without any additional effort.  We
>> could have:
>> EAP6 + Keycloak
>> AS7 + Keycloak
>> WF8 (web) + Keycloak
>> WF8 (full) + Keycloak
>> WF 9 beta (web) + Keycloak
>> WF 9 beta (full) + Keycloak
>> etc.
>>
> IMO, we just need:
> * war-dist
> * appliance-dist
>
> Appliance distribution would have the most stable platform available.
> Since we can't distribute EAP, then it would be the most stable and
> maintained version of Wildfly that allows us to cluster and deploy Keycloak.
>
>


From bburke at redhat.com  Tue Dec  2 14:49:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Dec 2014 14:49:50 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E14EA.4040706@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com> <547E14EA.4040706@redhat.com>
Message-ID: <547E17DE.8000309@redhat.com>

We should keep as7 adapter support at least.  We support older versions 
of Jetty and tomcat too, it would be strange not to support AS7. 
Hopefully stan has a fix.

Looking at it, it looks like OperationDefinition is only within 
auth-server subsystem.  That could be the "hack' you're talkin about.

Shouldn't the auth-server and adapter should be separate subsystems anyways?

On 12/2/2014 2:37 PM, Marek Posolda wrote:
> One slightly related issue. I just did some testing and figured that
> eap6.3 and as7 distribution were broken as they excluded
> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. But on
> AS 7.1.1 the keycloak-subsystem doesn't work and I have:
>
> Caused by: java.lang.ClassNotFoundException:
> org.jboss.as.controller.OperationDefinition from [Module
> "org.keycloak.keycloak-subsystem:main"
>
> I am seeing options like:
> 1) Drop AS7 support
> 2) Revert AS7 specific subsystem
> 3) Do some hack in keycloak-subsystem to have it working on AS 7.1.1 (is
> it doable?)
>
> Anything else I am missing?
>
> Marek
>
> On 2.12.2014 14:38, Bill Burke wrote:
>>
>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
>>>> before release?
>>> I don't see a reason not to go to WF 8.2.  If we do that, let me know so
>>> I can run a quick smoke test on the subsystem before we release.
>>>> With regards to distro we should move the adapters and examples into
>>>> separate downloads. Also, we should move the examples into a
>>>> separate github project (keycloak/keycloak-examples). This will make
>>>> it easier for those that wants to fork the examples separately.
>>>>
>>>> Also, we should consider a download based on the web-lite profile.
>>>> For non-JavaEE apps, containers (Docker) and those that want to run
>>>> a standalone KC server it would be nice to have a small as possible
>>>> distro.
>>> Depending on how the feature pack turns out, we might be able to offer
>>> many flavors of the appliance distro without any additional effort.  We
>>> could have:
>>> EAP6 + Keycloak
>>> AS7 + Keycloak
>>> WF8 (web) + Keycloak
>>> WF8 (full) + Keycloak
>>> WF 9 beta (web) + Keycloak
>>> WF 9 beta (full) + Keycloak
>>> etc.
>>>
>> IMO, we just need:
>> * war-dist
>> * appliance-dist
>>
>> Appliance distribution would have the most stable platform available.
>> Since we can't distribute EAP, then it would be the most stable and
>> maintained version of Wildfly that allows us to cluster and deploy
>> Keycloak.
>>
>>
>

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

From ssilvert at redhat.com  Tue Dec  2 14:55:02 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 02 Dec 2014 14:55:02 -0500
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547E14EA.4040706@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com> <547E14EA.4040706@redhat.com>
Message-ID: <547E1916.1090704@redhat.com>

I missed that after the subsys was renamed.  Thanks for cleaning it up.

I'll take a look at AS7.  Don't know why I never thought to test that.  
Sloppy, sloppy.

On 12/2/2014 2:37 PM, Marek Posolda wrote:
> One slightly related issue. I just did some testing and figured that
> eap6.3 and as7 distribution were broken as they excluded
> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. But on
> AS 7.1.1 the keycloak-subsystem doesn't work and I have:
>
> Caused by: java.lang.ClassNotFoundException:
> org.jboss.as.controller.OperationDefinition from [Module
> "org.keycloak.keycloak-subsystem:main"
>
> I am seeing options like:
> 1) Drop AS7 support
> 2) Revert AS7 specific subsystem
> 3) Do some hack in keycloak-subsystem to have it working on AS 7.1.1 (is
> it doable?)
>
> Anything else I am missing?
>
> Marek
>
> On 2.12.2014 14:38, Bill Burke wrote:
>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>> Should we upgrade to WF 8.2 and also do some changes to the distro before release?
>>> I don't see a reason not to go to WF 8.2.  If we do that, let me know so
>>> I can run a quick smoke test on the subsystem before we release.
>>>> With regards to distro we should move the adapters and examples into separate downloads. Also, we should move the examples into a separate github project (keycloak/keycloak-examples). This will make it easier for those that wants to fork the examples separately.
>>>>
>>>> Also, we should consider a download based on the web-lite profile. For non-JavaEE apps, containers (Docker) and those that want to run a standalone KC server it would be nice to have a small as possible distro.
>>> Depending on how the feature pack turns out, we might be able to offer
>>> many flavors of the appliance distro without any additional effort.  We
>>> could have:
>>> EAP6 + Keycloak
>>> AS7 + Keycloak
>>> WF8 (web) + Keycloak
>>> WF8 (full) + Keycloak
>>> WF 9 beta (web) + Keycloak
>>> WF 9 beta (full) + Keycloak
>>> etc.
>>>
>> IMO, we just need:
>> * war-dist
>> * appliance-dist
>>
>> Appliance distribution would have the most stable platform available.
>> Since we can't distribute EAP, then it would be the most stable and
>> maintained version of Wildfly that allows us to cluster and deploy Keycloak.
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Tue Dec  2 15:01:02 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 02 Dec 2014 21:01:02 +0100
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E17DE.8000309@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com> <547E14EA.4040706@redhat.com>
	<547E17DE.8000309@redhat.com>
Message-ID: <547E1A7E.80004@redhat.com>

Maybe an option is to keep just adapter support on AS7, but drop support 
for the auth-server itself on AS7? Of course, if we are able to somehow 
fix everything, it might be best option:-)

Marek

On 2.12.2014 20:49, Bill Burke wrote:
> We should keep as7 adapter support at least.  We support older 
> versions of Jetty and tomcat too, it would be strange not to support 
> AS7. Hopefully stan has a fix.
>
> Looking at it, it looks like OperationDefinition is only within 
> auth-server subsystem.  That could be the "hack' you're talkin about.
>
> Shouldn't the auth-server and adapter should be separate subsystems 
> anyways?
>
> On 12/2/2014 2:37 PM, Marek Posolda wrote:
>> One slightly related issue. I just did some testing and figured that
>> eap6.3 and as7 distribution were broken as they excluded
>> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. But on
>> AS 7.1.1 the keycloak-subsystem doesn't work and I have:
>>
>> Caused by: java.lang.ClassNotFoundException:
>> org.jboss.as.controller.OperationDefinition from [Module
>> "org.keycloak.keycloak-subsystem:main"
>>
>> I am seeing options like:
>> 1) Drop AS7 support
>> 2) Revert AS7 specific subsystem
>> 3) Do some hack in keycloak-subsystem to have it working on AS 7.1.1 (is
>> it doable?)
>>
>> Anything else I am missing?
>>
>> Marek
>>
>> On 2.12.2014 14:38, Bill Burke wrote:
>>>
>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
>>>>> before release?
>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me 
>>>> know so
>>>> I can run a quick smoke test on the subsystem before we release.
>>>>> With regards to distro we should move the adapters and examples into
>>>>> separate downloads. Also, we should move the examples into a
>>>>> separate github project (keycloak/keycloak-examples). This will make
>>>>> it easier for those that wants to fork the examples separately.
>>>>>
>>>>> Also, we should consider a download based on the web-lite profile.
>>>>> For non-JavaEE apps, containers (Docker) and those that want to run
>>>>> a standalone KC server it would be nice to have a small as possible
>>>>> distro.
>>>> Depending on how the feature pack turns out, we might be able to offer
>>>> many flavors of the appliance distro without any additional 
>>>> effort.  We
>>>> could have:
>>>> EAP6 + Keycloak
>>>> AS7 + Keycloak
>>>> WF8 (web) + Keycloak
>>>> WF8 (full) + Keycloak
>>>> WF 9 beta (web) + Keycloak
>>>> WF 9 beta (full) + Keycloak
>>>> etc.
>>>>
>>> IMO, we just need:
>>> * war-dist
>>> * appliance-dist
>>>
>>> Appliance distribution would have the most stable platform available.
>>> Since we can't distribute EAP, then it would be the most stable and
>>> maintained version of Wildfly that allows us to cluster and deploy
>>> Keycloak.
>>>
>>>
>>
>


From ssilvert at redhat.com  Tue Dec  2 15:05:04 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 02 Dec 2014 15:05:04 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E17DE.8000309@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com> <547E14EA.4040706@redhat.com>
	<547E17DE.8000309@redhat.com>
Message-ID: <547E1B70.8080702@redhat.com>

On 12/2/2014 2:49 PM, Bill Burke wrote:
> We should keep as7 adapter support at least.  We support older versions
> of Jetty and tomcat too, it would be strange not to support AS7.
> Hopefully stan has a fix.
>
> Looking at it, it looks like OperationDefinition is only within
> auth-server subsystem.  That could be the "hack' you're talkin about.
>
> Shouldn't the auth-server and adapter should be separate subsystems anyways?
They are seperated.  The auth-server runs from the subsystem.  The 
adapter is just an ordinary module.

I'm hoping this is just a naming issue that's easy to resolve.
>
> On 12/2/2014 2:37 PM, Marek Posolda wrote:
>> One slightly related issue. I just did some testing and figured that
>> eap6.3 and as7 distribution were broken as they excluded
>> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. But on
>> AS 7.1.1 the keycloak-subsystem doesn't work and I have:
>>
>> Caused by: java.lang.ClassNotFoundException:
>> org.jboss.as.controller.OperationDefinition from [Module
>> "org.keycloak.keycloak-subsystem:main"
>>
>> I am seeing options like:
>> 1) Drop AS7 support
>> 2) Revert AS7 specific subsystem
>> 3) Do some hack in keycloak-subsystem to have it working on AS 7.1.1 (is
>> it doable?)
>>
>> Anything else I am missing?
>>
>> Marek
>>
>> On 2.12.2014 14:38, Bill Burke wrote:
>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
>>>>> before release?
>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me know so
>>>> I can run a quick smoke test on the subsystem before we release.
>>>>> With regards to distro we should move the adapters and examples into
>>>>> separate downloads. Also, we should move the examples into a
>>>>> separate github project (keycloak/keycloak-examples). This will make
>>>>> it easier for those that wants to fork the examples separately.
>>>>>
>>>>> Also, we should consider a download based on the web-lite profile.
>>>>> For non-JavaEE apps, containers (Docker) and those that want to run
>>>>> a standalone KC server it would be nice to have a small as possible
>>>>> distro.
>>>> Depending on how the feature pack turns out, we might be able to offer
>>>> many flavors of the appliance distro without any additional effort.  We
>>>> could have:
>>>> EAP6 + Keycloak
>>>> AS7 + Keycloak
>>>> WF8 (web) + Keycloak
>>>> WF8 (full) + Keycloak
>>>> WF 9 beta (web) + Keycloak
>>>> WF 9 beta (full) + Keycloak
>>>> etc.
>>>>
>>> IMO, we just need:
>>> * war-dist
>>> * appliance-dist
>>>
>>> Appliance distribution would have the most stable platform available.
>>> Since we can't distribute EAP, then it would be the most stable and
>>> maintained version of Wildfly that allows us to cluster and deploy
>>> Keycloak.
>>>
>>>


From ssilvert at redhat.com  Tue Dec  2 15:12:45 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 02 Dec 2014 15:12:45 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E1A7E.80004@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com> <547E14EA.4040706@redhat.com>
	<547E17DE.8000309@redhat.com> <547E1A7E.80004@redhat.com>
Message-ID: <547E1D3D.2040209@redhat.com>

We may have other problems.  I just updated to the latest and OSGI core 
adapter fails to build.   I can continue what I'm doing because the AS7 
adapter built successfully.

See WARNING below.  Possibly a Windows problem?

[INFO] Building Keycloak OSGI Core Adapter Integration 1.1.0.Beta2-SNAPSHOT
[INFO] 
------------------------------------------------------------------------
[INFO]
[INFO] --- buildnumber-maven-plugin:1.3:create-timestamp 
(get-build-timestamp) @ keycloak-osgi-core-adapter ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.3:create (get-scm-revision) @ 
keycloak-osgi-core-adapter ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
keycloak-osgi-core-adapter ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered 
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
C:\GitHub\keycloak\distribution\osgi\core-adapter\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ 
keycloak-osgi-core-adapter ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-bundle-plugin:2.3.7:manifest (bundle-manifest) @ 
keycloak-osgi-core-adapter ---
[INFO] 
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Keycloak JBoss Modules ............................. SUCCESS [  
7.552 s]
[INFO] Keycloak AS7 Adapter Distro ........................ SUCCESS [  
0.798 s]
[INFO] Keycloak Tomcat 6 Adapter Distro ................... SUCCESS [  
0.438 s]
[INFO] Keycloak Tomcat 7 Adapter Distro ................... SUCCESS [  
0.185 s]
[INFO] Keycloak Tomcat 8 Adapter Distro ................... SUCCESS [  
0.168 s]
[INFO] Keycloak EAP6 Adapter Distro ....................... SUCCESS [  
0.738 s]
[INFO] Keycloak Wildfly Adapter Distro .................... SUCCESS [  
0.838 s]
[INFO] Keycloak Jetty 8.1.x Adapter Distro ................ SUCCESS [  
0.261 s]
[INFO] Keycloak Jetty 9.1.x Adapter Distro ................ SUCCESS [  
0.257 s]
[INFO] Keycloak Jetty 9.2.x Adapter Distro ................ SUCCESS [  
0.294 s]
[INFO] Keycloak Examples and Doc Distribution ............. SUCCESS [  
5.459 s]
[INFO] Keycloak Example Themes ............................ SUCCESS [  
1.361 s]
[INFO] Keycloak WAR Deployment For Wildfly/AS7/EAP ........ SUCCESS [  
1.657 s]
[INFO] Keycloak WAR Distribution .......................... SUCCESS [  
5.911 s]
[INFO] Keycloak OSGI Features ............................. SUCCESS [  
0.433 s]
[INFO] Keycloak OSGI Core Adapter Integration ............. FAILURE [  
0.328 s]
[INFO] Keycloak OSGI JAAS ................................. SKIPPED
[INFO] Keycloak OSGI Integration .......................... SKIPPED
[INFO] Proxy Distro ....................................... SKIPPED
[INFO] Keycloak Appliance Distribution .................... SKIPPED
[INFO] Keycloak Source Distribution ....................... SKIPPED
[INFO] Distribution ....................................... SKIPPED
[INFO] 
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] 
------------------------------------------------------------------------
[INFO] Total time: 27.514 s
[INFO] Finished at: 2014-12-02T15:06:24-05:00
[INFO] Final Memory: 54M/470M
[INFO] 
------------------------------------------------------------------------
[ERROR] Failed to execute goal 
org.apache.felix:maven-bundle-plugin:2.3.7:manifest (bundle-manifest) on 
project keycloak-osgi-core-adapter: Cannot find C:\GitHub\keycloak
\distribution\osgi\core-adapter\target\classes (manifest goal must be 
run after compile phase) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the 
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, 
please read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the 
command
[ERROR]   mvn <goals> -rf :keycloak-osgi-core-adapter

On 12/2/2014 3:01 PM, Marek Posolda wrote:
> Maybe an option is to keep just adapter support on AS7, but drop support
> for the auth-server itself on AS7? Of course, if we are able to somehow
> fix everything, it might be best option:-)
>
> Marek
>
> On 2.12.2014 20:49, Bill Burke wrote:
>> We should keep as7 adapter support at least.  We support older
>> versions of Jetty and tomcat too, it would be strange not to support
>> AS7. Hopefully stan has a fix.
>>
>> Looking at it, it looks like OperationDefinition is only within
>> auth-server subsystem.  That could be the "hack' you're talkin about.
>>
>> Shouldn't the auth-server and adapter should be separate subsystems
>> anyways?
>>
>> On 12/2/2014 2:37 PM, Marek Posolda wrote:
>>> One slightly related issue. I just did some testing and figured that
>>> eap6.3 and as7 distribution were broken as they excluded
>>> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. But on
>>> AS 7.1.1 the keycloak-subsystem doesn't work and I have:
>>>
>>> Caused by: java.lang.ClassNotFoundException:
>>> org.jboss.as.controller.OperationDefinition from [Module
>>> "org.keycloak.keycloak-subsystem:main"
>>>
>>> I am seeing options like:
>>> 1) Drop AS7 support
>>> 2) Revert AS7 specific subsystem
>>> 3) Do some hack in keycloak-subsystem to have it working on AS 7.1.1 (is
>>> it doable?)
>>>
>>> Anything else I am missing?
>>>
>>> Marek
>>>
>>> On 2.12.2014 14:38, Bill Burke wrote:
>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
>>>>>> before release?
>>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me
>>>>> know so
>>>>> I can run a quick smoke test on the subsystem before we release.
>>>>>> With regards to distro we should move the adapters and examples into
>>>>>> separate downloads. Also, we should move the examples into a
>>>>>> separate github project (keycloak/keycloak-examples). This will make
>>>>>> it easier for those that wants to fork the examples separately.
>>>>>>
>>>>>> Also, we should consider a download based on the web-lite profile.
>>>>>> For non-JavaEE apps, containers (Docker) and those that want to run
>>>>>> a standalone KC server it would be nice to have a small as possible
>>>>>> distro.
>>>>> Depending on how the feature pack turns out, we might be able to offer
>>>>> many flavors of the appliance distro without any additional
>>>>> effort.  We
>>>>> could have:
>>>>> EAP6 + Keycloak
>>>>> AS7 + Keycloak
>>>>> WF8 (web) + Keycloak
>>>>> WF8 (full) + Keycloak
>>>>> WF 9 beta (web) + Keycloak
>>>>> WF 9 beta (full) + Keycloak
>>>>> etc.
>>>>>
>>>> IMO, we just need:
>>>> * war-dist
>>>> * appliance-dist
>>>>
>>>> Appliance distribution would have the most stable platform available.
>>>> Since we can't distribute EAP, then it would be the most stable and
>>>> maintained version of Wildfly that allows us to cluster and deploy
>>>> Keycloak.
>>>>
>>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Tue Dec  2 15:36:03 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 02 Dec 2014 21:36:03 +0100
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E1D3D.2040209@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com> <547E14EA.4040706@redhat.com>
	<547E17DE.8000309@redhat.com> <547E1A7E.80004@redhat.com>
	<547E1D3D.2040209@redhat.com>
Message-ID: <547E22B3.2050300@redhat.com>

oops, thanks to you for reporting issue to me this time:-)

It should be fixed now. Let me know if it helps.

Marek

On 2.12.2014 21:12, Stan Silvert wrote:
> We may have other problems.  I just updated to the latest and OSGI 
> core adapter fails to build.   I can continue what I'm doing because 
> the AS7 adapter built successfully.
>
> See WARNING below.  Possibly a Windows problem?
>
> [INFO] Building Keycloak OSGI Core Adapter Integration 
> 1.1.0.Beta2-SNAPSHOT
> [INFO] 
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.3:create-timestamp 
> (get-build-timestamp) @ keycloak-osgi-core-adapter ---
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.3:create (get-scm-revision) @ 
> keycloak-osgi-core-adapter ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
> keycloak-osgi-core-adapter ---
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered 
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory 
> C:\GitHub\keycloak\distribution\osgi\core-adapter\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ 
> keycloak-osgi-core-adapter ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-bundle-plugin:2.3.7:manifest (bundle-manifest) @ 
> keycloak-osgi-core-adapter ---
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Keycloak JBoss Modules ............................. SUCCESS [  
> 7.552 s]
> [INFO] Keycloak AS7 Adapter Distro ........................ SUCCESS [  
> 0.798 s]
> [INFO] Keycloak Tomcat 6 Adapter Distro ................... SUCCESS [  
> 0.438 s]
> [INFO] Keycloak Tomcat 7 Adapter Distro ................... SUCCESS [  
> 0.185 s]
> [INFO] Keycloak Tomcat 8 Adapter Distro ................... SUCCESS [  
> 0.168 s]
> [INFO] Keycloak EAP6 Adapter Distro ....................... SUCCESS [  
> 0.738 s]
> [INFO] Keycloak Wildfly Adapter Distro .................... SUCCESS [  
> 0.838 s]
> [INFO] Keycloak Jetty 8.1.x Adapter Distro ................ SUCCESS [  
> 0.261 s]
> [INFO] Keycloak Jetty 9.1.x Adapter Distro ................ SUCCESS [  
> 0.257 s]
> [INFO] Keycloak Jetty 9.2.x Adapter Distro ................ SUCCESS [  
> 0.294 s]
> [INFO] Keycloak Examples and Doc Distribution ............. SUCCESS [  
> 5.459 s]
> [INFO] Keycloak Example Themes ............................ SUCCESS [  
> 1.361 s]
> [INFO] Keycloak WAR Deployment For Wildfly/AS7/EAP ........ SUCCESS [  
> 1.657 s]
> [INFO] Keycloak WAR Distribution .......................... SUCCESS [  
> 5.911 s]
> [INFO] Keycloak OSGI Features ............................. SUCCESS [  
> 0.433 s]
> [INFO] Keycloak OSGI Core Adapter Integration ............. FAILURE [  
> 0.328 s]
> [INFO] Keycloak OSGI JAAS ................................. SKIPPED
> [INFO] Keycloak OSGI Integration .......................... SKIPPED
> [INFO] Proxy Distro ....................................... SKIPPED
> [INFO] Keycloak Appliance Distribution .................... SKIPPED
> [INFO] Keycloak Source Distribution ....................... SKIPPED
> [INFO] Distribution ....................................... SKIPPED
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Total time: 27.514 s
> [INFO] Finished at: 2014-12-02T15:06:24-05:00
> [INFO] Final Memory: 54M/470M
> [INFO] 
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal 
> org.apache.felix:maven-bundle-plugin:2.3.7:manifest (bundle-manifest) 
> on project keycloak-osgi-core-adapter: Cannot find C:\GitHub\keycloak
> \distribution\osgi\core-adapter\target\classes (manifest goal must be 
> run after compile phase) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with 
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, 
> please read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with 
> the command
> [ERROR]   mvn <goals> -rf :keycloak-osgi-core-adapter
>
> On 12/2/2014 3:01 PM, Marek Posolda wrote:
>> Maybe an option is to keep just adapter support on AS7, but drop support
>> for the auth-server itself on AS7? Of course, if we are able to somehow
>> fix everything, it might be best option:-)
>>
>> Marek
>>
>> On 2.12.2014 20:49, Bill Burke wrote:
>>> We should keep as7 adapter support at least.  We support older
>>> versions of Jetty and tomcat too, it would be strange not to support
>>> AS7. Hopefully stan has a fix.
>>>
>>> Looking at it, it looks like OperationDefinition is only within
>>> auth-server subsystem.  That could be the "hack' you're talkin about.
>>>
>>> Shouldn't the auth-server and adapter should be separate subsystems
>>> anyways?
>>>
>>> On 12/2/2014 2:37 PM, Marek Posolda wrote:
>>>> One slightly related issue. I just did some testing and figured that
>>>> eap6.3 and as7 distribution were broken as they excluded
>>>> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. 
>>>> But on
>>>> AS 7.1.1 the keycloak-subsystem doesn't work and I have:
>>>>
>>>> Caused by: java.lang.ClassNotFoundException:
>>>> org.jboss.as.controller.OperationDefinition from [Module
>>>> "org.keycloak.keycloak-subsystem:main"
>>>>
>>>> I am seeing options like:
>>>> 1) Drop AS7 support
>>>> 2) Revert AS7 specific subsystem
>>>> 3) Do some hack in keycloak-subsystem to have it working on AS 
>>>> 7.1.1 (is
>>>> it doable?)
>>>>
>>>> Anything else I am missing?
>>>>
>>>> Marek
>>>>
>>>> On 2.12.2014 14:38, Bill Burke wrote:
>>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
>>>>>>> before release?
>>>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me
>>>>>> know so
>>>>>> I can run a quick smoke test on the subsystem before we release.
>>>>>>> With regards to distro we should move the adapters and examples 
>>>>>>> into
>>>>>>> separate downloads. Also, we should move the examples into a
>>>>>>> separate github project (keycloak/keycloak-examples). This will 
>>>>>>> make
>>>>>>> it easier for those that wants to fork the examples separately.
>>>>>>>
>>>>>>> Also, we should consider a download based on the web-lite profile.
>>>>>>> For non-JavaEE apps, containers (Docker) and those that want to run
>>>>>>> a standalone KC server it would be nice to have a small as possible
>>>>>>> distro.
>>>>>> Depending on how the feature pack turns out, we might be able to 
>>>>>> offer
>>>>>> many flavors of the appliance distro without any additional
>>>>>> effort.  We
>>>>>> could have:
>>>>>> EAP6 + Keycloak
>>>>>> AS7 + Keycloak
>>>>>> WF8 (web) + Keycloak
>>>>>> WF8 (full) + Keycloak
>>>>>> WF 9 beta (web) + Keycloak
>>>>>> WF 9 beta (full) + Keycloak
>>>>>> etc.
>>>>>>
>>>>> IMO, we just need:
>>>>> * war-dist
>>>>> * appliance-dist
>>>>>
>>>>> Appliance distribution would have the most stable platform available.
>>>>> Since we can't distribute EAP, then it would be the most stable and
>>>>> maintained version of Wildfly that allows us to cluster and deploy
>>>>> Keycloak.
>>>>>
>>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From ssilvert at redhat.com  Tue Dec  2 15:55:01 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 02 Dec 2014 15:55:01 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E22B3.2050300@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com> <547E14EA.4040706@redhat.com>
	<547E17DE.8000309@redhat.com> <547E1A7E.80004@redhat.com>
	<547E1D3D.2040209@redhat.com> <547E22B3.2050300@redhat.com>
Message-ID: <547E2725.8040006@redhat.com>

On 12/2/2014 3:36 PM, Marek Posolda wrote:
> oops, thanks to you for reporting issue to me this time:-)
>
> It should be fixed now. Let me know if it helps.
That fixed it.  Wish mine was that easy.

So much for EAP6 being based on AS7.  The API I'm using doesn't exist on 
AS7.  It does exist on EAP6, WF8, and WF9.

I think our best course right now is to not use the subsystem on AS7.  
You can still deploy the auth-server WAR into the /deployments directory 
if you are dead set on using AS7 that way.

This doesn't affect the AS7 adapter at all.  We just need to remove the 
subsystem module from the dist.

>
> Marek
>
> On 2.12.2014 21:12, Stan Silvert wrote:
>> We may have other problems.  I just updated to the latest and OSGI 
>> core adapter fails to build.   I can continue what I'm doing because 
>> the AS7 adapter built successfully.
>>
>> See WARNING below.  Possibly a Windows problem?
>>
>> [INFO] Building Keycloak OSGI Core Adapter Integration 
>> 1.1.0.Beta2-SNAPSHOT
>> [INFO] 
>> ------------------------------------------------------------------------
>> [INFO]
>> [INFO] --- buildnumber-maven-plugin:1.3:create-timestamp 
>> (get-build-timestamp) @ keycloak-osgi-core-adapter ---
>> [INFO]
>> [INFO] --- buildnumber-maven-plugin:1.3:create (get-scm-revision) @ 
>> keycloak-osgi-core-adapter ---
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
>> keycloak-osgi-core-adapter ---
>> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered 
>> resources, i.e. build is platform dependent!
>> [INFO] skip non existing resourceDirectory 
>> C:\GitHub\keycloak\distribution\osgi\core-adapter\src\main\resources
>> [INFO]
>> [INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ 
>> keycloak-osgi-core-adapter ---
>> [INFO] No sources to compile
>> [INFO]
>> [INFO] --- maven-bundle-plugin:2.3.7:manifest (bundle-manifest) @ 
>> keycloak-osgi-core-adapter ---
>> [INFO] 
>> ------------------------------------------------------------------------
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Keycloak JBoss Modules ............................. SUCCESS 
>> [  7.552 s]
>> [INFO] Keycloak AS7 Adapter Distro ........................ SUCCESS 
>> [  0.798 s]
>> [INFO] Keycloak Tomcat 6 Adapter Distro ................... SUCCESS 
>> [  0.438 s]
>> [INFO] Keycloak Tomcat 7 Adapter Distro ................... SUCCESS 
>> [  0.185 s]
>> [INFO] Keycloak Tomcat 8 Adapter Distro ................... SUCCESS 
>> [  0.168 s]
>> [INFO] Keycloak EAP6 Adapter Distro ....................... SUCCESS 
>> [  0.738 s]
>> [INFO] Keycloak Wildfly Adapter Distro .................... SUCCESS 
>> [  0.838 s]
>> [INFO] Keycloak Jetty 8.1.x Adapter Distro ................ SUCCESS 
>> [  0.261 s]
>> [INFO] Keycloak Jetty 9.1.x Adapter Distro ................ SUCCESS 
>> [  0.257 s]
>> [INFO] Keycloak Jetty 9.2.x Adapter Distro ................ SUCCESS 
>> [  0.294 s]
>> [INFO] Keycloak Examples and Doc Distribution ............. SUCCESS 
>> [  5.459 s]
>> [INFO] Keycloak Example Themes ............................ SUCCESS 
>> [  1.361 s]
>> [INFO] Keycloak WAR Deployment For Wildfly/AS7/EAP ........ SUCCESS 
>> [  1.657 s]
>> [INFO] Keycloak WAR Distribution .......................... SUCCESS 
>> [  5.911 s]
>> [INFO] Keycloak OSGI Features ............................. SUCCESS 
>> [  0.433 s]
>> [INFO] Keycloak OSGI Core Adapter Integration ............. FAILURE 
>> [  0.328 s]
>> [INFO] Keycloak OSGI JAAS ................................. SKIPPED
>> [INFO] Keycloak OSGI Integration .......................... SKIPPED
>> [INFO] Proxy Distro ....................................... SKIPPED
>> [INFO] Keycloak Appliance Distribution .................... SKIPPED
>> [INFO] Keycloak Source Distribution ....................... SKIPPED
>> [INFO] Distribution ....................................... SKIPPED
>> [INFO] 
>> ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO] 
>> ------------------------------------------------------------------------
>> [INFO] Total time: 27.514 s
>> [INFO] Finished at: 2014-12-02T15:06:24-05:00
>> [INFO] Final Memory: 54M/470M
>> [INFO] 
>> ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal 
>> org.apache.felix:maven-bundle-plugin:2.3.7:manifest (bundle-manifest) 
>> on project keycloak-osgi-core-adapter: Cannot find C:\GitHub\keycloak
>> \distribution\osgi\core-adapter\target\classes (manifest goal must be 
>> run after compile phase) -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with 
>> the -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions, 
>> please read the following articles:
>> [ERROR] [Help 1] 
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>> [ERROR]
>> [ERROR] After correcting the problems, you can resume the build with 
>> the command
>> [ERROR]   mvn <goals> -rf :keycloak-osgi-core-adapter
>>
>> On 12/2/2014 3:01 PM, Marek Posolda wrote:
>>> Maybe an option is to keep just adapter support on AS7, but drop 
>>> support
>>> for the auth-server itself on AS7? Of course, if we are able to somehow
>>> fix everything, it might be best option:-)
>>>
>>> Marek
>>>
>>> On 2.12.2014 20:49, Bill Burke wrote:
>>>> We should keep as7 adapter support at least.  We support older
>>>> versions of Jetty and tomcat too, it would be strange not to support
>>>> AS7. Hopefully stan has a fix.
>>>>
>>>> Looking at it, it looks like OperationDefinition is only within
>>>> auth-server subsystem.  That could be the "hack' you're talkin about.
>>>>
>>>> Shouldn't the auth-server and adapter should be separate subsystems
>>>> anyways?
>>>>
>>>> On 12/2/2014 2:37 PM, Marek Posolda wrote:
>>>>> One slightly related issue. I just did some testing and figured that
>>>>> eap6.3 and as7 distribution were broken as they excluded
>>>>> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now. 
>>>>> But on
>>>>> AS 7.1.1 the keycloak-subsystem doesn't work and I have:
>>>>>
>>>>> Caused by: java.lang.ClassNotFoundException:
>>>>> org.jboss.as.controller.OperationDefinition from [Module
>>>>> "org.keycloak.keycloak-subsystem:main"
>>>>>
>>>>> I am seeing options like:
>>>>> 1) Drop AS7 support
>>>>> 2) Revert AS7 specific subsystem
>>>>> 3) Do some hack in keycloak-subsystem to have it working on AS 
>>>>> 7.1.1 (is
>>>>> it doable?)
>>>>>
>>>>> Anything else I am missing?
>>>>>
>>>>> Marek
>>>>>
>>>>> On 2.12.2014 14:38, Bill Burke wrote:
>>>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
>>>>>>>> before release?
>>>>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me
>>>>>>> know so
>>>>>>> I can run a quick smoke test on the subsystem before we release.
>>>>>>>> With regards to distro we should move the adapters and examples 
>>>>>>>> into
>>>>>>>> separate downloads. Also, we should move the examples into a
>>>>>>>> separate github project (keycloak/keycloak-examples). This will 
>>>>>>>> make
>>>>>>>> it easier for those that wants to fork the examples separately.
>>>>>>>>
>>>>>>>> Also, we should consider a download based on the web-lite profile.
>>>>>>>> For non-JavaEE apps, containers (Docker) and those that want to 
>>>>>>>> run
>>>>>>>> a standalone KC server it would be nice to have a small as 
>>>>>>>> possible
>>>>>>>> distro.
>>>>>>> Depending on how the feature pack turns out, we might be able to 
>>>>>>> offer
>>>>>>> many flavors of the appliance distro without any additional
>>>>>>> effort.  We
>>>>>>> could have:
>>>>>>> EAP6 + Keycloak
>>>>>>> AS7 + Keycloak
>>>>>>> WF8 (web) + Keycloak
>>>>>>> WF8 (full) + Keycloak
>>>>>>> WF 9 beta (web) + Keycloak
>>>>>>> WF 9 beta (full) + Keycloak
>>>>>>> etc.
>>>>>>>
>>>>>> IMO, we just need:
>>>>>> * war-dist
>>>>>> * appliance-dist
>>>>>>
>>>>>> Appliance distribution would have the most stable platform 
>>>>>> available.
>>>>>> Since we can't distribute EAP, then it would be the most stable and
>>>>>> maintained version of Wildfly that allows us to cluster and deploy
>>>>>> Keycloak.
>>>>>>
>>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


From ssilvert at redhat.com  Tue Dec  2 16:14:35 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 02 Dec 2014 16:14:35 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E2725.8040006@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com> <547E14EA.4040706@redhat.com>
	<547E17DE.8000309@redhat.com> <547E1A7E.80004@redhat.com>
	<547E1D3D.2040209@redhat.com> <547E22B3.2050300@redhat.com>
	<547E2725.8040006@redhat.com>
Message-ID: <547E2BBB.8040902@redhat.com>

On 12/2/2014 3:55 PM, Stan Silvert wrote:
> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>> oops, thanks to you for reporting issue to me this time:-)
>>
>> It should be fixed now. Let me know if it helps.
> That fixed it.  Wish mine was that easy.
>
> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
> AS7.  It does exist on EAP6, WF8, and WF9.
>
> I think our best course right now is to not use the subsystem on AS7.
> You can still deploy the auth-server WAR into the /deployments directory
> if you are dead set on using AS7 that way.
>
> This doesn't affect the AS7 adapter at all.  We just need to remove the
> subsystem module from the dist.
Created a PR for this. https://github.com/keycloak/keycloak/pull/880

I have to leave for a few hours.  I still need to update the doc to 
reflect that the subsystem doesn't work on AS7 (assuming everyone agrees 
that is what we should do.)
>
>> Marek
>>
>> On 2.12.2014 21:12, Stan Silvert wrote:
>>> We may have other problems.  I just updated to the latest and OSGI
>>> core adapter fails to build.   I can continue what I'm doing because
>>> the AS7 adapter built successfully.
>>>
>>> See WARNING below.  Possibly a Windows problem?
>>>
>>> [INFO] Building Keycloak OSGI Core Adapter Integration
>>> 1.1.0.Beta2-SNAPSHOT
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO]
>>> [INFO] --- buildnumber-maven-plugin:1.3:create-timestamp
>>> (get-build-timestamp) @ keycloak-osgi-core-adapter ---
>>> [INFO]
>>> [INFO] --- buildnumber-maven-plugin:1.3:create (get-scm-revision) @
>>> keycloak-osgi-core-adapter ---
>>> [INFO]
>>> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
>>> keycloak-osgi-core-adapter ---
>>> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
>>> resources, i.e. build is platform dependent!
>>> [INFO] skip non existing resourceDirectory
>>> C:\GitHub\keycloak\distribution\osgi\core-adapter\src\main\resources
>>> [INFO]
>>> [INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @
>>> keycloak-osgi-core-adapter ---
>>> [INFO] No sources to compile
>>> [INFO]
>>> [INFO] --- maven-bundle-plugin:2.3.7:manifest (bundle-manifest) @
>>> keycloak-osgi-core-adapter ---
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Reactor Summary:
>>> [INFO]
>>> [INFO] Keycloak JBoss Modules ............................. SUCCESS
>>> [  7.552 s]
>>> [INFO] Keycloak AS7 Adapter Distro ........................ SUCCESS
>>> [  0.798 s]
>>> [INFO] Keycloak Tomcat 6 Adapter Distro ................... SUCCESS
>>> [  0.438 s]
>>> [INFO] Keycloak Tomcat 7 Adapter Distro ................... SUCCESS
>>> [  0.185 s]
>>> [INFO] Keycloak Tomcat 8 Adapter Distro ................... SUCCESS
>>> [  0.168 s]
>>> [INFO] Keycloak EAP6 Adapter Distro ....................... SUCCESS
>>> [  0.738 s]
>>> [INFO] Keycloak Wildfly Adapter Distro .................... SUCCESS
>>> [  0.838 s]
>>> [INFO] Keycloak Jetty 8.1.x Adapter Distro ................ SUCCESS
>>> [  0.261 s]
>>> [INFO] Keycloak Jetty 9.1.x Adapter Distro ................ SUCCESS
>>> [  0.257 s]
>>> [INFO] Keycloak Jetty 9.2.x Adapter Distro ................ SUCCESS
>>> [  0.294 s]
>>> [INFO] Keycloak Examples and Doc Distribution ............. SUCCESS
>>> [  5.459 s]
>>> [INFO] Keycloak Example Themes ............................ SUCCESS
>>> [  1.361 s]
>>> [INFO] Keycloak WAR Deployment For Wildfly/AS7/EAP ........ SUCCESS
>>> [  1.657 s]
>>> [INFO] Keycloak WAR Distribution .......................... SUCCESS
>>> [  5.911 s]
>>> [INFO] Keycloak OSGI Features ............................. SUCCESS
>>> [  0.433 s]
>>> [INFO] Keycloak OSGI Core Adapter Integration ............. FAILURE
>>> [  0.328 s]
>>> [INFO] Keycloak OSGI JAAS ................................. SKIPPED
>>> [INFO] Keycloak OSGI Integration .......................... SKIPPED
>>> [INFO] Proxy Distro ....................................... SKIPPED
>>> [INFO] Keycloak Appliance Distribution .................... SKIPPED
>>> [INFO] Keycloak Source Distribution ....................... SKIPPED
>>> [INFO] Distribution ....................................... SKIPPED
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] BUILD FAILURE
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Total time: 27.514 s
>>> [INFO] Finished at: 2014-12-02T15:06:24-05:00
>>> [INFO] Final Memory: 54M/470M
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [ERROR] Failed to execute goal
>>> org.apache.felix:maven-bundle-plugin:2.3.7:manifest (bundle-manifest)
>>> on project keycloak-osgi-core-adapter: Cannot find C:\GitHub\keycloak
>>> \distribution\osgi\core-adapter\target\classes (manifest goal must be
>>> run after compile phase) -> [Help 1]
>>> [ERROR]
>>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>>> the -e switch.
>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>> [ERROR]
>>> [ERROR] For more information about the errors and possible solutions,
>>> please read the following articles:
>>> [ERROR] [Help 1]
>>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>>> [ERROR]
>>> [ERROR] After correcting the problems, you can resume the build with
>>> the command
>>> [ERROR]   mvn <goals> -rf :keycloak-osgi-core-adapter
>>>
>>> On 12/2/2014 3:01 PM, Marek Posolda wrote:
>>>> Maybe an option is to keep just adapter support on AS7, but drop
>>>> support
>>>> for the auth-server itself on AS7? Of course, if we are able to somehow
>>>> fix everything, it might be best option:-)
>>>>
>>>> Marek
>>>>
>>>> On 2.12.2014 20:49, Bill Burke wrote:
>>>>> We should keep as7 adapter support at least.  We support older
>>>>> versions of Jetty and tomcat too, it would be strange not to support
>>>>> AS7. Hopefully stan has a fix.
>>>>>
>>>>> Looking at it, it looks like OperationDefinition is only within
>>>>> auth-server subsystem.  That could be the "hack' you're talkin about.
>>>>>
>>>>> Shouldn't the auth-server and adapter should be separate subsystems
>>>>> anyways?
>>>>>
>>>>> On 12/2/2014 2:37 PM, Marek Posolda wrote:
>>>>>> One slightly related issue. I just did some testing and figured that
>>>>>> eap6.3 and as7 distribution were broken as they excluded
>>>>>> keycloak-subsystem . I've fixed that and EAP 6.3 works fine now.
>>>>>> But on
>>>>>> AS 7.1.1 the keycloak-subsystem doesn't work and I have:
>>>>>>
>>>>>> Caused by: java.lang.ClassNotFoundException:
>>>>>> org.jboss.as.controller.OperationDefinition from [Module
>>>>>> "org.keycloak.keycloak-subsystem:main"
>>>>>>
>>>>>> I am seeing options like:
>>>>>> 1) Drop AS7 support
>>>>>> 2) Revert AS7 specific subsystem
>>>>>> 3) Do some hack in keycloak-subsystem to have it working on AS
>>>>>> 7.1.1 (is
>>>>>> it doable?)
>>>>>>
>>>>>> Anything else I am missing?
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>> On 2.12.2014 14:38, Bill Burke wrote:
>>>>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
>>>>>>>>> before release?
>>>>>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me
>>>>>>>> know so
>>>>>>>> I can run a quick smoke test on the subsystem before we release.
>>>>>>>>> With regards to distro we should move the adapters and examples
>>>>>>>>> into
>>>>>>>>> separate downloads. Also, we should move the examples into a
>>>>>>>>> separate github project (keycloak/keycloak-examples). This will
>>>>>>>>> make
>>>>>>>>> it easier for those that wants to fork the examples separately.
>>>>>>>>>
>>>>>>>>> Also, we should consider a download based on the web-lite profile.
>>>>>>>>> For non-JavaEE apps, containers (Docker) and those that want to
>>>>>>>>> run
>>>>>>>>> a standalone KC server it would be nice to have a small as
>>>>>>>>> possible
>>>>>>>>> distro.
>>>>>>>> Depending on how the feature pack turns out, we might be able to
>>>>>>>> offer
>>>>>>>> many flavors of the appliance distro without any additional
>>>>>>>> effort.  We
>>>>>>>> could have:
>>>>>>>> EAP6 + Keycloak
>>>>>>>> AS7 + Keycloak
>>>>>>>> WF8 (web) + Keycloak
>>>>>>>> WF8 (full) + Keycloak
>>>>>>>> WF 9 beta (web) + Keycloak
>>>>>>>> WF 9 beta (full) + Keycloak
>>>>>>>> etc.
>>>>>>>>
>>>>>>> IMO, we just need:
>>>>>>> * war-dist
>>>>>>> * appliance-dist
>>>>>>>
>>>>>>> Appliance distribution would have the most stable platform
>>>>>>> available.
>>>>>>> Since we can't distribute EAP, then it would be the most stable and
>>>>>>> maintained version of Wildfly that allows us to cluster and deploy
>>>>>>> Keycloak.
>>>>>>>
>>>>>>>
>>>> _______________________________________________
>>>> 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 Dec  2 16:38:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Dec 2014 16:38:46 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E2725.8040006@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>
	<547DC0D8.9000404@redhat.com> <547E14EA.4040706@redhat.com>
	<547E17DE.8000309@redhat.com> <547E1A7E.80004@redhat.com>
	<547E1D3D.2040209@redhat.com> <547E22B3.2050300@redhat.com>
	<547E2725.8040006@redhat.com>
Message-ID: <547E3166.9000007@redhat.com>



On 12/2/2014 3:55 PM, Stan Silvert wrote:
> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>> oops, thanks to you for reporting issue to me this time:-)
>>
>> It should be fixed now. Let me know if it helps.
> That fixed it.  Wish mine was that easy.
>
> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
> AS7.  It does exist on EAP6, WF8, and WF9.
>
> I think our best course right now is to not use the subsystem on AS7.
> You can still deploy the auth-server WAR into the /deployments directory
> if you are dead set on using AS7 that way.
>
> This doesn't affect the AS7 adapter at all.  We just need to remove the
> subsystem module from the dist.
>

Isn't the adapter subsystem and auth-server subsystem in the same 
jar/module?

http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter

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

From bburke at redhat.com  Tue Dec  2 16:41:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Dec 2014 16:41:44 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E3166.9000007@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>	<547DC0D8.9000404@redhat.com>
	<547E14EA.4040706@redhat.com>	<547E17DE.8000309@redhat.com>
	<547E1A7E.80004@redhat.com>	<547E1D3D.2040209@redhat.com>
	<547E22B3.2050300@redhat.com>	<547E2725.8040006@redhat.com>
	<547E3166.9000007@redhat.com>
Message-ID: <547E3218.8080908@redhat.com>



On 12/2/2014 4:38 PM, Bill Burke wrote:
>
>
> On 12/2/2014 3:55 PM, Stan Silvert wrote:
>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>>> oops, thanks to you for reporting issue to me this time:-)
>>>
>>> It should be fixed now. Let me know if it helps.
>> That fixed it.  Wish mine was that easy.
>>
>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
>> AS7.  It does exist on EAP6, WF8, and WF9.
>>
>> I think our best course right now is to not use the subsystem on AS7.
>> You can still deploy the auth-server WAR into the /deployments directory
>> if you are dead set on using AS7 that way.
>>
>> This doesn't affect the AS7 adapter at all.  We just need to remove the
>> subsystem module from the dist.
>>
>
> Isn't the adapter subsystem and auth-server subsystem in the same
> jar/module?
>
> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
>

What I'm saying is...didn't you just totally break the as7 adapter?


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

From ssilvert at redhat.com  Tue Dec  2 18:18:54 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 02 Dec 2014 18:18:54 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E3218.8080908@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>	<547DC0D8.9000404@redhat.com>
	<547E14EA.4040706@redhat.com>	<547E17DE.8000309@redhat.com>
	<547E1A7E.80004@redhat.com>	<547E1D3D.2040209@redhat.com>
	<547E22B3.2050300@redhat.com>	<547E2725.8040006@redhat.com>
	<547E3166.9000007@redhat.com> <547E3218.8080908@redhat.com>
Message-ID: <547E48DE.4080101@redhat.com>

On 12/2/2014 4:41 PM, Bill Burke wrote:
>
> On 12/2/2014 4:38 PM, Bill Burke wrote:
>>
>> On 12/2/2014 3:55 PM, Stan Silvert wrote:
>>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>>>> oops, thanks to you for reporting issue to me this time:-)
>>>>
>>>> It should be fixed now. Let me know if it helps.
>>> That fixed it.  Wish mine was that easy.
>>>
>>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
>>> AS7.  It does exist on EAP6, WF8, and WF9.
>>>
>>> I think our best course right now is to not use the subsystem on AS7.
>>> You can still deploy the auth-server WAR into the /deployments directory
>>> if you are dead set on using AS7 that way.
>>>
>>> This doesn't affect the AS7 adapter at all.  We just need to remove the
>>> subsystem module from the dist.
>>>
>> Isn't the adapter subsystem and auth-server subsystem in the same
>> jar/module?
>>
>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
>>
> What I'm saying is...didn't you just totally break the as7 adapter?
>
>
No, they are not in the same module.  But now I do see what you are 
saying.  The subsystem is adding the adapter module, so yes, it's broken 
unless you add the module in jboss-structure.xml.

Need to think on this some more.

From ssilvert at redhat.com  Tue Dec  2 21:56:27 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 02 Dec 2014 21:56:27 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E48DE.4080101@redhat.com>
References: <547C8466.4050103@redhat.com>	<547C8F0B.4060904@redhat.com>	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>	<547DB6A7.8040200@redhat.com>	<547DC0D8.9000404@redhat.com>
	<547E14EA.4040706@redhat.com>	<547E17DE.8000309@redhat.com>
	<547E1A7E.80004@redhat.com>	<547E1D3D.2040209@redhat.com>
	<547E22B3.2050300@redhat.com>	<547E2725.8040006@redhat.com>
	<547E3166.9000007@redhat.com> <547E3218.8080908@redhat.com>
	<547E48DE.4080101@redhat.com>
Message-ID: <547E7BDB.3090907@redhat.com>

On 12/2/2014 6:18 PM, Stan Silvert wrote:
> On 12/2/2014 4:41 PM, Bill Burke wrote:
>> On 12/2/2014 4:38 PM, Bill Burke wrote:
>>> On 12/2/2014 3:55 PM, Stan Silvert wrote:
>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>>>>> oops, thanks to you for reporting issue to me this time:-)
>>>>>
>>>>> It should be fixed now. Let me know if it helps.
>>>> That fixed it.  Wish mine was that easy.
>>>>
>>>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
>>>> AS7.  It does exist on EAP6, WF8, and WF9.
>>>>
>>>> I think our best course right now is to not use the subsystem on AS7.
>>>> You can still deploy the auth-server WAR into the /deployments directory
>>>> if you are dead set on using AS7 that way.
>>>>
>>>> This doesn't affect the AS7 adapter at all.  We just need to remove the
>>>> subsystem module from the dist.
>>>>
>>> Isn't the adapter subsystem and auth-server subsystem in the same
>>> jar/module?
>>>
>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
>>>
>> What I'm saying is...didn't you just totally break the as7 adapter?
>>
>>
> No, they are not in the same module.  But now I do see what you are
> saying.  The subsystem is adding the adapter module, so yes, it's broken
> unless you add the module in jboss-structure.xml.
>
> Need to think on this some more.
So the simplest solution actually is to do what I say above when using 
AS7.  That is, you either package the adapter in your WAR or you 
reference it in jboss-structure.xml.  That would require no further 
changes.  Just merge the PR I sent earlier and I'll change the docs.

Is that acceptable?  There are some other solutions, but I don't like 
them as much.  Anything else we do will require treating the AS7 
subsystem as a special case and I just don't see the ROI.  AS7 is (or 
should be) a dead platform.

So what I'm proposing is that we just treat AS7 like Tomcat or Jetty.  
We still have the AS7 adapter but you don't use the subsystem.



From stian at redhat.com  Wed Dec  3 02:38:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 02:38:34 -0500 (EST)
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547DE950.4020702@redhat.com>
References: <547C8466.4050103@redhat.com>
	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
	<547DB6A7.8040200@redhat.com> <547DC0D8.9000404@redhat.com>
	<2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
	<547DD697.5030909@redhat.com>
	<1850709811.8894994.1417535591934.JavaMail.zimbra@redhat.com>
	<547DE950.4020702@redhat.com>
Message-ID: <497458874.9345334.1417592314199.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, 2 December, 2014 5:31:12 PM
> Subject: Re: [keycloak-dev] release?  Stan?
> 
> 
> 
> On 12/2/2014 10:53 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 2 December, 2014 4:11:19 PM
> >> Subject: Re: [keycloak-dev] release?  Stan?
> >>
> >>
> >>
> >> On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 2 December, 2014 2:38:32 PM
> >>>> Subject: Re: [keycloak-dev] release?  Stan?
> >>>>
> >>>>
> >>>>
> >>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
> >>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
> >>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
> >>>>>> before
> >>>>>> release?
> >>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me know
> >>>>> so
> >>>>> I can run a quick smoke test on the subsystem before we release.
> >>>>>>
> >>>>>> With regards to distro we should move the adapters and examples into
> >>>>>> separate downloads. Also, we should move the examples into a separate
> >>>>>> github project (keycloak/keycloak-examples). This will make it easier
> >>>>>> for
> >>>>>> those that wants to fork the examples separately.
> >>>>>>
> >>>>>> Also, we should consider a download based on the web-lite profile. For
> >>>>>> non-JavaEE apps, containers (Docker) and those that want to run a
> >>>>>> standalone KC server it would be nice to have a small as possible
> >>>>>> distro.
> >>>>> Depending on how the feature pack turns out, we might be able to offer
> >>>>> many flavors of the appliance distro without any additional effort.  We
> >>>>> could have:
> >>>>> EAP6 + Keycloak
> >>>>> AS7 + Keycloak
> >>>>> WF8 (web) + Keycloak
> >>>>> WF8 (full) + Keycloak
> >>>>> WF 9 beta (web) + Keycloak
> >>>>> WF 9 beta (full) + Keycloak
> >>>>> etc.
> >>>>>
> >>>>
> >>>> IMO, we just need:
> >>>> * war-dist
> >>>> * appliance-dist
> >>>>
> >>>> Appliance distribution would have the most stable platform available.
> >>>> Since we can't distribute EAP, then it would be the most stable and
> >>>> maintained version of Wildfly that allows us to cluster and deploy
> >>>> Keycloak.
> >>>
> >>> Our download at the moment is 160MB and is really aimed at the first-time
> >>> JavaEE user (bundled with examples and documentation). Why should we
> >>> require someone that just wants to upgrade their server to download all
> >>> of
> >>> that? There'll also be loads of people that don't need the JavaEE parts,
> >>> a
> >>> NodeJS developer or deploying to cloud for example. I think we could
> >>> easily have a standalone Keycloak server download that'd be around 30MB.
> >>>
> >>> IMO we should have:
> >>>
> >>> * Minimal server (based on WildFly web/core)
> >>> * Full server (based on WildFly full)
> >>> * Feature pack - to easily install onto other version of WF, EAP, etc.
> >>>
> >>> Neither of those downloads should include docs or examples. As we don't
> >>> really support installing onto Tomcat or Jetty, why have a war-dist?
> >>>
> >>
> >> I disagree.  At least one download should have everything:  docs,
> >> examples, and a distro that can run the examples.  Reducing even simple
> >> steps for 1st time users is crucial to adoption.  How fast a first time
> >> user can get "hello world" running is crucial.  BTW, That's a major
> >> reason why your suggestion earlier of having examples on Github is not a
> >> great idea.
> >
> > WildFly, PicketLink, Infinispan, etc. all use the same approach for
> > quickstarts. They're in GitHub in a separate project, which can easily be
> > forked/cloned by users. This is IMO a much better way to get started than
> > downloading a zip. Problem is that currently we don't cater for those that
> > want to fork/clone the examples as they have to do everything, which would
> > at least stop me from doing it. If we put it in a separate project that
> > doesn't stop us from releasing a bundle with everything in it. It just
> > adds an extra step to the releasing, which could be automated with a
> > script.
> >
> 
> Just because everybody does it doesn't mean it is a good idea.  I really
> hate that they do that and have run into problems.  Let me give more
> reasons why it is a bad idea:
> 
> * A user may never have used github

Sure, so let's have a download from them as well. In fact you can download a github repo with a single click.

> * There may be an incompatibility with the version developer is using
> vs. the master example branch.
> * Requires user to either edit example pom to point to desired project
> version or to checkout correct tag.

I agree with versions being a bit of an issue, but that's easily fixed with tags. Also, I'm fine with having a bundle with everything in it as well for those that want that. I just want to cater for those that don't as well.

> * Keycloak examples are currently active modules in our main git repo.
> They load up as a module in our IDE.  Examples are targeted for refactor
> events just like any other project.

You can import multiple mvn projects into the same IDE project.

> * Keycloak examples are built with build.  Thus catching any compiler
> bugs that often happen when refactoring Keycloak SPIs, APIs, or whatever.

See above + we should have continuous integration running tests on examples against head of KC

> 
> > Personally, I download servers then read docs online and clone/fork
> > examples/quickstarts. Second time around I don't need examples/quickstarts
> > and it annoys me that I have to get a bundle with everything, when all I
> > want is the server.
> >
> 
> The extra few seconds it takes to download and extract really bothers
> you that much?

tgz's can be piped into tar to be extracted directly when downloading. It's nice for scripting things and annoys me when other software isn't available as a tgz.

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

From stian at redhat.com  Wed Dec  3 02:43:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 02:43:18 -0500 (EST)
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547E7BDB.3090907@redhat.com>
References: <547C8466.4050103@redhat.com> <547E1D3D.2040209@redhat.com>
	<547E22B3.2050300@redhat.com> <547E2725.8040006@redhat.com>
	<547E3166.9000007@redhat.com> <547E3218.8080908@redhat.com>
	<547E48DE.4080101@redhat.com> <547E7BDB.3090907@redhat.com>
Message-ID: <375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 3:56:27 AM
> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> 
> On 12/2/2014 6:18 PM, Stan Silvert wrote:
> > On 12/2/2014 4:41 PM, Bill Burke wrote:
> >> On 12/2/2014 4:38 PM, Bill Burke wrote:
> >>> On 12/2/2014 3:55 PM, Stan Silvert wrote:
> >>>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
> >>>>> oops, thanks to you for reporting issue to me this time:-)
> >>>>>
> >>>>> It should be fixed now. Let me know if it helps.
> >>>> That fixed it.  Wish mine was that easy.
> >>>>
> >>>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
> >>>> AS7.  It does exist on EAP6, WF8, and WF9.
> >>>>
> >>>> I think our best course right now is to not use the subsystem on AS7.
> >>>> You can still deploy the auth-server WAR into the /deployments directory
> >>>> if you are dead set on using AS7 that way.
> >>>>
> >>>> This doesn't affect the AS7 adapter at all.  We just need to remove the
> >>>> subsystem module from the dist.
> >>>>
> >>> Isn't the adapter subsystem and auth-server subsystem in the same
> >>> jar/module?
> >>>
> >>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
> >>>
> >> What I'm saying is...didn't you just totally break the as7 adapter?
> >>
> >>
> > No, they are not in the same module.  But now I do see what you are
> > saying.  The subsystem is adding the adapter module, so yes, it's broken
> > unless you add the module in jboss-structure.xml.
> >
> > Need to think on this some more.
> So the simplest solution actually is to do what I say above when using
> AS7.  That is, you either package the adapter in your WAR or you
> reference it in jboss-structure.xml.  That would require no further
> changes.  Just merge the PR I sent earlier and I'll change the docs.
> 
> Is that acceptable?  There are some other solutions, but I don't like
> them as much.  Anything else we do will require treating the AS7
> subsystem as a special case and I just don't see the ROI.  AS7 is (or
> should be) a dead platform.
> 
> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty.
> We still have the AS7 adapter but you don't use the subsystem.

IMO that's a decent solution and better than having a separate subsystem for AS7 (assuming that'd be the only option).

> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Dec  3 02:48:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 02:48:43 -0500 (EST)
Subject: [keycloak-dev] Login with Access Token
In-Reply-To: <547DFDD2.4080500@gmail.com>
References: <547DFDD2.4080500@gmail.com>
Message-ID: <1533062182.9350512.1417592923589.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Christian Beikov" <christian.beikov at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 6:58:42 PM
> Subject: [keycloak-dev] Login with Access Token
> 
> Hello!
> 
> I am new to OAuth so sorry if my question is dumb.
> I have an App which wants to provide a custom and Facebook login. Since many
> people already have the Facebook App installed, I thought it might be better
> to give them the native experience and use the Facebook SDK to implement the
> login.
> The problem now is, that I have the Access Token from the successful Facebook
> login, but don't know how to properly login at the Keycloak server with
> that.
> 
> Any ideas on how to do that? Or is that even stupid and is there a better
> way?

Not at all a dumb question and we actually had someone else ask the same last week.

Currently, Keycloak does not support this flow, but it something we may consider adding.

> --
> 
> Mit freundlichen Gr??en,
> 
> Christian Beikov
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Dec  3 02:55:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 02:55:24 -0500 (EST)
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <1070211230.9355157.1417593270779.JavaMail.zimbra@redhat.com>
Message-ID: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>

As AccessToken and RefreshToken extends IDToken they contain the ID Token claims. If I've read the spec correctly those claims should only be in the ID Token. There should also be a separate UserInfo endpoint which we're missing.

Is there a reason why AccessToken extends IDToken, or can we remove that?

From christian.beikov at gmail.com  Wed Dec  3 03:33:20 2014
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 3 Dec 2014 09:33:20 +0100
Subject: [keycloak-dev] Login with Access Token
In-Reply-To: <758632778.9393795.1417594963102.JavaMail.zimbra@redhat.com>
References: <547DFDD2.4080500@gmail.com>
	<1533062182.9350512.1417592923589.JavaMail.zimbra@redhat.com>
	<CANMUGsVhNOvdCKu6ZkuNQc-t-i_xh3DDXBuv+m=wCxXGNX+HZg@mail.gmail.com>
	<758632778.9393795.1417594963102.JavaMail.zimbra@redhat.com>
Message-ID: <CANMUGsU=H1BNbjwOoPXdQccLLoSz1n-v76Sni47VpQ5HNC3j7Q@mail.gmail.com>

I am wondering how you do that. I know that there is a state parameter that
is added to the facebook login url, but I could just make an initial
request to keycloak to copy that, or did I understand something wrong?

2014-12-03 9:22 GMT+01:00 Stian Thorgersen <stian at redhat.com>:

> It's code that is currently changing as we're working on adding enterprise
> IdP's as well as social IdP's we have at the moment.
>
> I think the correct approach would be to use the direct grant api, which
> currently lets you exchange a username + password for a Keycloak token, we
> could add an option here to pass in a token from an external IdP to
> exchange for a internal Keycloak token. If you're interested in looking at
> the code look at OpenIDConnectService.grantAccessToken.
>
> There's no work-around that you can do due to security restrictions in
> Keycloak. Keycloak makes sure that the callback can only be called if it
> indeed made the original request.
>
> ----- Original Message -----
> > From: "Christian Beikov" <christian.beikov at gmail.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Sent: Wednesday, 3 December, 2014 9:11:55 AM
> > Subject: Re: [keycloak-dev] Login with Access Token
> >
> > Thanks for the quick answer. Could you maybe give me a hint on how I
> could
> > implement that in a quick-and-dirty way? Could I maybe do some iframe
> magic
> > in a hidden webview to do the login? I am not quite sure how the social
> > login works exactly. Facebook will redirect me back to the social
> callback
> > address after a login, but how does keycloak actually retrieve that
> access
> > token? If I knew that, I could maybe create a workaround for now and
> maybe
> > also contribute something? :)
> >
> > 2014-12-03 8:48 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > To: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, 2 December, 2014 6:58:42 PM
> > > > Subject: [keycloak-dev] Login with Access Token
> > > >
> > > > Hello!
> > > >
> > > > I am new to OAuth so sorry if my question is dumb.
> > > > I have an App which wants to provide a custom and Facebook login.
> Since
> > > many
> > > > people already have the Facebook App installed, I thought it might be
> > > better
> > > > to give them the native experience and use the Facebook SDK to
> implement
> > > the
> > > > login.
> > > > The problem now is, that I have the Access Token from the successful
> > > Facebook
> > > > login, but don't know how to properly login at the Keycloak server
> with
> > > > that.
> > > >
> > > > Any ideas on how to do that? Or is that even stupid and is there a
> better
> > > > way?
> > >
> > > Not at all a dumb question and we actually had someone else ask the
> same
> > > last week.
> > >
> > > Currently, Keycloak does not support this flow, but it something we may
> > > consider adding.
> > >
> > > > --
> > > >
> > > > Mit freundlichen Gr??en,
> > > >
> > > > Christian Beikov
> > > >
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> >
> >
> >
> > --
> >
> > Mit freundlichen Gr??en,
> >
> >
> > *Christian Beikov*Blazebit Design & Developing
> > http://www.blazebit.com
> >
>



-- 

Mit freundlichen Gr??en,


*Christian Beikov*Blazebit Design & Developing
http://www.blazebit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141203/e7b1c897/attachment.html 

From mposolda at redhat.com  Wed Dec  3 03:42:36 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 03 Dec 2014 09:42:36 +0100
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com>
	<547E1D3D.2040209@redhat.com>	<547E22B3.2050300@redhat.com>
	<547E2725.8040006@redhat.com>	<547E3166.9000007@redhat.com>
	<547E3218.8080908@redhat.com>	<547E48DE.4080101@redhat.com>
	<547E7BDB.3090907@redhat.com>
	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
Message-ID: <547ECCFC.9040706@redhat.com>

On 3.12.2014 08:43, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 3 December, 2014 3:56:27 AM
>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>
>> On 12/2/2014 6:18 PM, Stan Silvert wrote:
>>> On 12/2/2014 4:41 PM, Bill Burke wrote:
>>>> On 12/2/2014 4:38 PM, Bill Burke wrote:
>>>>> On 12/2/2014 3:55 PM, Stan Silvert wrote:
>>>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>>>>>>> oops, thanks to you for reporting issue to me this time:-)
>>>>>>>
>>>>>>> It should be fixed now. Let me know if it helps.
>>>>>> That fixed it.  Wish mine was that easy.
>>>>>>
>>>>>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
>>>>>> AS7.  It does exist on EAP6, WF8, and WF9.
>>>>>>
>>>>>> I think our best course right now is to not use the subsystem on AS7.
>>>>>> You can still deploy the auth-server WAR into the /deployments directory
>>>>>> if you are dead set on using AS7 that way.
>>>>>>
>>>>>> This doesn't affect the AS7 adapter at all.  We just need to remove the
>>>>>> subsystem module from the dist.
>>>>>>
>>>>> Isn't the adapter subsystem and auth-server subsystem in the same
>>>>> jar/module?
>>>>>
>>>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
>>>>>
>>>> What I'm saying is...didn't you just totally break the as7 adapter?
>>>>
>>>>
>>> No, they are not in the same module.  But now I do see what you are
>>> saying.  The subsystem is adding the adapter module, so yes, it's broken
>>> unless you add the module in jboss-structure.xml.
>>>
>>> Need to think on this some more.
>> So the simplest solution actually is to do what I say above when using
>> AS7.  That is, you either package the adapter in your WAR or you
>> reference it in jboss-structure.xml.  That would require no further
>> changes.  Just merge the PR I sent earlier and I'll change the docs.
>>
>> Is that acceptable?  There are some other solutions, but I don't like
>> them as much.  Anything else we do will require treating the AS7
>> subsystem as a special case and I just don't see the ROI.  AS7 is (or
>> should be) a dead platform.
>>
>> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty.
>> We still have the AS7 adapter but you don't use the subsystem.
> IMO that's a decent solution and better than having a separate subsystem for AS7 (assuming that'd be the only option).
How about auth-server support on AS7? From what I understand, if we 
still want to support it, we would need to add auth-server.war into 
standalone/deployments like it was before. That would mean that 
instructions for adding new providers will be different for other 
platforms than for AS7. Also we already have some additional steps 
required if people want to have auth-server on AS7: 
http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/server-installation.html#as7-specifics 
.

So are we instead going to drop auth-server support on AS7 and keep just 
adapters support?

Marek
>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Dec  3 03:43:10 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 03:43:10 -0500 (EST)
Subject: [keycloak-dev] Login with Access Token
In-Reply-To: <CANMUGsU=H1BNbjwOoPXdQccLLoSz1n-v76Sni47VpQ5HNC3j7Q@mail.gmail.com>
References: <547DFDD2.4080500@gmail.com>
	<1533062182.9350512.1417592923589.JavaMail.zimbra@redhat.com>
	<CANMUGsVhNOvdCKu6ZkuNQc-t-i_xh3DDXBuv+m=wCxXGNX+HZg@mail.gmail.com>
	<758632778.9393795.1417594963102.JavaMail.zimbra@redhat.com>
	<CANMUGsU=H1BNbjwOoPXdQccLLoSz1n-v76Sni47VpQ5HNC3j7Q@mail.gmail.com>
Message-ID: <1778226955.9401093.1417596190241.JavaMail.zimbra@redhat.com>

Keycloak generates a special state parameter. It consists of two parts, a signature and an id. The id is used to lookup a session in Keycloak, while the signature is then used to verify that specific request is valid (a session can only be used for one thing at a time, for example a social login). By design there's no way you can generate this yourself unless you have access to the Keycloak database.

----- Original Message -----
> From: "Christian Beikov" <christian.beikov at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 9:33:20 AM
> Subject: Re: [keycloak-dev] Login with Access Token
> 
> I am wondering how you do that. I know that there is a state parameter that
> is added to the facebook login url, but I could just make an initial
> request to keycloak to copy that, or did I understand something wrong?
> 
> 2014-12-03 9:22 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> 
> > It's code that is currently changing as we're working on adding enterprise
> > IdP's as well as social IdP's we have at the moment.
> >
> > I think the correct approach would be to use the direct grant api, which
> > currently lets you exchange a username + password for a Keycloak token, we
> > could add an option here to pass in a token from an external IdP to
> > exchange for a internal Keycloak token. If you're interested in looking at
> > the code look at OpenIDConnectService.grantAccessToken.
> >
> > There's no work-around that you can do due to security restrictions in
> > Keycloak. Keycloak makes sure that the callback can only be called if it
> > indeed made the original request.
> >
> > ----- Original Message -----
> > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Sent: Wednesday, 3 December, 2014 9:11:55 AM
> > > Subject: Re: [keycloak-dev] Login with Access Token
> > >
> > > Thanks for the quick answer. Could you maybe give me a hint on how I
> > could
> > > implement that in a quick-and-dirty way? Could I maybe do some iframe
> > magic
> > > in a hidden webview to do the login? I am not quite sure how the social
> > > login works exactly. Facebook will redirect me back to the social
> > callback
> > > address after a login, but how does keycloak actually retrieve that
> > access
> > > token? If I knew that, I could maybe create a workaround for now and
> > maybe
> > > also contribute something? :)
> > >
> > > 2014-12-03 8:48 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > > To: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, 2 December, 2014 6:58:42 PM
> > > > > Subject: [keycloak-dev] Login with Access Token
> > > > >
> > > > > Hello!
> > > > >
> > > > > I am new to OAuth so sorry if my question is dumb.
> > > > > I have an App which wants to provide a custom and Facebook login.
> > Since
> > > > many
> > > > > people already have the Facebook App installed, I thought it might be
> > > > better
> > > > > to give them the native experience and use the Facebook SDK to
> > implement
> > > > the
> > > > > login.
> > > > > The problem now is, that I have the Access Token from the successful
> > > > Facebook
> > > > > login, but don't know how to properly login at the Keycloak server
> > with
> > > > > that.
> > > > >
> > > > > Any ideas on how to do that? Or is that even stupid and is there a
> > better
> > > > > way?
> > > >
> > > > Not at all a dumb question and we actually had someone else ask the
> > same
> > > > last week.
> > > >
> > > > Currently, Keycloak does not support this flow, but it something we may
> > > > consider adding.
> > > >
> > > > > --
> > > > >
> > > > > Mit freundlichen Gr??en,
> > > > >
> > > > > Christian Beikov
> > > > >
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Mit freundlichen Gr??en,
> > >
> > >
> > > *Christian Beikov*Blazebit Design & Developing
> > > http://www.blazebit.com
> > >
> >
> 
> 
> 
> --
> 
> Mit freundlichen Gr??en,
> 
> 
> *Christian Beikov*Blazebit Design & Developing
> http://www.blazebit.com
> 


From stian at redhat.com  Wed Dec  3 03:45:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 03:45:15 -0500 (EST)
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547ECCFC.9040706@redhat.com>
References: <547C8466.4050103@redhat.com> <547E2725.8040006@redhat.com>
	<547E3166.9000007@redhat.com> <547E3218.8080908@redhat.com>
	<547E48DE.4080101@redhat.com> <547E7BDB.3090907@redhat.com>
	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
	<547ECCFC.9040706@redhat.com>
Message-ID: <212632819.9401761.1417596315957.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Stan Silvert" <ssilvert at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 9:42:36 AM
> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> 
> On 3.12.2014 08:43, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 3 December, 2014 3:56:27 AM
> >> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> >>
> >> On 12/2/2014 6:18 PM, Stan Silvert wrote:
> >>> On 12/2/2014 4:41 PM, Bill Burke wrote:
> >>>> On 12/2/2014 4:38 PM, Bill Burke wrote:
> >>>>> On 12/2/2014 3:55 PM, Stan Silvert wrote:
> >>>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
> >>>>>>> oops, thanks to you for reporting issue to me this time:-)
> >>>>>>>
> >>>>>>> It should be fixed now. Let me know if it helps.
> >>>>>> That fixed it.  Wish mine was that easy.
> >>>>>>
> >>>>>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist
> >>>>>> on
> >>>>>> AS7.  It does exist on EAP6, WF8, and WF9.
> >>>>>>
> >>>>>> I think our best course right now is to not use the subsystem on AS7.
> >>>>>> You can still deploy the auth-server WAR into the /deployments
> >>>>>> directory
> >>>>>> if you are dead set on using AS7 that way.
> >>>>>>
> >>>>>> This doesn't affect the AS7 adapter at all.  We just need to remove
> >>>>>> the
> >>>>>> subsystem module from the dist.
> >>>>>>
> >>>>> Isn't the adapter subsystem and auth-server subsystem in the same
> >>>>> jar/module?
> >>>>>
> >>>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
> >>>>>
> >>>> What I'm saying is...didn't you just totally break the as7 adapter?
> >>>>
> >>>>
> >>> No, they are not in the same module.  But now I do see what you are
> >>> saying.  The subsystem is adding the adapter module, so yes, it's broken
> >>> unless you add the module in jboss-structure.xml.
> >>>
> >>> Need to think on this some more.
> >> So the simplest solution actually is to do what I say above when using
> >> AS7.  That is, you either package the adapter in your WAR or you
> >> reference it in jboss-structure.xml.  That would require no further
> >> changes.  Just merge the PR I sent earlier and I'll change the docs.
> >>
> >> Is that acceptable?  There are some other solutions, but I don't like
> >> them as much.  Anything else we do will require treating the AS7
> >> subsystem as a special case and I just don't see the ROI.  AS7 is (or
> >> should be) a dead platform.
> >>
> >> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty.
> >> We still have the AS7 adapter but you don't use the subsystem.
> > IMO that's a decent solution and better than having a separate subsystem
> > for AS7 (assuming that'd be the only option).
> How about auth-server support on AS7? From what I understand, if we
> still want to support it, we would need to add auth-server.war into
> standalone/deployments like it was before. That would mean that
> instructions for adding new providers will be different for other
> platforms than for AS7. Also we already have some additional steps
> required if people want to have auth-server on AS7:
> http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/server-installation.html#as7-specifics
> .
> 
> So are we instead going to drop auth-server support on AS7 and keep just
> adapters support?

My assumption was that it would be done with old fashioned war deployment.

> 
> Marek
> >
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From christian.beikov at gmail.com  Wed Dec  3 05:04:05 2014
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 3 Dec 2014 11:04:05 +0100
Subject: [keycloak-dev] Login with Access Token
In-Reply-To: <1778226955.9401093.1417596190241.JavaMail.zimbra@redhat.com>
References: <547DFDD2.4080500@gmail.com>
	<1533062182.9350512.1417592923589.JavaMail.zimbra@redhat.com>
	<CANMUGsVhNOvdCKu6ZkuNQc-t-i_xh3DDXBuv+m=wCxXGNX+HZg@mail.gmail.com>
	<758632778.9393795.1417594963102.JavaMail.zimbra@redhat.com>
	<CANMUGsU=H1BNbjwOoPXdQccLLoSz1n-v76Sni47VpQ5HNC3j7Q@mail.gmail.com>
	<1778226955.9401093.1417596190241.JavaMail.zimbra@redhat.com>
Message-ID: <CANMUGsUoF+L4dxZ8GAW3mt12wM6mqpKyrXq3c+CUtK823ktNtw@mail.gmail.com>

I was thinking of something like the following as a workaround

1. Create a hidden iframe in a webview that navigates to the login page of
the keycloak server.
2. Extract the state from the link of the Facebook login
3. Start the login with the native SDK
4. On success navigate in the iframe to the social callback
5. Use some keycloak token to act as the logged in user

Regarding 4. I am not sure what URL I should invoke exactly. I guess I have
to append the state parameter to it, but I couldn't find out exactly and I
haven't debugged that far yet.
Regarding 5. I don't know how to retrieve that keycloak token from the
iframe, but I hope there is a way.

For this to work I will probably have to add some CORS http headers that
will allow localhost so that the app can access the iframe. Although this
makes it vulnerable, since every localhost app could then "steal" the
keycloak token, it would do the job for now.

What do you think? Could that work?

2014-12-03 9:43 GMT+01:00 Stian Thorgersen <stian at redhat.com>:

> Keycloak generates a special state parameter. It consists of two parts, a
> signature and an id. The id is used to lookup a session in Keycloak, while
> the signature is then used to verify that specific request is valid (a
> session can only be used for one thing at a time, for example a social
> login). By design there's no way you can generate this yourself unless you
> have access to the Keycloak database.
>
> ----- Original Message -----
> > From: "Christian Beikov" <christian.beikov at gmail.com>
> > To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 3 December, 2014 9:33:20 AM
> > Subject: Re: [keycloak-dev] Login with Access Token
> >
> > I am wondering how you do that. I know that there is a state parameter
> that
> > is added to the facebook login url, but I could just make an initial
> > request to keycloak to copy that, or did I understand something wrong?
> >
> > 2014-12-03 9:22 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> >
> > > It's code that is currently changing as we're working on adding
> enterprise
> > > IdP's as well as social IdP's we have at the moment.
> > >
> > > I think the correct approach would be to use the direct grant api,
> which
> > > currently lets you exchange a username + password for a Keycloak
> token, we
> > > could add an option here to pass in a token from an external IdP to
> > > exchange for a internal Keycloak token. If you're interested in
> looking at
> > > the code look at OpenIDConnectService.grantAccessToken.
> > >
> > > There's no work-around that you can do due to security restrictions in
> > > Keycloak. Keycloak makes sure that the callback can only be called if
> it
> > > indeed made the original request.
> > >
> > > ----- Original Message -----
> > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Sent: Wednesday, 3 December, 2014 9:11:55 AM
> > > > Subject: Re: [keycloak-dev] Login with Access Token
> > > >
> > > > Thanks for the quick answer. Could you maybe give me a hint on how I
> > > could
> > > > implement that in a quick-and-dirty way? Could I maybe do some iframe
> > > magic
> > > > in a hidden webview to do the login? I am not quite sure how the
> social
> > > > login works exactly. Facebook will redirect me back to the social
> > > callback
> > > > address after a login, but how does keycloak actually retrieve that
> > > access
> > > > token? If I knew that, I could maybe create a workaround for now and
> > > maybe
> > > > also contribute something? :)
> > > >
> > > > 2014-12-03 8:48 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, 2 December, 2014 6:58:42 PM
> > > > > > Subject: [keycloak-dev] Login with Access Token
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > > I am new to OAuth so sorry if my question is dumb.
> > > > > > I have an App which wants to provide a custom and Facebook login.
> > > Since
> > > > > many
> > > > > > people already have the Facebook App installed, I thought it
> might be
> > > > > better
> > > > > > to give them the native experience and use the Facebook SDK to
> > > implement
> > > > > the
> > > > > > login.
> > > > > > The problem now is, that I have the Access Token from the
> successful
> > > > > Facebook
> > > > > > login, but don't know how to properly login at the Keycloak
> server
> > > with
> > > > > > that.
> > > > > >
> > > > > > Any ideas on how to do that? Or is that even stupid and is there
> a
> > > better
> > > > > > way?
> > > > >
> > > > > Not at all a dumb question and we actually had someone else ask the
> > > same
> > > > > last week.
> > > > >
> > > > > Currently, Keycloak does not support this flow, but it something
> we may
> > > > > consider adding.
> > > > >
> > > > > > --
> > > > > >
> > > > > > Mit freundlichen Gr??en,
> > > > > >
> > > > > > Christian Beikov
> > > > > >
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Mit freundlichen Gr??en,
> > > >
> > > >
> > > > *Christian Beikov*Blazebit Design & Developing
> > > > http://www.blazebit.com
> > > >
> > >
> >
> >
> >
> > --
> >
> > Mit freundlichen Gr??en,
> >
> >
> > *Christian Beikov*Blazebit Design & Developing
> > http://www.blazebit.com
> >
>



-- 

Mit freundlichen Gr??en,


*Christian Beikov*Blazebit Design & Developing
http://www.blazebit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141203/3f383891/attachment.html 

From psilva at redhat.com  Wed Dec  3 06:28:11 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 3 Dec 2014 06:28:11 -0500 (EST)
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
Message-ID: <673430011.23448226.1417606091496.JavaMail.zimbra@redhat.com>

I notice that too when trying to broker a KeyCloak server from another one.

Also, I think KC is missing OpenID Connect Discovery [1].

[1] http://openid.net/specs/openid-connect-discovery-1_0.html

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Wednesday, December 3, 2014 5:55:24 AM
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token

As AccessToken and RefreshToken extends IDToken they contain the ID Token claims. If I've read the spec correctly those claims should only be in the ID Token. There should also be a separate UserInfo endpoint which we're missing.

Is there a reason why AccessToken extends IDToken, or can we remove that?
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Wed Dec  3 06:30:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 06:30:03 -0500 (EST)
Subject: [keycloak-dev] Login with Access Token
In-Reply-To: <CANMUGsUoF+L4dxZ8GAW3mt12wM6mqpKyrXq3c+CUtK823ktNtw@mail.gmail.com>
References: <547DFDD2.4080500@gmail.com>
	<1533062182.9350512.1417592923589.JavaMail.zimbra@redhat.com>
	<CANMUGsVhNOvdCKu6ZkuNQc-t-i_xh3DDXBuv+m=wCxXGNX+HZg@mail.gmail.com>
	<758632778.9393795.1417594963102.JavaMail.zimbra@redhat.com>
	<CANMUGsU=H1BNbjwOoPXdQccLLoSz1n-v76Sni47VpQ5HNC3j7Q@mail.gmail.com>
	<1778226955.9401093.1417596190241.JavaMail.zimbra@redhat.com>
	<CANMUGsUoF+L4dxZ8GAW3mt12wM6mqpKyrXq3c+CUtK823ktNtw@mail.gmail.com>
Message-ID: <1961314962.9522155.1417606203740.JavaMail.zimbra@redhat.com>

The callback to Keycloak expects a code, not a token, so I don't think it would work unless you modify Keycloak's Facebook provider. I can't think of any other reasons why it wouldn't work.

----- Original Message -----
> From: "Christian Beikov" <christian.beikov at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 11:04:05 AM
> Subject: Re: [keycloak-dev] Login with Access Token
> 
> I was thinking of something like the following as a workaround
> 
> 1. Create a hidden iframe in a webview that navigates to the login page of
> the keycloak server.
> 2. Extract the state from the link of the Facebook login
> 3. Start the login with the native SDK
> 4. On success navigate in the iframe to the social callback
> 5. Use some keycloak token to act as the logged in user
> 
> Regarding 4. I am not sure what URL I should invoke exactly. I guess I have
> to append the state parameter to it, but I couldn't find out exactly and I
> haven't debugged that far yet.
> Regarding 5. I don't know how to retrieve that keycloak token from the
> iframe, but I hope there is a way.
> 
> For this to work I will probably have to add some CORS http headers that
> will allow localhost so that the app can access the iframe. Although this
> makes it vulnerable, since every localhost app could then "steal" the
> keycloak token, it would do the job for now.
> 
> What do you think? Could that work?
> 
> 2014-12-03 9:43 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> 
> > Keycloak generates a special state parameter. It consists of two parts, a
> > signature and an id. The id is used to lookup a session in Keycloak, while
> > the signature is then used to verify that specific request is valid (a
> > session can only be used for one thing at a time, for example a social
> > login). By design there's no way you can generate this yourself unless you
> > have access to the Keycloak database.
> >
> > ----- Original Message -----
> > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> > > Sent: Wednesday, 3 December, 2014 9:33:20 AM
> > > Subject: Re: [keycloak-dev] Login with Access Token
> > >
> > > I am wondering how you do that. I know that there is a state parameter
> > that
> > > is added to the facebook login url, but I could just make an initial
> > > request to keycloak to copy that, or did I understand something wrong?
> > >
> > > 2014-12-03 9:22 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > >
> > > > It's code that is currently changing as we're working on adding
> > enterprise
> > > > IdP's as well as social IdP's we have at the moment.
> > > >
> > > > I think the correct approach would be to use the direct grant api,
> > which
> > > > currently lets you exchange a username + password for a Keycloak
> > token, we
> > > > could add an option here to pass in a token from an external IdP to
> > > > exchange for a internal Keycloak token. If you're interested in
> > looking at
> > > > the code look at OpenIDConnectService.grantAccessToken.
> > > >
> > > > There's no work-around that you can do due to security restrictions in
> > > > Keycloak. Keycloak makes sure that the callback can only be called if
> > it
> > > > indeed made the original request.
> > > >
> > > > ----- Original Message -----
> > > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Sent: Wednesday, 3 December, 2014 9:11:55 AM
> > > > > Subject: Re: [keycloak-dev] Login with Access Token
> > > > >
> > > > > Thanks for the quick answer. Could you maybe give me a hint on how I
> > > > could
> > > > > implement that in a quick-and-dirty way? Could I maybe do some iframe
> > > > magic
> > > > > in a hidden webview to do the login? I am not quite sure how the
> > social
> > > > > login works exactly. Facebook will redirect me back to the social
> > > > callback
> > > > > address after a login, but how does keycloak actually retrieve that
> > > > access
> > > > > token? If I knew that, I could maybe create a workaround for now and
> > > > maybe
> > > > > also contribute something? :)
> > > > >
> > > > > 2014-12-03 8:48 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > > > >
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, 2 December, 2014 6:58:42 PM
> > > > > > > Subject: [keycloak-dev] Login with Access Token
> > > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > I am new to OAuth so sorry if my question is dumb.
> > > > > > > I have an App which wants to provide a custom and Facebook login.
> > > > Since
> > > > > > many
> > > > > > > people already have the Facebook App installed, I thought it
> > might be
> > > > > > better
> > > > > > > to give them the native experience and use the Facebook SDK to
> > > > implement
> > > > > > the
> > > > > > > login.
> > > > > > > The problem now is, that I have the Access Token from the
> > successful
> > > > > > Facebook
> > > > > > > login, but don't know how to properly login at the Keycloak
> > server
> > > > with
> > > > > > > that.
> > > > > > >
> > > > > > > Any ideas on how to do that? Or is that even stupid and is there
> > a
> > > > better
> > > > > > > way?
> > > > > >
> > > > > > Not at all a dumb question and we actually had someone else ask the
> > > > same
> > > > > > last week.
> > > > > >
> > > > > > Currently, Keycloak does not support this flow, but it something
> > we may
> > > > > > consider adding.
> > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Mit freundlichen Gr??en,
> > > > > > >
> > > > > > > Christian Beikov
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > keycloak-dev mailing list
> > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Mit freundlichen Gr??en,
> > > > >
> > > > >
> > > > > *Christian Beikov*Blazebit Design & Developing
> > > > > http://www.blazebit.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Mit freundlichen Gr??en,
> > >
> > >
> > > *Christian Beikov*Blazebit Design & Developing
> > > http://www.blazebit.com
> > >
> >
> 
> 
> 
> --
> 
> Mit freundlichen Gr??en,
> 
> 
> *Christian Beikov*Blazebit Design & Developing
> http://www.blazebit.com
> 


From stian at redhat.com  Wed Dec  3 06:31:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 06:31:42 -0500 (EST)
Subject: [keycloak-dev] Login with Access Token
In-Reply-To: <1961314962.9522155.1417606203740.JavaMail.zimbra@redhat.com>
References: <547DFDD2.4080500@gmail.com>
	<1533062182.9350512.1417592923589.JavaMail.zimbra@redhat.com>
	<CANMUGsVhNOvdCKu6ZkuNQc-t-i_xh3DDXBuv+m=wCxXGNX+HZg@mail.gmail.com>
	<758632778.9393795.1417594963102.JavaMail.zimbra@redhat.com>
	<CANMUGsU=H1BNbjwOoPXdQccLLoSz1n-v76Sni47VpQ5HNC3j7Q@mail.gmail.com>
	<1778226955.9401093.1417596190241.JavaMail.zimbra@redhat.com>
	<CANMUGsUoF+L4dxZ8GAW3mt12wM6mqpKyrXq3c+CUtK823ktNtw@mail.gmail.com>
	<1961314962.9522155.1417606203740.JavaMail.zimbra@redhat.com>
Message-ID: <65581544.9522973.1417606302820.JavaMail.zimbra@redhat.com>

Just thought of a reason why it won't work. The link to login with Facebook is to the Keycloak server, which then sets the required state before redirecting to Facebook.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Christian Beikov" <christian.beikov at gmail.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 12:30:03 PM
> Subject: Re: [keycloak-dev] Login with Access Token
> 
> The callback to Keycloak expects a code, not a token, so I don't think it
> would work unless you modify Keycloak's Facebook provider. I can't think of
> any other reasons why it wouldn't work.
> 
> ----- Original Message -----
> > From: "Christian Beikov" <christian.beikov at gmail.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 3 December, 2014 11:04:05 AM
> > Subject: Re: [keycloak-dev] Login with Access Token
> > 
> > I was thinking of something like the following as a workaround
> > 
> > 1. Create a hidden iframe in a webview that navigates to the login page of
> > the keycloak server.
> > 2. Extract the state from the link of the Facebook login
> > 3. Start the login with the native SDK
> > 4. On success navigate in the iframe to the social callback
> > 5. Use some keycloak token to act as the logged in user
> > 
> > Regarding 4. I am not sure what URL I should invoke exactly. I guess I have
> > to append the state parameter to it, but I couldn't find out exactly and I
> > haven't debugged that far yet.
> > Regarding 5. I don't know how to retrieve that keycloak token from the
> > iframe, but I hope there is a way.
> > 
> > For this to work I will probably have to add some CORS http headers that
> > will allow localhost so that the app can access the iframe. Although this
> > makes it vulnerable, since every localhost app could then "steal" the
> > keycloak token, it would do the job for now.
> > 
> > What do you think? Could that work?
> > 
> > 2014-12-03 9:43 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > 
> > > Keycloak generates a special state parameter. It consists of two parts, a
> > > signature and an id. The id is used to lookup a session in Keycloak,
> > > while
> > > the signature is then used to verify that specific request is valid (a
> > > session can only be used for one thing at a time, for example a social
> > > login). By design there's no way you can generate this yourself unless
> > > you
> > > have access to the Keycloak database.
> > >
> > > ----- Original Message -----
> > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> > > > Sent: Wednesday, 3 December, 2014 9:33:20 AM
> > > > Subject: Re: [keycloak-dev] Login with Access Token
> > > >
> > > > I am wondering how you do that. I know that there is a state parameter
> > > that
> > > > is added to the facebook login url, but I could just make an initial
> > > > request to keycloak to copy that, or did I understand something wrong?
> > > >
> > > > 2014-12-03 9:22 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > > >
> > > > > It's code that is currently changing as we're working on adding
> > > enterprise
> > > > > IdP's as well as social IdP's we have at the moment.
> > > > >
> > > > > I think the correct approach would be to use the direct grant api,
> > > which
> > > > > currently lets you exchange a username + password for a Keycloak
> > > token, we
> > > > > could add an option here to pass in a token from an external IdP to
> > > > > exchange for a internal Keycloak token. If you're interested in
> > > looking at
> > > > > the code look at OpenIDConnectService.grantAccessToken.
> > > > >
> > > > > There's no work-around that you can do due to security restrictions
> > > > > in
> > > > > Keycloak. Keycloak makes sure that the callback can only be called if
> > > it
> > > > > indeed made the original request.
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Sent: Wednesday, 3 December, 2014 9:11:55 AM
> > > > > > Subject: Re: [keycloak-dev] Login with Access Token
> > > > > >
> > > > > > Thanks for the quick answer. Could you maybe give me a hint on how
> > > > > > I
> > > > > could
> > > > > > implement that in a quick-and-dirty way? Could I maybe do some
> > > > > > iframe
> > > > > magic
> > > > > > in a hidden webview to do the login? I am not quite sure how the
> > > social
> > > > > > login works exactly. Facebook will redirect me back to the social
> > > > > callback
> > > > > > address after a login, but how does keycloak actually retrieve that
> > > > > access
> > > > > > token? If I knew that, I could maybe create a workaround for now
> > > > > > and
> > > > > maybe
> > > > > > also contribute something? :)
> > > > > >
> > > > > > 2014-12-03 8:48 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, 2 December, 2014 6:58:42 PM
> > > > > > > > Subject: [keycloak-dev] Login with Access Token
> > > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > I am new to OAuth so sorry if my question is dumb.
> > > > > > > > I have an App which wants to provide a custom and Facebook
> > > > > > > > login.
> > > > > Since
> > > > > > > many
> > > > > > > > people already have the Facebook App installed, I thought it
> > > might be
> > > > > > > better
> > > > > > > > to give them the native experience and use the Facebook SDK to
> > > > > implement
> > > > > > > the
> > > > > > > > login.
> > > > > > > > The problem now is, that I have the Access Token from the
> > > successful
> > > > > > > Facebook
> > > > > > > > login, but don't know how to properly login at the Keycloak
> > > server
> > > > > with
> > > > > > > > that.
> > > > > > > >
> > > > > > > > Any ideas on how to do that? Or is that even stupid and is
> > > > > > > > there
> > > a
> > > > > better
> > > > > > > > way?
> > > > > > >
> > > > > > > Not at all a dumb question and we actually had someone else ask
> > > > > > > the
> > > > > same
> > > > > > > last week.
> > > > > > >
> > > > > > > Currently, Keycloak does not support this flow, but it something
> > > we may
> > > > > > > consider adding.
> > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Mit freundlichen Gr??en,
> > > > > > > >
> > > > > > > > Christian Beikov
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-dev mailing list
> > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Mit freundlichen Gr??en,
> > > > > >
> > > > > >
> > > > > > *Christian Beikov*Blazebit Design & Developing
> > > > > > http://www.blazebit.com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Mit freundlichen Gr??en,
> > > >
> > > >
> > > > *Christian Beikov*Blazebit Design & Developing
> > > > http://www.blazebit.com
> > > >
> > >
> > 
> > 
> > 
> > --
> > 
> > Mit freundlichen Gr??en,
> > 
> > 
> > *Christian Beikov*Blazebit Design & Developing
> > http://www.blazebit.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 Dec  3 06:32:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 06:32:21 -0500 (EST)
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <673430011.23448226.1417606091496.JavaMail.zimbra@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
	<673430011.23448226.1417606091496.JavaMail.zimbra@redhat.com>
Message-ID: <259924578.9523312.1417606341087.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, 3 December, 2014 12:28:11 PM
> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
> 
> I notice that too when trying to broker a KeyCloak server from another one.
> 
> Also, I think KC is missing OpenID Connect Discovery [1].
> 
> [1] http://openid.net/specs/openid-connect-discovery-1_0.html

Yep, we've only implemented the core spec and parts of the session spec.

> 
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, December 3, 2014 5:55:24 AM
> Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
> 
> As AccessToken and RefreshToken extends IDToken they contain the ID Token
> claims. If I've read the spec correctly those claims should only be in the
> ID Token. There should also be a separate UserInfo endpoint which we're
> missing.
> 
> Is there a reason why AccessToken extends IDToken, or can we remove that?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From christian.beikov at gmail.com  Wed Dec  3 06:33:55 2014
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 3 Dec 2014 12:33:55 +0100
Subject: [keycloak-dev] Login with Access Token
In-Reply-To: <65581544.9522973.1417606302820.JavaMail.zimbra@redhat.com>
References: <547DFDD2.4080500@gmail.com>
	<1533062182.9350512.1417592923589.JavaMail.zimbra@redhat.com>
	<CANMUGsVhNOvdCKu6ZkuNQc-t-i_xh3DDXBuv+m=wCxXGNX+HZg@mail.gmail.com>
	<758632778.9393795.1417594963102.JavaMail.zimbra@redhat.com>
	<CANMUGsU=H1BNbjwOoPXdQccLLoSz1n-v76Sni47VpQ5HNC3j7Q@mail.gmail.com>
	<1778226955.9401093.1417596190241.JavaMail.zimbra@redhat.com>
	<CANMUGsUoF+L4dxZ8GAW3mt12wM6mqpKyrXq3c+CUtK823ktNtw@mail.gmail.com>
	<1961314962.9522155.1417606203740.JavaMail.zimbra@redhat.com>
	<65581544.9522973.1417606302820.JavaMail.zimbra@redhat.com>
Message-ID: <CANMUGsUqgPYCFUjXZ5MJBbWD8U7N0VABUj8JLPea7Fia6X3VcA@mail.gmail.com>

Correct me if I am wrong, but the last time I looked at the Facebook button
that appears on the login page, it was just a simple link to facebook with
some parameters like the state.

2014-12-03 12:31 GMT+01:00 Stian Thorgersen <stian at redhat.com>:

> Just thought of a reason why it won't work. The link to login with
> Facebook is to the Keycloak server, which then sets the required state
> before redirecting to Facebook.
>
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Christian Beikov" <christian.beikov at gmail.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 3 December, 2014 12:30:03 PM
> > Subject: Re: [keycloak-dev] Login with Access Token
> >
> > The callback to Keycloak expects a code, not a token, so I don't think it
> > would work unless you modify Keycloak's Facebook provider. I can't think
> of
> > any other reasons why it wouldn't work.
> >
> > ----- Original Message -----
> > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Wednesday, 3 December, 2014 11:04:05 AM
> > > Subject: Re: [keycloak-dev] Login with Access Token
> > >
> > > I was thinking of something like the following as a workaround
> > >
> > > 1. Create a hidden iframe in a webview that navigates to the login
> page of
> > > the keycloak server.
> > > 2. Extract the state from the link of the Facebook login
> > > 3. Start the login with the native SDK
> > > 4. On success navigate in the iframe to the social callback
> > > 5. Use some keycloak token to act as the logged in user
> > >
> > > Regarding 4. I am not sure what URL I should invoke exactly. I guess I
> have
> > > to append the state parameter to it, but I couldn't find out exactly
> and I
> > > haven't debugged that far yet.
> > > Regarding 5. I don't know how to retrieve that keycloak token from the
> > > iframe, but I hope there is a way.
> > >
> > > For this to work I will probably have to add some CORS http headers
> that
> > > will allow localhost so that the app can access the iframe. Although
> this
> > > makes it vulnerable, since every localhost app could then "steal" the
> > > keycloak token, it would do the job for now.
> > >
> > > What do you think? Could that work?
> > >
> > > 2014-12-03 9:43 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > >
> > > > Keycloak generates a special state parameter. It consists of two
> parts, a
> > > > signature and an id. The id is used to lookup a session in Keycloak,
> > > > while
> > > > the signature is then used to verify that specific request is valid
> (a
> > > > session can only be used for one thing at a time, for example a
> social
> > > > login). By design there's no way you can generate this yourself
> unless
> > > > you
> > > > have access to the Keycloak database.
> > > >
> > > > ----- Original Message -----
> > > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>,
> keycloak-dev at lists.jboss.org
> > > > > Sent: Wednesday, 3 December, 2014 9:33:20 AM
> > > > > Subject: Re: [keycloak-dev] Login with Access Token
> > > > >
> > > > > I am wondering how you do that. I know that there is a state
> parameter
> > > > that
> > > > > is added to the facebook login url, but I could just make an
> initial
> > > > > request to keycloak to copy that, or did I understand something
> wrong?
> > > > >
> > > > > 2014-12-03 9:22 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > > > >
> > > > > > It's code that is currently changing as we're working on adding
> > > > enterprise
> > > > > > IdP's as well as social IdP's we have at the moment.
> > > > > >
> > > > > > I think the correct approach would be to use the direct grant
> api,
> > > > which
> > > > > > currently lets you exchange a username + password for a Keycloak
> > > > token, we
> > > > > > could add an option here to pass in a token from an external IdP
> to
> > > > > > exchange for a internal Keycloak token. If you're interested in
> > > > looking at
> > > > > > the code look at OpenIDConnectService.grantAccessToken.
> > > > > >
> > > > > > There's no work-around that you can do due to security
> restrictions
> > > > > > in
> > > > > > Keycloak. Keycloak makes sure that the callback can only be
> called if
> > > > it
> > > > > > indeed made the original request.
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Sent: Wednesday, 3 December, 2014 9:11:55 AM
> > > > > > > Subject: Re: [keycloak-dev] Login with Access Token
> > > > > > >
> > > > > > > Thanks for the quick answer. Could you maybe give me a hint on
> how
> > > > > > > I
> > > > > > could
> > > > > > > implement that in a quick-and-dirty way? Could I maybe do some
> > > > > > > iframe
> > > > > > magic
> > > > > > > in a hidden webview to do the login? I am not quite sure how
> the
> > > > social
> > > > > > > login works exactly. Facebook will redirect me back to the
> social
> > > > > > callback
> > > > > > > address after a login, but how does keycloak actually retrieve
> that
> > > > > > access
> > > > > > > token? If I knew that, I could maybe create a workaround for
> now
> > > > > > > and
> > > > > > maybe
> > > > > > > also contribute something? :)
> > > > > > >
> > > > > > > 2014-12-03 8:48 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Christian Beikov" <christian.beikov at gmail.com>
> > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, 2 December, 2014 6:58:42 PM
> > > > > > > > > Subject: [keycloak-dev] Login with Access Token
> > > > > > > > >
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > I am new to OAuth so sorry if my question is dumb.
> > > > > > > > > I have an App which wants to provide a custom and Facebook
> > > > > > > > > login.
> > > > > > Since
> > > > > > > > many
> > > > > > > > > people already have the Facebook App installed, I thought
> it
> > > > might be
> > > > > > > > better
> > > > > > > > > to give them the native experience and use the Facebook
> SDK to
> > > > > > implement
> > > > > > > > the
> > > > > > > > > login.
> > > > > > > > > The problem now is, that I have the Access Token from the
> > > > successful
> > > > > > > > Facebook
> > > > > > > > > login, but don't know how to properly login at the Keycloak
> > > > server
> > > > > > with
> > > > > > > > > that.
> > > > > > > > >
> > > > > > > > > Any ideas on how to do that? Or is that even stupid and is
> > > > > > > > > there
> > > > a
> > > > > > better
> > > > > > > > > way?
> > > > > > > >
> > > > > > > > Not at all a dumb question and we actually had someone else
> ask
> > > > > > > > the
> > > > > > same
> > > > > > > > last week.
> > > > > > > >
> > > > > > > > Currently, Keycloak does not support this flow, but it
> something
> > > > we may
> > > > > > > > consider adding.
> > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > Mit freundlichen Gr??en,
> > > > > > > > >
> > > > > > > > > Christian Beikov
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Mit freundlichen Gr??en,
> > > > > > >
> > > > > > >
> > > > > > > *Christian Beikov*Blazebit Design & Developing
> > > > > > > http://www.blazebit.com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Mit freundlichen Gr??en,
> > > > >
> > > > >
> > > > > *Christian Beikov*Blazebit Design & Developing
> > > > > http://www.blazebit.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Mit freundlichen Gr??en,
> > >
> > >
> > > *Christian Beikov*Blazebit Design & Developing
> > > http://www.blazebit.com
> > >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

Mit freundlichen Gr??en,


*Christian Beikov*Blazebit Design & Developing
http://www.blazebit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141203/f1d86e7b/attachment.html 

From mposolda at redhat.com  Wed Dec  3 08:39:14 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 03 Dec 2014 14:39:14 +0100
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
Message-ID: <547F1282.4050303@redhat.com>

The one reason I can think of is bearer authentication. Currently we are 
doing it with accessToken and if we remove claims from accessToken, then 
bearer app won't be able to easily retrieve informations about user 
without sending another request to UserInfo endpoint. I agree that 
having userInfo in all tokens doesn't makes much sense, but not sure how 
to improve it. Some options:
1) Remove IDToken (but I guess we need it for OpenID connect support, 
right?)
2) Send both accessToken+idToken to bearer auth (but there is more 
network bandwith then)
3) Allow bearer apps to retrieve data from UserInfo, but that's another 
request to KC needed then
4) Keep as it is.

For UserInfo we have endpoint on AccountManagement, which is used for 
example by keycloak.js (Keycloak.loadUserProfile). Or do you mean 
something different?

Marek


On 3.12.2014 08:55, Stian Thorgersen wrote:
> As AccessToken and RefreshToken extends IDToken they contain the ID Token claims. If I've read the spec correctly those claims should only be in the ID Token. There should also be a separate UserInfo endpoint which we're missing.
>
> Is there a reason why AccessToken extends IDToken, or can we remove that?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Wed Dec  3 08:58:52 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 03 Dec 2014 14:58:52 +0100
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <547F1282.4050303@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
	<547F1282.4050303@redhat.com>
Message-ID: <547F171C.9030602@redhat.com>

I wonder if we can have it configurable if IDToken is sent or not? The 
only reason to have it enabled is for specs compliance afaik, but for 
Keycloak itself it doesn't need to be needed anywhere as data are on 
access token. Also removing user claims from refresh token makes sense 
anyway to me. It needs to keep only stuff, which is needed by Keycloak 
to refresh new set of tokens (like sessionId, expiration etc).

On 3.12.2014 14:39, Marek Posolda wrote:
> The one reason I can think of is bearer authentication. Currently we are
> doing it with accessToken and if we remove claims from accessToken, then
> bearer app won't be able to easily retrieve informations about user
> without sending another request to UserInfo endpoint. I agree that
> having userInfo in all tokens doesn't makes much sense, but not sure how
> to improve it. Some options:
> 1) Remove IDToken (but I guess we need it for OpenID connect support,
> right?)
> 2) Send both accessToken+idToken to bearer auth (but there is more
> network bandwith then)
> 3) Allow bearer apps to retrieve data from UserInfo, but that's another
> request to KC needed then
> 4) Keep as it is.
>
> For UserInfo we have endpoint on AccountManagement, which is used for
> example by keycloak.js (Keycloak.loadUserProfile). Or do you mean
> something different?
>
> Marek
>
>
> On 3.12.2014 08:55, Stian Thorgersen wrote:
>> As AccessToken and RefreshToken extends IDToken they contain the ID Token claims. If I've read the spec correctly those claims should only be in the ID Token. There should also be a separate UserInfo endpoint which we're missing.
>>
>> Is there a reason why AccessToken extends IDToken, or can we remove that?
>> _______________________________________________
>> 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  Wed Dec  3 09:01:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 09:01:19 -0500 (EST)
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <547F1282.4050303@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
	<547F1282.4050303@redhat.com>
Message-ID: <1242377153.9645069.1417615279852.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, 3 December, 2014 2:39:14 PM
> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
> 
> The one reason I can think of is bearer authentication. Currently we are
> doing it with accessToken and if we remove claims from accessToken, then
> bearer app won't be able to easily retrieve informations about user
> without sending another request to UserInfo endpoint. I agree that
> having userInfo in all tokens doesn't makes much sense, but not sure how
> to improve it. Some options:
> 1) Remove IDToken (but I guess we need it for OpenID connect support,
> right?)
> 2) Send both accessToken+idToken to bearer auth (but there is more
> network bandwith then)
> 3) Allow bearer apps to retrieve data from UserInfo, but that's another
> request to KC needed then
> 4) Keep as it is.

It would reduce the size of the access token. Could be by quite a few bytes when there's more and more claims added. Question is how does REST endpoints expect to retrieve these claims, and how many REST endpoints actually use the claims at all? Not sure how you would send the token separately as it's expected the authorization header contains the bearer token only.

> 
> For UserInfo we have endpoint on AccountManagement, which is used for
> example by keycloak.js (Keycloak.loadUserProfile). Or do you mean
> something different?

Something else as it should be OpenID Connect specific with the same fields as the ID Token.

> 
> Marek
> 
> 
> On 3.12.2014 08:55, Stian Thorgersen wrote:
> > As AccessToken and RefreshToken extends IDToken they contain the ID Token
> > claims. If I've read the spec correctly those claims should only be in the
> > ID Token. There should also be a separate UserInfo endpoint which we're
> > missing.
> >
> > Is there a reason why AccessToken extends IDToken, or can we remove that?
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From bburke at redhat.com  Wed Dec  3 09:03:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Dec 2014 09:03:51 -0500
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <497458874.9345334.1417592314199.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com>
	<1721066473.8543017.1417513932887.JavaMail.zimbra@redhat.com>
	<547DB6A7.8040200@redhat.com> <547DC0D8.9000404@redhat.com>
	<2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
	<547DD697.5030909@redhat.com>
	<1850709811.8894994.1417535591934.JavaMail.zimbra@redhat.com>
	<547DE950.4020702@redhat.com>
	<497458874.9345334.1417592314199.JavaMail.zimbra@redhat.com>
Message-ID: <547F1847.5070705@redhat.com>



On 12/3/2014 2:38 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 2 December, 2014 5:31:12 PM
>> Subject: Re: [keycloak-dev] release?  Stan?
>>
>>
>>
>> On 12/2/2014 10:53 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 2 December, 2014 4:11:19 PM
>>>> Subject: Re: [keycloak-dev] release?  Stan?
>>>>
>>>>
>>>>
>>>> On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Tuesday, 2 December, 2014 2:38:32 PM
>>>>>> Subject: Re: [keycloak-dev] release?  Stan?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
>>>>>>>> before
>>>>>>>> release?
>>>>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me know
>>>>>>> so
>>>>>>> I can run a quick smoke test on the subsystem before we release.
>>>>>>>>
>>>>>>>> With regards to distro we should move the adapters and examples into
>>>>>>>> separate downloads. Also, we should move the examples into a separate
>>>>>>>> github project (keycloak/keycloak-examples). This will make it easier
>>>>>>>> for
>>>>>>>> those that wants to fork the examples separately.
>>>>>>>>
>>>>>>>> Also, we should consider a download based on the web-lite profile. For
>>>>>>>> non-JavaEE apps, containers (Docker) and those that want to run a
>>>>>>>> standalone KC server it would be nice to have a small as possible
>>>>>>>> distro.
>>>>>>> Depending on how the feature pack turns out, we might be able to offer
>>>>>>> many flavors of the appliance distro without any additional effort.  We
>>>>>>> could have:
>>>>>>> EAP6 + Keycloak
>>>>>>> AS7 + Keycloak
>>>>>>> WF8 (web) + Keycloak
>>>>>>> WF8 (full) + Keycloak
>>>>>>> WF 9 beta (web) + Keycloak
>>>>>>> WF 9 beta (full) + Keycloak
>>>>>>> etc.
>>>>>>>
>>>>>>
>>>>>> IMO, we just need:
>>>>>> * war-dist
>>>>>> * appliance-dist
>>>>>>
>>>>>> Appliance distribution would have the most stable platform available.
>>>>>> Since we can't distribute EAP, then it would be the most stable and
>>>>>> maintained version of Wildfly that allows us to cluster and deploy
>>>>>> Keycloak.
>>>>>
>>>>> Our download at the moment is 160MB and is really aimed at the first-time
>>>>> JavaEE user (bundled with examples and documentation). Why should we
>>>>> require someone that just wants to upgrade their server to download all
>>>>> of
>>>>> that? There'll also be loads of people that don't need the JavaEE parts,
>>>>> a
>>>>> NodeJS developer or deploying to cloud for example. I think we could
>>>>> easily have a standalone Keycloak server download that'd be around 30MB.
>>>>>
>>>>> IMO we should have:
>>>>>
>>>>> * Minimal server (based on WildFly web/core)
>>>>> * Full server (based on WildFly full)
>>>>> * Feature pack - to easily install onto other version of WF, EAP, etc.
>>>>>
>>>>> Neither of those downloads should include docs or examples. As we don't
>>>>> really support installing onto Tomcat or Jetty, why have a war-dist?
>>>>>
>>>>
>>>> I disagree.  At least one download should have everything:  docs,
>>>> examples, and a distro that can run the examples.  Reducing even simple
>>>> steps for 1st time users is crucial to adoption.  How fast a first time
>>>> user can get "hello world" running is crucial.  BTW, That's a major
>>>> reason why your suggestion earlier of having examples on Github is not a
>>>> great idea.
>>>
>>> WildFly, PicketLink, Infinispan, etc. all use the same approach for
>>> quickstarts. They're in GitHub in a separate project, which can easily be
>>> forked/cloned by users. This is IMO a much better way to get started than
>>> downloading a zip. Problem is that currently we don't cater for those that
>>> want to fork/clone the examples as they have to do everything, which would
>>> at least stop me from doing it. If we put it in a separate project that
>>> doesn't stop us from releasing a bundle with everything in it. It just
>>> adds an extra step to the releasing, which could be automated with a
>>> script.
>>>
>>
>> Just because everybody does it doesn't mean it is a good idea.  I really
>> hate that they do that and have run into problems.  Let me give more
>> reasons why it is a bad idea:
>>
>> * A user may never have used github
>
> Sure, so let's have a download from them as well. In fact you can download a github repo with a single click.
>
>> * There may be an incompatibility with the version developer is using
>> vs. the master example branch.
>> * Requires user to either edit example pom to point to desired project
>> version or to checkout correct tag.
>
> I agree with versions being a bit of an issue, but that's easily fixed with tags. Also, I'm fine with having a bundle with everything in it as well for those that want that. I just want to cater for those that don't as well.
>
>> * Keycloak examples are currently active modules in our main git repo.
>> They load up as a module in our IDE.  Examples are targeted for refactor
>> events just like any other project.
>
> You can import multiple mvn projects into the same IDE project.
>

We can barely get contributors to perform a build before submitting a PR.

>> * Keycloak examples are built with build.  Thus catching any compiler
>> bugs that often happen when refactoring Keycloak SPIs, APIs, or whatever.
>
> See above + we should have continuous integration running tests on examples against head of KC
>

So, more infrastructure to support something that is already done?

I just don't see how a git repo for examples gives you any advantages 
over the current situation.  It just complicates things all around both 
for users and keycloak contributors.  Seriously what are the advantages 
other than saving a few meg in a distro?



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

From bburke at redhat.com  Wed Dec  3 09:07:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Dec 2014 09:07:08 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com>
	<547E1D3D.2040209@redhat.com>	<547E22B3.2050300@redhat.com>
	<547E2725.8040006@redhat.com>	<547E3166.9000007@redhat.com>
	<547E3218.8080908@redhat.com>	<547E48DE.4080101@redhat.com>
	<547E7BDB.3090907@redhat.com>
	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
Message-ID: <547F190C.4010803@redhat.com>



On 12/3/2014 2:43 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 3 December, 2014 3:56:27 AM
>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>
>> On 12/2/2014 6:18 PM, Stan Silvert wrote:
>>> On 12/2/2014 4:41 PM, Bill Burke wrote:
>>>> On 12/2/2014 4:38 PM, Bill Burke wrote:
>>>>> On 12/2/2014 3:55 PM, Stan Silvert wrote:
>>>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>>>>>>> oops, thanks to you for reporting issue to me this time:-)
>>>>>>>
>>>>>>> It should be fixed now. Let me know if it helps.
>>>>>> That fixed it.  Wish mine was that easy.
>>>>>>
>>>>>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
>>>>>> AS7.  It does exist on EAP6, WF8, and WF9.
>>>>>>
>>>>>> I think our best course right now is to not use the subsystem on AS7.
>>>>>> You can still deploy the auth-server WAR into the /deployments directory
>>>>>> if you are dead set on using AS7 that way.
>>>>>>
>>>>>> This doesn't affect the AS7 adapter at all.  We just need to remove the
>>>>>> subsystem module from the dist.
>>>>>>
>>>>> Isn't the adapter subsystem and auth-server subsystem in the same
>>>>> jar/module?
>>>>>
>>>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
>>>>>
>>>> What I'm saying is...didn't you just totally break the as7 adapter?
>>>>
>>>>
>>> No, they are not in the same module.  But now I do see what you are
>>> saying.  The subsystem is adding the adapter module, so yes, it's broken
>>> unless you add the module in jboss-structure.xml.
>>>
>>> Need to think on this some more.
>> So the simplest solution actually is to do what I say above when using
>> AS7.  That is, you either package the adapter in your WAR or you
>> reference it in jboss-structure.xml.  That would require no further
>> changes.  Just merge the PR I sent earlier and I'll change the docs.
>>
>> Is that acceptable?  There are some other solutions, but I don't like
>> them as much.  Anything else we do will require treating the AS7
>> subsystem as a special case and I just don't see the ROI.  AS7 is (or
>> should be) a dead platform.
>>
>> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty.
>> We still have the AS7 adapter but you don't use the subsystem.
>
> IMO that's a decent solution and better than having a separate subsystem for AS7 (assuming that'd be the only option).
>

-20...The subsystem allows you to have specify KEYCLOAK as the 
<auth-method>, as well as to override a WAR's security settings in 
standalone.xml.  Without a subsystem you have to specify a jboss-web.xml 
and a valve.  We need to be as consistent as possible.  If you're not 
going to fix it, let me know and I'll do it.

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

From bburke at redhat.com  Wed Dec  3 09:10:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Dec 2014 09:10:08 -0500
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
Message-ID: <547F19C0.9040206@redhat.com>



On 12/3/2014 2:55 AM, Stian Thorgersen wrote:
> As AccessToken and RefreshToken extends IDToken they contain the ID Token claims. If I've read the spec correctly those claims should only be in the ID Token. There should also be a separate UserInfo endpoint which we're missing.
>

access and refresh tokens are opaque.  We can put anything we want in them.

> Is there a reason why AccessToken extends IDToken, or can we remove that?

Please don't remove it.  AccessToken extends IDTOken so that we can 
propagate stuff with bearer token auth.  Refresh token needs much of the 
same information as JWT, expiration, subject, roles granted, claims 
granted so it can make decisions on whether to refresh the token or not.

> _______________________________________________
> 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  Wed Dec  3 09:12:01 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 03 Dec 2014 09:12:01 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547F190C.4010803@redhat.com>
References: <547C8466.4050103@redhat.com>
	<547E1D3D.2040209@redhat.com>	<547E22B3.2050300@redhat.com>
	<547E2725.8040006@redhat.com>	<547E3166.9000007@redhat.com>
	<547E3218.8080908@redhat.com>	<547E48DE.4080101@redhat.com>
	<547E7BDB.3090907@redhat.com>
	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
	<547F190C.4010803@redhat.com>
Message-ID: <547F1A31.9050703@redhat.com>

On 12/3/2014 9:07 AM, Bill Burke wrote:
>
> On 12/3/2014 2:43 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 3 December, 2014 3:56:27 AM
>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>>
>>> On 12/2/2014 6:18 PM, Stan Silvert wrote:
>>>> On 12/2/2014 4:41 PM, Bill Burke wrote:
>>>>> On 12/2/2014 4:38 PM, Bill Burke wrote:
>>>>>> On 12/2/2014 3:55 PM, Stan Silvert wrote:
>>>>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>>>>>>>> oops, thanks to you for reporting issue to me this time:-)
>>>>>>>>
>>>>>>>> It should be fixed now. Let me know if it helps.
>>>>>>> That fixed it.  Wish mine was that easy.
>>>>>>>
>>>>>>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
>>>>>>> AS7.  It does exist on EAP6, WF8, and WF9.
>>>>>>>
>>>>>>> I think our best course right now is to not use the subsystem on AS7.
>>>>>>> You can still deploy the auth-server WAR into the /deployments directory
>>>>>>> if you are dead set on using AS7 that way.
>>>>>>>
>>>>>>> This doesn't affect the AS7 adapter at all.  We just need to remove the
>>>>>>> subsystem module from the dist.
>>>>>>>
>>>>>> Isn't the adapter subsystem and auth-server subsystem in the same
>>>>>> jar/module?
>>>>>>
>>>>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
>>>>>>
>>>>> What I'm saying is...didn't you just totally break the as7 adapter?
>>>>>
>>>>>
>>>> No, they are not in the same module.  But now I do see what you are
>>>> saying.  The subsystem is adding the adapter module, so yes, it's broken
>>>> unless you add the module in jboss-structure.xml.
>>>>
>>>> Need to think on this some more.
>>> So the simplest solution actually is to do what I say above when using
>>> AS7.  That is, you either package the adapter in your WAR or you
>>> reference it in jboss-structure.xml.  That would require no further
>>> changes.  Just merge the PR I sent earlier and I'll change the docs.
>>>
>>> Is that acceptable?  There are some other solutions, but I don't like
>>> them as much.  Anything else we do will require treating the AS7
>>> subsystem as a special case and I just don't see the ROI.  AS7 is (or
>>> should be) a dead platform.
>>>
>>> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty.
>>> We still have the AS7 adapter but you don't use the subsystem.
>> IMO that's a decent solution and better than having a separate subsystem for AS7 (assuming that'd be the only option).
>>
> -20...The subsystem allows you to have specify KEYCLOAK as the
> <auth-method>, as well as to override a WAR's security settings in
> standalone.xml.  Without a subsystem you have to specify a jboss-web.xml
> and a valve.  We need to be as consistent as possible.  If you're not
> going to fix it, let me know and I'll do it.
>
That's fine.  I can fix it, but it will take some time.

I could disable auth server creation within the subsystem on AS7. All 
the places where I used the newer API are in that part of the 
subsystem.  So if you wanted to run the auth server on AS7, you would 
need to deploy the WAR manually.  Everything else in the subsystem would 
work as it did in the previous release.

Does that sound OK?

From bburke at redhat.com  Wed Dec  3 09:12:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Dec 2014 09:12:04 -0500
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <547F1282.4050303@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
	<547F1282.4050303@redhat.com>
Message-ID: <547F1A34.4090001@redhat.com>



On 12/3/2014 8:39 AM, Marek Posolda wrote:
> 4) Keep as it is.
>

We will keep it as is.  Going back to the auth server every request to 
obtain role mappings and user information is counter to what we are 
trying to accomplish.

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

From bburke at redhat.com  Wed Dec  3 09:15:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Dec 2014 09:15:05 -0500
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <1242377153.9645069.1417615279852.JavaMail.zimbra@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>	<547F1282.4050303@redhat.com>
	<1242377153.9645069.1417615279852.JavaMail.zimbra@redhat.com>
Message-ID: <547F1AE9.8020500@redhat.com>



On 12/3/2014 9:01 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Wednesday, 3 December, 2014 2:39:14 PM
>> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
>>
>> The one reason I can think of is bearer authentication. Currently we are
>> doing it with accessToken and if we remove claims from accessToken, then
>> bearer app won't be able to easily retrieve informations about user
>> without sending another request to UserInfo endpoint. I agree that
>> having userInfo in all tokens doesn't makes much sense, but not sure how
>> to improve it. Some options:
>> 1) Remove IDToken (but I guess we need it for OpenID connect support,
>> right?)
>> 2) Send both accessToken+idToken to bearer auth (but there is more
>> network bandwith then)
>> 3) Allow bearer apps to retrieve data from UserInfo, but that's another
>> request to KC needed then
>> 4) Keep as it is.
>
> It would reduce the size of the access token. Could be by quite a few bytes when there's more and more claims added. Question is how does REST endpoints expect to retrieve these claims, and how many REST endpoints actually use the claims at all? Not sure how you would send the token separately as it's expected the authorization header contains the bearer token only.
>

You can currently control per client what exactly goes in the access token.

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

From bburke at redhat.com  Wed Dec  3 09:16:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Dec 2014 09:16:28 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547F1A31.9050703@redhat.com>
References: <547C8466.4050103@redhat.com>	<547E1D3D.2040209@redhat.com>	<547E22B3.2050300@redhat.com>	<547E2725.8040006@redhat.com>	<547E3166.9000007@redhat.com>	<547E3218.8080908@redhat.com>	<547E48DE.4080101@redhat.com>	<547E7BDB.3090907@redhat.com>	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>	<547F190C.4010803@redhat.com>
	<547F1A31.9050703@redhat.com>
Message-ID: <547F1B3C.8090507@redhat.com>



On 12/3/2014 9:12 AM, Stan Silvert wrote:
> On 12/3/2014 9:07 AM, Bill Burke wrote:
>>
>> On 12/3/2014 2:43 AM, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 3 December, 2014 3:56:27 AM
>>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>>>
>>>> On 12/2/2014 6:18 PM, Stan Silvert wrote:
>>>>> On 12/2/2014 4:41 PM, Bill Burke wrote:
>>>>>> On 12/2/2014 4:38 PM, Bill Burke wrote:
>>>>>>> On 12/2/2014 3:55 PM, Stan Silvert wrote:
>>>>>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>>>>>>>>> oops, thanks to you for reporting issue to me this time:-)
>>>>>>>>>
>>>>>>>>> It should be fixed now. Let me know if it helps.
>>>>>>>> That fixed it.  Wish mine was that easy.
>>>>>>>>
>>>>>>>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
>>>>>>>> AS7.  It does exist on EAP6, WF8, and WF9.
>>>>>>>>
>>>>>>>> I think our best course right now is to not use the subsystem on AS7.
>>>>>>>> You can still deploy the auth-server WAR into the /deployments directory
>>>>>>>> if you are dead set on using AS7 that way.
>>>>>>>>
>>>>>>>> This doesn't affect the AS7 adapter at all.  We just need to remove the
>>>>>>>> subsystem module from the dist.
>>>>>>>>
>>>>>>> Isn't the adapter subsystem and auth-server subsystem in the same
>>>>>>> jar/module?
>>>>>>>
>>>>>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
>>>>>>>
>>>>>> What I'm saying is...didn't you just totally break the as7 adapter?
>>>>>>
>>>>>>
>>>>> No, they are not in the same module.  But now I do see what you are
>>>>> saying.  The subsystem is adding the adapter module, so yes, it's broken
>>>>> unless you add the module in jboss-structure.xml.
>>>>>
>>>>> Need to think on this some more.
>>>> So the simplest solution actually is to do what I say above when using
>>>> AS7.  That is, you either package the adapter in your WAR or you
>>>> reference it in jboss-structure.xml.  That would require no further
>>>> changes.  Just merge the PR I sent earlier and I'll change the docs.
>>>>
>>>> Is that acceptable?  There are some other solutions, but I don't like
>>>> them as much.  Anything else we do will require treating the AS7
>>>> subsystem as a special case and I just don't see the ROI.  AS7 is (or
>>>> should be) a dead platform.
>>>>
>>>> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty.
>>>> We still have the AS7 adapter but you don't use the subsystem.
>>> IMO that's a decent solution and better than having a separate subsystem for AS7 (assuming that'd be the only option).
>>>
>> -20...The subsystem allows you to have specify KEYCLOAK as the
>> <auth-method>, as well as to override a WAR's security settings in
>> standalone.xml.  Without a subsystem you have to specify a jboss-web.xml
>> and a valve.  We need to be as consistent as possible.  If you're not
>> going to fix it, let me know and I'll do it.
>>
> That's fine.  I can fix it, but it will take some time.
>
> I could disable auth server creation within the subsystem on AS7. All
> the places where I used the newer API are in that part of the
> subsystem.  So if you wanted to run the auth server on AS7, you would
> need to deploy the WAR manually.  Everything else in the subsystem would
> work as it did in the previous release.
>
> Does that sound OK?

Sure, or you could just separate the auth-server and adapter subsystem 
code into separate artifacts and modules.

Bill

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

From stian at redhat.com  Wed Dec  3 09:28:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 09:28:01 -0500 (EST)
Subject: [keycloak-dev] release?  Stan?
In-Reply-To: <547F1847.5070705@redhat.com>
References: <547C8466.4050103@redhat.com> <547DC0D8.9000404@redhat.com>
	<2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
	<547DD697.5030909@redhat.com>
	<1850709811.8894994.1417535591934.JavaMail.zimbra@redhat.com>
	<547DE950.4020702@redhat.com>
	<497458874.9345334.1417592314199.JavaMail.zimbra@redhat.com>
	<547F1847.5070705@redhat.com>
Message-ID: <711150735.9669861.1417616881834.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, 3 December, 2014 3:03:51 PM
> Subject: Re: [keycloak-dev] release?  Stan?
> 
> 
> 
> On 12/3/2014 2:38 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 2 December, 2014 5:31:12 PM
> >> Subject: Re: [keycloak-dev] release?  Stan?
> >>
> >>
> >>
> >> On 12/2/2014 10:53 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 2 December, 2014 4:11:19 PM
> >>>> Subject: Re: [keycloak-dev] release?  Stan?
> >>>>
> >>>>
> >>>>
> >>>> On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Tuesday, 2 December, 2014 2:38:32 PM
> >>>>>> Subject: Re: [keycloak-dev] release?  Stan?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
> >>>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
> >>>>>>>> Should we upgrade to WF 8.2 and also do some changes to the distro
> >>>>>>>> before
> >>>>>>>> release?
> >>>>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me know
> >>>>>>> so
> >>>>>>> I can run a quick smoke test on the subsystem before we release.
> >>>>>>>>
> >>>>>>>> With regards to distro we should move the adapters and examples into
> >>>>>>>> separate downloads. Also, we should move the examples into a
> >>>>>>>> separate
> >>>>>>>> github project (keycloak/keycloak-examples). This will make it
> >>>>>>>> easier
> >>>>>>>> for
> >>>>>>>> those that wants to fork the examples separately.
> >>>>>>>>
> >>>>>>>> Also, we should consider a download based on the web-lite profile.
> >>>>>>>> For
> >>>>>>>> non-JavaEE apps, containers (Docker) and those that want to run a
> >>>>>>>> standalone KC server it would be nice to have a small as possible
> >>>>>>>> distro.
> >>>>>>> Depending on how the feature pack turns out, we might be able to
> >>>>>>> offer
> >>>>>>> many flavors of the appliance distro without any additional effort.
> >>>>>>> We
> >>>>>>> could have:
> >>>>>>> EAP6 + Keycloak
> >>>>>>> AS7 + Keycloak
> >>>>>>> WF8 (web) + Keycloak
> >>>>>>> WF8 (full) + Keycloak
> >>>>>>> WF 9 beta (web) + Keycloak
> >>>>>>> WF 9 beta (full) + Keycloak
> >>>>>>> etc.
> >>>>>>>
> >>>>>>
> >>>>>> IMO, we just need:
> >>>>>> * war-dist
> >>>>>> * appliance-dist
> >>>>>>
> >>>>>> Appliance distribution would have the most stable platform available.
> >>>>>> Since we can't distribute EAP, then it would be the most stable and
> >>>>>> maintained version of Wildfly that allows us to cluster and deploy
> >>>>>> Keycloak.
> >>>>>
> >>>>> Our download at the moment is 160MB and is really aimed at the
> >>>>> first-time
> >>>>> JavaEE user (bundled with examples and documentation). Why should we
> >>>>> require someone that just wants to upgrade their server to download all
> >>>>> of
> >>>>> that? There'll also be loads of people that don't need the JavaEE
> >>>>> parts,
> >>>>> a
> >>>>> NodeJS developer or deploying to cloud for example. I think we could
> >>>>> easily have a standalone Keycloak server download that'd be around
> >>>>> 30MB.
> >>>>>
> >>>>> IMO we should have:
> >>>>>
> >>>>> * Minimal server (based on WildFly web/core)
> >>>>> * Full server (based on WildFly full)
> >>>>> * Feature pack - to easily install onto other version of WF, EAP, etc.
> >>>>>
> >>>>> Neither of those downloads should include docs or examples. As we don't
> >>>>> really support installing onto Tomcat or Jetty, why have a war-dist?
> >>>>>
> >>>>
> >>>> I disagree.  At least one download should have everything:  docs,
> >>>> examples, and a distro that can run the examples.  Reducing even simple
> >>>> steps for 1st time users is crucial to adoption.  How fast a first time
> >>>> user can get "hello world" running is crucial.  BTW, That's a major
> >>>> reason why your suggestion earlier of having examples on Github is not a
> >>>> great idea.
> >>>
> >>> WildFly, PicketLink, Infinispan, etc. all use the same approach for
> >>> quickstarts. They're in GitHub in a separate project, which can easily be
> >>> forked/cloned by users. This is IMO a much better way to get started than
> >>> downloading a zip. Problem is that currently we don't cater for those
> >>> that
> >>> want to fork/clone the examples as they have to do everything, which
> >>> would
> >>> at least stop me from doing it. If we put it in a separate project that
> >>> doesn't stop us from releasing a bundle with everything in it. It just
> >>> adds an extra step to the releasing, which could be automated with a
> >>> script.
> >>>
> >>
> >> Just because everybody does it doesn't mean it is a good idea.  I really
> >> hate that they do that and have run into problems.  Let me give more
> >> reasons why it is a bad idea:
> >>
> >> * A user may never have used github
> >
> > Sure, so let's have a download from them as well. In fact you can download
> > a github repo with a single click.
> >
> >> * There may be an incompatibility with the version developer is using
> >> vs. the master example branch.
> >> * Requires user to either edit example pom to point to desired project
> >> version or to checkout correct tag.
> >
> > I agree with versions being a bit of an issue, but that's easily fixed with
> > tags. Also, I'm fine with having a bundle with everything in it as well
> > for those that want that. I just want to cater for those that don't as
> > well.
> >
> >> * Keycloak examples are currently active modules in our main git repo.
> >> They load up as a module in our IDE.  Examples are targeted for refactor
> >> events just like any other project.
> >
> > You can import multiple mvn projects into the same IDE project.
> >
> 
> We can barely get contributors to perform a build before submitting a PR.

And you expect external contributors to do large changes to API's or refactor code? 

With proper CI integration we can build automatically on PRs so contributors don't have to run tests at all. Which we should do in either case as we can't just merge an external PR without at least checking it builds and tests pass first.

> 
> >> * Keycloak examples are built with build.  Thus catching any compiler
> >> bugs that often happen when refactoring Keycloak SPIs, APIs, or whatever.
> >
> > See above + we should have continuous integration running tests on examples
> > against head of KC
> >
> 
> So, more infrastructure to support something that is already done?

There's nothing extra - we don't test examples currently, and testing examples whether or not they're part of the core code or a separate project makes no difference IMO.

> 
> I just don't see how a git repo for examples gives you any advantages
> over the current situation.  It just complicates things all around both
> for users and keycloak contributors.  Seriously what are the advantages
> other than saving a few meg in a distro?

More and more people are used to GitHub these days, especially in Open Source. I certainly wouldn't want to clone a large code-base to get just the examples. With a GitHub fork of examples users can fork the examples and play with them, instead of having to extract the zip then commit it to a separate GitHub. It also lets you add examples or fix examples after a release. 

For automation/scripting things there's a lot more steps involved, as well as a longer spin-up time of images. The more docs (and images) and examples we add the bigger the distro. As a user of Keycloak I would actually have ended up with repackaging KC server for distribution internally as ours isn't suitable for it. This may be a Linux thing, but I have loads of scripts that automate things for me.

With the distro I'm looking for I can script installation of KC to just:

  curl <KEYCLOAK DOWNLOAD URL> | tar zx

While with our current distro I need to do:

  curl -O <KEYCLOAK DOWNLOAD URL>
  unzip keycloak-appliance-dist-all-<KEYCLOAK_VERSION>.zip
  mv keycloak-appliance-dist-all-<KEYCLOAK_VERSION>/keycloak keycloak-<KEYCLOAK_VERSION> 
  rm -rf keycloak-appliance-dist-all-<KEYCLOAK_VERSION>

It would also be nice to have a similar developer experience to other JBoss projects.

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

From stian at redhat.com  Wed Dec  3 09:34:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 09:34:13 -0500 (EST)
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <547F1AE9.8020500@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
	<547F1282.4050303@redhat.com>
	<1242377153.9645069.1417615279852.JavaMail.zimbra@redhat.com>
	<547F1AE9.8020500@redhat.com>
Message-ID: <14665240.9674652.1417617253477.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 3:15:05 PM
> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
> 
> 
> 
> On 12/3/2014 9:01 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
> >> <keycloak-dev at lists.jboss.org>
> >> Sent: Wednesday, 3 December, 2014 2:39:14 PM
> >> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh
> >> Token
> >>
> >> The one reason I can think of is bearer authentication. Currently we are
> >> doing it with accessToken and if we remove claims from accessToken, then
> >> bearer app won't be able to easily retrieve informations about user
> >> without sending another request to UserInfo endpoint. I agree that
> >> having userInfo in all tokens doesn't makes much sense, but not sure how
> >> to improve it. Some options:
> >> 1) Remove IDToken (but I guess we need it for OpenID connect support,
> >> right?)
> >> 2) Send both accessToken+idToken to bearer auth (but there is more
> >> network bandwith then)
> >> 3) Allow bearer apps to retrieve data from UserInfo, but that's another
> >> request to KC needed then
> >> 4) Keep as it is.
> >
> > It would reduce the size of the access token. Could be by quite a few bytes
> > when there's more and more claims added. Question is how does REST
> > endpoints expect to retrieve these claims, and how many REST endpoints
> > actually use the claims at all? Not sure how you would send the token
> > separately as it's expected the authorization header contains the bearer
> > token only.
> >
> 
> You can currently control per client what exactly goes in the access token.

That doesn't really help. A front-end app may for example want the full profile, but if it does that means the token it sends with all requests is bigger 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 alain at rexorient.com  Wed Dec  3 11:26:26 2014
From: alain at rexorient.com (Alain Penders)
Date: Wed, 3 Dec 2014 09:26:26 -0700
Subject: [keycloak-dev] release? Stan?
In-Reply-To: <711150735.9669861.1417616881834.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com> <547DC0D8.9000404@redhat.com>
	<2016677582.8721083.1417528922020.JavaMail.zimbra@redhat.com>
	<547DD697.5030909@redhat.com>
	<1850709811.8894994.1417535591934.JavaMail.zimbra@redhat.com>
	<547DE950.4020702@redhat.com>
	<497458874.9345334.1417592314199.JavaMail.zimbra@redhat.com>
	<547F1847.5070705@redhat.com>
	<711150735.9669861.1417616881834.JavaMail.zimbra@redhat.com>
Message-ID: <CAMtP740D4k-Ag+Ra=oaaChsS+=zQ3Usws5am1p2QgYr-oJRs1g@mail.gmail.com>

Being a KC user and possibly one of those pesky external contributors, I'd
like to throw in a few cents...

1. Github is key to open source developers, but at least 50% of the "Senior
Software Developers" I work with have no clue about it, Linux, tar, or
pipes.  These developers have always worked for companies developing closed
source software, know git only because we have a local git repo and someone
wrote a wiki page on how to use it from IntelliJ, and aren't the ones
selecting 3rd party libraries to use (which are then loaded into our Nexus
repo and magically show up in their builds.)
2. We have a home-grown authentication / authorization system that is
extremely similar to KC.  We used Spring Security OAuth, but almost all
layers of it were replaced by custom implementations to make it hook into
our legacy login system, build tokens with a ton of data in them, and
integrate with SAML.  I think we have close to a million users on our
production system.
3. The main reason I picked KC over using Spring Security OAuth for the
home project I'm working on were the instructional videos Bill did.  More
than any example can possibly do, they helped jump start my understanding
of KC and showed how to integrate it.   After watching those, the examples
turned into a library to copy and paste from.
4. For projects which don't have much documentation (KC is extremely well
documented), cloning an example and playing with it is my preferred way of
getting to know a new library/solution.   To that extent, having the
examples in a separate Git repo (or one repo per platform the exampled
target) does help.

Alain


On Wed, Dec 3, 2014 at 7:28 AM, 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, 3 December, 2014 3:03:51 PM
> > Subject: Re: [keycloak-dev] release?  Stan?
> >
> >
> >
> > On 12/3/2014 2:38 AM, Stian Thorgersen wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: "Stian Thorgersen" <stian at redhat.com>
> > >> Cc: keycloak-dev at lists.jboss.org
> > >> Sent: Tuesday, 2 December, 2014 5:31:12 PM
> > >> Subject: Re: [keycloak-dev] release?  Stan?
> > >>
> > >>
> > >>
> > >> On 12/2/2014 10:53 AM, Stian Thorgersen wrote:
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>> Cc: keycloak-dev at lists.jboss.org
> > >>>> Sent: Tuesday, 2 December, 2014 4:11:19 PM
> > >>>> Subject: Re: [keycloak-dev] release?  Stan?
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
> > >>>>>
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>>> To: keycloak-dev at lists.jboss.org
> > >>>>>> Sent: Tuesday, 2 December, 2014 2:38:32 PM
> > >>>>>> Subject: Re: [keycloak-dev] release?  Stan?
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
> > >>>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
> > >>>>>>>> Should we upgrade to WF 8.2 and also do some changes to the
> distro
> > >>>>>>>> before
> > >>>>>>>> release?
> > >>>>>>> I don't see a reason not to go to WF 8.2.  If we do that, let me
> know
> > >>>>>>> so
> > >>>>>>> I can run a quick smoke test on the subsystem before we release.
> > >>>>>>>>
> > >>>>>>>> With regards to distro we should move the adapters and examples
> into
> > >>>>>>>> separate downloads. Also, we should move the examples into a
> > >>>>>>>> separate
> > >>>>>>>> github project (keycloak/keycloak-examples). This will make it
> > >>>>>>>> easier
> > >>>>>>>> for
> > >>>>>>>> those that wants to fork the examples separately.
> > >>>>>>>>
> > >>>>>>>> Also, we should consider a download based on the web-lite
> profile.
> > >>>>>>>> For
> > >>>>>>>> non-JavaEE apps, containers (Docker) and those that want to run
> a
> > >>>>>>>> standalone KC server it would be nice to have a small as
> possible
> > >>>>>>>> distro.
> > >>>>>>> Depending on how the feature pack turns out, we might be able to
> > >>>>>>> offer
> > >>>>>>> many flavors of the appliance distro without any additional
> effort.
> > >>>>>>> We
> > >>>>>>> could have:
> > >>>>>>> EAP6 + Keycloak
> > >>>>>>> AS7 + Keycloak
> > >>>>>>> WF8 (web) + Keycloak
> > >>>>>>> WF8 (full) + Keycloak
> > >>>>>>> WF 9 beta (web) + Keycloak
> > >>>>>>> WF 9 beta (full) + Keycloak
> > >>>>>>> etc.
> > >>>>>>>
> > >>>>>>
> > >>>>>> IMO, we just need:
> > >>>>>> * war-dist
> > >>>>>> * appliance-dist
> > >>>>>>
> > >>>>>> Appliance distribution would have the most stable platform
> available.
> > >>>>>> Since we can't distribute EAP, then it would be the most stable
> and
> > >>>>>> maintained version of Wildfly that allows us to cluster and deploy
> > >>>>>> Keycloak.
> > >>>>>
> > >>>>> Our download at the moment is 160MB and is really aimed at the
> > >>>>> first-time
> > >>>>> JavaEE user (bundled with examples and documentation). Why should
> we
> > >>>>> require someone that just wants to upgrade their server to
> download all
> > >>>>> of
> > >>>>> that? There'll also be loads of people that don't need the JavaEE
> > >>>>> parts,
> > >>>>> a
> > >>>>> NodeJS developer or deploying to cloud for example. I think we
> could
> > >>>>> easily have a standalone Keycloak server download that'd be around
> > >>>>> 30MB.
> > >>>>>
> > >>>>> IMO we should have:
> > >>>>>
> > >>>>> * Minimal server (based on WildFly web/core)
> > >>>>> * Full server (based on WildFly full)
> > >>>>> * Feature pack - to easily install onto other version of WF, EAP,
> etc.
> > >>>>>
> > >>>>> Neither of those downloads should include docs or examples. As we
> don't
> > >>>>> really support installing onto Tomcat or Jetty, why have a
> war-dist?
> > >>>>>
> > >>>>
> > >>>> I disagree.  At least one download should have everything:  docs,
> > >>>> examples, and a distro that can run the examples.  Reducing even
> simple
> > >>>> steps for 1st time users is crucial to adoption.  How fast a first
> time
> > >>>> user can get "hello world" running is crucial.  BTW, That's a major
> > >>>> reason why your suggestion earlier of having examples on Github is
> not a
> > >>>> great idea.
> > >>>
> > >>> WildFly, PicketLink, Infinispan, etc. all use the same approach for
> > >>> quickstarts. They're in GitHub in a separate project, which can
> easily be
> > >>> forked/cloned by users. This is IMO a much better way to get started
> than
> > >>> downloading a zip. Problem is that currently we don't cater for those
> > >>> that
> > >>> want to fork/clone the examples as they have to do everything, which
> > >>> would
> > >>> at least stop me from doing it. If we put it in a separate project
> that
> > >>> doesn't stop us from releasing a bundle with everything in it. It
> just
> > >>> adds an extra step to the releasing, which could be automated with a
> > >>> script.
> > >>>
> > >>
> > >> Just because everybody does it doesn't mean it is a good idea.  I
> really
> > >> hate that they do that and have run into problems.  Let me give more
> > >> reasons why it is a bad idea:
> > >>
> > >> * A user may never have used github
> > >
> > > Sure, so let's have a download from them as well. In fact you can
> download
> > > a github repo with a single click.
> > >
> > >> * There may be an incompatibility with the version developer is using
> > >> vs. the master example branch.
> > >> * Requires user to either edit example pom to point to desired project
> > >> version or to checkout correct tag.
> > >
> > > I agree with versions being a bit of an issue, but that's easily fixed
> with
> > > tags. Also, I'm fine with having a bundle with everything in it as well
> > > for those that want that. I just want to cater for those that don't as
> > > well.
> > >
> > >> * Keycloak examples are currently active modules in our main git repo.
> > >> They load up as a module in our IDE.  Examples are targeted for
> refactor
> > >> events just like any other project.
> > >
> > > You can import multiple mvn projects into the same IDE project.
> > >
> >
> > We can barely get contributors to perform a build before submitting a PR.
>
> And you expect external contributors to do large changes to API's or
> refactor code?
>
> With proper CI integration we can build automatically on PRs so
> contributors don't have to run tests at all. Which we should do in either
> case as we can't just merge an external PR without at least checking it
> builds and tests pass first.
>
> >
> > >> * Keycloak examples are built with build.  Thus catching any compiler
> > >> bugs that often happen when refactoring Keycloak SPIs, APIs, or
> whatever.
> > >
> > > See above + we should have continuous integration running tests on
> examples
> > > against head of KC
> > >
> >
> > So, more infrastructure to support something that is already done?
>
> There's nothing extra - we don't test examples currently, and testing
> examples whether or not they're part of the core code or a separate project
> makes no difference IMO.
>
> >
> > I just don't see how a git repo for examples gives you any advantages
> > over the current situation.  It just complicates things all around both
> > for users and keycloak contributors.  Seriously what are the advantages
> > other than saving a few meg in a distro?
>
> More and more people are used to GitHub these days, especially in Open
> Source. I certainly wouldn't want to clone a large code-base to get just
> the examples. With a GitHub fork of examples users can fork the examples
> and play with them, instead of having to extract the zip then commit it to
> a separate GitHub. It also lets you add examples or fix examples after a
> release.
>
> For automation/scripting things there's a lot more steps involved, as well
> as a longer spin-up time of images. The more docs (and images) and examples
> we add the bigger the distro. As a user of Keycloak I would actually have
> ended up with repackaging KC server for distribution internally as ours
> isn't suitable for it. This may be a Linux thing, but I have loads of
> scripts that automate things for me.
>
> With the distro I'm looking for I can script installation of KC to just:
>
>   curl <KEYCLOAK DOWNLOAD URL> | tar zx
>
> While with our current distro I need to do:
>
>   curl -O <KEYCLOAK DOWNLOAD URL>
>   unzip keycloak-appliance-dist-all-<KEYCLOAK_VERSION>.zip
>   mv keycloak-appliance-dist-all-<KEYCLOAK_VERSION>/keycloak
> keycloak-<KEYCLOAK_VERSION>
>   rm -rf keycloak-appliance-dist-all-<KEYCLOAK_VERSION>
>
> It would also be nice to have a similar developer experience to other
> JBoss projects.
>
> >
> >
> >
> > --
> > 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/20141203/f10417ba/attachment-0001.html 

From ssilvert at redhat.com  Wed Dec  3 12:30:00 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 03 Dec 2014 12:30:00 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547F190C.4010803@redhat.com>
References: <547C8466.4050103@redhat.com>
	<547E1D3D.2040209@redhat.com>	<547E22B3.2050300@redhat.com>
	<547E2725.8040006@redhat.com>	<547E3166.9000007@redhat.com>
	<547E3218.8080908@redhat.com>	<547E48DE.4080101@redhat.com>
	<547E7BDB.3090907@redhat.com>
	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
	<547F190C.4010803@redhat.com>
Message-ID: <547F4898.7070107@redhat.com>

On 12/3/2014 9:07 AM, Bill Burke wrote:
>
> On 12/3/2014 2:43 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 3 December, 2014 3:56:27 AM
>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>>
>>> On 12/2/2014 6:18 PM, Stan Silvert wrote:
>>>> On 12/2/2014 4:41 PM, Bill Burke wrote:
>>>>> On 12/2/2014 4:38 PM, Bill Burke wrote:
>>>>>> On 12/2/2014 3:55 PM, Stan Silvert wrote:
>>>>>>> On 12/2/2014 3:36 PM, Marek Posolda wrote:
>>>>>>>> oops, thanks to you for reporting issue to me this time:-)
>>>>>>>>
>>>>>>>> It should be fixed now. Let me know if it helps.
>>>>>>> That fixed it.  Wish mine was that easy.
>>>>>>>
>>>>>>> So much for EAP6 being based on AS7.  The API I'm using doesn't exist on
>>>>>>> AS7.  It does exist on EAP6, WF8, and WF9.
>>>>>>>
>>>>>>> I think our best course right now is to not use the subsystem on AS7.
>>>>>>> You can still deploy the auth-server WAR into the /deployments directory
>>>>>>> if you are dead set on using AS7 that way.
>>>>>>>
>>>>>>> This doesn't affect the AS7 adapter at all.  We just need to remove the
>>>>>>> subsystem module from the dist.
>>>>>>>
>>>>>> Isn't the adapter subsystem and auth-server subsystem in the same
>>>>>> jar/module?
>>>>>>
>>>>>> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter
>>>>>>
>>>>> What I'm saying is...didn't you just totally break the as7 adapter?
>>>>>
>>>>>
>>>> No, they are not in the same module.  But now I do see what you are
>>>> saying.  The subsystem is adding the adapter module, so yes, it's broken
>>>> unless you add the module in jboss-structure.xml.
>>>>
>>>> Need to think on this some more.
>>> So the simplest solution actually is to do what I say above when using
>>> AS7.  That is, you either package the adapter in your WAR or you
>>> reference it in jboss-structure.xml.  That would require no further
>>> changes.  Just merge the PR I sent earlier and I'll change the docs.
>>>
>>> Is that acceptable?  There are some other solutions, but I don't like
>>> them as much.  Anything else we do will require treating the AS7
>>> subsystem as a special case and I just don't see the ROI.  AS7 is (or
>>> should be) a dead platform.
>>>
>>> So what I'm proposing is that we just treat AS7 like Tomcat or Jetty.
>>> We still have the AS7 adapter but you don't use the subsystem.
>> IMO that's a decent solution and better than having a separate subsystem for AS7 (assuming that'd be the only option).
>>
> -20...The subsystem allows you to have specify KEYCLOAK as the
> <auth-method>, as well as to override a WAR's security settings in
> standalone.xml.  Without a subsystem you have to specify a jboss-web.xml
> and a valve.  We need to be as consistent as possible.  If you're not
> going to fix it, let me know and I'll do it.
>
More bad news.  The subsystem simply won't run on AS7 unless it is 
compiled against the AS7 API set.  They've done so much backporting on 
EAP that it looks more like WildFly than the AS7 it was supposed to be 
based on.

I see three choices:

1) Bring back the old code for the AS7 subsystem.
2) Treat AS7 like Tomcat
3) Dump AS7 support altogether.  This is not an entirely radical 
choice.  The last version of AS7 was released almost 3 years ago. It is 
no longer maintained or supported.  It would be interesting to find out 
if anyone is actually using it with Keycloak.

From bburke at redhat.com  Wed Dec  3 14:00:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Dec 2014 14:00:51 -0500
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <14665240.9674652.1417617253477.JavaMail.zimbra@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
	<547F1282.4050303@redhat.com>
	<1242377153.9645069.1417615279852.JavaMail.zimbra@redhat.com>
	<547F1AE9.8020500@redhat.com>
	<14665240.9674652.1417617253477.JavaMail.zimbra@redhat.com>
Message-ID: <547F5DE3.4090802@redhat.com>



On 12/3/2014 9:34 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 3 December, 2014 3:15:05 PM
>> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
>>
>>
>>
>> On 12/3/2014 9:01 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
>>>> <keycloak-dev at lists.jboss.org>
>>>> Sent: Wednesday, 3 December, 2014 2:39:14 PM
>>>> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh
>>>> Token
>>>>
>>>> The one reason I can think of is bearer authentication. Currently we are
>>>> doing it with accessToken and if we remove claims from accessToken, then
>>>> bearer app won't be able to easily retrieve informations about user
>>>> without sending another request to UserInfo endpoint. I agree that
>>>> having userInfo in all tokens doesn't makes much sense, but not sure how
>>>> to improve it. Some options:
>>>> 1) Remove IDToken (but I guess we need it for OpenID connect support,
>>>> right?)
>>>> 2) Send both accessToken+idToken to bearer auth (but there is more
>>>> network bandwith then)
>>>> 3) Allow bearer apps to retrieve data from UserInfo, but that's another
>>>> request to KC needed then
>>>> 4) Keep as it is.
>>>
>>> It would reduce the size of the access token. Could be by quite a few bytes
>>> when there's more and more claims added. Question is how does REST
>>> endpoints expect to retrieve these claims, and how many REST endpoints
>>> actually use the claims at all? Not sure how you would send the token
>>> separately as it's expected the authorization header contains the bearer
>>> token only.
>>>
>>
>> You can currently control per client what exactly goes in the access token.
>
> That doesn't really help. A front-end app may for example want the full profile, but if it does that means the token it sends with all requests is bigger as well.
>

And that matters because?  You're talking about bytes here...not 
kilobytes, not megabytes.  Really, this is a non-issue.  Isn't there 
other things to work on?



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

From bburke at redhat.com  Wed Dec  3 14:23:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Dec 2014 14:23:55 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547F4898.7070107@redhat.com>
References: <547C8466.4050103@redhat.com>	<547E1D3D.2040209@redhat.com>	<547E22B3.2050300@redhat.com>	<547E2725.8040006@redhat.com>	<547E3166.9000007@redhat.com>	<547E3218.8080908@redhat.com>	<547E48DE.4080101@redhat.com>	<547E7BDB.3090907@redhat.com>	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>	<547F190C.4010803@redhat.com>
	<547F4898.7070107@redhat.com>
Message-ID: <547F634B.9060203@redhat.com>



On 12/3/2014 12:30 PM, Stan Silvert wrote:
> 1) Bring back the old code for the AS7 subsystem.

Bring it back.  If you don't, let me know and I'll do it.


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

From ssilvert at redhat.com  Wed Dec  3 14:30:03 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 03 Dec 2014 14:30:03 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547F634B.9060203@redhat.com>
References: <547C8466.4050103@redhat.com>	<547E1D3D.2040209@redhat.com>	<547E22B3.2050300@redhat.com>	<547E2725.8040006@redhat.com>	<547E3166.9000007@redhat.com>	<547E3218.8080908@redhat.com>	<547E48DE.4080101@redhat.com>	<547E7BDB.3090907@redhat.com>	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>	<547F190C.4010803@redhat.com>
	<547F4898.7070107@redhat.com> <547F634B.9060203@redhat.com>
Message-ID: <547F64BB.8030800@redhat.com>

On 12/3/2014 2:23 PM, Bill Burke wrote:
>
> On 12/3/2014 12:30 PM, Stan Silvert wrote:
>> 1) Bring back the old code for the AS7 subsystem.
> Bring it back.  If you don't, let me know and I'll do it.
>
>
I'll take care of it.

Just to be clear,  EAP6 will use the enhanced subsystem.  The AS7 
subsystem is for AS7 only and it contains the same functionality as the 
previous release.

From stian at redhat.com  Thu Dec  4 02:41:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 4 Dec 2014 02:41:02 -0500 (EST)
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
In-Reply-To: <547F5DE3.4090802@redhat.com>
References: <154197352.9356832.1417593324915.JavaMail.zimbra@redhat.com>
	<547F1282.4050303@redhat.com>
	<1242377153.9645069.1417615279852.JavaMail.zimbra@redhat.com>
	<547F1AE9.8020500@redhat.com>
	<14665240.9674652.1417617253477.JavaMail.zimbra@redhat.com>
	<547F5DE3.4090802@redhat.com>
Message-ID: <1641331036.10150840.1417678862926.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, 3 December, 2014 8:00:51 PM
> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
> 
> 
> 
> On 12/3/2014 9:34 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 3 December, 2014 3:15:05 PM
> >> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh
> >> Token
> >>
> >>
> >>
> >> On 12/3/2014 9:01 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Marek Posolda" <mposolda at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
> >>>> <keycloak-dev at lists.jboss.org>
> >>>> Sent: Wednesday, 3 December, 2014 2:39:14 PM
> >>>> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh
> >>>> Token
> >>>>
> >>>> The one reason I can think of is bearer authentication. Currently we are
> >>>> doing it with accessToken and if we remove claims from accessToken, then
> >>>> bearer app won't be able to easily retrieve informations about user
> >>>> without sending another request to UserInfo endpoint. I agree that
> >>>> having userInfo in all tokens doesn't makes much sense, but not sure how
> >>>> to improve it. Some options:
> >>>> 1) Remove IDToken (but I guess we need it for OpenID connect support,
> >>>> right?)
> >>>> 2) Send both accessToken+idToken to bearer auth (but there is more
> >>>> network bandwith then)
> >>>> 3) Allow bearer apps to retrieve data from UserInfo, but that's another
> >>>> request to KC needed then
> >>>> 4) Keep as it is.
> >>>
> >>> It would reduce the size of the access token. Could be by quite a few
> >>> bytes
> >>> when there's more and more claims added. Question is how does REST
> >>> endpoints expect to retrieve these claims, and how many REST endpoints
> >>> actually use the claims at all? Not sure how you would send the token
> >>> separately as it's expected the authorization header contains the bearer
> >>> token only.
> >>>
> >>
> >> You can currently control per client what exactly goes in the access
> >> token.
> >
> > That doesn't really help. A front-end app may for example want the full
> > profile, but if it does that means the token it sends with all requests is
> > bigger as well.
> >
> 
> And that matters because?  You're talking about bytes here...not
> kilobytes, not megabytes.  Really, this is a non-issue.  Isn't there
> other things to work on?

I'm just asking questions and discussing something that wasn't clear to me!

Bytes do add up and I believe we have to be careful about what we put into the tokens, but yes I totally agree we have more important things to work on.

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

From stian at redhat.com  Thu Dec  4 02:54:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 4 Dec 2014 02:54:45 -0500 (EST)
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <547F634B.9060203@redhat.com>
References: <547C8466.4050103@redhat.com> <547E3218.8080908@redhat.com>
	<547E48DE.4080101@redhat.com> <547E7BDB.3090907@redhat.com>
	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
	<547F190C.4010803@redhat.com> <547F4898.7070107@redhat.com>
	<547F634B.9060203@redhat.com>
Message-ID: <345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 8:23:55 PM
> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> 
> 
> 
> On 12/3/2014 12:30 PM, Stan Silvert wrote:
> > 1) Bring back the old code for the AS7 subsystem.
> 
> Bring it back.  If you don't, let me know and I'll do it.

Why? I don't get why we keep trying to get AS7 to work. We've already wasted a fair bit of time on this.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bruno at abstractj.org  Thu Dec  4 04:09:26 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 4 Dec 2014 07:09:26 -0200
Subject: [keycloak-dev] Invalid redirect_uri with passport
Message-ID: <20141204090925.GA27060@abstractj.org>

Good morning, I'm doing some progress with Keycloak and Passport.js[1].
Although I get "invalid redirect_uri" using HTTP or HTTPS, if the
callback url[2] is changed to something like "http://www.google.com"
everything works fine.

I saw one issue related to Undertow[3], but I'm not sure if it's
truly related with what's happening here or me doing something wrong.

I'll move forward investigating the issue, but if you have an idea or
suggestion, it will be more than welcome. To reproduce the issue, just
follow the readme instructions[4].

[1] - https://github.com/abstractj/passport-keycloak/tree/goose
[2] -
https://github.com/abstractj/passport-keycloak/blob/goose/examples/app.js#L11
[3] - https://issues.jboss.org/browse/KEYCLOAK-568
[4] -
https://github.com/abstractj/passport-keycloak/blob/goose/README.md

--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Thu Dec  4 05:42:26 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 4 Dec 2014 08:42:26 -0200
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <20141204090925.GA27060@abstractj.org>
References: <20141204090925.GA27060@abstractj.org>
Message-ID: <20141204104226.GA30278@abstractj.org>

Ahoy, after apply the changes suggested by Lukas on IRC[1], I got it working.

I'm planning to release a version 0.0.1.Alpha today for testing if you
guys agree.

[1] -
https://github.com/abstractj/passport-keycloak/commit/0f0baa1fcce3f926ff75b3c1f5253022afe80619

On 2014-12-04, Bruno Oliveira wrote:
> Good morning, I'm doing some progress with Keycloak and Passport.js[1].
> Although I get "invalid redirect_uri" using HTTP or HTTPS, if the
> callback url[2] is changed to something like "http://www.google.com"
> everything works fine.
>
> I saw one issue related to Undertow[3], but I'm not sure if it's
> truly related with what's happening here or me doing something wrong.
>
> I'll move forward investigating the issue, but if you have an idea or
> suggestion, it will be more than welcome. To reproduce the issue, just
> follow the readme instructions[4].
>
> [1] - https://github.com/abstractj/passport-keycloak/tree/goose
> [2] -
> https://github.com/abstractj/passport-keycloak/blob/goose/examples/app.js#L11
> [3] - https://issues.jboss.org/browse/KEYCLOAK-568
> [4] -
> https://github.com/abstractj/passport-keycloak/blob/goose/README.md
>
> --
>
> abstractj
> PGP: 0x84DC9914

--

abstractj
PGP: 0x84DC9914

From stian at redhat.com  Thu Dec  4 06:00:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 4 Dec 2014 06:00:27 -0500 (EST)
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <20141204104226.GA30278@abstractj.org>
References: <20141204090925.GA27060@abstractj.org>
	<20141204104226.GA30278@abstractj.org>
Message-ID: <1699957401.10399598.1417690827780.JavaMail.zimbra@redhat.com>

Was just about to say I tried it here and it seems to be working ;)

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 4 December, 2014 11:42:26 AM
> Subject: Re: [keycloak-dev] Invalid redirect_uri with passport
> 
> Ahoy, after apply the changes suggested by Lukas on IRC[1], I got it working.
> 
> I'm planning to release a version 0.0.1.Alpha today for testing if you
> guys agree.
> 
> [1] -
> https://github.com/abstractj/passport-keycloak/commit/0f0baa1fcce3f926ff75b3c1f5253022afe80619
> 
> On 2014-12-04, Bruno Oliveira wrote:
> > Good morning, I'm doing some progress with Keycloak and Passport.js[1].
> > Although I get "invalid redirect_uri" using HTTP or HTTPS, if the
> > callback url[2] is changed to something like "http://www.google.com"
> > everything works fine.
> >
> > I saw one issue related to Undertow[3], but I'm not sure if it's
> > truly related with what's happening here or me doing something wrong.
> >
> > I'll move forward investigating the issue, but if you have an idea or
> > suggestion, it will be more than welcome. To reproduce the issue, just
> > follow the readme instructions[4].
> >
> > [1] - https://github.com/abstractj/passport-keycloak/tree/goose
> > [2] -
> > https://github.com/abstractj/passport-keycloak/blob/goose/examples/app.js#L11
> > [3] - https://issues.jboss.org/browse/KEYCLOAK-568
> > [4] -
> > https://github.com/abstractj/passport-keycloak/blob/goose/README.md
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From ssilvert at redhat.com  Thu Dec  4 07:27:11 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 04 Dec 2014 07:27:11 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com> <547E3218.8080908@redhat.com>
	<547E48DE.4080101@redhat.com> <547E7BDB.3090907@redhat.com>
	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
	<547F190C.4010803@redhat.com> <547F4898.7070107@redhat.com>
	<547F634B.9060203@redhat.com>
	<345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>
Message-ID: <5480531F.2050504@redhat.com>

On 12/4/2014 2:54 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 3 December, 2014 8:23:55 PM
>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>
>>
>>
>> On 12/3/2014 12:30 PM, Stan Silvert wrote:
>>> 1) Bring back the old code for the AS7 subsystem.
>> Bring it back.  If you don't, let me know and I'll do it.
> Why? I don't get why we keep trying to get AS7 to work. We've already wasted a fair bit of time on this.
To me, it's not really a matter of getting it to work.  I've restored 
the old code and I just need to test everything out today. There is no 
reason to think it won't work as before.

The only question in my mind is whether or not anyone will want to use 
it.  I guess there is not that much incremental cost in maintaining the 
old code.  As I understand it, Bill's overriding strategy is to support 
every platform possible.

I've already changed course on this a couple of times, so I'd like to 
just finish and move on.
>
>>
>> --
>> 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  Thu Dec  4 07:32:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 4 Dec 2014 07:32:31 -0500 (EST)
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <5480531F.2050504@redhat.com>
References: <547C8466.4050103@redhat.com> <547E7BDB.3090907@redhat.com>
	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
	<547F190C.4010803@redhat.com> <547F4898.7070107@redhat.com>
	<547F634B.9060203@redhat.com>
	<345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>
	<5480531F.2050504@redhat.com>
Message-ID: <69116521.10463553.1417696351592.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 4 December, 2014 1:27:11 PM
> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> 
> On 12/4/2014 2:54 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 3 December, 2014 8:23:55 PM
> >> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> >>
> >>
> >>
> >> On 12/3/2014 12:30 PM, Stan Silvert wrote:
> >>> 1) Bring back the old code for the AS7 subsystem.
> >> Bring it back.  If you don't, let me know and I'll do it.
> > Why? I don't get why we keep trying to get AS7 to work. We've already
> > wasted a fair bit of time on this.
> To me, it's not really a matter of getting it to work.  I've restored
> the old code and I just need to test everything out today. There is no
> reason to think it won't work as before.
> 
> The only question in my mind is whether or not anyone will want to use
> it.  I guess there is not that much incremental cost in maintaining the
> old code.  As I understand it, Bill's overriding strategy is to support
> every platform possible.
> 
> I've already changed course on this a couple of times, so I'd like to
> just finish and move on.

Sure, I just want a reason to continue supporting AS7 though as it does come back to haunt us every once in a while. 

JPA issues, web-services issues, sub-system issues, etc.. By now we've probably spent a few days at least this year on an outdated platform.

> >
> >>
> >> --
> >> 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
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From ssilvert at redhat.com  Thu Dec  4 07:39:09 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 04 Dec 2014 07:39:09 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <69116521.10463553.1417696351592.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com> <547E7BDB.3090907@redhat.com>
	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>
	<547F190C.4010803@redhat.com> <547F4898.7070107@redhat.com>
	<547F634B.9060203@redhat.com>
	<345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>
	<5480531F.2050504@redhat.com>
	<69116521.10463553.1417696351592.JavaMail.zimbra@redhat.com>
Message-ID: <548055ED.40507@redhat.com>

On 12/4/2014 7:32 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 4 December, 2014 1:27:11 PM
>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>
>> On 12/4/2014 2:54 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 3 December, 2014 8:23:55 PM
>>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>>>
>>>>
>>>>
>>>> On 12/3/2014 12:30 PM, Stan Silvert wrote:
>>>>> 1) Bring back the old code for the AS7 subsystem.
>>>> Bring it back.  If you don't, let me know and I'll do it.
>>> Why? I don't get why we keep trying to get AS7 to work. We've already
>>> wasted a fair bit of time on this.
>> To me, it's not really a matter of getting it to work.  I've restored
>> the old code and I just need to test everything out today. There is no
>> reason to think it won't work as before.
>>
>> The only question in my mind is whether or not anyone will want to use
>> it.  I guess there is not that much incremental cost in maintaining the
>> old code.  As I understand it, Bill's overriding strategy is to support
>> every platform possible.
>>
>> I've already changed course on this a couple of times, so I'd like to
>> just finish and move on.
> Sure, I just want a reason to continue supporting AS7 though as it does come back to haunt us every once in a while.
>
> JPA issues, web-services issues, sub-system issues, etc.. By now we've probably spent a few days at least this year on an outdated platform.
Perhaps dropping auth server support will help with that?  What I'm 
doing now only affects AS7 client apps.
>
>>>> --
>>>> 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
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Thu Dec  4 07:48:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 4 Dec 2014 07:48:59 -0500 (EST)
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <548055ED.40507@redhat.com>
References: <547C8466.4050103@redhat.com> <547F190C.4010803@redhat.com>
	<547F4898.7070107@redhat.com> <547F634B.9060203@redhat.com>
	<345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>
	<5480531F.2050504@redhat.com>
	<69116521.10463553.1417696351592.JavaMail.zimbra@redhat.com>
	<548055ED.40507@redhat.com>
Message-ID: <380044053.10480863.1417697339942.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 4 December, 2014 1:39:09 PM
> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> 
> On 12/4/2014 7:32 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 4 December, 2014 1:27:11 PM
> >> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> >>
> >> On 12/4/2014 2:54 AM, Stian Thorgersen wrote:
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Wednesday, 3 December, 2014 8:23:55 PM
> >>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> >>>>
> >>>>
> >>>>
> >>>> On 12/3/2014 12:30 PM, Stan Silvert wrote:
> >>>>> 1) Bring back the old code for the AS7 subsystem.
> >>>> Bring it back.  If you don't, let me know and I'll do it.
> >>> Why? I don't get why we keep trying to get AS7 to work. We've already
> >>> wasted a fair bit of time on this.
> >> To me, it's not really a matter of getting it to work.  I've restored
> >> the old code and I just need to test everything out today. There is no
> >> reason to think it won't work as before.
> >>
> >> The only question in my mind is whether or not anyone will want to use
> >> it.  I guess there is not that much incremental cost in maintaining the
> >> old code.  As I understand it, Bill's overriding strategy is to support
> >> every platform possible.
> >>
> >> I've already changed course on this a couple of times, so I'd like to
> >> just finish and move on.
> > Sure, I just want a reason to continue supporting AS7 though as it does
> > come back to haunt us every once in a while.
> >
> > JPA issues, web-services issues, sub-system issues, etc.. By now we've
> > probably spent a few days at least this year on an outdated platform.
> Perhaps dropping auth server support will help with that?  What I'm
> doing now only affects AS7 client apps.

Yes, IMO we should definitively drop auth server support on AS7.

With regards to client support, IMO we should drop support for AS7 completely, but at very least the subsystem and just require including the adapter in the WAR like we do for Tomcat, Jetty, etc...

> >
> >>>> --
> >>>> 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
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From mposolda at redhat.com  Thu Dec  4 08:12:45 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 04 Dec 2014 14:12:45 +0100
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <380044053.10480863.1417697339942.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com>
	<547F190C.4010803@redhat.com>	<547F4898.7070107@redhat.com>
	<547F634B.9060203@redhat.com>	<345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>	<5480531F.2050504@redhat.com>	<69116521.10463553.1417696351592.JavaMail.zimbra@redhat.com>	<548055ED.40507@redhat.com>
	<380044053.10480863.1417697339942.JavaMail.zimbra@redhat.com>
Message-ID: <54805DCD.8030206@redhat.com>

On 4.12.2014 13:48, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 4 December, 2014 1:39:09 PM
>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>
>> On 12/4/2014 7:32 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 4 December, 2014 1:27:11 PM
>>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>>>
>>>> On 12/4/2014 2:54 AM, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Wednesday, 3 December, 2014 8:23:55 PM
>>>>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/3/2014 12:30 PM, Stan Silvert wrote:
>>>>>>> 1) Bring back the old code for the AS7 subsystem.
>>>>>> Bring it back.  If you don't, let me know and I'll do it.
>>>>> Why? I don't get why we keep trying to get AS7 to work. We've already
>>>>> wasted a fair bit of time on this.
>>>> To me, it's not really a matter of getting it to work.  I've restored
>>>> the old code and I just need to test everything out today. There is no
>>>> reason to think it won't work as before.
>>>>
>>>> The only question in my mind is whether or not anyone will want to use
>>>> it.  I guess there is not that much incremental cost in maintaining the
>>>> old code.  As I understand it, Bill's overriding strategy is to support
>>>> every platform possible.
>>>>
>>>> I've already changed course on this a couple of times, so I'd like to
>>>> just finish and move on.
>>> Sure, I just want a reason to continue supporting AS7 though as it does
>>> come back to haunt us every once in a while.
>>>
>>> JPA issues, web-services issues, sub-system issues, etc.. By now we've
>>> probably spent a few days at least this year on an outdated platform.
>> Perhaps dropping auth server support will help with that?  What I'm
>> doing now only affects AS7 client apps.
> Yes, IMO we should definitively drop auth server support on AS7.
>
> With regards to client support, IMO we should drop support for AS7 completely, but at very least the subsystem and just require including the adapter in the WAR like we do for Tomcat, Jetty, etc...
I wonder if we should provide something like download with "generic" 
auth-server.war, which will be able to run on all servers like AS7, 
Tomcat or Jetty. It seems to me that having auth-server running on 
Tomcat or Jetty won't be so much headache. It may just be about bundling 
all required deps like resteasy, jackson etc in 
auth-server.war/WEB-INF/lib/ .

Having auth-server available on Tomcat or Jetty might be useful as we 
have adapters for them already, so people won't need to use separate 
Tomcat/Jetty server with  their apps and separate Wildfly/EAP6 with 
auth-server, but they can have everything on single server. It may be 
also useful for Fuse integration (it's still unclear to me how deep 
should be fuse integration and if keycloak integration/adapters is 
enabled just on demand or by default, but having possibility to have 
auth-server deployed in fuse might be helpful with the decision as then 
fuse won't require separate KC server running on WF or EAP)

Hopefully we will be able to have same auth-server.war running on AS7/ 
JEtty and Tomcat with all dependencies inside and without 
jboss-deployment-structure.xml (we already have some needed changes in 
jboss-deployment-structure.xml for AS7 - 
http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/server-installation.html#as7-specifics 
. So having separate WAR without jboss-deployment-structure.xml may help 
to avoid this and have AS7 integration even simpler)

Marek
>
>>>>>> --
>>>>>> 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
>>>> _______________________________________________
>>>> 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  Thu Dec  4 08:24:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 4 Dec 2014 08:24:06 -0500 (EST)
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <54805DCD.8030206@redhat.com>
References: <547C8466.4050103@redhat.com> <547F634B.9060203@redhat.com>
	<345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>
	<5480531F.2050504@redhat.com>
	<69116521.10463553.1417696351592.JavaMail.zimbra@redhat.com>
	<548055ED.40507@redhat.com>
	<380044053.10480863.1417697339942.JavaMail.zimbra@redhat.com>
	<54805DCD.8030206@redhat.com>
Message-ID: <266466549.10508338.1417699446095.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Stan Silvert" <ssilvert at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 4 December, 2014 2:12:45 PM
> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> 
> On 4.12.2014 13:48, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 4 December, 2014 1:39:09 PM
> >> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> >>
> >> On 12/4/2014 7:32 AM, Stian Thorgersen wrote:
> >>> ----- Original Message -----
> >>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 4 December, 2014 1:27:11 PM
> >>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
> >>>>
> >>>> On 12/4/2014 2:54 AM, Stian Thorgersen wrote:
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Wednesday, 3 December, 2014 8:23:55 PM
> >>>>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?
> >>>>>> Stan?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 12/3/2014 12:30 PM, Stan Silvert wrote:
> >>>>>>> 1) Bring back the old code for the AS7 subsystem.
> >>>>>> Bring it back.  If you don't, let me know and I'll do it.
> >>>>> Why? I don't get why we keep trying to get AS7 to work. We've already
> >>>>> wasted a fair bit of time on this.
> >>>> To me, it's not really a matter of getting it to work.  I've restored
> >>>> the old code and I just need to test everything out today. There is no
> >>>> reason to think it won't work as before.
> >>>>
> >>>> The only question in my mind is whether or not anyone will want to use
> >>>> it.  I guess there is not that much incremental cost in maintaining the
> >>>> old code.  As I understand it, Bill's overriding strategy is to support
> >>>> every platform possible.
> >>>>
> >>>> I've already changed course on this a couple of times, so I'd like to
> >>>> just finish and move on.
> >>> Sure, I just want a reason to continue supporting AS7 though as it does
> >>> come back to haunt us every once in a while.
> >>>
> >>> JPA issues, web-services issues, sub-system issues, etc.. By now we've
> >>> probably spent a few days at least this year on an outdated platform.
> >> Perhaps dropping auth server support will help with that?  What I'm
> >> doing now only affects AS7 client apps.
> > Yes, IMO we should definitively drop auth server support on AS7.
> >
> > With regards to client support, IMO we should drop support for AS7
> > completely, but at very least the subsystem and just require including the
> > adapter in the WAR like we do for Tomcat, Jetty, etc...
> I wonder if we should provide something like download with "generic"
> auth-server.war, which will be able to run on all servers like AS7,
> Tomcat or Jetty. It seems to me that having auth-server running on
> Tomcat or Jetty won't be so much headache. It may just be about bundling
> all required deps like resteasy, jackson etc in
> auth-server.war/WEB-INF/lib/ .
> 
> Having auth-server available on Tomcat or Jetty might be useful as we
> have adapters for them already, so people won't need to use separate
> Tomcat/Jetty server with  their apps and separate Wildfly/EAP6 with
> auth-server, but they can have everything on single server. It may be
> also useful for Fuse integration (it's still unclear to me how deep
> should be fuse integration and if keycloak integration/adapters is
> enabled just on demand or by default, but having possibility to have
> auth-server deployed in fuse might be helpful with the decision as then
> fuse won't require separate KC server running on WF or EAP)
> 
> Hopefully we will be able to have same auth-server.war running on AS7/
> JEtty and Tomcat with all dependencies inside and without
> jboss-deployment-structure.xml (we already have some needed changes in
> jboss-deployment-structure.xml for AS7 -
> http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/server-installation.html#as7-specifics
> . So having separate WAR without jboss-deployment-structure.xml may help
> to avoid this and have AS7 integration even simpler)

Tomcat and Jetty are actually much simpler, just chuck all deps into WEB-INF/lib and away you go. Problem with AS7 is that it adds all sorts of conflicting dependencies automatically and it doesn't have an easy way to exclude them as exclude-subsystem in jboss-deployment-structure.xml isn't available on AS7, which results in finding workarounds for all sorts of problems.

> 
> Marek
> >
> >>>>>> --
> >>>>>> 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
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From bburke at redhat.com  Thu Dec  4 08:50:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Dec 2014 08:50:12 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <5480531F.2050504@redhat.com>
References: <547C8466.4050103@redhat.com>
	<547E3218.8080908@redhat.com>	<547E48DE.4080101@redhat.com>
	<547E7BDB.3090907@redhat.com>	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>	<547F190C.4010803@redhat.com>
	<547F4898.7070107@redhat.com>	<547F634B.9060203@redhat.com>	<345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>
	<5480531F.2050504@redhat.com>
Message-ID: <54806694.4040006@redhat.com>



On 12/4/2014 7:27 AM, Stan Silvert wrote:
> On 12/4/2014 2:54 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 3 December, 2014 8:23:55 PM
>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>>
>>>
>>>
>>> On 12/3/2014 12:30 PM, Stan Silvert wrote:
>>>> 1) Bring back the old code for the AS7 subsystem.
>>> Bring it back.  If you don't, let me know and I'll do it.
>> Why? I don't get why we keep trying to get AS7 to work. We've already wasted a fair bit of time on this.
> To me, it's not really a matter of getting it to work.  I've restored
> the old code and I just need to test everything out today. There is no
> reason to think it won't work as before.
>
> The only question in my mind is whether or not anyone will want to use
> it.  I guess there is not that much incremental cost in maintaining the
> old code.  As I understand it, Bill's overriding strategy is to support
> every platform possible.
>
> I've already changed course on this a couple of times, so I'd like to
> just finish and move on.

Why is this a waste of time?  Just go back to the last tag, grab that 
code and bring it back, create a new AS7 distro for it in distribution/. 
  Would take me like 30 minutes max.

Once we have adapters as separate downloads then we see who is using 
what platform.  BTW, we'll eventually have to see if we can create 
adapters for EAP4 and EAP5.  There's still customers on that too.

Also, I abstracted the adapter tests a little and ported them to work 
with Tomcat 6-8, Jetty 8-9.  If I knew Arquillian, I'd create AS7 tests 
too.  Sucks we can't distribute EAP, otherwise I'd do EAP too.

Bill

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

From bburke at redhat.com  Thu Dec  4 08:56:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Dec 2014 08:56:11 -0500
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <20141204104226.GA30278@abstractj.org>
References: <20141204090925.GA27060@abstractj.org>
	<20141204104226.GA30278@abstractj.org>
Message-ID: <548067FB.7030500@redhat.com>

I'd like to distribute this in the next release and document it.  Will 
the appropriate Node.js distribution methods be available for this? 
(Bower?)  Change the version to 1.1.Beta2 :)

Another things to think about is to get on the Node.js lists and let 
them know about this.

On 12/4/2014 5:42 AM, Bruno Oliveira wrote:
> Ahoy, after apply the changes suggested by Lukas on IRC[1], I got it working.
>
> I'm planning to release a version 0.0.1.Alpha today for testing if you
> guys agree.
>
> [1] -
> https://github.com/abstractj/passport-keycloak/commit/0f0baa1fcce3f926ff75b3c1f5253022afe80619
>
> On 2014-12-04, Bruno Oliveira wrote:
>> Good morning, I'm doing some progress with Keycloak and Passport.js[1].
>> Although I get "invalid redirect_uri" using HTTP or HTTPS, if the
>> callback url[2] is changed to something like "http://www.google.com"
>> everything works fine.
>>
>> I saw one issue related to Undertow[3], but I'm not sure if it's
>> truly related with what's happening here or me doing something wrong.
>>
>> I'll move forward investigating the issue, but if you have an idea or
>> suggestion, it will be more than welcome. To reproduce the issue, just
>> follow the readme instructions[4].
>>
>> [1] - https://github.com/abstractj/passport-keycloak/tree/goose
>> [2] -
>> https://github.com/abstractj/passport-keycloak/blob/goose/examples/app.js#L11
>> [3] - https://issues.jboss.org/browse/KEYCLOAK-568
>> [4] -
>> https://github.com/abstractj/passport-keycloak/blob/goose/README.md
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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 Dec  4 08:57:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Dec 2014 08:57:14 -0500
Subject: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
In-Reply-To: <69116521.10463553.1417696351592.JavaMail.zimbra@redhat.com>
References: <547C8466.4050103@redhat.com>
	<547E7BDB.3090907@redhat.com>	<375969615.9348235.1417592598752.JavaMail.zimbra@redhat.com>	<547F190C.4010803@redhat.com>
	<547F4898.7070107@redhat.com>	<547F634B.9060203@redhat.com>	<345333082.10178260.1417679685759.JavaMail.zimbra@redhat.com>	<5480531F.2050504@redhat.com>
	<69116521.10463553.1417696351592.JavaMail.zimbra@redhat.com>
Message-ID: <5480683A.3050602@redhat.com>



On 12/4/2014 7:32 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 4 December, 2014 1:27:11 PM
>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>
>> On 12/4/2014 2:54 AM, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 3 December, 2014 8:23:55 PM
>>>> Subject: Re: [keycloak-dev] AS7 subsystem problems Re:  release?  Stan?
>>>>
>>>>
>>>>
>>>> On 12/3/2014 12:30 PM, Stan Silvert wrote:
>>>>> 1) Bring back the old code for the AS7 subsystem.
>>>> Bring it back.  If you don't, let me know and I'll do it.
>>> Why? I don't get why we keep trying to get AS7 to work. We've already
>>> wasted a fair bit of time on this.
>> To me, it's not really a matter of getting it to work.  I've restored
>> the old code and I just need to test everything out today. There is no
>> reason to think it won't work as before.
>>
>> The only question in my mind is whether or not anyone will want to use
>> it.  I guess there is not that much incremental cost in maintaining the
>> old code.  As I understand it, Bill's overriding strategy is to support
>> every platform possible.
>>
>> I've already changed course on this a couple of times, so I'd like to
>> just finish and move on.
>
> Sure, I just want a reason to continue supporting AS7 though as it does come back to haunt us every once in a while.
>
> JPA issues, web-services issues, sub-system issues, etc.. By now we've probably spent a few days at least this year on an outdated platform.
>

I don't care about supporting keycloak server on AS7, just the adapter.

Bill

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

From bruno at abstractj.org  Thu Dec  4 09:08:10 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 4 Dec 2014 12:08:10 -0200
Subject: [keycloak-dev] passport-keycloak 0.0.1 released!
Message-ID: <20141204140810.GA38595@abstractj.org>

The first version of the Passport adapter was released
https://www.npmjs.org/package/passport-keycloak.

Let me know if you find something wrong.

--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Thu Dec  4 09:19:44 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 4 Dec 2014 12:19:44 -0200
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <548067FB.7030500@redhat.com>
References: <20141204090925.GA27060@abstractj.org>
	<20141204104226.GA30278@abstractj.org>
	<548067FB.7030500@redhat.com>
Message-ID: <20141204141944.GA38630@abstractj.org>

On 2014-12-04, Bill Burke wrote:
> I'd like to distribute this in the next release and document it.  Will
> the appropriate Node.js distribution methods be available for this?
> (Bower?)

Hi Bill, it's distributed under npm here
https://www.npmjs.org/package/passport-keycloak

> Change the version to 1.1.Beta2 :)

I'm not so sure about the versioning, it's a big bump for the first
release. But I'm fine if you guys think the opposite.

Let me know what works best for the project.

>
> Another things to think about is to get on the Node.js lists and let
> them know about this.
>
> On 12/4/2014 5:42 AM, Bruno Oliveira wrote:
> > Ahoy, after apply the changes suggested by Lukas on IRC[1], I got it working.
> >
> > I'm planning to release a version 0.0.1.Alpha today for testing if you
> > guys agree.
> >
> > [1] -
> > https://github.com/abstractj/passport-keycloak/commit/0f0baa1fcce3f926ff75b3c1f5253022afe80619
> >
> > On 2014-12-04, Bruno Oliveira wrote:
> >> Good morning, I'm doing some progress with Keycloak and Passport.js[1].
> >> Although I get "invalid redirect_uri" using HTTP or HTTPS, if the
> >> callback url[2] is changed to something like "http://www.google.com"
> >> everything works fine.
> >>
> >> I saw one issue related to Undertow[3], but I'm not sure if it's
> >> truly related with what's happening here or me doing something wrong.
> >>
> >> I'll move forward investigating the issue, but if you have an idea or
> >> suggestion, it will be more than welcome. To reproduce the issue, just
> >> follow the readme instructions[4].
> >>
> >> [1] - https://github.com/abstractj/passport-keycloak/tree/goose
> >> [2] -
> >> https://github.com/abstractj/passport-keycloak/blob/goose/examples/app.js#L11
> >> [3] - https://issues.jboss.org/browse/KEYCLOAK-568
> >> [4] -
> >> https://github.com/abstractj/passport-keycloak/blob/goose/README.md
> >>
> >> --
> >>
> >> abstractj
> >> PGP: 0x84DC9914
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Thu Dec  4 09:37:30 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 4 Dec 2014 12:37:30 -0200
Subject: [keycloak-dev] passport-keycloak 0.0.1 released!
In-Reply-To: <20141204140810.GA38595@abstractj.org>
References: <20141204140810.GA38595@abstractj.org>
Message-ID: <20141204143730.GA38701@abstractj.org>

Damn, I forgot to mention. If you guys think it's doable, I would like
to migrate the code to keycloak organization.

After that, if you agree, we can publish Keycloak at Passport's
providers list http://passportjs.org/guide/providers/.

On 2014-12-04, Bruno Oliveira wrote:
> The first version of the Passport adapter was released
> https://www.npmjs.org/package/passport-keycloak.
>
> Let me know if you find something wrong.
>
> --
>
> abstractj
> PGP: 0x84DC9914

--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Thu Dec  4 09:56:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Dec 2014 09:56:04 -0500
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <20141204141944.GA38630@abstractj.org>
References: <20141204090925.GA27060@abstractj.org>
	<20141204104226.GA30278@abstractj.org>
	<548067FB.7030500@redhat.com>
	<20141204141944.GA38630@abstractj.org>
Message-ID: <54807604.2020409@redhat.com>



On 12/4/2014 9:19 AM, Bruno Oliveira wrote:
> On 2014-12-04, Bill Burke wrote:
>> I'd like to distribute this in the next release and document it.  Will
>> the appropriate Node.js distribution methods be available for this?
>> (Bower?)
>
> Hi Bill, it's distributed under npm here
> https://www.npmjs.org/package/passport-keycloak
>
>> Change the version to 1.1.Beta2 :)
>
> I'm not so sure about the versioning, it's a big bump for the first
> release. But I'm fine if you guys think the opposite.
>

Doesn't matter.  Have it same version as Keycloak.  It will be easier to 
keep track of compatibilities for both us and users.  BTW, our Tomcat 
and Jetty are new, we didn't version it 0.0.alph1. :)

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

From bburke at redhat.com  Thu Dec  4 09:58:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Dec 2014 09:58:48 -0500
Subject: [keycloak-dev] passport-keycloak 0.0.1 released!
In-Reply-To: <20141204140810.GA38595@abstractj.org>
References: <20141204140810.GA38595@abstractj.org>
Message-ID: <548076A8.3080006@redhat.com>

Questions:

* role mapping checks?
* Bearer auth work?
* Browser login work? (auth-code browser redirect flow).
* Integrates with Node.js http sessions?

Thanks,

Bill

On 12/4/2014 9:08 AM, Bruno Oliveira wrote:
> The first version of the Passport adapter was released
> https://www.npmjs.org/package/passport-keycloak.
>
> Let me know if you find something wrong.
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bruno at abstractj.org  Thu Dec  4 10:04:14 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 4 Dec 2014 13:04:14 -0200
Subject: [keycloak-dev] passport-keycloak 0.0.1 released!
In-Reply-To: <548076A8.3080006@redhat.com>
References: <20141204140810.GA38595@abstractj.org>
	<548076A8.3080006@redhat.com>
Message-ID: <20141204150414.GA38989@abstractj.org>

On 2014-12-04, Bill Burke wrote:
> Questions:
>
> * role mapping checks?
> * Bearer auth work?

Both, not supported yet. Also, currently credential type is supported.

> * Browser login work? (auth-code browser redirect flow).

Yes. See the example when you get the chance.

> * Integrates with Node.js http sessions?

The next on the list.

>
> Thanks,
>
> Bill
>
> On 12/4/2014 9:08 AM, Bruno Oliveira wrote:
> > The first version of the Passport adapter was released
> > https://www.npmjs.org/package/passport-keycloak.
> >
> > Let me know if you find something wrong.
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914

From lholmqui at redhat.com  Thu Dec  4 10:04:41 2014
From: lholmqui at redhat.com (Lucas Holmquist)
Date: Thu, 4 Dec 2014 10:04:41 -0500
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <54807604.2020409@redhat.com>
References: <20141204090925.GA27060@abstractj.org>
	<20141204104226.GA30278@abstractj.org>
	<548067FB.7030500@redhat.com>
	<20141204141944.GA38630@abstractj.org>
	<54807604.2020409@redhat.com>
Message-ID: <ED9D071C-4FDE-4EAA-BE1A-7B1B7E400C9B@redhat.com>


> On Dec 4, 2014, at 9:56 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> 
> 
> On 12/4/2014 9:19 AM, Bruno Oliveira wrote:
>> On 2014-12-04, Bill Burke wrote:
>>> I'd like to distribute this in the next release and document it.  Will
>>> the appropriate Node.js distribution methods be available for this?
>>> (Bower?)
>> 
>> Hi Bill, it's distributed under npm here
>> https://www.npmjs.org/package/passport-keycloak
>> 
>>> Change the version to 1.1.Beta2 :)
>> 
>> I'm not so sure about the versioning, it's a big bump for the first
>> release. But I'm fine if you guys think the opposite.
>> 
> 
> Doesn't matter.  Have it same version as Keycloak.  It will be easier to 
> keep track of compatibilities for both us and users.  BTW, our Tomcat 
> and Jetty are new, we didn't version it 0.0.alph1. :)

i sort of disagree here.  This is just an adapter really, and should be on it?s own versioning independent of what the main key cloak distribution is.



> 
> -- 
> 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 Dec  4 10:48:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Dec 2014 10:48:05 -0500
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <ED9D071C-4FDE-4EAA-BE1A-7B1B7E400C9B@redhat.com>
References: <20141204090925.GA27060@abstractj.org>
	<20141204104226.GA30278@abstractj.org>
	<548067FB.7030500@redhat.com>
	<20141204141944.GA38630@abstractj.org>
	<54807604.2020409@redhat.com>
	<ED9D071C-4FDE-4EAA-BE1A-7B1B7E400C9B@redhat.com>
Message-ID: <54808235.5040504@redhat.com>



On 12/4/2014 10:04 AM, Lucas Holmquist wrote:
>
>> On Dec 4, 2014, at 9:56 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>>
>>
>> On 12/4/2014 9:19 AM, Bruno Oliveira wrote:
>>> On 2014-12-04, Bill Burke wrote:
>>>> I'd like to distribute this in the next release and document it.  Will
>>>> the appropriate Node.js distribution methods be available for this?
>>>> (Bower?)
>>>
>>> Hi Bill, it's distributed under npm here
>>> https://www.npmjs.org/package/passport-keycloak
>>>
>>>> Change the version to 1.1.Beta2 :)
>>>
>>> I'm not so sure about the versioning, it's a big bump for the first
>>> release. But I'm fine if you guys think the opposite.
>>>
>>
>> Doesn't matter.  Have it same version as Keycloak.  It will be easier to
>> keep track of compatibilities for both us and users.  BTW, our Tomcat
>> and Jetty are new, we didn't version it 0.0.alph1. :)
>
> i sort of disagree here.  This is just an adapter really, and should be on it?s own versioning independent of what the main key cloak distribution is.
>

In my experience different versions just confuses people.  It starts to 
become important when you have multiple major versions out in the wild 
and there are incompatibilities between them.


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

From bruno at abstractj.org  Thu Dec  4 11:01:41 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 4 Dec 2014 14:01:41 -0200
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <54808235.5040504@redhat.com>
References: <20141204090925.GA27060@abstractj.org>
	<20141204104226.GA30278@abstractj.org>
	<548067FB.7030500@redhat.com>
	<20141204141944.GA38630@abstractj.org>
	<54807604.2020409@redhat.com>
	<ED9D071C-4FDE-4EAA-BE1A-7B1B7E400C9B@redhat.com>
	<54808235.5040504@redhat.com>
Message-ID: <20141204160141.GB38989@abstractj.org>

On 2014-12-04, Bill Burke wrote:
>
>
> On 12/4/2014 10:04 AM, Lucas Holmquist wrote:
> >
> >>On Dec 4, 2014, at 9:56 AM, Bill Burke <bburke at redhat.com> wrote:
> >>
> >>
> >>
> >>On 12/4/2014 9:19 AM, Bruno Oliveira wrote:
> >>>On 2014-12-04, Bill Burke wrote:
> >>>>I'd like to distribute this in the next release and document it.  Will
> >>>>the appropriate Node.js distribution methods be available for this?
> >>>>(Bower?)
> >>>
> >>>Hi Bill, it's distributed under npm here
> >>>https://www.npmjs.org/package/passport-keycloak
> >>>
> >>>>Change the version to 1.1.Beta2 :)
> >>>
> >>>I'm not so sure about the versioning, it's a big bump for the first
> >>>release. But I'm fine if you guys think the opposite.
> >>>
> >>
> >>Doesn't matter.  Have it same version as Keycloak.  It will be easier to
> >>keep track of compatibilities for both us and users.  BTW, our Tomcat
> >>and Jetty are new, we didn't version it 0.0.alph1. :)
> >
> >i sort of disagree here.  This is just an adapter really, and should be on it?s own versioning independent of what the main key cloak distribution is.
> >
>
> In my experience different versions just confuses people.  It starts to
> become important when you have multiple major versions out in the wild and
> there are incompatibilities between them.

Bill, my major concern about having the same versioning. Is people
mistakenly assuming that this adapter is full compatible with all the features on
Keycloak, which is not true at the moment. More work is required, like
you asked for role mappings, bearer tokens and etc.

Does it make sense to you?

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

--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Thu Dec  4 12:53:53 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 4 Dec 2014 15:53:53 -0200
Subject: [keycloak-dev] passport-keycloak 0.0.1 released!
In-Reply-To: <548076A8.3080006@redhat.com>
References: <20141204140810.GA38595@abstractj.org>
	<548076A8.3080006@redhat.com>
Message-ID: <20141204175353.GA41150@abstractj.org>

I created some sub-tasks to track the progress here:
https://issues.jboss.org/browse/KEYCLOAK-864


On 2014-12-04, Bill Burke wrote:
> Questions:
>
> * role mapping checks?
> * Bearer auth work?
> * Browser login work? (auth-code browser redirect flow).
> * Integrates with Node.js http sessions?
>
> Thanks,
>
> Bill
>
> On 12/4/2014 9:08 AM, Bruno Oliveira wrote:
> > The first version of the Passport adapter was released
> > https://www.npmjs.org/package/passport-keycloak.
> >
> > Let me know if you find something wrong.
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914

From ssilvert at redhat.com  Thu Dec  4 15:01:49 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 04 Dec 2014 15:01:49 -0500
Subject: [keycloak-dev] AS7 subsystem restored
Message-ID: <5480BDAD.7010800@redhat.com>

I've updated the docs and done smoke tests on WildFly, EAP6, and AS7.  
Here is the PR:

https://github.com/keycloak/keycloak/pull/880

From bburke at redhat.com  Thu Dec  4 19:25:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Dec 2014 19:25:10 -0500
Subject: [keycloak-dev] AS7 subsystem restored
In-Reply-To: <5480BDAD.7010800@redhat.com>
References: <5480BDAD.7010800@redhat.com>
Message-ID: <5480FB66.6000109@redhat.com>

Thank you stan.

On 12/4/2014 3:01 PM, Stan Silvert wrote:
> I've updated the docs and done smoke tests on WildFly, EAP6, and AS7.
> Here is the PR:
>
> https://github.com/keycloak/keycloak/pull/880
> _______________________________________________
> 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 psilva at redhat.com  Thu Dec  4 20:29:37 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 4 Dec 2014 20:29:37 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<732604538.8590377.1417520085671.JavaMail.zimbra@redhat.com>
	<917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>
	<247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>
	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
Message-ID: <839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>

Hi,

   Social has a button to enable/disable it. I'm wondering what to do with the brokered identity providers. Shall we add a similar flag for that ?

   I was also wondering if the best would be a flag in a per provider basis. So we can disable/enable a specific provider (social or brokered), instead of doing that for all.

Regards.
Pedro Igor

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Stian Thorgersen" <stian at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Tuesday, December 2, 2014 10:42:11 AM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, December 2, 2014 10:23:24 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > I'll go for it then. Will remove the icon url from the model and leave that
> > for users if they want to provide icons for their identity providers.
> > 
> > My point is that icons can be usually served by the same server/application
> > or proxy, so download images are not such a big deal. Also, the icon url is
> > part of the freemarker model and people can do what ever they want with it.
> > What I think will also help in your future plans.
> 
> I'm not following. Are you saying that if a named image 'my-provider.png' is
> loaded from a theme, then you can override it in another theme?
> 
> If so, that's basically the same as having a css class 'my-provider' in a
> theme. With the exception that with an image you end up with having to
> require a image per provider per theme per language, which could be a lot of
> images for a single provider. Also, buttons for accessibility should be
> defined with text and css, not images that can't be interpreted. You also
> still need to modify the theme, so I don't see any benefits.

You are right. Having a icon url per provider does not makes sense if there are requirements to change images accordingly to a theme or language. CSS makes life easier.

Will remove that property from the model.

> 
> > 
> > ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Users can now specify a Icon Url to be rendered on the login page when
> > > social
> > > or any other identity provider is configured. So we just load the image
> > > the
> > > url entered by the user.
> > > 
> > > Are you saying that users should change the theme or customize css if
> > > they
> > > only want to change an icon for a provider ?
> > 
> > Yes, there's many issues with having a icon url:
> > 
> > * Won't work for internationalization - we don't have this now, but we will
> > * Image is not a good button - CSS is much better
> > * Doesn't support themes - we allow users to switch l&f by switching
> > themes,
> > but that won't work for a icon url. In the future we may also support
> > multiple themes per-realm, for example to depending on the devices (one
> > theme for mobiles, one for desktops, etc)
> > * Requires the URL to be hosted somewhere - why require a separate call to
> > download an image (to a separate server maybe) if it can simply be defined
> > in a single CSS file?
> > 
> > Rather than add additional places to define look and feel components we
> > should in the future make it easier to add/customize themes.
> > 
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > All look and feel related things including images and stylesheets should
> > > be
> > > part of themes. This is to allow customizing them in the theme. Also, an
> > > image is not the correct way to render a button, it should be defined in
> > > CSS.
> > > 
> > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > You shouldn't have icon images for social providers. They should be
> > > > specified
> > > > as part of the theme in CSS as is now.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Hi,
> > > > > 
> > > > >     Anyone know where I can get the icons images for social providers
> > > > >     ?
> > > > >     It
> > > > >     seems zocial defines them encoded in some way in CSS. I need that
> > > > >     to
> > > > >     provide default images if user does not specify their own.
> > > > > 
> > > > >     Or is still possible to use zocial ones ?
> > > > > 
> > > > > Regards.
> > > > > 
> > > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Hi guys,
> > > > > 
> > > > >    I've done some initial work covering both persistence and
> > > > >    brokering.
> > > > >    No
> > > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > > >    functionality
> > > > >    for now.
> > > > > 
> > > > >    What I have is enough to decide if we are aligned about this
> > > > >    functionality. So you can understand how the model (and
> > > > >    persistence),
> > > > >    rest api and brokering functionality looks like. Can we schedule a
> > > > >    meeting ?
> > > > > 
> > > > >    Btw, my branch is here [1].
> > > > > 
> > > > > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > 
> > > > > Regards.
> > > > > Pedro Igor
> > > > > 
> > > > > ----- Original Message -----
> > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > To: keycloak-dev at lists.jboss.org
> > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Currently adapters can only make authz decisions (@RolesAllowed)
> > > > > based
> > > > > on either realm roles or the roles of one specific application.  This
> > > > > is
> > > > > related to 1) too.
> > > > > 
> > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > >
> > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > >> I just wanted to quickly list the additional work we discussed so
> > > > > >> everyone
> > > > > >> can think about it (in no particular order):
> > > > > >>
> > > > > >> 1) Mapping of tokens - how do we deal with mapping of an external
> > > > > >> token
> > > > > >> to
> > > > > >> a KC token? For example an external token with attribute 'group'
> > > > > >> that
> > > > > >> contains 'sales' and 'manager' could be mapped to 'manager' role
> > > > > >> for
> > > > > >> 'sales app in a KC token. Could we use Drools? This could also be
> > > > > >> used
> > > > > >> in
> > > > > >> user federation to allow more complex mapping of roles/groups than
> > > > > >> a
> > > > > >> simple 1-1
> > > > > >> 2) Retrieving tokens - if an application wants to retrieve the
> > > > > >> external
> > > > > >> token (for example to view Facebook friends if user logged in with
> > > > > >> Facebook)
> > > > > >> 3) Configure scope - currently for social we only request a very
> > > > > >> limited
> > > > > >> scope (basic profile and email), to for example view Facebook
> > > > > >> friends
> > > > > >> we'd need to ask for that as well
> > > > > >> 4) Selecting provider - currently in social (and for first pass of
> > > > > >> brokering) we have an icon user has to select, but can we select
> > > > > >> the
> > > > > >> provider in a different way (for example ask user for email, and
> > > > > >> select
> > > > > >> based on email domain)
> > > > > >> 5) Gateway - don't create a KC token, but just forward the
> > > > > >> external
> > > > > >> token
> > > > > >>
> > > > > >> IMO 1) is a killer feature, as it would allow companies to add
> > > > > >> external
> > > > > >> users without having to modify their applications. Issue with 5)
> > > > > >> is
> > > > > >> that
> > > > > >> applications need to understand more than one token, which would
> > > > > >> require
> > > > > >> rewriting applications.
> > > > > >>
> > > > > >> This work is also somewhat related to other authentication
> > > > > >> mechanisms
> > > > > >> (for
> > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > >>> Broker
> > > > > >>>
> > > > > >>> ----- Original Message -----
> > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > >>>> Authentication
> > > > > >>>> Broker
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > >>>>> Hi,
> > > > > >>>>>
> > > > > >>>>>        Would like to start a discussion about how to enable KC
> > > > > >>>>>        as
> > > > > >>>>>        an
> > > > > >>>>>        Authentication Broker in order to supported Chained
> > > > > >>>>>        Federation
> > > > > >>>>>        and
> > > > > >>>>>        also Identity Federation. First of all, some background
> > > > > >>>>>        about
> > > > > >>>>>        what
> > > > > >>>>>        this is all about.
> > > > > >>>>>
> > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > >>>>>        authentication
> > > > > >>>>>        (correct
> > > > > >>>>>        me if I'm wrong, please):
> > > > > >>>>>
> > > > > >>>>>            1) Local authentication (based on some credential
> > > > > >>>>>            type
> > > > > >>>>>            enabled
> > > > > >>>>>            to
> > > > > >>>>>            a realm)
> > > > > >>>>>            2) Social authentication
> > > > > >>>>>
> > > > > >>>>>        Local authentication is about authenticating the user
> > > > > >>>>>        locally
> > > > > >>>>>        using
> > > > > >>>>>        KC's own identity store. Nothing special here. And
> > > > > >>>>>        Social
> > > > > >>>>>        Authentication which allows users to choose the Social
> > > > > >>>>>        IdP
> > > > > >>>>>        they
> > > > > >>>>>        want
> > > > > >>>>>        to authenticate with. In this case, the IdP is always
> > > > > >>>>>        one
> > > > > >>>>>        of
> > > > > >>>>>        the
> > > > > >>>>>        built-in social providers supported by KC such as
> > > > > >>>>>        Facebook,
> > > > > >>>>>        Google,
> > > > > >>>>>        Twitter, Github and so forth.
> > > > > >>>>>
> > > > > >>>>>        When doing social, the user is automatically provisioned
> > > > > >>>>>        in
> > > > > >>>>>        KC
> > > > > >>>>>        identity store after a successful authentication. The
> > > > > >>>>>        user
> > > > > >>>>>        does
> > > > > >>>>>        not
> > > > > >>>>>        need to fill a registration form and can access the
> > > > > >>>>>        application
> > > > > >>>>>        very
> > > > > >>>>>        quickly. During the provisioning some basic information
> > > > > >>>>>        is
> > > > > >>>>>        retrieved
> > > > > >>>>>        from the social provider such as email, firstname and so
> > > > > >>>>>        forth.
> > > > > >>>>>        These
> > > > > >>>>>        are very basic information, any other information such
> > > > > >>>>>        as
> > > > > >>>>>        those
> > > > > >>>>>        related with authorization policies - eg.: roles and
> > > > > >>>>>        groups
> > > > > >>>>>        -
> > > > > >>>>>        must
> > > > > >>>>>        be
> > > > > >>>>>        defined later via KC's admin console.
> > > > > >>>>>
> > > > > >>>>>        Another important characteristic of social
> > > > > >>>>>        authentication
> > > > > >>>>>        is
> > > > > >>>>>        that
> > > > > >>>>>        the
> > > > > >>>>>        application receives a KC token and not the token that
> > > > > >>>>>        was
> > > > > >>>>>        issued by
> > > > > >>>>>        the social IdP during the authentication process. If the
> > > > > >>>>>        application
> > > > > >>>>>        wants to consume resources from the resource provider he
> > > > > >>>>>        was
> > > > > >>>>>        authenticated it must obtain the access token(again) by
> > > > > >>>>>        itself
> > > > > >>>>>        prior
> > > > > >>>>>        to invoke the resource provider API. Assuming all those
> > > > > >>>>>        social
> > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > >>>>>
> > > > > >>>>>        That said, the Authentication Broker functionality aims
> > > > > >>>>>        to
> > > > > >>>>>        cover
> > > > > >>>>>        the
> > > > > >>>>>        same use cases but with a lot of more flexibility on how
> > > > > >>>>>        you
> > > > > >>>>>        setup
> > > > > >>>>>        identity providers(not only social ones) and the
> > > > > >>>>>        different
> > > > > >>>>>        federation
> > > > > >>>>>        protocols they may support such as SAML, OpenID, oAuth
> > > > > >>>>>        and
> > > > > >>>>>        so
> > > > > >>>>>        forth.
> > > > > >>>>>        This is useful when an enterprise is providing services
> > > > > >>>>>        to
> > > > > >>>>>        different
> > > > > >>>>>        customers(IdP) and does not want to manage many to many
> > > > > >>>>>        relationships. When using a broker, the authentication
> > > > > >>>>>        steps
> > > > > >>>>>        are
> > > > > >>>>>        pretty much the same when you are using social
> > > > > >>>>>        authentication,
> > > > > >>>>>        with
> > > > > >>>>>        important differences on how you support different
> > > > > >>>>>        identity
> > > > > >>>>>        providers, different federation protocols, how users are
> > > > > >>>>>        provisioned
> > > > > >>>>>        and how claims and attributes are resolved.
> > > > > >>>>>
> > > > > >>>>>        The brokering functionality can be done in two ways
> > > > > >>>>>        depending
> > > > > >>>>>        if
> > > > > >>>>>        the
> > > > > >>>>>        broker service is acting as a gateway or not. When
> > > > > >>>>>        acting
> > > > > >>>>>        as
> > > > > >>>>>        a
> > > > > >>>>>        gateway, the broker will respond to the application the
> > > > > >>>>>        same
> > > > > >>>>>        token
> > > > > >>>>>        issued by the trusted identity provider. For instance,
> > > > > >>>>>        if
> > > > > >>>>>        the
> > > > > >>>>>        user
> > > > > >>>>>        selects a SAML IdP to authenticate with, the application
> > > > > >>>>>        will
> > > > > >>>>>        receive
> > > > > >>>>>        a SAML Response. In this case, the application must also
> > > > > >>>>>        be
> > > > > >>>>>        prepared
> > > > > >>>>>        to handle a specific federation protocol.
> > > > > >>>>>
> > > > > >>>>>        However, the broker service can also be used to
> > > > > >>>>>        completely
> > > > > >>>>>        abstract
> > > > > >>>>>        from the application the protocol used to authenticate
> > > > > >>>>>        an
> > > > > >>>>>        user.
> > > > > >>>>>        In
> > > > > >>>>>        this case, the application will just receive an ordinary
> > > > > >>>>>        KC
> > > > > >>>>>        token
> > > > > >>>>>        after a successful authentication.
> > > > > >>>>>
> > > > > >>>>>        In both cases, the broker acts as an intermediary where
> > > > > >>>>>        specific
> > > > > >>>>>        security policies can be applied when users try to
> > > > > >>>>>        authenticate
> > > > > >>>>>        themselves against a 3rd party IdP. That brings a lot of
> > > > > >>>>>        value
> > > > > >>>>>        when
> > > > > >>>>>        you think about auditing, authorization and how users
> > > > > >>>>>        are
> > > > > >>>>>        provisioned
> > > > > >>>>>        when federation of identities is needed. This also
> > > > > >>>>>        allows
> > > > > >>>>>        existing
> > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > >>>>>        infrastructures)
> > > > > >>>>>        to
> > > > > >>>>>        benefit
> > > > > >>>>>        from KC's support for cloud, rest and mobile use cases.
> > > > > >>>>>
> > > > > >>>>>        I think this is enough to start a discussion. I've an
> > > > > >>>>>        initial
> > > > > >>>>>        discussion with Stian about all that and we agreed that
> > > > > >>>>>        abstract
> > > > > >>>>>        the
> > > > > >>>>>        protocol from applications should be prioritized. The
> > > > > >>>>>        main
> > > > > >>>>>        reason is
> > > > > >>>>>        that it makes life easier for applications so they only
> > > > > >>>>>        need
> > > > > >>>>>        to
> > > > > >>>>>        know
> > > > > >>>>>        about KC tokens and nothing else. However that brings
> > > > > >>>>>        some
> > > > > >>>>>        new
> > > > > >>>>>        requirements around user provisioning and
> > > > > >>>>>        claim/attribute
> > > > > >>>>>        resolution
> > > > > >>>>>        or mapping. But that would be another thread.
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> Can you elaborate on "abstract the protocol from applications"?
> > > > > >>>> Not
> > > > > >>>> sure what you mean by that.  IDP federation should be configured
> > > > > >>>> at
> > > > > >>>> the
> > > > > >>>> realm level and really has nothing to do with applications.
> > > > > >>>>
> > > > > >>>> I'm really happy that somebody is doing this.  We're getting a
> > > > > >>>> real
> > > > > >>>> impressive feature set!
> > > > > >>>
> > > > > >>> Sure. What I meant was that the application only knows about KC
> > > > > >>> tokens
> > > > > >>> nothing else. It will always receive a KC token regardless the
> > > > > >>> protocol
> > > > > >>> used
> > > > > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > > > > >>> whatever).
> > > > > >>> The
> > > > > >>> example I gave was about an user trying to authenticate against a
> > > > > >>> SAML
> > > > > >>> IdP.
> > > > > >>> In this case, after a successful authentication on the IdP, the
> > > > > >>> IdP
> > > > > >>> will
> > > > > >>> issue a token to KC. Then KC will validate the token, perform
> > > > > >>> trust
> > > > > >>> and
> > > > > >>> security checks, do user provisioning and attribute/claim
> > > > > >>> resolution
> > > > > >>> to
> > > > > >>> finally issue a KC token and redirect the user to the
> > > > > >>> application.
> > > > > >>> If
> > > > > >>> the
> > > > > >>> app is configured to use openid in KC then it will receive a
> > > > > >>> openid
> > > > > >>> token
> > > > > >>> from KC, not saml ...
> > > > > >>>
> > > > > >>> The other scenario is pretty much the same. The difference is
> > > > > >>> that
> > > > > >>> KC
> > > > > >>> will
> > > > > >>> not issue its own token but just replay the token issued by the
> > > > > >>> 3rd
> > > > > >>> party
> > > > > >>> IdP to the service provider.
> > > > > >>>
> > > > > >>> I agree that this config goes at the realm level. For instance,
> > > > > >>> to
> > > > > >>> create
> > > > > >>> and
> > > > > >>> enable providers for being used. However, I think we would need
> > > > > >>> some
> > > > > >>> specific configuration for applications as well. Specially when
> > > > > >>> defining
> > > > > >>> default roles, mapping attributes. Another example of application
> > > > > >>> config
> > > > > >>> is
> > > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > > > > >>> per-application.
> > > > > >>>
> > > > > >>>>
> > > > > >>>> --
> > > > > >>>> Bill Burke
> > > > > >>>> JBoss, a division of Red Hat
> > > > > >>>> http://bill.burkecentral.com
> > > > > >>>> _______________________________________________
> > > > > >>>> keycloak-dev mailing list
> > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > >>>>
> > > > > >>> _______________________________________________
> > > > > >>> 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
> > > > > 
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > 
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Dec  5 03:15:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 03:15:15 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>
	<247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>
	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
Message-ID: <2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>

Having a separate enable/disable for each provider would be good. If you're leaving the social tab as is and adding a separate tab for configuring brokered idp's then we should leave the social enable/disable button, otherwise it depends how it'll look like in the end.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 2:29:37 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Hi,
> 
>    Social has a button to enable/disable it. I'm wondering what to do with
>    the brokered identity providers. Shall we add a similar flag for that ?
> 
>    I was also wondering if the best would be a flag in a per provider basis.
>    So we can disable/enable a specific provider (social or brokered),
>    instead of doing that for all.
> 
> Regards.
> Pedro Igor
> 
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, December 2, 2014 10:42:11 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > I'll go for it then. Will remove the icon url from the model and leave
> > > that
> > > for users if they want to provide icons for their identity providers.
> > > 
> > > My point is that icons can be usually served by the same
> > > server/application
> > > or proxy, so download images are not such a big deal. Also, the icon url
> > > is
> > > part of the freemarker model and people can do what ever they want with
> > > it.
> > > What I think will also help in your future plans.
> > 
> > I'm not following. Are you saying that if a named image 'my-provider.png'
> > is
> > loaded from a theme, then you can override it in another theme?
> > 
> > If so, that's basically the same as having a css class 'my-provider' in a
> > theme. With the exception that with an image you end up with having to
> > require a image per provider per theme per language, which could be a lot
> > of
> > images for a single provider. Also, buttons for accessibility should be
> > defined with text and css, not images that can't be interpreted. You also
> > still need to modify the theme, so I don't see any benefits.
> 
> You are right. Having a icon url per provider does not makes sense if there
> are requirements to change images accordingly to a theme or language. CSS
> makes life easier.
> 
> Will remove that property from the model.
> 
> > 
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Users can now specify a Icon Url to be rendered on the login page when
> > > > social
> > > > or any other identity provider is configured. So we just load the image
> > > > the
> > > > url entered by the user.
> > > > 
> > > > Are you saying that users should change the theme or customize css if
> > > > they
> > > > only want to change an icon for a provider ?
> > > 
> > > Yes, there's many issues with having a icon url:
> > > 
> > > * Won't work for internationalization - we don't have this now, but we
> > > will
> > > * Image is not a good button - CSS is much better
> > > * Doesn't support themes - we allow users to switch l&f by switching
> > > themes,
> > > but that won't work for a icon url. In the future we may also support
> > > multiple themes per-realm, for example to depending on the devices (one
> > > theme for mobiles, one for desktops, etc)
> > > * Requires the URL to be hosted somewhere - why require a separate call
> > > to
> > > download an image (to a separate server maybe) if it can simply be
> > > defined
> > > in a single CSS file?
> > > 
> > > Rather than add additional places to define look and feel components we
> > > should in the future make it easier to add/customize themes.
> > > 
> > > > 
> > > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > All look and feel related things including images and stylesheets
> > > > should
> > > > be
> > > > part of themes. This is to allow customizing them in the theme. Also,
> > > > an
> > > > image is not the correct way to render a button, it should be defined
> > > > in
> > > > CSS.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > You shouldn't have icon images for social providers. They should be
> > > > > specified
> > > > > as part of the theme in CSS as is now.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > >     Anyone know where I can get the icons images for social
> > > > > >     providers
> > > > > >     ?
> > > > > >     It
> > > > > >     seems zocial defines them encoded in some way in CSS. I need
> > > > > >     that
> > > > > >     to
> > > > > >     provide default images if user does not specify their own.
> > > > > > 
> > > > > >     Or is still possible to use zocial ones ?
> > > > > > 
> > > > > > Regards.
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Hi guys,
> > > > > > 
> > > > > >    I've done some initial work covering both persistence and
> > > > > >    brokering.
> > > > > >    No
> > > > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > > > >    functionality
> > > > > >    for now.
> > > > > > 
> > > > > >    What I have is enough to decide if we are aligned about this
> > > > > >    functionality. So you can understand how the model (and
> > > > > >    persistence),
> > > > > >    rest api and brokering functionality looks like. Can we schedule
> > > > > >    a
> > > > > >    meeting ?
> > > > > > 
> > > > > >    Btw, my branch is here [1].
> > > > > > 
> > > > > > [1]
> > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > 
> > > > > > Regards.
> > > > > > Pedro Igor
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Currently adapters can only make authz decisions (@RolesAllowed)
> > > > > > based
> > > > > > on either realm roles or the roles of one specific application.
> > > > > > This
> > > > > > is
> > > > > > related to 1) too.
> > > > > > 
> > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > >
> > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > >> I just wanted to quickly list the additional work we discussed
> > > > > > >> so
> > > > > > >> everyone
> > > > > > >> can think about it (in no particular order):
> > > > > > >>
> > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an
> > > > > > >> external
> > > > > > >> token
> > > > > > >> to
> > > > > > >> a KC token? For example an external token with attribute 'group'
> > > > > > >> that
> > > > > > >> contains 'sales' and 'manager' could be mapped to 'manager' role
> > > > > > >> for
> > > > > > >> 'sales app in a KC token. Could we use Drools? This could also
> > > > > > >> be
> > > > > > >> used
> > > > > > >> in
> > > > > > >> user federation to allow more complex mapping of roles/groups
> > > > > > >> than
> > > > > > >> a
> > > > > > >> simple 1-1
> > > > > > >> 2) Retrieving tokens - if an application wants to retrieve the
> > > > > > >> external
> > > > > > >> token (for example to view Facebook friends if user logged in
> > > > > > >> with
> > > > > > >> Facebook)
> > > > > > >> 3) Configure scope - currently for social we only request a very
> > > > > > >> limited
> > > > > > >> scope (basic profile and email), to for example view Facebook
> > > > > > >> friends
> > > > > > >> we'd need to ask for that as well
> > > > > > >> 4) Selecting provider - currently in social (and for first pass
> > > > > > >> of
> > > > > > >> brokering) we have an icon user has to select, but can we select
> > > > > > >> the
> > > > > > >> provider in a different way (for example ask user for email, and
> > > > > > >> select
> > > > > > >> based on email domain)
> > > > > > >> 5) Gateway - don't create a KC token, but just forward the
> > > > > > >> external
> > > > > > >> token
> > > > > > >>
> > > > > > >> IMO 1) is a killer feature, as it would allow companies to add
> > > > > > >> external
> > > > > > >> users without having to modify their applications. Issue with 5)
> > > > > > >> is
> > > > > > >> that
> > > > > > >> applications need to understand more than one token, which would
> > > > > > >> require
> > > > > > >> rewriting applications.
> > > > > > >>
> > > > > > >> This work is also somewhat related to other authentication
> > > > > > >> mechanisms
> > > > > > >> (for
> > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > >>
> > > > > > >> ----- Original Message -----
> > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > >>> Authentication
> > > > > > >>> Broker
> > > > > > >>>
> > > > > > >>> ----- Original Message -----
> > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > >>>> Authentication
> > > > > > >>>> Broker
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > >>>>> Hi,
> > > > > > >>>>>
> > > > > > >>>>>        Would like to start a discussion about how to enable
> > > > > > >>>>>        KC
> > > > > > >>>>>        as
> > > > > > >>>>>        an
> > > > > > >>>>>        Authentication Broker in order to supported Chained
> > > > > > >>>>>        Federation
> > > > > > >>>>>        and
> > > > > > >>>>>        also Identity Federation. First of all, some
> > > > > > >>>>>        background
> > > > > > >>>>>        about
> > > > > > >>>>>        what
> > > > > > >>>>>        this is all about.
> > > > > > >>>>>
> > > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > > >>>>>        authentication
> > > > > > >>>>>        (correct
> > > > > > >>>>>        me if I'm wrong, please):
> > > > > > >>>>>
> > > > > > >>>>>            1) Local authentication (based on some credential
> > > > > > >>>>>            type
> > > > > > >>>>>            enabled
> > > > > > >>>>>            to
> > > > > > >>>>>            a realm)
> > > > > > >>>>>            2) Social authentication
> > > > > > >>>>>
> > > > > > >>>>>        Local authentication is about authenticating the user
> > > > > > >>>>>        locally
> > > > > > >>>>>        using
> > > > > > >>>>>        KC's own identity store. Nothing special here. And
> > > > > > >>>>>        Social
> > > > > > >>>>>        Authentication which allows users to choose the Social
> > > > > > >>>>>        IdP
> > > > > > >>>>>        they
> > > > > > >>>>>        want
> > > > > > >>>>>        to authenticate with. In this case, the IdP is always
> > > > > > >>>>>        one
> > > > > > >>>>>        of
> > > > > > >>>>>        the
> > > > > > >>>>>        built-in social providers supported by KC such as
> > > > > > >>>>>        Facebook,
> > > > > > >>>>>        Google,
> > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > >>>>>
> > > > > > >>>>>        When doing social, the user is automatically
> > > > > > >>>>>        provisioned
> > > > > > >>>>>        in
> > > > > > >>>>>        KC
> > > > > > >>>>>        identity store after a successful authentication. The
> > > > > > >>>>>        user
> > > > > > >>>>>        does
> > > > > > >>>>>        not
> > > > > > >>>>>        need to fill a registration form and can access the
> > > > > > >>>>>        application
> > > > > > >>>>>        very
> > > > > > >>>>>        quickly. During the provisioning some basic
> > > > > > >>>>>        information
> > > > > > >>>>>        is
> > > > > > >>>>>        retrieved
> > > > > > >>>>>        from the social provider such as email, firstname and
> > > > > > >>>>>        so
> > > > > > >>>>>        forth.
> > > > > > >>>>>        These
> > > > > > >>>>>        are very basic information, any other information such
> > > > > > >>>>>        as
> > > > > > >>>>>        those
> > > > > > >>>>>        related with authorization policies - eg.: roles and
> > > > > > >>>>>        groups
> > > > > > >>>>>        -
> > > > > > >>>>>        must
> > > > > > >>>>>        be
> > > > > > >>>>>        defined later via KC's admin console.
> > > > > > >>>>>
> > > > > > >>>>>        Another important characteristic of social
> > > > > > >>>>>        authentication
> > > > > > >>>>>        is
> > > > > > >>>>>        that
> > > > > > >>>>>        the
> > > > > > >>>>>        application receives a KC token and not the token that
> > > > > > >>>>>        was
> > > > > > >>>>>        issued by
> > > > > > >>>>>        the social IdP during the authentication process. If
> > > > > > >>>>>        the
> > > > > > >>>>>        application
> > > > > > >>>>>        wants to consume resources from the resource provider
> > > > > > >>>>>        he
> > > > > > >>>>>        was
> > > > > > >>>>>        authenticated it must obtain the access token(again)
> > > > > > >>>>>        by
> > > > > > >>>>>        itself
> > > > > > >>>>>        prior
> > > > > > >>>>>        to invoke the resource provider API. Assuming all
> > > > > > >>>>>        those
> > > > > > >>>>>        social
> > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > >>>>>
> > > > > > >>>>>        That said, the Authentication Broker functionality
> > > > > > >>>>>        aims
> > > > > > >>>>>        to
> > > > > > >>>>>        cover
> > > > > > >>>>>        the
> > > > > > >>>>>        same use cases but with a lot of more flexibility on
> > > > > > >>>>>        how
> > > > > > >>>>>        you
> > > > > > >>>>>        setup
> > > > > > >>>>>        identity providers(not only social ones) and the
> > > > > > >>>>>        different
> > > > > > >>>>>        federation
> > > > > > >>>>>        protocols they may support such as SAML, OpenID, oAuth
> > > > > > >>>>>        and
> > > > > > >>>>>        so
> > > > > > >>>>>        forth.
> > > > > > >>>>>        This is useful when an enterprise is providing
> > > > > > >>>>>        services
> > > > > > >>>>>        to
> > > > > > >>>>>        different
> > > > > > >>>>>        customers(IdP) and does not want to manage many to
> > > > > > >>>>>        many
> > > > > > >>>>>        relationships. When using a broker, the authentication
> > > > > > >>>>>        steps
> > > > > > >>>>>        are
> > > > > > >>>>>        pretty much the same when you are using social
> > > > > > >>>>>        authentication,
> > > > > > >>>>>        with
> > > > > > >>>>>        important differences on how you support different
> > > > > > >>>>>        identity
> > > > > > >>>>>        providers, different federation protocols, how users
> > > > > > >>>>>        are
> > > > > > >>>>>        provisioned
> > > > > > >>>>>        and how claims and attributes are resolved.
> > > > > > >>>>>
> > > > > > >>>>>        The brokering functionality can be done in two ways
> > > > > > >>>>>        depending
> > > > > > >>>>>        if
> > > > > > >>>>>        the
> > > > > > >>>>>        broker service is acting as a gateway or not. When
> > > > > > >>>>>        acting
> > > > > > >>>>>        as
> > > > > > >>>>>        a
> > > > > > >>>>>        gateway, the broker will respond to the application
> > > > > > >>>>>        the
> > > > > > >>>>>        same
> > > > > > >>>>>        token
> > > > > > >>>>>        issued by the trusted identity provider. For instance,
> > > > > > >>>>>        if
> > > > > > >>>>>        the
> > > > > > >>>>>        user
> > > > > > >>>>>        selects a SAML IdP to authenticate with, the
> > > > > > >>>>>        application
> > > > > > >>>>>        will
> > > > > > >>>>>        receive
> > > > > > >>>>>        a SAML Response. In this case, the application must
> > > > > > >>>>>        also
> > > > > > >>>>>        be
> > > > > > >>>>>        prepared
> > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > >>>>>
> > > > > > >>>>>        However, the broker service can also be used to
> > > > > > >>>>>        completely
> > > > > > >>>>>        abstract
> > > > > > >>>>>        from the application the protocol used to authenticate
> > > > > > >>>>>        an
> > > > > > >>>>>        user.
> > > > > > >>>>>        In
> > > > > > >>>>>        this case, the application will just receive an
> > > > > > >>>>>        ordinary
> > > > > > >>>>>        KC
> > > > > > >>>>>        token
> > > > > > >>>>>        after a successful authentication.
> > > > > > >>>>>
> > > > > > >>>>>        In both cases, the broker acts as an intermediary
> > > > > > >>>>>        where
> > > > > > >>>>>        specific
> > > > > > >>>>>        security policies can be applied when users try to
> > > > > > >>>>>        authenticate
> > > > > > >>>>>        themselves against a 3rd party IdP. That brings a lot
> > > > > > >>>>>        of
> > > > > > >>>>>        value
> > > > > > >>>>>        when
> > > > > > >>>>>        you think about auditing, authorization and how users
> > > > > > >>>>>        are
> > > > > > >>>>>        provisioned
> > > > > > >>>>>        when federation of identities is needed. This also
> > > > > > >>>>>        allows
> > > > > > >>>>>        existing
> > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > >>>>>        infrastructures)
> > > > > > >>>>>        to
> > > > > > >>>>>        benefit
> > > > > > >>>>>        from KC's support for cloud, rest and mobile use
> > > > > > >>>>>        cases.
> > > > > > >>>>>
> > > > > > >>>>>        I think this is enough to start a discussion. I've an
> > > > > > >>>>>        initial
> > > > > > >>>>>        discussion with Stian about all that and we agreed
> > > > > > >>>>>        that
> > > > > > >>>>>        abstract
> > > > > > >>>>>        the
> > > > > > >>>>>        protocol from applications should be prioritized. The
> > > > > > >>>>>        main
> > > > > > >>>>>        reason is
> > > > > > >>>>>        that it makes life easier for applications so they
> > > > > > >>>>>        only
> > > > > > >>>>>        need
> > > > > > >>>>>        to
> > > > > > >>>>>        know
> > > > > > >>>>>        about KC tokens and nothing else. However that brings
> > > > > > >>>>>        some
> > > > > > >>>>>        new
> > > > > > >>>>>        requirements around user provisioning and
> > > > > > >>>>>        claim/attribute
> > > > > > >>>>>        resolution
> > > > > > >>>>>        or mapping. But that would be another thread.
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > >>>> applications"?
> > > > > > >>>> Not
> > > > > > >>>> sure what you mean by that.  IDP federation should be
> > > > > > >>>> configured
> > > > > > >>>> at
> > > > > > >>>> the
> > > > > > >>>> realm level and really has nothing to do with applications.
> > > > > > >>>>
> > > > > > >>>> I'm really happy that somebody is doing this.  We're getting a
> > > > > > >>>> real
> > > > > > >>>> impressive feature set!
> > > > > > >>>
> > > > > > >>> Sure. What I meant was that the application only knows about KC
> > > > > > >>> tokens
> > > > > > >>> nothing else. It will always receive a KC token regardless the
> > > > > > >>> protocol
> > > > > > >>> used
> > > > > > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > > > > > >>> whatever).
> > > > > > >>> The
> > > > > > >>> example I gave was about an user trying to authenticate against
> > > > > > >>> a
> > > > > > >>> SAML
> > > > > > >>> IdP.
> > > > > > >>> In this case, after a successful authentication on the IdP, the
> > > > > > >>> IdP
> > > > > > >>> will
> > > > > > >>> issue a token to KC. Then KC will validate the token, perform
> > > > > > >>> trust
> > > > > > >>> and
> > > > > > >>> security checks, do user provisioning and attribute/claim
> > > > > > >>> resolution
> > > > > > >>> to
> > > > > > >>> finally issue a KC token and redirect the user to the
> > > > > > >>> application.
> > > > > > >>> If
> > > > > > >>> the
> > > > > > >>> app is configured to use openid in KC then it will receive a
> > > > > > >>> openid
> > > > > > >>> token
> > > > > > >>> from KC, not saml ...
> > > > > > >>>
> > > > > > >>> The other scenario is pretty much the same. The difference is
> > > > > > >>> that
> > > > > > >>> KC
> > > > > > >>> will
> > > > > > >>> not issue its own token but just replay the token issued by the
> > > > > > >>> 3rd
> > > > > > >>> party
> > > > > > >>> IdP to the service provider.
> > > > > > >>>
> > > > > > >>> I agree that this config goes at the realm level. For instance,
> > > > > > >>> to
> > > > > > >>> create
> > > > > > >>> and
> > > > > > >>> enable providers for being used. However, I think we would need
> > > > > > >>> some
> > > > > > >>> specific configuration for applications as well. Specially when
> > > > > > >>> defining
> > > > > > >>> default roles, mapping attributes. Another example of
> > > > > > >>> application
> > > > > > >>> config
> > > > > > >>> is
> > > > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > > > > > >>> per-application.
> > > > > > >>>
> > > > > > >>>>
> > > > > > >>>> --
> > > > > > >>>> Bill Burke
> > > > > > >>>> JBoss, a division of Red Hat
> > > > > > >>>> http://bill.burkecentral.com
> > > > > > >>>> _______________________________________________
> > > > > > >>>> keycloak-dev mailing list
> > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > >>>>
> > > > > > >>> _______________________________________________
> > > > > > >>> 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
> > > > > > 
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > 
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > 
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > 
> > > 
> > 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From stian at redhat.com  Fri Dec  5 03:23:56 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 03:23:56 -0500 (EST)
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <20141204160141.GB38989@abstractj.org>
References: <20141204090925.GA27060@abstractj.org>
	<20141204104226.GA30278@abstractj.org>
	<548067FB.7030500@redhat.com>
	<20141204141944.GA38630@abstractj.org>
	<54807604.2020409@redhat.com>
	<ED9D071C-4FDE-4EAA-BE1A-7B1B7E400C9B@redhat.com>
	<54808235.5040504@redhat.com>
	<20141204160141.GB38989@abstractj.org>
Message-ID: <1144347172.11173475.1417767836452.JavaMail.zimbra@redhat.com>

There's benefits to both approaches, but the simple fact is we currently version everything the same. Keycloak, adapters, cartridges, etc. I don't want to have a special case for the Passport adapter, so let's use the same version at least for now. 

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 4 December, 2014 5:01:41 PM
> Subject: Re: [keycloak-dev] Invalid redirect_uri with passport
> 
> On 2014-12-04, Bill Burke wrote:
> >
> >
> > On 12/4/2014 10:04 AM, Lucas Holmquist wrote:
> > >
> > >>On Dec 4, 2014, at 9:56 AM, Bill Burke <bburke at redhat.com> wrote:
> > >>
> > >>
> > >>
> > >>On 12/4/2014 9:19 AM, Bruno Oliveira wrote:
> > >>>On 2014-12-04, Bill Burke wrote:
> > >>>>I'd like to distribute this in the next release and document it.  Will
> > >>>>the appropriate Node.js distribution methods be available for this?
> > >>>>(Bower?)
> > >>>
> > >>>Hi Bill, it's distributed under npm here
> > >>>https://www.npmjs.org/package/passport-keycloak
> > >>>
> > >>>>Change the version to 1.1.Beta2 :)
> > >>>
> > >>>I'm not so sure about the versioning, it's a big bump for the first
> > >>>release. But I'm fine if you guys think the opposite.
> > >>>
> > >>
> > >>Doesn't matter.  Have it same version as Keycloak.  It will be easier to
> > >>keep track of compatibilities for both us and users.  BTW, our Tomcat
> > >>and Jetty are new, we didn't version it 0.0.alph1. :)
> > >
> > >i sort of disagree here.  This is just an adapter really, and should be on
> > >it?s own versioning independent of what the main key cloak distribution
> > >is.
> > >
> >
> > In my experience different versions just confuses people.  It starts to
> > become important when you have multiple major versions out in the wild and
> > there are incompatibilities between them.
> 
> Bill, my major concern about having the same versioning. Is people
> mistakenly assuming that this adapter is full compatible with all the
> features on
> Keycloak, which is not true at the moment. More work is required, like
> you asked for role mappings, bearer tokens and etc.
> 
> Does it make sense to you?
> 
> >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Fri Dec  5 03:28:31 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 5 Dec 2014 06:28:31 -0200
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <1144347172.11173475.1417767836452.JavaMail.zimbra@redhat.com>
References: <20141204090925.GA27060@abstractj.org>
	<20141204104226.GA30278@abstractj.org>
	<548067FB.7030500@redhat.com> <20141204141944.GA38630@abstractj.org>
	<54807604.2020409@redhat.com>
	<ED9D071C-4FDE-4EAA-BE1A-7B1B7E400C9B@redhat.com>
	<54808235.5040504@redhat.com> <20141204160141.GB38989@abstractj.org>
	<1144347172.11173475.1417767836452.JavaMail.zimbra@redhat.com>
Message-ID: <CAM5SUC5AePLGRggi+6Wc_4u1t25Ny7+vBq3TtX3Eaqw0WvQ27Q@mail.gmail.com>

No problem at all. Would you guys like to have the codebase under keycloak
organization? Just let me know.

On Fri, Dec 5, 2014 at 6:23 AM, Stian Thorgersen <stian at redhat.com> wrote:

> There's benefits to both approaches, but the simple fact is we currently
> version everything the same. Keycloak, adapters, cartridges, etc. I don't
> want to have a special case for the Passport adapter, so let's use the same
> version at least for now.
>
> ----- Original Message -----
> > From: "Bruno Oliveira" <bruno at abstractj.org>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 4 December, 2014 5:01:41 PM
> > Subject: Re: [keycloak-dev] Invalid redirect_uri with passport
> >
> > On 2014-12-04, Bill Burke wrote:
> > >
> > >
> > > On 12/4/2014 10:04 AM, Lucas Holmquist wrote:
> > > >
> > > >>On Dec 4, 2014, at 9:56 AM, Bill Burke <bburke at redhat.com> wrote:
> > > >>
> > > >>
> > > >>
> > > >>On 12/4/2014 9:19 AM, Bruno Oliveira wrote:
> > > >>>On 2014-12-04, Bill Burke wrote:
> > > >>>>I'd like to distribute this in the next release and document it.
> Will
> > > >>>>the appropriate Node.js distribution methods be available for this?
> > > >>>>(Bower?)
> > > >>>
> > > >>>Hi Bill, it's distributed under npm here
> > > >>>https://www.npmjs.org/package/passport-keycloak
> > > >>>
> > > >>>>Change the version to 1.1.Beta2 :)
> > > >>>
> > > >>>I'm not so sure about the versioning, it's a big bump for the first
> > > >>>release. But I'm fine if you guys think the opposite.
> > > >>>
> > > >>
> > > >>Doesn't matter.  Have it same version as Keycloak.  It will be
> easier to
> > > >>keep track of compatibilities for both us and users.  BTW, our Tomcat
> > > >>and Jetty are new, we didn't version it 0.0.alph1. :)
> > > >
> > > >i sort of disagree here.  This is just an adapter really, and should
> be on
> > > >it?s own versioning independent of what the main key cloak
> distribution
> > > >is.
> > > >
> > >
> > > In my experience different versions just confuses people.  It starts to
> > > become important when you have multiple major versions out in the wild
> and
> > > there are incompatibilities between them.
> >
> > Bill, my major concern about having the same versioning. Is people
> > mistakenly assuming that this adapter is full compatible with all the
> > features on
> > Keycloak, which is not true at the moment. More work is required, like
> > you asked for role mappings, bearer tokens and etc.
> >
> > Does it make sense to you?
> >
> > >
> > >
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141205/69642617/attachment.html 

From stian at redhat.com  Fri Dec  5 03:33:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 03:33:31 -0500 (EST)
Subject: [keycloak-dev] Invalid redirect_uri with passport
In-Reply-To: <CAM5SUC5AePLGRggi+6Wc_4u1t25Ny7+vBq3TtX3Eaqw0WvQ27Q@mail.gmail.com>
References: <20141204090925.GA27060@abstractj.org>
	<20141204141944.GA38630@abstractj.org>
	<54807604.2020409@redhat.com>
	<ED9D071C-4FDE-4EAA-BE1A-7B1B7E400C9B@redhat.com>
	<54808235.5040504@redhat.com>
	<20141204160141.GB38989@abstractj.org>
	<1144347172.11173475.1417767836452.JavaMail.zimbra@redhat.com>
	<CAM5SUC5AePLGRggi+6Wc_4u1t25Ny7+vBq3TtX3Eaqw0WvQ27Q@mail.gmail.com>
Message-ID: <817773585.11177006.1417768411514.JavaMail.zimbra@redhat.com>

Yes please, do a PR to https://github.com/keycloak/keycloak-passport :)

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 9:28:31 AM
> Subject: Re: [keycloak-dev] Invalid redirect_uri with passport
> 
> No problem at all. Would you guys like to have the codebase under keycloak
> organization? Just let me know.

Yes, please. I guess it should be in a separate repo?

> 
> On Fri, Dec 5, 2014 at 6:23 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > There's benefits to both approaches, but the simple fact is we currently
> > version everything the same. Keycloak, adapters, cartridges, etc. I don't
> > want to have a special case for the Passport adapter, so let's use the same
> > version at least for now.
> >
> > ----- Original Message -----
> > > From: "Bruno Oliveira" <bruno at abstractj.org>
> > > To: "Bill Burke" <bburke at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Thursday, 4 December, 2014 5:01:41 PM
> > > Subject: Re: [keycloak-dev] Invalid redirect_uri with passport
> > >
> > > On 2014-12-04, Bill Burke wrote:
> > > >
> > > >
> > > > On 12/4/2014 10:04 AM, Lucas Holmquist wrote:
> > > > >
> > > > >>On Dec 4, 2014, at 9:56 AM, Bill Burke <bburke at redhat.com> wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>On 12/4/2014 9:19 AM, Bruno Oliveira wrote:
> > > > >>>On 2014-12-04, Bill Burke wrote:
> > > > >>>>I'd like to distribute this in the next release and document it.
> > Will
> > > > >>>>the appropriate Node.js distribution methods be available for this?
> > > > >>>>(Bower?)
> > > > >>>
> > > > >>>Hi Bill, it's distributed under npm here
> > > > >>>https://www.npmjs.org/package/passport-keycloak
> > > > >>>
> > > > >>>>Change the version to 1.1.Beta2 :)
> > > > >>>
> > > > >>>I'm not so sure about the versioning, it's a big bump for the first
> > > > >>>release. But I'm fine if you guys think the opposite.
> > > > >>>
> > > > >>
> > > > >>Doesn't matter.  Have it same version as Keycloak.  It will be
> > easier to
> > > > >>keep track of compatibilities for both us and users.  BTW, our Tomcat
> > > > >>and Jetty are new, we didn't version it 0.0.alph1. :)
> > > > >
> > > > >i sort of disagree here.  This is just an adapter really, and should
> > be on
> > > > >it?s own versioning independent of what the main key cloak
> > distribution
> > > > >is.
> > > > >
> > > >
> > > > In my experience different versions just confuses people.  It starts to
> > > > become important when you have multiple major versions out in the wild
> > and
> > > > there are incompatibilities between them.
> > >
> > > Bill, my major concern about having the same versioning. Is people
> > > mistakenly assuming that this adapter is full compatible with all the
> > > features on
> > > Keycloak, which is not true at the moment. More work is required, like
> > > you asked for role mappings, bearer tokens and etc.
> > >
> > > Does it make sense to you?
> > >
> > > >
> > > >
> > > > --
> > > > Bill Burke
> > > > JBoss, a division of Red Hat
> > > > http://bill.burkecentral.com
> > >
> > > --
> > >
> > > abstractj
> > > PGP: 0x84DC9914
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> 
> 
> --
> 
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
> 


From psilva at redhat.com  Fri Dec  5 07:08:53 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 Dec 2014 07:08:53 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>
	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
Message-ID: <2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>

In one of our last discussions, you suggested to leave Social as it is. Although IMO I think we can have a single place to manage both social and user-defined identity providers. Social ones are just OOTB and pre-configured identity providers now.

That said, today I'm using separated tabs for social and user-defined. Please, take a look at [1] for more details on how the UI looks like.

I've changed social UI a bit in order to provide a specific page for create/update. I've also added a "Show Secret" link to display the client_secret in clear text if user wants to.

Beside the enable/disable button, I think another good thing to do is specify a default role(s) for each provider. That can be useful if applications want to perform any kind of authorization based on the identity provider or authentication method used to authenticate an user (eg.: useful for adaptative or multi-level access control). We can also use the "amr" claim in the ID Token, which seems KC is not considering at all. The latter is an important thing to think of, regardless this broker work I'm doing.

[1] https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Friday, December 5, 2014 6:15:15 AM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker

Having a separate enable/disable for each provider would be good. If you're leaving the social tab as is and adding a separate tab for configuring brokered idp's then we should leave the social enable/disable button, otherwise it depends how it'll look like in the end.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 2:29:37 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Hi,
> 
>    Social has a button to enable/disable it. I'm wondering what to do with
>    the brokered identity providers. Shall we add a similar flag for that ?
> 
>    I was also wondering if the best would be a flag in a per provider basis.
>    So we can disable/enable a specific provider (social or brokered),
>    instead of doing that for all.
> 
> Regards.
> Pedro Igor
> 
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, December 2, 2014 10:42:11 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > I'll go for it then. Will remove the icon url from the model and leave
> > > that
> > > for users if they want to provide icons for their identity providers.
> > > 
> > > My point is that icons can be usually served by the same
> > > server/application
> > > or proxy, so download images are not such a big deal. Also, the icon url
> > > is
> > > part of the freemarker model and people can do what ever they want with
> > > it.
> > > What I think will also help in your future plans.
> > 
> > I'm not following. Are you saying that if a named image 'my-provider.png'
> > is
> > loaded from a theme, then you can override it in another theme?
> > 
> > If so, that's basically the same as having a css class 'my-provider' in a
> > theme. With the exception that with an image you end up with having to
> > require a image per provider per theme per language, which could be a lot
> > of
> > images for a single provider. Also, buttons for accessibility should be
> > defined with text and css, not images that can't be interpreted. You also
> > still need to modify the theme, so I don't see any benefits.
> 
> You are right. Having a icon url per provider does not makes sense if there
> are requirements to change images accordingly to a theme or language. CSS
> makes life easier.
> 
> Will remove that property from the model.
> 
> > 
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Users can now specify a Icon Url to be rendered on the login page when
> > > > social
> > > > or any other identity provider is configured. So we just load the image
> > > > the
> > > > url entered by the user.
> > > > 
> > > > Are you saying that users should change the theme or customize css if
> > > > they
> > > > only want to change an icon for a provider ?
> > > 
> > > Yes, there's many issues with having a icon url:
> > > 
> > > * Won't work for internationalization - we don't have this now, but we
> > > will
> > > * Image is not a good button - CSS is much better
> > > * Doesn't support themes - we allow users to switch l&f by switching
> > > themes,
> > > but that won't work for a icon url. In the future we may also support
> > > multiple themes per-realm, for example to depending on the devices (one
> > > theme for mobiles, one for desktops, etc)
> > > * Requires the URL to be hosted somewhere - why require a separate call
> > > to
> > > download an image (to a separate server maybe) if it can simply be
> > > defined
> > > in a single CSS file?
> > > 
> > > Rather than add additional places to define look and feel components we
> > > should in the future make it easier to add/customize themes.
> > > 
> > > > 
> > > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > All look and feel related things including images and stylesheets
> > > > should
> > > > be
> > > > part of themes. This is to allow customizing them in the theme. Also,
> > > > an
> > > > image is not the correct way to render a button, it should be defined
> > > > in
> > > > CSS.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > You shouldn't have icon images for social providers. They should be
> > > > > specified
> > > > > as part of the theme in CSS as is now.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > >     Anyone know where I can get the icons images for social
> > > > > >     providers
> > > > > >     ?
> > > > > >     It
> > > > > >     seems zocial defines them encoded in some way in CSS. I need
> > > > > >     that
> > > > > >     to
> > > > > >     provide default images if user does not specify their own.
> > > > > > 
> > > > > >     Or is still possible to use zocial ones ?
> > > > > > 
> > > > > > Regards.
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Hi guys,
> > > > > > 
> > > > > >    I've done some initial work covering both persistence and
> > > > > >    brokering.
> > > > > >    No
> > > > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > > > >    functionality
> > > > > >    for now.
> > > > > > 
> > > > > >    What I have is enough to decide if we are aligned about this
> > > > > >    functionality. So you can understand how the model (and
> > > > > >    persistence),
> > > > > >    rest api and brokering functionality looks like. Can we schedule
> > > > > >    a
> > > > > >    meeting ?
> > > > > > 
> > > > > >    Btw, my branch is here [1].
> > > > > > 
> > > > > > [1]
> > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > 
> > > > > > Regards.
> > > > > > Pedro Igor
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Currently adapters can only make authz decisions (@RolesAllowed)
> > > > > > based
> > > > > > on either realm roles or the roles of one specific application.
> > > > > > This
> > > > > > is
> > > > > > related to 1) too.
> > > > > > 
> > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > >
> > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > >> I just wanted to quickly list the additional work we discussed
> > > > > > >> so
> > > > > > >> everyone
> > > > > > >> can think about it (in no particular order):
> > > > > > >>
> > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an
> > > > > > >> external
> > > > > > >> token
> > > > > > >> to
> > > > > > >> a KC token? For example an external token with attribute 'group'
> > > > > > >> that
> > > > > > >> contains 'sales' and 'manager' could be mapped to 'manager' role
> > > > > > >> for
> > > > > > >> 'sales app in a KC token. Could we use Drools? This could also
> > > > > > >> be
> > > > > > >> used
> > > > > > >> in
> > > > > > >> user federation to allow more complex mapping of roles/groups
> > > > > > >> than
> > > > > > >> a
> > > > > > >> simple 1-1
> > > > > > >> 2) Retrieving tokens - if an application wants to retrieve the
> > > > > > >> external
> > > > > > >> token (for example to view Facebook friends if user logged in
> > > > > > >> with
> > > > > > >> Facebook)
> > > > > > >> 3) Configure scope - currently for social we only request a very
> > > > > > >> limited
> > > > > > >> scope (basic profile and email), to for example view Facebook
> > > > > > >> friends
> > > > > > >> we'd need to ask for that as well
> > > > > > >> 4) Selecting provider - currently in social (and for first pass
> > > > > > >> of
> > > > > > >> brokering) we have an icon user has to select, but can we select
> > > > > > >> the
> > > > > > >> provider in a different way (for example ask user for email, and
> > > > > > >> select
> > > > > > >> based on email domain)
> > > > > > >> 5) Gateway - don't create a KC token, but just forward the
> > > > > > >> external
> > > > > > >> token
> > > > > > >>
> > > > > > >> IMO 1) is a killer feature, as it would allow companies to add
> > > > > > >> external
> > > > > > >> users without having to modify their applications. Issue with 5)
> > > > > > >> is
> > > > > > >> that
> > > > > > >> applications need to understand more than one token, which would
> > > > > > >> require
> > > > > > >> rewriting applications.
> > > > > > >>
> > > > > > >> This work is also somewhat related to other authentication
> > > > > > >> mechanisms
> > > > > > >> (for
> > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > >>
> > > > > > >> ----- Original Message -----
> > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > >>> Authentication
> > > > > > >>> Broker
> > > > > > >>>
> > > > > > >>> ----- Original Message -----
> > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > >>>> Authentication
> > > > > > >>>> Broker
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > >>>>> Hi,
> > > > > > >>>>>
> > > > > > >>>>>        Would like to start a discussion about how to enable
> > > > > > >>>>>        KC
> > > > > > >>>>>        as
> > > > > > >>>>>        an
> > > > > > >>>>>        Authentication Broker in order to supported Chained
> > > > > > >>>>>        Federation
> > > > > > >>>>>        and
> > > > > > >>>>>        also Identity Federation. First of all, some
> > > > > > >>>>>        background
> > > > > > >>>>>        about
> > > > > > >>>>>        what
> > > > > > >>>>>        this is all about.
> > > > > > >>>>>
> > > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > > >>>>>        authentication
> > > > > > >>>>>        (correct
> > > > > > >>>>>        me if I'm wrong, please):
> > > > > > >>>>>
> > > > > > >>>>>            1) Local authentication (based on some credential
> > > > > > >>>>>            type
> > > > > > >>>>>            enabled
> > > > > > >>>>>            to
> > > > > > >>>>>            a realm)
> > > > > > >>>>>            2) Social authentication
> > > > > > >>>>>
> > > > > > >>>>>        Local authentication is about authenticating the user
> > > > > > >>>>>        locally
> > > > > > >>>>>        using
> > > > > > >>>>>        KC's own identity store. Nothing special here. And
> > > > > > >>>>>        Social
> > > > > > >>>>>        Authentication which allows users to choose the Social
> > > > > > >>>>>        IdP
> > > > > > >>>>>        they
> > > > > > >>>>>        want
> > > > > > >>>>>        to authenticate with. In this case, the IdP is always
> > > > > > >>>>>        one
> > > > > > >>>>>        of
> > > > > > >>>>>        the
> > > > > > >>>>>        built-in social providers supported by KC such as
> > > > > > >>>>>        Facebook,
> > > > > > >>>>>        Google,
> > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > >>>>>
> > > > > > >>>>>        When doing social, the user is automatically
> > > > > > >>>>>        provisioned
> > > > > > >>>>>        in
> > > > > > >>>>>        KC
> > > > > > >>>>>        identity store after a successful authentication. The
> > > > > > >>>>>        user
> > > > > > >>>>>        does
> > > > > > >>>>>        not
> > > > > > >>>>>        need to fill a registration form and can access the
> > > > > > >>>>>        application
> > > > > > >>>>>        very
> > > > > > >>>>>        quickly. During the provisioning some basic
> > > > > > >>>>>        information
> > > > > > >>>>>        is
> > > > > > >>>>>        retrieved
> > > > > > >>>>>        from the social provider such as email, firstname and
> > > > > > >>>>>        so
> > > > > > >>>>>        forth.
> > > > > > >>>>>        These
> > > > > > >>>>>        are very basic information, any other information such
> > > > > > >>>>>        as
> > > > > > >>>>>        those
> > > > > > >>>>>        related with authorization policies - eg.: roles and
> > > > > > >>>>>        groups
> > > > > > >>>>>        -
> > > > > > >>>>>        must
> > > > > > >>>>>        be
> > > > > > >>>>>        defined later via KC's admin console.
> > > > > > >>>>>
> > > > > > >>>>>        Another important characteristic of social
> > > > > > >>>>>        authentication
> > > > > > >>>>>        is
> > > > > > >>>>>        that
> > > > > > >>>>>        the
> > > > > > >>>>>        application receives a KC token and not the token that
> > > > > > >>>>>        was
> > > > > > >>>>>        issued by
> > > > > > >>>>>        the social IdP during the authentication process. If
> > > > > > >>>>>        the
> > > > > > >>>>>        application
> > > > > > >>>>>        wants to consume resources from the resource provider
> > > > > > >>>>>        he
> > > > > > >>>>>        was
> > > > > > >>>>>        authenticated it must obtain the access token(again)
> > > > > > >>>>>        by
> > > > > > >>>>>        itself
> > > > > > >>>>>        prior
> > > > > > >>>>>        to invoke the resource provider API. Assuming all
> > > > > > >>>>>        those
> > > > > > >>>>>        social
> > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > >>>>>
> > > > > > >>>>>        That said, the Authentication Broker functionality
> > > > > > >>>>>        aims
> > > > > > >>>>>        to
> > > > > > >>>>>        cover
> > > > > > >>>>>        the
> > > > > > >>>>>        same use cases but with a lot of more flexibility on
> > > > > > >>>>>        how
> > > > > > >>>>>        you
> > > > > > >>>>>        setup
> > > > > > >>>>>        identity providers(not only social ones) and the
> > > > > > >>>>>        different
> > > > > > >>>>>        federation
> > > > > > >>>>>        protocols they may support such as SAML, OpenID, oAuth
> > > > > > >>>>>        and
> > > > > > >>>>>        so
> > > > > > >>>>>        forth.
> > > > > > >>>>>        This is useful when an enterprise is providing
> > > > > > >>>>>        services
> > > > > > >>>>>        to
> > > > > > >>>>>        different
> > > > > > >>>>>        customers(IdP) and does not want to manage many to
> > > > > > >>>>>        many
> > > > > > >>>>>        relationships. When using a broker, the authentication
> > > > > > >>>>>        steps
> > > > > > >>>>>        are
> > > > > > >>>>>        pretty much the same when you are using social
> > > > > > >>>>>        authentication,
> > > > > > >>>>>        with
> > > > > > >>>>>        important differences on how you support different
> > > > > > >>>>>        identity
> > > > > > >>>>>        providers, different federation protocols, how users
> > > > > > >>>>>        are
> > > > > > >>>>>        provisioned
> > > > > > >>>>>        and how claims and attributes are resolved.
> > > > > > >>>>>
> > > > > > >>>>>        The brokering functionality can be done in two ways
> > > > > > >>>>>        depending
> > > > > > >>>>>        if
> > > > > > >>>>>        the
> > > > > > >>>>>        broker service is acting as a gateway or not. When
> > > > > > >>>>>        acting
> > > > > > >>>>>        as
> > > > > > >>>>>        a
> > > > > > >>>>>        gateway, the broker will respond to the application
> > > > > > >>>>>        the
> > > > > > >>>>>        same
> > > > > > >>>>>        token
> > > > > > >>>>>        issued by the trusted identity provider. For instance,
> > > > > > >>>>>        if
> > > > > > >>>>>        the
> > > > > > >>>>>        user
> > > > > > >>>>>        selects a SAML IdP to authenticate with, the
> > > > > > >>>>>        application
> > > > > > >>>>>        will
> > > > > > >>>>>        receive
> > > > > > >>>>>        a SAML Response. In this case, the application must
> > > > > > >>>>>        also
> > > > > > >>>>>        be
> > > > > > >>>>>        prepared
> > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > >>>>>
> > > > > > >>>>>        However, the broker service can also be used to
> > > > > > >>>>>        completely
> > > > > > >>>>>        abstract
> > > > > > >>>>>        from the application the protocol used to authenticate
> > > > > > >>>>>        an
> > > > > > >>>>>        user.
> > > > > > >>>>>        In
> > > > > > >>>>>        this case, the application will just receive an
> > > > > > >>>>>        ordinary
> > > > > > >>>>>        KC
> > > > > > >>>>>        token
> > > > > > >>>>>        after a successful authentication.
> > > > > > >>>>>
> > > > > > >>>>>        In both cases, the broker acts as an intermediary
> > > > > > >>>>>        where
> > > > > > >>>>>        specific
> > > > > > >>>>>        security policies can be applied when users try to
> > > > > > >>>>>        authenticate
> > > > > > >>>>>        themselves against a 3rd party IdP. That brings a lot
> > > > > > >>>>>        of
> > > > > > >>>>>        value
> > > > > > >>>>>        when
> > > > > > >>>>>        you think about auditing, authorization and how users
> > > > > > >>>>>        are
> > > > > > >>>>>        provisioned
> > > > > > >>>>>        when federation of identities is needed. This also
> > > > > > >>>>>        allows
> > > > > > >>>>>        existing
> > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > >>>>>        infrastructures)
> > > > > > >>>>>        to
> > > > > > >>>>>        benefit
> > > > > > >>>>>        from KC's support for cloud, rest and mobile use
> > > > > > >>>>>        cases.
> > > > > > >>>>>
> > > > > > >>>>>        I think this is enough to start a discussion. I've an
> > > > > > >>>>>        initial
> > > > > > >>>>>        discussion with Stian about all that and we agreed
> > > > > > >>>>>        that
> > > > > > >>>>>        abstract
> > > > > > >>>>>        the
> > > > > > >>>>>        protocol from applications should be prioritized. The
> > > > > > >>>>>        main
> > > > > > >>>>>        reason is
> > > > > > >>>>>        that it makes life easier for applications so they
> > > > > > >>>>>        only
> > > > > > >>>>>        need
> > > > > > >>>>>        to
> > > > > > >>>>>        know
> > > > > > >>>>>        about KC tokens and nothing else. However that brings
> > > > > > >>>>>        some
> > > > > > >>>>>        new
> > > > > > >>>>>        requirements around user provisioning and
> > > > > > >>>>>        claim/attribute
> > > > > > >>>>>        resolution
> > > > > > >>>>>        or mapping. But that would be another thread.
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > >>>> applications"?
> > > > > > >>>> Not
> > > > > > >>>> sure what you mean by that.  IDP federation should be
> > > > > > >>>> configured
> > > > > > >>>> at
> > > > > > >>>> the
> > > > > > >>>> realm level and really has nothing to do with applications.
> > > > > > >>>>
> > > > > > >>>> I'm really happy that somebody is doing this.  We're getting a
> > > > > > >>>> real
> > > > > > >>>> impressive feature set!
> > > > > > >>>
> > > > > > >>> Sure. What I meant was that the application only knows about KC
> > > > > > >>> tokens
> > > > > > >>> nothing else. It will always receive a KC token regardless the
> > > > > > >>> protocol
> > > > > > >>> used
> > > > > > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > > > > > >>> whatever).
> > > > > > >>> The
> > > > > > >>> example I gave was about an user trying to authenticate against
> > > > > > >>> a
> > > > > > >>> SAML
> > > > > > >>> IdP.
> > > > > > >>> In this case, after a successful authentication on the IdP, the
> > > > > > >>> IdP
> > > > > > >>> will
> > > > > > >>> issue a token to KC. Then KC will validate the token, perform
> > > > > > >>> trust
> > > > > > >>> and
> > > > > > >>> security checks, do user provisioning and attribute/claim
> > > > > > >>> resolution
> > > > > > >>> to
> > > > > > >>> finally issue a KC token and redirect the user to the
> > > > > > >>> application.
> > > > > > >>> If
> > > > > > >>> the
> > > > > > >>> app is configured to use openid in KC then it will receive a
> > > > > > >>> openid
> > > > > > >>> token
> > > > > > >>> from KC, not saml ...
> > > > > > >>>
> > > > > > >>> The other scenario is pretty much the same. The difference is
> > > > > > >>> that
> > > > > > >>> KC
> > > > > > >>> will
> > > > > > >>> not issue its own token but just replay the token issued by the
> > > > > > >>> 3rd
> > > > > > >>> party
> > > > > > >>> IdP to the service provider.
> > > > > > >>>
> > > > > > >>> I agree that this config goes at the realm level. For instance,
> > > > > > >>> to
> > > > > > >>> create
> > > > > > >>> and
> > > > > > >>> enable providers for being used. However, I think we would need
> > > > > > >>> some
> > > > > > >>> specific configuration for applications as well. Specially when
> > > > > > >>> defining
> > > > > > >>> default roles, mapping attributes. Another example of
> > > > > > >>> application
> > > > > > >>> config
> > > > > > >>> is
> > > > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > > > > > >>> per-application.
> > > > > > >>>
> > > > > > >>>>
> > > > > > >>>> --
> > > > > > >>>> Bill Burke
> > > > > > >>>> JBoss, a division of Red Hat
> > > > > > >>>> http://bill.burkecentral.com
> > > > > > >>>> _______________________________________________
> > > > > > >>>> keycloak-dev mailing list
> > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > >>>>
> > > > > > >>> _______________________________________________
> > > > > > >>> 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
> > > > > > 
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > 
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > 
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > 
> > > 
> > 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From stian at redhat.com  Fri Dec  5 07:22:10 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 07:22:10 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
Message-ID: <2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>

Looks good. I reckon we can combine the two pages. What about if the 'Add provider' drop-down is:

  OpenID 
  SAML
  ------
  Google
  GitHub
  Facebook
  Twitter

Let's drop social on/off and instead have a enable/disable button on each provider.

Also, would be nice if users could set a name or alias for a provider instance. This would make the callback url easier to use (instead of callback/<UUID> it's callback/<alias>). The user federation providers have this.


----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 1:08:53 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> In one of our last discussions, you suggested to leave Social as it is.
> Although IMO I think we can have a single place to manage both social and
> user-defined identity providers. Social ones are just OOTB and
> pre-configured identity providers now.
> 
> That said, today I'm using separated tabs for social and user-defined.
> Please, take a look at [1] for more details on how the UI looks like.
> 
> I've changed social UI a bit in order to provide a specific page for
> create/update. I've also added a "Show Secret" link to display the
> client_secret in clear text if user wants to.
> 
> Beside the enable/disable button, I think another good thing to do is specify
> a default role(s) for each provider. That can be useful if applications want
> to perform any kind of authorization based on the identity provider or
> authentication method used to authenticate an user (eg.: useful for
> adaptative or multi-level access control). We can also use the "amr" claim
> in the ID Token, which seems KC is not considering at all. The latter is an
> important thing to think of, regardless this broker work I'm doing.
> 
> [1]
> https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> 
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, December 5, 2014 6:15:15 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Having a separate enable/disable for each provider would be good. If you're
> leaving the social tab as is and adding a separate tab for configuring
> brokered idp's then we should leave the social enable/disable button,
> otherwise it depends how it'll look like in the end.
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 5 December, 2014 2:29:37 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Hi,
> > 
> >    Social has a button to enable/disable it. I'm wondering what to do with
> >    the brokered identity providers. Shall we add a similar flag for that ?
> > 
> >    I was also wondering if the best would be a flag in a per provider
> >    basis.
> >    So we can disable/enable a specific provider (social or brokered),
> >    instead of doing that for all.
> > 
> > Regards.
> > Pedro Igor
> > 
> > ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > I'll go for it then. Will remove the icon url from the model and leave
> > > > that
> > > > for users if they want to provide icons for their identity providers.
> > > > 
> > > > My point is that icons can be usually served by the same
> > > > server/application
> > > > or proxy, so download images are not such a big deal. Also, the icon
> > > > url
> > > > is
> > > > part of the freemarker model and people can do what ever they want with
> > > > it.
> > > > What I think will also help in your future plans.
> > > 
> > > I'm not following. Are you saying that if a named image 'my-provider.png'
> > > is
> > > loaded from a theme, then you can override it in another theme?
> > > 
> > > If so, that's basically the same as having a css class 'my-provider' in a
> > > theme. With the exception that with an image you end up with having to
> > > require a image per provider per theme per language, which could be a lot
> > > of
> > > images for a single provider. Also, buttons for accessibility should be
> > > defined with text and css, not images that can't be interpreted. You also
> > > still need to modify the theme, so I don't see any benefits.
> > 
> > You are right. Having a icon url per provider does not makes sense if there
> > are requirements to change images accordingly to a theme or language. CSS
> > makes life easier.
> > 
> > Will remove that property from the model.
> > 
> > > 
> > > > 
> > > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Users can now specify a Icon Url to be rendered on the login page
> > > > > when
> > > > > social
> > > > > or any other identity provider is configured. So we just load the
> > > > > image
> > > > > the
> > > > > url entered by the user.
> > > > > 
> > > > > Are you saying that users should change the theme or customize css if
> > > > > they
> > > > > only want to change an icon for a provider ?
> > > > 
> > > > Yes, there's many issues with having a icon url:
> > > > 
> > > > * Won't work for internationalization - we don't have this now, but we
> > > > will
> > > > * Image is not a good button - CSS is much better
> > > > * Doesn't support themes - we allow users to switch l&f by switching
> > > > themes,
> > > > but that won't work for a icon url. In the future we may also support
> > > > multiple themes per-realm, for example to depending on the devices (one
> > > > theme for mobiles, one for desktops, etc)
> > > > * Requires the URL to be hosted somewhere - why require a separate call
> > > > to
> > > > download an image (to a separate server maybe) if it can simply be
> > > > defined
> > > > in a single CSS file?
> > > > 
> > > > Rather than add additional places to define look and feel components we
> > > > should in the future make it easier to add/customize themes.
> > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > All look and feel related things including images and stylesheets
> > > > > should
> > > > > be
> > > > > part of themes. This is to allow customizing them in the theme. Also,
> > > > > an
> > > > > image is not the correct way to render a button, it should be defined
> > > > > in
> > > > > CSS.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > You shouldn't have icon images for social providers. They should be
> > > > > > specified
> > > > > > as part of the theme in CSS as is now.
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > >     Anyone know where I can get the icons images for social
> > > > > > >     providers
> > > > > > >     ?
> > > > > > >     It
> > > > > > >     seems zocial defines them encoded in some way in CSS. I need
> > > > > > >     that
> > > > > > >     to
> > > > > > >     provide default images if user does not specify their own.
> > > > > > > 
> > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > 
> > > > > > > Regards.
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Hi guys,
> > > > > > > 
> > > > > > >    I've done some initial work covering both persistence and
> > > > > > >    brokering.
> > > > > > >    No
> > > > > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > > > > >    functionality
> > > > > > >    for now.
> > > > > > > 
> > > > > > >    What I have is enough to decide if we are aligned about this
> > > > > > >    functionality. So you can understand how the model (and
> > > > > > >    persistence),
> > > > > > >    rest api and brokering functionality looks like. Can we
> > > > > > >    schedule
> > > > > > >    a
> > > > > > >    meeting ?
> > > > > > > 
> > > > > > >    Btw, my branch is here [1].
> > > > > > > 
> > > > > > > [1]
> > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > 
> > > > > > > Regards.
> > > > > > > Pedro Igor
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Currently adapters can only make authz decisions (@RolesAllowed)
> > > > > > > based
> > > > > > > on either realm roles or the roles of one specific application.
> > > > > > > This
> > > > > > > is
> > > > > > > related to 1) too.
> > > > > > > 
> > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > > >
> > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > >> I just wanted to quickly list the additional work we discussed
> > > > > > > >> so
> > > > > > > >> everyone
> > > > > > > >> can think about it (in no particular order):
> > > > > > > >>
> > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an
> > > > > > > >> external
> > > > > > > >> token
> > > > > > > >> to
> > > > > > > >> a KC token? For example an external token with attribute
> > > > > > > >> 'group'
> > > > > > > >> that
> > > > > > > >> contains 'sales' and 'manager' could be mapped to 'manager'
> > > > > > > >> role
> > > > > > > >> for
> > > > > > > >> 'sales app in a KC token. Could we use Drools? This could also
> > > > > > > >> be
> > > > > > > >> used
> > > > > > > >> in
> > > > > > > >> user federation to allow more complex mapping of roles/groups
> > > > > > > >> than
> > > > > > > >> a
> > > > > > > >> simple 1-1
> > > > > > > >> 2) Retrieving tokens - if an application wants to retrieve the
> > > > > > > >> external
> > > > > > > >> token (for example to view Facebook friends if user logged in
> > > > > > > >> with
> > > > > > > >> Facebook)
> > > > > > > >> 3) Configure scope - currently for social we only request a
> > > > > > > >> very
> > > > > > > >> limited
> > > > > > > >> scope (basic profile and email), to for example view Facebook
> > > > > > > >> friends
> > > > > > > >> we'd need to ask for that as well
> > > > > > > >> 4) Selecting provider - currently in social (and for first
> > > > > > > >> pass
> > > > > > > >> of
> > > > > > > >> brokering) we have an icon user has to select, but can we
> > > > > > > >> select
> > > > > > > >> the
> > > > > > > >> provider in a different way (for example ask user for email,
> > > > > > > >> and
> > > > > > > >> select
> > > > > > > >> based on email domain)
> > > > > > > >> 5) Gateway - don't create a KC token, but just forward the
> > > > > > > >> external
> > > > > > > >> token
> > > > > > > >>
> > > > > > > >> IMO 1) is a killer feature, as it would allow companies to add
> > > > > > > >> external
> > > > > > > >> users without having to modify their applications. Issue with
> > > > > > > >> 5)
> > > > > > > >> is
> > > > > > > >> that
> > > > > > > >> applications need to understand more than one token, which
> > > > > > > >> would
> > > > > > > >> require
> > > > > > > >> rewriting applications.
> > > > > > > >>
> > > > > > > >> This work is also somewhat related to other authentication
> > > > > > > >> mechanisms
> > > > > > > >> (for
> > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > >>
> > > > > > > >> ----- Original Message -----
> > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > >>> Authentication
> > > > > > > >>> Broker
> > > > > > > >>>
> > > > > > > >>> ----- Original Message -----
> > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > >>>> Authentication
> > > > > > > >>>> Broker
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > >>>>> Hi,
> > > > > > > >>>>>
> > > > > > > >>>>>        Would like to start a discussion about how to enable
> > > > > > > >>>>>        KC
> > > > > > > >>>>>        as
> > > > > > > >>>>>        an
> > > > > > > >>>>>        Authentication Broker in order to supported Chained
> > > > > > > >>>>>        Federation
> > > > > > > >>>>>        and
> > > > > > > >>>>>        also Identity Federation. First of all, some
> > > > > > > >>>>>        background
> > > > > > > >>>>>        about
> > > > > > > >>>>>        what
> > > > > > > >>>>>        this is all about.
> > > > > > > >>>>>
> > > > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > > > >>>>>        authentication
> > > > > > > >>>>>        (correct
> > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > >>>>>
> > > > > > > >>>>>            1) Local authentication (based on some
> > > > > > > >>>>>            credential
> > > > > > > >>>>>            type
> > > > > > > >>>>>            enabled
> > > > > > > >>>>>            to
> > > > > > > >>>>>            a realm)
> > > > > > > >>>>>            2) Social authentication
> > > > > > > >>>>>
> > > > > > > >>>>>        Local authentication is about authenticating the
> > > > > > > >>>>>        user
> > > > > > > >>>>>        locally
> > > > > > > >>>>>        using
> > > > > > > >>>>>        KC's own identity store. Nothing special here. And
> > > > > > > >>>>>        Social
> > > > > > > >>>>>        Authentication which allows users to choose the
> > > > > > > >>>>>        Social
> > > > > > > >>>>>        IdP
> > > > > > > >>>>>        they
> > > > > > > >>>>>        want
> > > > > > > >>>>>        to authenticate with. In this case, the IdP is
> > > > > > > >>>>>        always
> > > > > > > >>>>>        one
> > > > > > > >>>>>        of
> > > > > > > >>>>>        the
> > > > > > > >>>>>        built-in social providers supported by KC such as
> > > > > > > >>>>>        Facebook,
> > > > > > > >>>>>        Google,
> > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > >>>>>
> > > > > > > >>>>>        When doing social, the user is automatically
> > > > > > > >>>>>        provisioned
> > > > > > > >>>>>        in
> > > > > > > >>>>>        KC
> > > > > > > >>>>>        identity store after a successful authentication.
> > > > > > > >>>>>        The
> > > > > > > >>>>>        user
> > > > > > > >>>>>        does
> > > > > > > >>>>>        not
> > > > > > > >>>>>        need to fill a registration form and can access the
> > > > > > > >>>>>        application
> > > > > > > >>>>>        very
> > > > > > > >>>>>        quickly. During the provisioning some basic
> > > > > > > >>>>>        information
> > > > > > > >>>>>        is
> > > > > > > >>>>>        retrieved
> > > > > > > >>>>>        from the social provider such as email, firstname
> > > > > > > >>>>>        and
> > > > > > > >>>>>        so
> > > > > > > >>>>>        forth.
> > > > > > > >>>>>        These
> > > > > > > >>>>>        are very basic information, any other information
> > > > > > > >>>>>        such
> > > > > > > >>>>>        as
> > > > > > > >>>>>        those
> > > > > > > >>>>>        related with authorization policies - eg.: roles and
> > > > > > > >>>>>        groups
> > > > > > > >>>>>        -
> > > > > > > >>>>>        must
> > > > > > > >>>>>        be
> > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > >>>>>
> > > > > > > >>>>>        Another important characteristic of social
> > > > > > > >>>>>        authentication
> > > > > > > >>>>>        is
> > > > > > > >>>>>        that
> > > > > > > >>>>>        the
> > > > > > > >>>>>        application receives a KC token and not the token
> > > > > > > >>>>>        that
> > > > > > > >>>>>        was
> > > > > > > >>>>>        issued by
> > > > > > > >>>>>        the social IdP during the authentication process. If
> > > > > > > >>>>>        the
> > > > > > > >>>>>        application
> > > > > > > >>>>>        wants to consume resources from the resource
> > > > > > > >>>>>        provider
> > > > > > > >>>>>        he
> > > > > > > >>>>>        was
> > > > > > > >>>>>        authenticated it must obtain the access token(again)
> > > > > > > >>>>>        by
> > > > > > > >>>>>        itself
> > > > > > > >>>>>        prior
> > > > > > > >>>>>        to invoke the resource provider API. Assuming all
> > > > > > > >>>>>        those
> > > > > > > >>>>>        social
> > > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > > >>>>>
> > > > > > > >>>>>        That said, the Authentication Broker functionality
> > > > > > > >>>>>        aims
> > > > > > > >>>>>        to
> > > > > > > >>>>>        cover
> > > > > > > >>>>>        the
> > > > > > > >>>>>        same use cases but with a lot of more flexibility on
> > > > > > > >>>>>        how
> > > > > > > >>>>>        you
> > > > > > > >>>>>        setup
> > > > > > > >>>>>        identity providers(not only social ones) and the
> > > > > > > >>>>>        different
> > > > > > > >>>>>        federation
> > > > > > > >>>>>        protocols they may support such as SAML, OpenID,
> > > > > > > >>>>>        oAuth
> > > > > > > >>>>>        and
> > > > > > > >>>>>        so
> > > > > > > >>>>>        forth.
> > > > > > > >>>>>        This is useful when an enterprise is providing
> > > > > > > >>>>>        services
> > > > > > > >>>>>        to
> > > > > > > >>>>>        different
> > > > > > > >>>>>        customers(IdP) and does not want to manage many to
> > > > > > > >>>>>        many
> > > > > > > >>>>>        relationships. When using a broker, the
> > > > > > > >>>>>        authentication
> > > > > > > >>>>>        steps
> > > > > > > >>>>>        are
> > > > > > > >>>>>        pretty much the same when you are using social
> > > > > > > >>>>>        authentication,
> > > > > > > >>>>>        with
> > > > > > > >>>>>        important differences on how you support different
> > > > > > > >>>>>        identity
> > > > > > > >>>>>        providers, different federation protocols, how users
> > > > > > > >>>>>        are
> > > > > > > >>>>>        provisioned
> > > > > > > >>>>>        and how claims and attributes are resolved.
> > > > > > > >>>>>
> > > > > > > >>>>>        The brokering functionality can be done in two ways
> > > > > > > >>>>>        depending
> > > > > > > >>>>>        if
> > > > > > > >>>>>        the
> > > > > > > >>>>>        broker service is acting as a gateway or not. When
> > > > > > > >>>>>        acting
> > > > > > > >>>>>        as
> > > > > > > >>>>>        a
> > > > > > > >>>>>        gateway, the broker will respond to the application
> > > > > > > >>>>>        the
> > > > > > > >>>>>        same
> > > > > > > >>>>>        token
> > > > > > > >>>>>        issued by the trusted identity provider. For
> > > > > > > >>>>>        instance,
> > > > > > > >>>>>        if
> > > > > > > >>>>>        the
> > > > > > > >>>>>        user
> > > > > > > >>>>>        selects a SAML IdP to authenticate with, the
> > > > > > > >>>>>        application
> > > > > > > >>>>>        will
> > > > > > > >>>>>        receive
> > > > > > > >>>>>        a SAML Response. In this case, the application must
> > > > > > > >>>>>        also
> > > > > > > >>>>>        be
> > > > > > > >>>>>        prepared
> > > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > > >>>>>
> > > > > > > >>>>>        However, the broker service can also be used to
> > > > > > > >>>>>        completely
> > > > > > > >>>>>        abstract
> > > > > > > >>>>>        from the application the protocol used to
> > > > > > > >>>>>        authenticate
> > > > > > > >>>>>        an
> > > > > > > >>>>>        user.
> > > > > > > >>>>>        In
> > > > > > > >>>>>        this case, the application will just receive an
> > > > > > > >>>>>        ordinary
> > > > > > > >>>>>        KC
> > > > > > > >>>>>        token
> > > > > > > >>>>>        after a successful authentication.
> > > > > > > >>>>>
> > > > > > > >>>>>        In both cases, the broker acts as an intermediary
> > > > > > > >>>>>        where
> > > > > > > >>>>>        specific
> > > > > > > >>>>>        security policies can be applied when users try to
> > > > > > > >>>>>        authenticate
> > > > > > > >>>>>        themselves against a 3rd party IdP. That brings a
> > > > > > > >>>>>        lot
> > > > > > > >>>>>        of
> > > > > > > >>>>>        value
> > > > > > > >>>>>        when
> > > > > > > >>>>>        you think about auditing, authorization and how
> > > > > > > >>>>>        users
> > > > > > > >>>>>        are
> > > > > > > >>>>>        provisioned
> > > > > > > >>>>>        when federation of identities is needed. This also
> > > > > > > >>>>>        allows
> > > > > > > >>>>>        existing
> > > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > > >>>>>        infrastructures)
> > > > > > > >>>>>        to
> > > > > > > >>>>>        benefit
> > > > > > > >>>>>        from KC's support for cloud, rest and mobile use
> > > > > > > >>>>>        cases.
> > > > > > > >>>>>
> > > > > > > >>>>>        I think this is enough to start a discussion. I've
> > > > > > > >>>>>        an
> > > > > > > >>>>>        initial
> > > > > > > >>>>>        discussion with Stian about all that and we agreed
> > > > > > > >>>>>        that
> > > > > > > >>>>>        abstract
> > > > > > > >>>>>        the
> > > > > > > >>>>>        protocol from applications should be prioritized.
> > > > > > > >>>>>        The
> > > > > > > >>>>>        main
> > > > > > > >>>>>        reason is
> > > > > > > >>>>>        that it makes life easier for applications so they
> > > > > > > >>>>>        only
> > > > > > > >>>>>        need
> > > > > > > >>>>>        to
> > > > > > > >>>>>        know
> > > > > > > >>>>>        about KC tokens and nothing else. However that
> > > > > > > >>>>>        brings
> > > > > > > >>>>>        some
> > > > > > > >>>>>        new
> > > > > > > >>>>>        requirements around user provisioning and
> > > > > > > >>>>>        claim/attribute
> > > > > > > >>>>>        resolution
> > > > > > > >>>>>        or mapping. But that would be another thread.
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > > >>>> applications"?
> > > > > > > >>>> Not
> > > > > > > >>>> sure what you mean by that.  IDP federation should be
> > > > > > > >>>> configured
> > > > > > > >>>> at
> > > > > > > >>>> the
> > > > > > > >>>> realm level and really has nothing to do with applications.
> > > > > > > >>>>
> > > > > > > >>>> I'm really happy that somebody is doing this.  We're getting
> > > > > > > >>>> a
> > > > > > > >>>> real
> > > > > > > >>>> impressive feature set!
> > > > > > > >>>
> > > > > > > >>> Sure. What I meant was that the application only knows about
> > > > > > > >>> KC
> > > > > > > >>> tokens
> > > > > > > >>> nothing else. It will always receive a KC token regardless
> > > > > > > >>> the
> > > > > > > >>> protocol
> > > > > > > >>> used
> > > > > > > >>> to authenticate the user against a 3rd party IdP (saml, oidc,
> > > > > > > >>> whatever).
> > > > > > > >>> The
> > > > > > > >>> example I gave was about an user trying to authenticate
> > > > > > > >>> against
> > > > > > > >>> a
> > > > > > > >>> SAML
> > > > > > > >>> IdP.
> > > > > > > >>> In this case, after a successful authentication on the IdP,
> > > > > > > >>> the
> > > > > > > >>> IdP
> > > > > > > >>> will
> > > > > > > >>> issue a token to KC. Then KC will validate the token, perform
> > > > > > > >>> trust
> > > > > > > >>> and
> > > > > > > >>> security checks, do user provisioning and attribute/claim
> > > > > > > >>> resolution
> > > > > > > >>> to
> > > > > > > >>> finally issue a KC token and redirect the user to the
> > > > > > > >>> application.
> > > > > > > >>> If
> > > > > > > >>> the
> > > > > > > >>> app is configured to use openid in KC then it will receive a
> > > > > > > >>> openid
> > > > > > > >>> token
> > > > > > > >>> from KC, not saml ...
> > > > > > > >>>
> > > > > > > >>> The other scenario is pretty much the same. The difference is
> > > > > > > >>> that
> > > > > > > >>> KC
> > > > > > > >>> will
> > > > > > > >>> not issue its own token but just replay the token issued by
> > > > > > > >>> the
> > > > > > > >>> 3rd
> > > > > > > >>> party
> > > > > > > >>> IdP to the service provider.
> > > > > > > >>>
> > > > > > > >>> I agree that this config goes at the realm level. For
> > > > > > > >>> instance,
> > > > > > > >>> to
> > > > > > > >>> create
> > > > > > > >>> and
> > > > > > > >>> enable providers for being used. However, I think we would
> > > > > > > >>> need
> > > > > > > >>> some
> > > > > > > >>> specific configuration for applications as well. Specially
> > > > > > > >>> when
> > > > > > > >>> defining
> > > > > > > >>> default roles, mapping attributes. Another example of
> > > > > > > >>> application
> > > > > > > >>> config
> > > > > > > >>> is
> > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > > > > > > >>> per-application.
> > > > > > > >>>
> > > > > > > >>>>
> > > > > > > >>>> --
> > > > > > > >>>> Bill Burke
> > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > >>>> _______________________________________________
> > > > > > > >>>> keycloak-dev mailing list
> > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > >>>>
> > > > > > > >>> _______________________________________________
> > > > > > > >>> 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
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > keycloak-dev mailing list
> > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > keycloak-dev mailing list
> > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > 
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > 
> > > > 
> > > 
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 


From psilva at redhat.com  Fri Dec  5 07:45:24 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 Dec 2014 07:45:24 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
Message-ID: <498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, December 5, 2014 10:22:10 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Looks good. I reckon we can combine the two pages. What about if the 'Add
> provider' drop-down is:
> 
>   OpenID
>   SAML
>   ------
>   Google
>   GitHub
>   Facebook
>   Twitter
> 
> Let's drop social on/off and instead have a enable/disable button on each
> provider.

Sure.

> 
> Also, would be nice if users could set a name or alias for a provider
> instance. This would make the callback url easier to use (instead of
> callback/<UUID> it's callback/<alias>). The user federation providers have
> this.

One of my first tries was using an alias, just like that. But I preferred using the UUID and make the configuration more easier. Beside that, the callback url is just a copy and paste, so I think an alias would not bring so much usability, but add one more step when configuring providers.

However, if this is an usability requirement for KC I can change that.

> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 5 December, 2014 1:08:53 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > In one of our last discussions, you suggested to leave Social as it is.
> > Although IMO I think we can have a single place to manage both social and
> > user-defined identity providers. Social ones are just OOTB and
> > pre-configured identity providers now.
> > 
> > That said, today I'm using separated tabs for social and user-defined.
> > Please, take a look at [1] for more details on how the UI looks like.
> > 
> > I've changed social UI a bit in order to provide a specific page for
> > create/update. I've also added a "Show Secret" link to display the
> > client_secret in clear text if user wants to.
> > 
> > Beside the enable/disable button, I think another good thing to do is
> > specify
> > a default role(s) for each provider. That can be useful if applications
> > want
> > to perform any kind of authorization based on the identity provider or
> > authentication method used to authenticate an user (eg.: useful for
> > adaptative or multi-level access control). We can also use the "amr" claim
> > in the ID Token, which seems KC is not considering at all. The latter is an
> > important thing to think of, regardless this broker work I'm doing.
> > 
> > [1]
> > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > 
> > ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, December 5, 2014 6:15:15 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Having a separate enable/disable for each provider would be good. If you're
> > leaving the social tab as is and adding a separate tab for configuring
> > brokered idp's then we should leave the social enable/disable button,
> > otherwise it depends how it'll look like in the end.
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Hi,
> > > 
> > >    Social has a button to enable/disable it. I'm wondering what to do
> > >    with
> > >    the brokered identity providers. Shall we add a similar flag for that
> > >    ?
> > > 
> > >    I was also wondering if the best would be a flag in a per provider
> > >    basis.
> > >    So we can disable/enable a specific provider (social or brokered),
> > >    instead of doing that for all.
> > > 
> > > Regards.
> > > Pedro Igor
> > > 
> > > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > I'll go for it then. Will remove the icon url from the model and
> > > > > leave
> > > > > that
> > > > > for users if they want to provide icons for their identity providers.
> > > > > 
> > > > > My point is that icons can be usually served by the same
> > > > > server/application
> > > > > or proxy, so download images are not such a big deal. Also, the icon
> > > > > url
> > > > > is
> > > > > part of the freemarker model and people can do what ever they want
> > > > > with
> > > > > it.
> > > > > What I think will also help in your future plans.
> > > > 
> > > > I'm not following. Are you saying that if a named image
> > > > 'my-provider.png'
> > > > is
> > > > loaded from a theme, then you can override it in another theme?
> > > > 
> > > > If so, that's basically the same as having a css class 'my-provider' in
> > > > a
> > > > theme. With the exception that with an image you end up with having to
> > > > require a image per provider per theme per language, which could be a
> > > > lot
> > > > of
> > > > images for a single provider. Also, buttons for accessibility should be
> > > > defined with text and css, not images that can't be interpreted. You
> > > > also
> > > > still need to modify the theme, so I don't see any benefits.
> > > 
> > > You are right. Having a icon url per provider does not makes sense if
> > > there
> > > are requirements to change images accordingly to a theme or language. CSS
> > > makes life easier.
> > > 
> > > Will remove that property from the model.
> > > 
> > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Users can now specify a Icon Url to be rendered on the login page
> > > > > > when
> > > > > > social
> > > > > > or any other identity provider is configured. So we just load the
> > > > > > image
> > > > > > the
> > > > > > url entered by the user.
> > > > > > 
> > > > > > Are you saying that users should change the theme or customize css
> > > > > > if
> > > > > > they
> > > > > > only want to change an icon for a provider ?
> > > > > 
> > > > > Yes, there's many issues with having a icon url:
> > > > > 
> > > > > * Won't work for internationalization - we don't have this now, but
> > > > > we
> > > > > will
> > > > > * Image is not a good button - CSS is much better
> > > > > * Doesn't support themes - we allow users to switch l&f by switching
> > > > > themes,
> > > > > but that won't work for a icon url. In the future we may also support
> > > > > multiple themes per-realm, for example to depending on the devices
> > > > > (one
> > > > > theme for mobiles, one for desktops, etc)
> > > > > * Requires the URL to be hosted somewhere - why require a separate
> > > > > call
> > > > > to
> > > > > download an image (to a separate server maybe) if it can simply be
> > > > > defined
> > > > > in a single CSS file?
> > > > > 
> > > > > Rather than add additional places to define look and feel components
> > > > > we
> > > > > should in the future make it easier to add/customize themes.
> > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > All look and feel related things including images and stylesheets
> > > > > > should
> > > > > > be
> > > > > > part of themes. This is to allow customizing them in the theme.
> > > > > > Also,
> > > > > > an
> > > > > > image is not the correct way to render a button, it should be
> > > > > > defined
> > > > > > in
> > > > > > CSS.
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > You shouldn't have icon images for social providers. They should
> > > > > > > be
> > > > > > > specified
> > > > > > > as part of the theme in CSS as is now.
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > >     Anyone know where I can get the icons images for social
> > > > > > > >     providers
> > > > > > > >     ?
> > > > > > > >     It
> > > > > > > >     seems zocial defines them encoded in some way in CSS. I
> > > > > > > >     need
> > > > > > > >     that
> > > > > > > >     to
> > > > > > > >     provide default images if user does not specify their own.
> > > > > > > > 
> > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > 
> > > > > > > > Regards.
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > Hi guys,
> > > > > > > > 
> > > > > > > >    I've done some initial work covering both persistence and
> > > > > > > >    brokering.
> > > > > > > >    No
> > > > > > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > > > > > >    functionality
> > > > > > > >    for now.
> > > > > > > > 
> > > > > > > >    What I have is enough to decide if we are aligned about this
> > > > > > > >    functionality. So you can understand how the model (and
> > > > > > > >    persistence),
> > > > > > > >    rest api and brokering functionality looks like. Can we
> > > > > > > >    schedule
> > > > > > > >    a
> > > > > > > >    meeting ?
> > > > > > > > 
> > > > > > > >    Btw, my branch is here [1].
> > > > > > > > 
> > > > > > > > [1]
> > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > 
> > > > > > > > Regards.
> > > > > > > > Pedro Igor
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > (@RolesAllowed)
> > > > > > > > based
> > > > > > > > on either realm roles or the roles of one specific application.
> > > > > > > > This
> > > > > > > > is
> > > > > > > > related to 1) too.
> > > > > > > > 
> > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > > > >
> > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > >> I just wanted to quickly list the additional work we
> > > > > > > > >> discussed
> > > > > > > > >> so
> > > > > > > > >> everyone
> > > > > > > > >> can think about it (in no particular order):
> > > > > > > > >>
> > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an
> > > > > > > > >> external
> > > > > > > > >> token
> > > > > > > > >> to
> > > > > > > > >> a KC token? For example an external token with attribute
> > > > > > > > >> 'group'
> > > > > > > > >> that
> > > > > > > > >> contains 'sales' and 'manager' could be mapped to 'manager'
> > > > > > > > >> role
> > > > > > > > >> for
> > > > > > > > >> 'sales app in a KC token. Could we use Drools? This could
> > > > > > > > >> also
> > > > > > > > >> be
> > > > > > > > >> used
> > > > > > > > >> in
> > > > > > > > >> user federation to allow more complex mapping of
> > > > > > > > >> roles/groups
> > > > > > > > >> than
> > > > > > > > >> a
> > > > > > > > >> simple 1-1
> > > > > > > > >> 2) Retrieving tokens - if an application wants to retrieve
> > > > > > > > >> the
> > > > > > > > >> external
> > > > > > > > >> token (for example to view Facebook friends if user logged
> > > > > > > > >> in
> > > > > > > > >> with
> > > > > > > > >> Facebook)
> > > > > > > > >> 3) Configure scope - currently for social we only request a
> > > > > > > > >> very
> > > > > > > > >> limited
> > > > > > > > >> scope (basic profile and email), to for example view
> > > > > > > > >> Facebook
> > > > > > > > >> friends
> > > > > > > > >> we'd need to ask for that as well
> > > > > > > > >> 4) Selecting provider - currently in social (and for first
> > > > > > > > >> pass
> > > > > > > > >> of
> > > > > > > > >> brokering) we have an icon user has to select, but can we
> > > > > > > > >> select
> > > > > > > > >> the
> > > > > > > > >> provider in a different way (for example ask user for email,
> > > > > > > > >> and
> > > > > > > > >> select
> > > > > > > > >> based on email domain)
> > > > > > > > >> 5) Gateway - don't create a KC token, but just forward the
> > > > > > > > >> external
> > > > > > > > >> token
> > > > > > > > >>
> > > > > > > > >> IMO 1) is a killer feature, as it would allow companies to
> > > > > > > > >> add
> > > > > > > > >> external
> > > > > > > > >> users without having to modify their applications. Issue
> > > > > > > > >> with
> > > > > > > > >> 5)
> > > > > > > > >> is
> > > > > > > > >> that
> > > > > > > > >> applications need to understand more than one token, which
> > > > > > > > >> would
> > > > > > > > >> require
> > > > > > > > >> rewriting applications.
> > > > > > > > >>
> > > > > > > > >> This work is also somewhat related to other authentication
> > > > > > > > >> mechanisms
> > > > > > > > >> (for
> > > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > > >>
> > > > > > > > >> ----- Original Message -----
> > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > >>> Authentication
> > > > > > > > >>> Broker
> > > > > > > > >>>
> > > > > > > > >>> ----- Original Message -----
> > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > >>>> Authentication
> > > > > > > > >>>> Broker
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > > >>>>> Hi,
> > > > > > > > >>>>>
> > > > > > > > >>>>>        Would like to start a discussion about how to
> > > > > > > > >>>>>        enable
> > > > > > > > >>>>>        KC
> > > > > > > > >>>>>        as
> > > > > > > > >>>>>        an
> > > > > > > > >>>>>        Authentication Broker in order to supported
> > > > > > > > >>>>>        Chained
> > > > > > > > >>>>>        Federation
> > > > > > > > >>>>>        and
> > > > > > > > >>>>>        also Identity Federation. First of all, some
> > > > > > > > >>>>>        background
> > > > > > > > >>>>>        about
> > > > > > > > >>>>>        what
> > > > > > > > >>>>>        this is all about.
> > > > > > > > >>>>>
> > > > > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > > > > >>>>>        authentication
> > > > > > > > >>>>>        (correct
> > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > >>>>>
> > > > > > > > >>>>>            1) Local authentication (based on some
> > > > > > > > >>>>>            credential
> > > > > > > > >>>>>            type
> > > > > > > > >>>>>            enabled
> > > > > > > > >>>>>            to
> > > > > > > > >>>>>            a realm)
> > > > > > > > >>>>>            2) Social authentication
> > > > > > > > >>>>>
> > > > > > > > >>>>>        Local authentication is about authenticating the
> > > > > > > > >>>>>        user
> > > > > > > > >>>>>        locally
> > > > > > > > >>>>>        using
> > > > > > > > >>>>>        KC's own identity store. Nothing special here. And
> > > > > > > > >>>>>        Social
> > > > > > > > >>>>>        Authentication which allows users to choose the
> > > > > > > > >>>>>        Social
> > > > > > > > >>>>>        IdP
> > > > > > > > >>>>>        they
> > > > > > > > >>>>>        want
> > > > > > > > >>>>>        to authenticate with. In this case, the IdP is
> > > > > > > > >>>>>        always
> > > > > > > > >>>>>        one
> > > > > > > > >>>>>        of
> > > > > > > > >>>>>        the
> > > > > > > > >>>>>        built-in social providers supported by KC such as
> > > > > > > > >>>>>        Facebook,
> > > > > > > > >>>>>        Google,
> > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > >>>>>
> > > > > > > > >>>>>        When doing social, the user is automatically
> > > > > > > > >>>>>        provisioned
> > > > > > > > >>>>>        in
> > > > > > > > >>>>>        KC
> > > > > > > > >>>>>        identity store after a successful authentication.
> > > > > > > > >>>>>        The
> > > > > > > > >>>>>        user
> > > > > > > > >>>>>        does
> > > > > > > > >>>>>        not
> > > > > > > > >>>>>        need to fill a registration form and can access
> > > > > > > > >>>>>        the
> > > > > > > > >>>>>        application
> > > > > > > > >>>>>        very
> > > > > > > > >>>>>        quickly. During the provisioning some basic
> > > > > > > > >>>>>        information
> > > > > > > > >>>>>        is
> > > > > > > > >>>>>        retrieved
> > > > > > > > >>>>>        from the social provider such as email, firstname
> > > > > > > > >>>>>        and
> > > > > > > > >>>>>        so
> > > > > > > > >>>>>        forth.
> > > > > > > > >>>>>        These
> > > > > > > > >>>>>        are very basic information, any other information
> > > > > > > > >>>>>        such
> > > > > > > > >>>>>        as
> > > > > > > > >>>>>        those
> > > > > > > > >>>>>        related with authorization policies - eg.: roles
> > > > > > > > >>>>>        and
> > > > > > > > >>>>>        groups
> > > > > > > > >>>>>        -
> > > > > > > > >>>>>        must
> > > > > > > > >>>>>        be
> > > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > > >>>>>
> > > > > > > > >>>>>        Another important characteristic of social
> > > > > > > > >>>>>        authentication
> > > > > > > > >>>>>        is
> > > > > > > > >>>>>        that
> > > > > > > > >>>>>        the
> > > > > > > > >>>>>        application receives a KC token and not the token
> > > > > > > > >>>>>        that
> > > > > > > > >>>>>        was
> > > > > > > > >>>>>        issued by
> > > > > > > > >>>>>        the social IdP during the authentication process.
> > > > > > > > >>>>>        If
> > > > > > > > >>>>>        the
> > > > > > > > >>>>>        application
> > > > > > > > >>>>>        wants to consume resources from the resource
> > > > > > > > >>>>>        provider
> > > > > > > > >>>>>        he
> > > > > > > > >>>>>        was
> > > > > > > > >>>>>        authenticated it must obtain the access
> > > > > > > > >>>>>        token(again)
> > > > > > > > >>>>>        by
> > > > > > > > >>>>>        itself
> > > > > > > > >>>>>        prior
> > > > > > > > >>>>>        to invoke the resource provider API. Assuming all
> > > > > > > > >>>>>        those
> > > > > > > > >>>>>        social
> > > > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > > > >>>>>
> > > > > > > > >>>>>        That said, the Authentication Broker functionality
> > > > > > > > >>>>>        aims
> > > > > > > > >>>>>        to
> > > > > > > > >>>>>        cover
> > > > > > > > >>>>>        the
> > > > > > > > >>>>>        same use cases but with a lot of more flexibility
> > > > > > > > >>>>>        on
> > > > > > > > >>>>>        how
> > > > > > > > >>>>>        you
> > > > > > > > >>>>>        setup
> > > > > > > > >>>>>        identity providers(not only social ones) and the
> > > > > > > > >>>>>        different
> > > > > > > > >>>>>        federation
> > > > > > > > >>>>>        protocols they may support such as SAML, OpenID,
> > > > > > > > >>>>>        oAuth
> > > > > > > > >>>>>        and
> > > > > > > > >>>>>        so
> > > > > > > > >>>>>        forth.
> > > > > > > > >>>>>        This is useful when an enterprise is providing
> > > > > > > > >>>>>        services
> > > > > > > > >>>>>        to
> > > > > > > > >>>>>        different
> > > > > > > > >>>>>        customers(IdP) and does not want to manage many to
> > > > > > > > >>>>>        many
> > > > > > > > >>>>>        relationships. When using a broker, the
> > > > > > > > >>>>>        authentication
> > > > > > > > >>>>>        steps
> > > > > > > > >>>>>        are
> > > > > > > > >>>>>        pretty much the same when you are using social
> > > > > > > > >>>>>        authentication,
> > > > > > > > >>>>>        with
> > > > > > > > >>>>>        important differences on how you support different
> > > > > > > > >>>>>        identity
> > > > > > > > >>>>>        providers, different federation protocols, how
> > > > > > > > >>>>>        users
> > > > > > > > >>>>>        are
> > > > > > > > >>>>>        provisioned
> > > > > > > > >>>>>        and how claims and attributes are resolved.
> > > > > > > > >>>>>
> > > > > > > > >>>>>        The brokering functionality can be done in two
> > > > > > > > >>>>>        ways
> > > > > > > > >>>>>        depending
> > > > > > > > >>>>>        if
> > > > > > > > >>>>>        the
> > > > > > > > >>>>>        broker service is acting as a gateway or not. When
> > > > > > > > >>>>>        acting
> > > > > > > > >>>>>        as
> > > > > > > > >>>>>        a
> > > > > > > > >>>>>        gateway, the broker will respond to the
> > > > > > > > >>>>>        application
> > > > > > > > >>>>>        the
> > > > > > > > >>>>>        same
> > > > > > > > >>>>>        token
> > > > > > > > >>>>>        issued by the trusted identity provider. For
> > > > > > > > >>>>>        instance,
> > > > > > > > >>>>>        if
> > > > > > > > >>>>>        the
> > > > > > > > >>>>>        user
> > > > > > > > >>>>>        selects a SAML IdP to authenticate with, the
> > > > > > > > >>>>>        application
> > > > > > > > >>>>>        will
> > > > > > > > >>>>>        receive
> > > > > > > > >>>>>        a SAML Response. In this case, the application
> > > > > > > > >>>>>        must
> > > > > > > > >>>>>        also
> > > > > > > > >>>>>        be
> > > > > > > > >>>>>        prepared
> > > > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > > > >>>>>
> > > > > > > > >>>>>        However, the broker service can also be used to
> > > > > > > > >>>>>        completely
> > > > > > > > >>>>>        abstract
> > > > > > > > >>>>>        from the application the protocol used to
> > > > > > > > >>>>>        authenticate
> > > > > > > > >>>>>        an
> > > > > > > > >>>>>        user.
> > > > > > > > >>>>>        In
> > > > > > > > >>>>>        this case, the application will just receive an
> > > > > > > > >>>>>        ordinary
> > > > > > > > >>>>>        KC
> > > > > > > > >>>>>        token
> > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > >>>>>
> > > > > > > > >>>>>        In both cases, the broker acts as an intermediary
> > > > > > > > >>>>>        where
> > > > > > > > >>>>>        specific
> > > > > > > > >>>>>        security policies can be applied when users try to
> > > > > > > > >>>>>        authenticate
> > > > > > > > >>>>>        themselves against a 3rd party IdP. That brings a
> > > > > > > > >>>>>        lot
> > > > > > > > >>>>>        of
> > > > > > > > >>>>>        value
> > > > > > > > >>>>>        when
> > > > > > > > >>>>>        you think about auditing, authorization and how
> > > > > > > > >>>>>        users
> > > > > > > > >>>>>        are
> > > > > > > > >>>>>        provisioned
> > > > > > > > >>>>>        when federation of identities is needed. This also
> > > > > > > > >>>>>        allows
> > > > > > > > >>>>>        existing
> > > > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > > > >>>>>        infrastructures)
> > > > > > > > >>>>>        to
> > > > > > > > >>>>>        benefit
> > > > > > > > >>>>>        from KC's support for cloud, rest and mobile use
> > > > > > > > >>>>>        cases.
> > > > > > > > >>>>>
> > > > > > > > >>>>>        I think this is enough to start a discussion. I've
> > > > > > > > >>>>>        an
> > > > > > > > >>>>>        initial
> > > > > > > > >>>>>        discussion with Stian about all that and we agreed
> > > > > > > > >>>>>        that
> > > > > > > > >>>>>        abstract
> > > > > > > > >>>>>        the
> > > > > > > > >>>>>        protocol from applications should be prioritized.
> > > > > > > > >>>>>        The
> > > > > > > > >>>>>        main
> > > > > > > > >>>>>        reason is
> > > > > > > > >>>>>        that it makes life easier for applications so they
> > > > > > > > >>>>>        only
> > > > > > > > >>>>>        need
> > > > > > > > >>>>>        to
> > > > > > > > >>>>>        know
> > > > > > > > >>>>>        about KC tokens and nothing else. However that
> > > > > > > > >>>>>        brings
> > > > > > > > >>>>>        some
> > > > > > > > >>>>>        new
> > > > > > > > >>>>>        requirements around user provisioning and
> > > > > > > > >>>>>        claim/attribute
> > > > > > > > >>>>>        resolution
> > > > > > > > >>>>>        or mapping. But that would be another thread.
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > > > >>>> applications"?
> > > > > > > > >>>> Not
> > > > > > > > >>>> sure what you mean by that.  IDP federation should be
> > > > > > > > >>>> configured
> > > > > > > > >>>> at
> > > > > > > > >>>> the
> > > > > > > > >>>> realm level and really has nothing to do with
> > > > > > > > >>>> applications.
> > > > > > > > >>>>
> > > > > > > > >>>> I'm really happy that somebody is doing this.  We're
> > > > > > > > >>>> getting
> > > > > > > > >>>> a
> > > > > > > > >>>> real
> > > > > > > > >>>> impressive feature set!
> > > > > > > > >>>
> > > > > > > > >>> Sure. What I meant was that the application only knows
> > > > > > > > >>> about
> > > > > > > > >>> KC
> > > > > > > > >>> tokens
> > > > > > > > >>> nothing else. It will always receive a KC token regardless
> > > > > > > > >>> the
> > > > > > > > >>> protocol
> > > > > > > > >>> used
> > > > > > > > >>> to authenticate the user against a 3rd party IdP (saml,
> > > > > > > > >>> oidc,
> > > > > > > > >>> whatever).
> > > > > > > > >>> The
> > > > > > > > >>> example I gave was about an user trying to authenticate
> > > > > > > > >>> against
> > > > > > > > >>> a
> > > > > > > > >>> SAML
> > > > > > > > >>> IdP.
> > > > > > > > >>> In this case, after a successful authentication on the IdP,
> > > > > > > > >>> the
> > > > > > > > >>> IdP
> > > > > > > > >>> will
> > > > > > > > >>> issue a token to KC. Then KC will validate the token,
> > > > > > > > >>> perform
> > > > > > > > >>> trust
> > > > > > > > >>> and
> > > > > > > > >>> security checks, do user provisioning and attribute/claim
> > > > > > > > >>> resolution
> > > > > > > > >>> to
> > > > > > > > >>> finally issue a KC token and redirect the user to the
> > > > > > > > >>> application.
> > > > > > > > >>> If
> > > > > > > > >>> the
> > > > > > > > >>> app is configured to use openid in KC then it will receive
> > > > > > > > >>> a
> > > > > > > > >>> openid
> > > > > > > > >>> token
> > > > > > > > >>> from KC, not saml ...
> > > > > > > > >>>
> > > > > > > > >>> The other scenario is pretty much the same. The difference
> > > > > > > > >>> is
> > > > > > > > >>> that
> > > > > > > > >>> KC
> > > > > > > > >>> will
> > > > > > > > >>> not issue its own token but just replay the token issued by
> > > > > > > > >>> the
> > > > > > > > >>> 3rd
> > > > > > > > >>> party
> > > > > > > > >>> IdP to the service provider.
> > > > > > > > >>>
> > > > > > > > >>> I agree that this config goes at the realm level. For
> > > > > > > > >>> instance,
> > > > > > > > >>> to
> > > > > > > > >>> create
> > > > > > > > >>> and
> > > > > > > > >>> enable providers for being used. However, I think we would
> > > > > > > > >>> need
> > > > > > > > >>> some
> > > > > > > > >>> specific configuration for applications as well. Specially
> > > > > > > > >>> when
> > > > > > > > >>> defining
> > > > > > > > >>> default roles, mapping attributes. Another example of
> > > > > > > > >>> application
> > > > > > > > >>> config
> > > > > > > > >>> is
> > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes
> > > > > > > > >>> per-application.
> > > > > > > > >>>
> > > > > > > > >>>>
> > > > > > > > >>>> --
> > > > > > > > >>>> Bill Burke
> > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > >>>> _______________________________________________
> > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > >>>>
> > > > > > > > >>> _______________________________________________
> > > > > > > > >>> 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
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-dev mailing list
> > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-dev mailing list
> > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > keycloak-dev mailing list
> > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > 
> > > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > 
> 


From stian at redhat.com  Fri Dec  5 07:55:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 07:55:32 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
Message-ID: <1861805773.11275595.1417784132116.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 1:45:24 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, December 5, 2014 10:22:10 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Looks good. I reckon we can combine the two pages. What about if the 'Add
> > provider' drop-down is:
> > 
> >   OpenID
> >   SAML
> >   ------
> >   Google
> >   GitHub
> >   Facebook
> >   Twitter
> > 
> > Let's drop social on/off and instead have a enable/disable button on each
> > provider.
> 
> Sure.
> 
> > 
> > Also, would be nice if users could set a name or alias for a provider
> > instance. This would make the callback url easier to use (instead of
> > callback/<UUID> it's callback/<alias>). The user federation providers have
> > this.
> 
> One of my first tries was using an alias, just like that. But I preferred
> using the UUID and make the configuration more easier. Beside that, the
> callback url is just a copy and paste, so I think an alias would not bring
> so much usability, but add one more step when configuring providers.
> 
> However, if this is an usability requirement for KC I can change that.

Please do. If it uses a UUID it also requires updating the provider if you have to re-create the provider for whatever reason. For example I've got keys I use for dev/testing and I've just set the callback to http://localhost:8080/auth/callback/google. As long as I can re-create the provider with the same alias I don't have to touch Google, but if it's a generated UUID I always have to.

> 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > In one of our last discussions, you suggested to leave Social as it is.
> > > Although IMO I think we can have a single place to manage both social and
> > > user-defined identity providers. Social ones are just OOTB and
> > > pre-configured identity providers now.
> > > 
> > > That said, today I'm using separated tabs for social and user-defined.
> > > Please, take a look at [1] for more details on how the UI looks like.
> > > 
> > > I've changed social UI a bit in order to provide a specific page for
> > > create/update. I've also added a "Show Secret" link to display the
> > > client_secret in clear text if user wants to.
> > > 
> > > Beside the enable/disable button, I think another good thing to do is
> > > specify
> > > a default role(s) for each provider. That can be useful if applications
> > > want
> > > to perform any kind of authorization based on the identity provider or
> > > authentication method used to authenticate an user (eg.: useful for
> > > adaptative or multi-level access control). We can also use the "amr"
> > > claim
> > > in the ID Token, which seems KC is not considering at all. The latter is
> > > an
> > > important thing to think of, regardless this broker work I'm doing.
> > > 
> > > [1]
> > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Having a separate enable/disable for each provider would be good. If
> > > you're
> > > leaving the social tab as is and adding a separate tab for configuring
> > > brokered idp's then we should leave the social enable/disable button,
> > > otherwise it depends how it'll look like in the end.
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Hi,
> > > > 
> > > >    Social has a button to enable/disable it. I'm wondering what to do
> > > >    with
> > > >    the brokered identity providers. Shall we add a similar flag for
> > > >    that
> > > >    ?
> > > > 
> > > >    I was also wondering if the best would be a flag in a per provider
> > > >    basis.
> > > >    So we can disable/enable a specific provider (social or brokered),
> > > >    instead of doing that for all.
> > > > 
> > > > Regards.
> > > > Pedro Igor
> > > > 
> > > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > I'll go for it then. Will remove the icon url from the model and
> > > > > > leave
> > > > > > that
> > > > > > for users if they want to provide icons for their identity
> > > > > > providers.
> > > > > > 
> > > > > > My point is that icons can be usually served by the same
> > > > > > server/application
> > > > > > or proxy, so download images are not such a big deal. Also, the
> > > > > > icon
> > > > > > url
> > > > > > is
> > > > > > part of the freemarker model and people can do what ever they want
> > > > > > with
> > > > > > it.
> > > > > > What I think will also help in your future plans.
> > > > > 
> > > > > I'm not following. Are you saying that if a named image
> > > > > 'my-provider.png'
> > > > > is
> > > > > loaded from a theme, then you can override it in another theme?
> > > > > 
> > > > > If so, that's basically the same as having a css class 'my-provider'
> > > > > in
> > > > > a
> > > > > theme. With the exception that with an image you end up with having
> > > > > to
> > > > > require a image per provider per theme per language, which could be a
> > > > > lot
> > > > > of
> > > > > images for a single provider. Also, buttons for accessibility should
> > > > > be
> > > > > defined with text and css, not images that can't be interpreted. You
> > > > > also
> > > > > still need to modify the theme, so I don't see any benefits.
> > > > 
> > > > You are right. Having a icon url per provider does not makes sense if
> > > > there
> > > > are requirements to change images accordingly to a theme or language.
> > > > CSS
> > > > makes life easier.
> > > > 
> > > > Will remove that property from the model.
> > > > 
> > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Users can now specify a Icon Url to be rendered on the login page
> > > > > > > when
> > > > > > > social
> > > > > > > or any other identity provider is configured. So we just load the
> > > > > > > image
> > > > > > > the
> > > > > > > url entered by the user.
> > > > > > > 
> > > > > > > Are you saying that users should change the theme or customize
> > > > > > > css
> > > > > > > if
> > > > > > > they
> > > > > > > only want to change an icon for a provider ?
> > > > > > 
> > > > > > Yes, there's many issues with having a icon url:
> > > > > > 
> > > > > > * Won't work for internationalization - we don't have this now, but
> > > > > > we
> > > > > > will
> > > > > > * Image is not a good button - CSS is much better
> > > > > > * Doesn't support themes - we allow users to switch l&f by
> > > > > > switching
> > > > > > themes,
> > > > > > but that won't work for a icon url. In the future we may also
> > > > > > support
> > > > > > multiple themes per-realm, for example to depending on the devices
> > > > > > (one
> > > > > > theme for mobiles, one for desktops, etc)
> > > > > > * Requires the URL to be hosted somewhere - why require a separate
> > > > > > call
> > > > > > to
> > > > > > download an image (to a separate server maybe) if it can simply be
> > > > > > defined
> > > > > > in a single CSS file?
> > > > > > 
> > > > > > Rather than add additional places to define look and feel
> > > > > > components
> > > > > > we
> > > > > > should in the future make it easier to add/customize themes.
> > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > All look and feel related things including images and stylesheets
> > > > > > > should
> > > > > > > be
> > > > > > > part of themes. This is to allow customizing them in the theme.
> > > > > > > Also,
> > > > > > > an
> > > > > > > image is not the correct way to render a button, it should be
> > > > > > > defined
> > > > > > > in
> > > > > > > CSS.
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > You shouldn't have icon images for social providers. They
> > > > > > > > should
> > > > > > > > be
> > > > > > > > specified
> > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > >     Anyone know where I can get the icons images for social
> > > > > > > > >     providers
> > > > > > > > >     ?
> > > > > > > > >     It
> > > > > > > > >     seems zocial defines them encoded in some way in CSS. I
> > > > > > > > >     need
> > > > > > > > >     that
> > > > > > > > >     to
> > > > > > > > >     provide default images if user does not specify their
> > > > > > > > >     own.
> > > > > > > > > 
> > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > 
> > > > > > > > > Regards.
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Hi guys,
> > > > > > > > > 
> > > > > > > > >    I've done some initial work covering both persistence and
> > > > > > > > >    brokering.
> > > > > > > > >    No
> > > > > > > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > > > > > > >    functionality
> > > > > > > > >    for now.
> > > > > > > > > 
> > > > > > > > >    What I have is enough to decide if we are aligned about
> > > > > > > > >    this
> > > > > > > > >    functionality. So you can understand how the model (and
> > > > > > > > >    persistence),
> > > > > > > > >    rest api and brokering functionality looks like. Can we
> > > > > > > > >    schedule
> > > > > > > > >    a
> > > > > > > > >    meeting ?
> > > > > > > > > 
> > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > 
> > > > > > > > > [1]
> > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > 
> > > > > > > > > Regards.
> > > > > > > > > Pedro Igor
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > > (@RolesAllowed)
> > > > > > > > > based
> > > > > > > > > on either realm roles or the roles of one specific
> > > > > > > > > application.
> > > > > > > > > This
> > > > > > > > > is
> > > > > > > > > related to 1) too.
> > > > > > > > > 
> > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > > > > >
> > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > > >> I just wanted to quickly list the additional work we
> > > > > > > > > >> discussed
> > > > > > > > > >> so
> > > > > > > > > >> everyone
> > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > >>
> > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an
> > > > > > > > > >> external
> > > > > > > > > >> token
> > > > > > > > > >> to
> > > > > > > > > >> a KC token? For example an external token with attribute
> > > > > > > > > >> 'group'
> > > > > > > > > >> that
> > > > > > > > > >> contains 'sales' and 'manager' could be mapped to
> > > > > > > > > >> 'manager'
> > > > > > > > > >> role
> > > > > > > > > >> for
> > > > > > > > > >> 'sales app in a KC token. Could we use Drools? This could
> > > > > > > > > >> also
> > > > > > > > > >> be
> > > > > > > > > >> used
> > > > > > > > > >> in
> > > > > > > > > >> user federation to allow more complex mapping of
> > > > > > > > > >> roles/groups
> > > > > > > > > >> than
> > > > > > > > > >> a
> > > > > > > > > >> simple 1-1
> > > > > > > > > >> 2) Retrieving tokens - if an application wants to retrieve
> > > > > > > > > >> the
> > > > > > > > > >> external
> > > > > > > > > >> token (for example to view Facebook friends if user logged
> > > > > > > > > >> in
> > > > > > > > > >> with
> > > > > > > > > >> Facebook)
> > > > > > > > > >> 3) Configure scope - currently for social we only request
> > > > > > > > > >> a
> > > > > > > > > >> very
> > > > > > > > > >> limited
> > > > > > > > > >> scope (basic profile and email), to for example view
> > > > > > > > > >> Facebook
> > > > > > > > > >> friends
> > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > >> 4) Selecting provider - currently in social (and for first
> > > > > > > > > >> pass
> > > > > > > > > >> of
> > > > > > > > > >> brokering) we have an icon user has to select, but can we
> > > > > > > > > >> select
> > > > > > > > > >> the
> > > > > > > > > >> provider in a different way (for example ask user for
> > > > > > > > > >> email,
> > > > > > > > > >> and
> > > > > > > > > >> select
> > > > > > > > > >> based on email domain)
> > > > > > > > > >> 5) Gateway - don't create a KC token, but just forward the
> > > > > > > > > >> external
> > > > > > > > > >> token
> > > > > > > > > >>
> > > > > > > > > >> IMO 1) is a killer feature, as it would allow companies to
> > > > > > > > > >> add
> > > > > > > > > >> external
> > > > > > > > > >> users without having to modify their applications. Issue
> > > > > > > > > >> with
> > > > > > > > > >> 5)
> > > > > > > > > >> is
> > > > > > > > > >> that
> > > > > > > > > >> applications need to understand more than one token, which
> > > > > > > > > >> would
> > > > > > > > > >> require
> > > > > > > > > >> rewriting applications.
> > > > > > > > > >>
> > > > > > > > > >> This work is also somewhat related to other authentication
> > > > > > > > > >> mechanisms
> > > > > > > > > >> (for
> > > > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > > > >>
> > > > > > > > > >> ----- Original Message -----
> > > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > >>> Authentication
> > > > > > > > > >>> Broker
> > > > > > > > > >>>
> > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > >>>> Authentication
> > > > > > > > > >>>> Broker
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > > > >>>>> Hi,
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Would like to start a discussion about how to
> > > > > > > > > >>>>>        enable
> > > > > > > > > >>>>>        KC
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        an
> > > > > > > > > >>>>>        Authentication Broker in order to supported
> > > > > > > > > >>>>>        Chained
> > > > > > > > > >>>>>        Federation
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        also Identity Federation. First of all, some
> > > > > > > > > >>>>>        background
> > > > > > > > > >>>>>        about
> > > > > > > > > >>>>>        what
> > > > > > > > > >>>>>        this is all about.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > > > > > >>>>>        authentication
> > > > > > > > > >>>>>        (correct
> > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>            1) Local authentication (based on some
> > > > > > > > > >>>>>            credential
> > > > > > > > > >>>>>            type
> > > > > > > > > >>>>>            enabled
> > > > > > > > > >>>>>            to
> > > > > > > > > >>>>>            a realm)
> > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Local authentication is about authenticating the
> > > > > > > > > >>>>>        user
> > > > > > > > > >>>>>        locally
> > > > > > > > > >>>>>        using
> > > > > > > > > >>>>>        KC's own identity store. Nothing special here.
> > > > > > > > > >>>>>        And
> > > > > > > > > >>>>>        Social
> > > > > > > > > >>>>>        Authentication which allows users to choose the
> > > > > > > > > >>>>>        Social
> > > > > > > > > >>>>>        IdP
> > > > > > > > > >>>>>        they
> > > > > > > > > >>>>>        want
> > > > > > > > > >>>>>        to authenticate with. In this case, the IdP is
> > > > > > > > > >>>>>        always
> > > > > > > > > >>>>>        one
> > > > > > > > > >>>>>        of
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        built-in social providers supported by KC such
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        Facebook,
> > > > > > > > > >>>>>        Google,
> > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        When doing social, the user is automatically
> > > > > > > > > >>>>>        provisioned
> > > > > > > > > >>>>>        in
> > > > > > > > > >>>>>        KC
> > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > >>>>>        authentication.
> > > > > > > > > >>>>>        The
> > > > > > > > > >>>>>        user
> > > > > > > > > >>>>>        does
> > > > > > > > > >>>>>        not
> > > > > > > > > >>>>>        need to fill a registration form and can access
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        very
> > > > > > > > > >>>>>        quickly. During the provisioning some basic
> > > > > > > > > >>>>>        information
> > > > > > > > > >>>>>        is
> > > > > > > > > >>>>>        retrieved
> > > > > > > > > >>>>>        from the social provider such as email,
> > > > > > > > > >>>>>        firstname
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        so
> > > > > > > > > >>>>>        forth.
> > > > > > > > > >>>>>        These
> > > > > > > > > >>>>>        are very basic information, any other
> > > > > > > > > >>>>>        information
> > > > > > > > > >>>>>        such
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        those
> > > > > > > > > >>>>>        related with authorization policies - eg.: roles
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        groups
> > > > > > > > > >>>>>        -
> > > > > > > > > >>>>>        must
> > > > > > > > > >>>>>        be
> > > > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Another important characteristic of social
> > > > > > > > > >>>>>        authentication
> > > > > > > > > >>>>>        is
> > > > > > > > > >>>>>        that
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        application receives a KC token and not the
> > > > > > > > > >>>>>        token
> > > > > > > > > >>>>>        that
> > > > > > > > > >>>>>        was
> > > > > > > > > >>>>>        issued by
> > > > > > > > > >>>>>        the social IdP during the authentication
> > > > > > > > > >>>>>        process.
> > > > > > > > > >>>>>        If
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        wants to consume resources from the resource
> > > > > > > > > >>>>>        provider
> > > > > > > > > >>>>>        he
> > > > > > > > > >>>>>        was
> > > > > > > > > >>>>>        authenticated it must obtain the access
> > > > > > > > > >>>>>        token(again)
> > > > > > > > > >>>>>        by
> > > > > > > > > >>>>>        itself
> > > > > > > > > >>>>>        prior
> > > > > > > > > >>>>>        to invoke the resource provider API. Assuming
> > > > > > > > > >>>>>        all
> > > > > > > > > >>>>>        those
> > > > > > > > > >>>>>        social
> > > > > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        That said, the Authentication Broker
> > > > > > > > > >>>>>        functionality
> > > > > > > > > >>>>>        aims
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        cover
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        same use cases but with a lot of more
> > > > > > > > > >>>>>        flexibility
> > > > > > > > > >>>>>        on
> > > > > > > > > >>>>>        how
> > > > > > > > > >>>>>        you
> > > > > > > > > >>>>>        setup
> > > > > > > > > >>>>>        identity providers(not only social ones) and the
> > > > > > > > > >>>>>        different
> > > > > > > > > >>>>>        federation
> > > > > > > > > >>>>>        protocols they may support such as SAML, OpenID,
> > > > > > > > > >>>>>        oAuth
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        so
> > > > > > > > > >>>>>        forth.
> > > > > > > > > >>>>>        This is useful when an enterprise is providing
> > > > > > > > > >>>>>        services
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        different
> > > > > > > > > >>>>>        customers(IdP) and does not want to manage many
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        many
> > > > > > > > > >>>>>        relationships. When using a broker, the
> > > > > > > > > >>>>>        authentication
> > > > > > > > > >>>>>        steps
> > > > > > > > > >>>>>        are
> > > > > > > > > >>>>>        pretty much the same when you are using social
> > > > > > > > > >>>>>        authentication,
> > > > > > > > > >>>>>        with
> > > > > > > > > >>>>>        important differences on how you support
> > > > > > > > > >>>>>        different
> > > > > > > > > >>>>>        identity
> > > > > > > > > >>>>>        providers, different federation protocols, how
> > > > > > > > > >>>>>        users
> > > > > > > > > >>>>>        are
> > > > > > > > > >>>>>        provisioned
> > > > > > > > > >>>>>        and how claims and attributes are resolved.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        The brokering functionality can be done in two
> > > > > > > > > >>>>>        ways
> > > > > > > > > >>>>>        depending
> > > > > > > > > >>>>>        if
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        broker service is acting as a gateway or not.
> > > > > > > > > >>>>>        When
> > > > > > > > > >>>>>        acting
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        a
> > > > > > > > > >>>>>        gateway, the broker will respond to the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        same
> > > > > > > > > >>>>>        token
> > > > > > > > > >>>>>        issued by the trusted identity provider. For
> > > > > > > > > >>>>>        instance,
> > > > > > > > > >>>>>        if
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        user
> > > > > > > > > >>>>>        selects a SAML IdP to authenticate with, the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        will
> > > > > > > > > >>>>>        receive
> > > > > > > > > >>>>>        a SAML Response. In this case, the application
> > > > > > > > > >>>>>        must
> > > > > > > > > >>>>>        also
> > > > > > > > > >>>>>        be
> > > > > > > > > >>>>>        prepared
> > > > > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        However, the broker service can also be used to
> > > > > > > > > >>>>>        completely
> > > > > > > > > >>>>>        abstract
> > > > > > > > > >>>>>        from the application the protocol used to
> > > > > > > > > >>>>>        authenticate
> > > > > > > > > >>>>>        an
> > > > > > > > > >>>>>        user.
> > > > > > > > > >>>>>        In
> > > > > > > > > >>>>>        this case, the application will just receive an
> > > > > > > > > >>>>>        ordinary
> > > > > > > > > >>>>>        KC
> > > > > > > > > >>>>>        token
> > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        In both cases, the broker acts as an
> > > > > > > > > >>>>>        intermediary
> > > > > > > > > >>>>>        where
> > > > > > > > > >>>>>        specific
> > > > > > > > > >>>>>        security policies can be applied when users try
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        authenticate
> > > > > > > > > >>>>>        themselves against a 3rd party IdP. That brings
> > > > > > > > > >>>>>        a
> > > > > > > > > >>>>>        lot
> > > > > > > > > >>>>>        of
> > > > > > > > > >>>>>        value
> > > > > > > > > >>>>>        when
> > > > > > > > > >>>>>        you think about auditing, authorization and how
> > > > > > > > > >>>>>        users
> > > > > > > > > >>>>>        are
> > > > > > > > > >>>>>        provisioned
> > > > > > > > > >>>>>        when federation of identities is needed. This
> > > > > > > > > >>>>>        also
> > > > > > > > > >>>>>        allows
> > > > > > > > > >>>>>        existing
> > > > > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        benefit
> > > > > > > > > >>>>>        from KC's support for cloud, rest and mobile use
> > > > > > > > > >>>>>        cases.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        I think this is enough to start a discussion.
> > > > > > > > > >>>>>        I've
> > > > > > > > > >>>>>        an
> > > > > > > > > >>>>>        initial
> > > > > > > > > >>>>>        discussion with Stian about all that and we
> > > > > > > > > >>>>>        agreed
> > > > > > > > > >>>>>        that
> > > > > > > > > >>>>>        abstract
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        protocol from applications should be
> > > > > > > > > >>>>>        prioritized.
> > > > > > > > > >>>>>        The
> > > > > > > > > >>>>>        main
> > > > > > > > > >>>>>        reason is
> > > > > > > > > >>>>>        that it makes life easier for applications so
> > > > > > > > > >>>>>        they
> > > > > > > > > >>>>>        only
> > > > > > > > > >>>>>        need
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        know
> > > > > > > > > >>>>>        about KC tokens and nothing else. However that
> > > > > > > > > >>>>>        brings
> > > > > > > > > >>>>>        some
> > > > > > > > > >>>>>        new
> > > > > > > > > >>>>>        requirements around user provisioning and
> > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > >>>>>        resolution
> > > > > > > > > >>>>>        or mapping. But that would be another thread.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > > > > >>>> applications"?
> > > > > > > > > >>>> Not
> > > > > > > > > >>>> sure what you mean by that.  IDP federation should be
> > > > > > > > > >>>> configured
> > > > > > > > > >>>> at
> > > > > > > > > >>>> the
> > > > > > > > > >>>> realm level and really has nothing to do with
> > > > > > > > > >>>> applications.
> > > > > > > > > >>>>
> > > > > > > > > >>>> I'm really happy that somebody is doing this.  We're
> > > > > > > > > >>>> getting
> > > > > > > > > >>>> a
> > > > > > > > > >>>> real
> > > > > > > > > >>>> impressive feature set!
> > > > > > > > > >>>
> > > > > > > > > >>> Sure. What I meant was that the application only knows
> > > > > > > > > >>> about
> > > > > > > > > >>> KC
> > > > > > > > > >>> tokens
> > > > > > > > > >>> nothing else. It will always receive a KC token
> > > > > > > > > >>> regardless
> > > > > > > > > >>> the
> > > > > > > > > >>> protocol
> > > > > > > > > >>> used
> > > > > > > > > >>> to authenticate the user against a 3rd party IdP (saml,
> > > > > > > > > >>> oidc,
> > > > > > > > > >>> whatever).
> > > > > > > > > >>> The
> > > > > > > > > >>> example I gave was about an user trying to authenticate
> > > > > > > > > >>> against
> > > > > > > > > >>> a
> > > > > > > > > >>> SAML
> > > > > > > > > >>> IdP.
> > > > > > > > > >>> In this case, after a successful authentication on the
> > > > > > > > > >>> IdP,
> > > > > > > > > >>> the
> > > > > > > > > >>> IdP
> > > > > > > > > >>> will
> > > > > > > > > >>> issue a token to KC. Then KC will validate the token,
> > > > > > > > > >>> perform
> > > > > > > > > >>> trust
> > > > > > > > > >>> and
> > > > > > > > > >>> security checks, do user provisioning and attribute/claim
> > > > > > > > > >>> resolution
> > > > > > > > > >>> to
> > > > > > > > > >>> finally issue a KC token and redirect the user to the
> > > > > > > > > >>> application.
> > > > > > > > > >>> If
> > > > > > > > > >>> the
> > > > > > > > > >>> app is configured to use openid in KC then it will
> > > > > > > > > >>> receive
> > > > > > > > > >>> a
> > > > > > > > > >>> openid
> > > > > > > > > >>> token
> > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > >>>
> > > > > > > > > >>> The other scenario is pretty much the same. The
> > > > > > > > > >>> difference
> > > > > > > > > >>> is
> > > > > > > > > >>> that
> > > > > > > > > >>> KC
> > > > > > > > > >>> will
> > > > > > > > > >>> not issue its own token but just replay the token issued
> > > > > > > > > >>> by
> > > > > > > > > >>> the
> > > > > > > > > >>> 3rd
> > > > > > > > > >>> party
> > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > >>>
> > > > > > > > > >>> I agree that this config goes at the realm level. For
> > > > > > > > > >>> instance,
> > > > > > > > > >>> to
> > > > > > > > > >>> create
> > > > > > > > > >>> and
> > > > > > > > > >>> enable providers for being used. However, I think we
> > > > > > > > > >>> would
> > > > > > > > > >>> need
> > > > > > > > > >>> some
> > > > > > > > > >>> specific configuration for applications as well.
> > > > > > > > > >>> Specially
> > > > > > > > > >>> when
> > > > > > > > > >>> defining
> > > > > > > > > >>> default roles, mapping attributes. Another example of
> > > > > > > > > >>> application
> > > > > > > > > >>> config
> > > > > > > > > >>> is
> > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define
> > > > > > > > > >>> scopes
> > > > > > > > > >>> per-application.
> > > > > > > > > >>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> --
> > > > > > > > > >>>> Bill Burke
> > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > >>>> _______________________________________________
> > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > >>>>
> > > > > > > > > >>> _______________________________________________
> > > > > > > > > >>> 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
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-dev mailing list
> > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > > 
> > 
> 


From stian at redhat.com  Fri Dec  5 07:59:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 07:59:08 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
Message-ID: <1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>

Another related thing. We've had a few people ask to be able to login to Keycloak on mobiles using the native social login mechanism.

I think the best way to do that is to use the direct grant api and make it possible to call that endpoint passing a IdP id and a token instead of username and password.

WDYT?

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 1:45:24 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, December 5, 2014 10:22:10 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Looks good. I reckon we can combine the two pages. What about if the 'Add
> > provider' drop-down is:
> > 
> >   OpenID
> >   SAML
> >   ------
> >   Google
> >   GitHub
> >   Facebook
> >   Twitter
> > 
> > Let's drop social on/off and instead have a enable/disable button on each
> > provider.
> 
> Sure.
> 
> > 
> > Also, would be nice if users could set a name or alias for a provider
> > instance. This would make the callback url easier to use (instead of
> > callback/<UUID> it's callback/<alias>). The user federation providers have
> > this.
> 
> One of my first tries was using an alias, just like that. But I preferred
> using the UUID and make the configuration more easier. Beside that, the
> callback url is just a copy and paste, so I think an alias would not bring
> so much usability, but add one more step when configuring providers.
> 
> However, if this is an usability requirement for KC I can change that.
> 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > In one of our last discussions, you suggested to leave Social as it is.
> > > Although IMO I think we can have a single place to manage both social and
> > > user-defined identity providers. Social ones are just OOTB and
> > > pre-configured identity providers now.
> > > 
> > > That said, today I'm using separated tabs for social and user-defined.
> > > Please, take a look at [1] for more details on how the UI looks like.
> > > 
> > > I've changed social UI a bit in order to provide a specific page for
> > > create/update. I've also added a "Show Secret" link to display the
> > > client_secret in clear text if user wants to.
> > > 
> > > Beside the enable/disable button, I think another good thing to do is
> > > specify
> > > a default role(s) for each provider. That can be useful if applications
> > > want
> > > to perform any kind of authorization based on the identity provider or
> > > authentication method used to authenticate an user (eg.: useful for
> > > adaptative or multi-level access control). We can also use the "amr"
> > > claim
> > > in the ID Token, which seems KC is not considering at all. The latter is
> > > an
> > > important thing to think of, regardless this broker work I'm doing.
> > > 
> > > [1]
> > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Having a separate enable/disable for each provider would be good. If
> > > you're
> > > leaving the social tab as is and adding a separate tab for configuring
> > > brokered idp's then we should leave the social enable/disable button,
> > > otherwise it depends how it'll look like in the end.
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Hi,
> > > > 
> > > >    Social has a button to enable/disable it. I'm wondering what to do
> > > >    with
> > > >    the brokered identity providers. Shall we add a similar flag for
> > > >    that
> > > >    ?
> > > > 
> > > >    I was also wondering if the best would be a flag in a per provider
> > > >    basis.
> > > >    So we can disable/enable a specific provider (social or brokered),
> > > >    instead of doing that for all.
> > > > 
> > > > Regards.
> > > > Pedro Igor
> > > > 
> > > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > I'll go for it then. Will remove the icon url from the model and
> > > > > > leave
> > > > > > that
> > > > > > for users if they want to provide icons for their identity
> > > > > > providers.
> > > > > > 
> > > > > > My point is that icons can be usually served by the same
> > > > > > server/application
> > > > > > or proxy, so download images are not such a big deal. Also, the
> > > > > > icon
> > > > > > url
> > > > > > is
> > > > > > part of the freemarker model and people can do what ever they want
> > > > > > with
> > > > > > it.
> > > > > > What I think will also help in your future plans.
> > > > > 
> > > > > I'm not following. Are you saying that if a named image
> > > > > 'my-provider.png'
> > > > > is
> > > > > loaded from a theme, then you can override it in another theme?
> > > > > 
> > > > > If so, that's basically the same as having a css class 'my-provider'
> > > > > in
> > > > > a
> > > > > theme. With the exception that with an image you end up with having
> > > > > to
> > > > > require a image per provider per theme per language, which could be a
> > > > > lot
> > > > > of
> > > > > images for a single provider. Also, buttons for accessibility should
> > > > > be
> > > > > defined with text and css, not images that can't be interpreted. You
> > > > > also
> > > > > still need to modify the theme, so I don't see any benefits.
> > > > 
> > > > You are right. Having a icon url per provider does not makes sense if
> > > > there
> > > > are requirements to change images accordingly to a theme or language.
> > > > CSS
> > > > makes life easier.
> > > > 
> > > > Will remove that property from the model.
> > > > 
> > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Users can now specify a Icon Url to be rendered on the login page
> > > > > > > when
> > > > > > > social
> > > > > > > or any other identity provider is configured. So we just load the
> > > > > > > image
> > > > > > > the
> > > > > > > url entered by the user.
> > > > > > > 
> > > > > > > Are you saying that users should change the theme or customize
> > > > > > > css
> > > > > > > if
> > > > > > > they
> > > > > > > only want to change an icon for a provider ?
> > > > > > 
> > > > > > Yes, there's many issues with having a icon url:
> > > > > > 
> > > > > > * Won't work for internationalization - we don't have this now, but
> > > > > > we
> > > > > > will
> > > > > > * Image is not a good button - CSS is much better
> > > > > > * Doesn't support themes - we allow users to switch l&f by
> > > > > > switching
> > > > > > themes,
> > > > > > but that won't work for a icon url. In the future we may also
> > > > > > support
> > > > > > multiple themes per-realm, for example to depending on the devices
> > > > > > (one
> > > > > > theme for mobiles, one for desktops, etc)
> > > > > > * Requires the URL to be hosted somewhere - why require a separate
> > > > > > call
> > > > > > to
> > > > > > download an image (to a separate server maybe) if it can simply be
> > > > > > defined
> > > > > > in a single CSS file?
> > > > > > 
> > > > > > Rather than add additional places to define look and feel
> > > > > > components
> > > > > > we
> > > > > > should in the future make it easier to add/customize themes.
> > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > All look and feel related things including images and stylesheets
> > > > > > > should
> > > > > > > be
> > > > > > > part of themes. This is to allow customizing them in the theme.
> > > > > > > Also,
> > > > > > > an
> > > > > > > image is not the correct way to render a button, it should be
> > > > > > > defined
> > > > > > > in
> > > > > > > CSS.
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > You shouldn't have icon images for social providers. They
> > > > > > > > should
> > > > > > > > be
> > > > > > > > specified
> > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > >     Anyone know where I can get the icons images for social
> > > > > > > > >     providers
> > > > > > > > >     ?
> > > > > > > > >     It
> > > > > > > > >     seems zocial defines them encoded in some way in CSS. I
> > > > > > > > >     need
> > > > > > > > >     that
> > > > > > > > >     to
> > > > > > > > >     provide default images if user does not specify their
> > > > > > > > >     own.
> > > > > > > > > 
> > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > 
> > > > > > > > > Regards.
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Hi guys,
> > > > > > > > > 
> > > > > > > > >    I've done some initial work covering both persistence and
> > > > > > > > >    brokering.
> > > > > > > > >    No
> > > > > > > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > > > > > > >    functionality
> > > > > > > > >    for now.
> > > > > > > > > 
> > > > > > > > >    What I have is enough to decide if we are aligned about
> > > > > > > > >    this
> > > > > > > > >    functionality. So you can understand how the model (and
> > > > > > > > >    persistence),
> > > > > > > > >    rest api and brokering functionality looks like. Can we
> > > > > > > > >    schedule
> > > > > > > > >    a
> > > > > > > > >    meeting ?
> > > > > > > > > 
> > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > 
> > > > > > > > > [1]
> > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > 
> > > > > > > > > Regards.
> > > > > > > > > Pedro Igor
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > > (@RolesAllowed)
> > > > > > > > > based
> > > > > > > > > on either realm roles or the roles of one specific
> > > > > > > > > application.
> > > > > > > > > This
> > > > > > > > > is
> > > > > > > > > related to 1) too.
> > > > > > > > > 
> > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > > > > >
> > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > > >> I just wanted to quickly list the additional work we
> > > > > > > > > >> discussed
> > > > > > > > > >> so
> > > > > > > > > >> everyone
> > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > >>
> > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an
> > > > > > > > > >> external
> > > > > > > > > >> token
> > > > > > > > > >> to
> > > > > > > > > >> a KC token? For example an external token with attribute
> > > > > > > > > >> 'group'
> > > > > > > > > >> that
> > > > > > > > > >> contains 'sales' and 'manager' could be mapped to
> > > > > > > > > >> 'manager'
> > > > > > > > > >> role
> > > > > > > > > >> for
> > > > > > > > > >> 'sales app in a KC token. Could we use Drools? This could
> > > > > > > > > >> also
> > > > > > > > > >> be
> > > > > > > > > >> used
> > > > > > > > > >> in
> > > > > > > > > >> user federation to allow more complex mapping of
> > > > > > > > > >> roles/groups
> > > > > > > > > >> than
> > > > > > > > > >> a
> > > > > > > > > >> simple 1-1
> > > > > > > > > >> 2) Retrieving tokens - if an application wants to retrieve
> > > > > > > > > >> the
> > > > > > > > > >> external
> > > > > > > > > >> token (for example to view Facebook friends if user logged
> > > > > > > > > >> in
> > > > > > > > > >> with
> > > > > > > > > >> Facebook)
> > > > > > > > > >> 3) Configure scope - currently for social we only request
> > > > > > > > > >> a
> > > > > > > > > >> very
> > > > > > > > > >> limited
> > > > > > > > > >> scope (basic profile and email), to for example view
> > > > > > > > > >> Facebook
> > > > > > > > > >> friends
> > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > >> 4) Selecting provider - currently in social (and for first
> > > > > > > > > >> pass
> > > > > > > > > >> of
> > > > > > > > > >> brokering) we have an icon user has to select, but can we
> > > > > > > > > >> select
> > > > > > > > > >> the
> > > > > > > > > >> provider in a different way (for example ask user for
> > > > > > > > > >> email,
> > > > > > > > > >> and
> > > > > > > > > >> select
> > > > > > > > > >> based on email domain)
> > > > > > > > > >> 5) Gateway - don't create a KC token, but just forward the
> > > > > > > > > >> external
> > > > > > > > > >> token
> > > > > > > > > >>
> > > > > > > > > >> IMO 1) is a killer feature, as it would allow companies to
> > > > > > > > > >> add
> > > > > > > > > >> external
> > > > > > > > > >> users without having to modify their applications. Issue
> > > > > > > > > >> with
> > > > > > > > > >> 5)
> > > > > > > > > >> is
> > > > > > > > > >> that
> > > > > > > > > >> applications need to understand more than one token, which
> > > > > > > > > >> would
> > > > > > > > > >> require
> > > > > > > > > >> rewriting applications.
> > > > > > > > > >>
> > > > > > > > > >> This work is also somewhat related to other authentication
> > > > > > > > > >> mechanisms
> > > > > > > > > >> (for
> > > > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > > > >>
> > > > > > > > > >> ----- Original Message -----
> > > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > >>> Authentication
> > > > > > > > > >>> Broker
> > > > > > > > > >>>
> > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > >>>> Authentication
> > > > > > > > > >>>> Broker
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > > > >>>>> Hi,
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Would like to start a discussion about how to
> > > > > > > > > >>>>>        enable
> > > > > > > > > >>>>>        KC
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        an
> > > > > > > > > >>>>>        Authentication Broker in order to supported
> > > > > > > > > >>>>>        Chained
> > > > > > > > > >>>>>        Federation
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        also Identity Federation. First of all, some
> > > > > > > > > >>>>>        background
> > > > > > > > > >>>>>        about
> > > > > > > > > >>>>>        what
> > > > > > > > > >>>>>        this is all about.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > > > > > >>>>>        authentication
> > > > > > > > > >>>>>        (correct
> > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>            1) Local authentication (based on some
> > > > > > > > > >>>>>            credential
> > > > > > > > > >>>>>            type
> > > > > > > > > >>>>>            enabled
> > > > > > > > > >>>>>            to
> > > > > > > > > >>>>>            a realm)
> > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Local authentication is about authenticating the
> > > > > > > > > >>>>>        user
> > > > > > > > > >>>>>        locally
> > > > > > > > > >>>>>        using
> > > > > > > > > >>>>>        KC's own identity store. Nothing special here.
> > > > > > > > > >>>>>        And
> > > > > > > > > >>>>>        Social
> > > > > > > > > >>>>>        Authentication which allows users to choose the
> > > > > > > > > >>>>>        Social
> > > > > > > > > >>>>>        IdP
> > > > > > > > > >>>>>        they
> > > > > > > > > >>>>>        want
> > > > > > > > > >>>>>        to authenticate with. In this case, the IdP is
> > > > > > > > > >>>>>        always
> > > > > > > > > >>>>>        one
> > > > > > > > > >>>>>        of
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        built-in social providers supported by KC such
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        Facebook,
> > > > > > > > > >>>>>        Google,
> > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        When doing social, the user is automatically
> > > > > > > > > >>>>>        provisioned
> > > > > > > > > >>>>>        in
> > > > > > > > > >>>>>        KC
> > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > >>>>>        authentication.
> > > > > > > > > >>>>>        The
> > > > > > > > > >>>>>        user
> > > > > > > > > >>>>>        does
> > > > > > > > > >>>>>        not
> > > > > > > > > >>>>>        need to fill a registration form and can access
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        very
> > > > > > > > > >>>>>        quickly. During the provisioning some basic
> > > > > > > > > >>>>>        information
> > > > > > > > > >>>>>        is
> > > > > > > > > >>>>>        retrieved
> > > > > > > > > >>>>>        from the social provider such as email,
> > > > > > > > > >>>>>        firstname
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        so
> > > > > > > > > >>>>>        forth.
> > > > > > > > > >>>>>        These
> > > > > > > > > >>>>>        are very basic information, any other
> > > > > > > > > >>>>>        information
> > > > > > > > > >>>>>        such
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        those
> > > > > > > > > >>>>>        related with authorization policies - eg.: roles
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        groups
> > > > > > > > > >>>>>        -
> > > > > > > > > >>>>>        must
> > > > > > > > > >>>>>        be
> > > > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Another important characteristic of social
> > > > > > > > > >>>>>        authentication
> > > > > > > > > >>>>>        is
> > > > > > > > > >>>>>        that
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        application receives a KC token and not the
> > > > > > > > > >>>>>        token
> > > > > > > > > >>>>>        that
> > > > > > > > > >>>>>        was
> > > > > > > > > >>>>>        issued by
> > > > > > > > > >>>>>        the social IdP during the authentication
> > > > > > > > > >>>>>        process.
> > > > > > > > > >>>>>        If
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        wants to consume resources from the resource
> > > > > > > > > >>>>>        provider
> > > > > > > > > >>>>>        he
> > > > > > > > > >>>>>        was
> > > > > > > > > >>>>>        authenticated it must obtain the access
> > > > > > > > > >>>>>        token(again)
> > > > > > > > > >>>>>        by
> > > > > > > > > >>>>>        itself
> > > > > > > > > >>>>>        prior
> > > > > > > > > >>>>>        to invoke the resource provider API. Assuming
> > > > > > > > > >>>>>        all
> > > > > > > > > >>>>>        those
> > > > > > > > > >>>>>        social
> > > > > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        That said, the Authentication Broker
> > > > > > > > > >>>>>        functionality
> > > > > > > > > >>>>>        aims
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        cover
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        same use cases but with a lot of more
> > > > > > > > > >>>>>        flexibility
> > > > > > > > > >>>>>        on
> > > > > > > > > >>>>>        how
> > > > > > > > > >>>>>        you
> > > > > > > > > >>>>>        setup
> > > > > > > > > >>>>>        identity providers(not only social ones) and the
> > > > > > > > > >>>>>        different
> > > > > > > > > >>>>>        federation
> > > > > > > > > >>>>>        protocols they may support such as SAML, OpenID,
> > > > > > > > > >>>>>        oAuth
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        so
> > > > > > > > > >>>>>        forth.
> > > > > > > > > >>>>>        This is useful when an enterprise is providing
> > > > > > > > > >>>>>        services
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        different
> > > > > > > > > >>>>>        customers(IdP) and does not want to manage many
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        many
> > > > > > > > > >>>>>        relationships. When using a broker, the
> > > > > > > > > >>>>>        authentication
> > > > > > > > > >>>>>        steps
> > > > > > > > > >>>>>        are
> > > > > > > > > >>>>>        pretty much the same when you are using social
> > > > > > > > > >>>>>        authentication,
> > > > > > > > > >>>>>        with
> > > > > > > > > >>>>>        important differences on how you support
> > > > > > > > > >>>>>        different
> > > > > > > > > >>>>>        identity
> > > > > > > > > >>>>>        providers, different federation protocols, how
> > > > > > > > > >>>>>        users
> > > > > > > > > >>>>>        are
> > > > > > > > > >>>>>        provisioned
> > > > > > > > > >>>>>        and how claims and attributes are resolved.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        The brokering functionality can be done in two
> > > > > > > > > >>>>>        ways
> > > > > > > > > >>>>>        depending
> > > > > > > > > >>>>>        if
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        broker service is acting as a gateway or not.
> > > > > > > > > >>>>>        When
> > > > > > > > > >>>>>        acting
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        a
> > > > > > > > > >>>>>        gateway, the broker will respond to the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        same
> > > > > > > > > >>>>>        token
> > > > > > > > > >>>>>        issued by the trusted identity provider. For
> > > > > > > > > >>>>>        instance,
> > > > > > > > > >>>>>        if
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        user
> > > > > > > > > >>>>>        selects a SAML IdP to authenticate with, the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        will
> > > > > > > > > >>>>>        receive
> > > > > > > > > >>>>>        a SAML Response. In this case, the application
> > > > > > > > > >>>>>        must
> > > > > > > > > >>>>>        also
> > > > > > > > > >>>>>        be
> > > > > > > > > >>>>>        prepared
> > > > > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        However, the broker service can also be used to
> > > > > > > > > >>>>>        completely
> > > > > > > > > >>>>>        abstract
> > > > > > > > > >>>>>        from the application the protocol used to
> > > > > > > > > >>>>>        authenticate
> > > > > > > > > >>>>>        an
> > > > > > > > > >>>>>        user.
> > > > > > > > > >>>>>        In
> > > > > > > > > >>>>>        this case, the application will just receive an
> > > > > > > > > >>>>>        ordinary
> > > > > > > > > >>>>>        KC
> > > > > > > > > >>>>>        token
> > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        In both cases, the broker acts as an
> > > > > > > > > >>>>>        intermediary
> > > > > > > > > >>>>>        where
> > > > > > > > > >>>>>        specific
> > > > > > > > > >>>>>        security policies can be applied when users try
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        authenticate
> > > > > > > > > >>>>>        themselves against a 3rd party IdP. That brings
> > > > > > > > > >>>>>        a
> > > > > > > > > >>>>>        lot
> > > > > > > > > >>>>>        of
> > > > > > > > > >>>>>        value
> > > > > > > > > >>>>>        when
> > > > > > > > > >>>>>        you think about auditing, authorization and how
> > > > > > > > > >>>>>        users
> > > > > > > > > >>>>>        are
> > > > > > > > > >>>>>        provisioned
> > > > > > > > > >>>>>        when federation of identities is needed. This
> > > > > > > > > >>>>>        also
> > > > > > > > > >>>>>        allows
> > > > > > > > > >>>>>        existing
> > > > > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        benefit
> > > > > > > > > >>>>>        from KC's support for cloud, rest and mobile use
> > > > > > > > > >>>>>        cases.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        I think this is enough to start a discussion.
> > > > > > > > > >>>>>        I've
> > > > > > > > > >>>>>        an
> > > > > > > > > >>>>>        initial
> > > > > > > > > >>>>>        discussion with Stian about all that and we
> > > > > > > > > >>>>>        agreed
> > > > > > > > > >>>>>        that
> > > > > > > > > >>>>>        abstract
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        protocol from applications should be
> > > > > > > > > >>>>>        prioritized.
> > > > > > > > > >>>>>        The
> > > > > > > > > >>>>>        main
> > > > > > > > > >>>>>        reason is
> > > > > > > > > >>>>>        that it makes life easier for applications so
> > > > > > > > > >>>>>        they
> > > > > > > > > >>>>>        only
> > > > > > > > > >>>>>        need
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        know
> > > > > > > > > >>>>>        about KC tokens and nothing else. However that
> > > > > > > > > >>>>>        brings
> > > > > > > > > >>>>>        some
> > > > > > > > > >>>>>        new
> > > > > > > > > >>>>>        requirements around user provisioning and
> > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > >>>>>        resolution
> > > > > > > > > >>>>>        or mapping. But that would be another thread.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > > > > >>>> applications"?
> > > > > > > > > >>>> Not
> > > > > > > > > >>>> sure what you mean by that.  IDP federation should be
> > > > > > > > > >>>> configured
> > > > > > > > > >>>> at
> > > > > > > > > >>>> the
> > > > > > > > > >>>> realm level and really has nothing to do with
> > > > > > > > > >>>> applications.
> > > > > > > > > >>>>
> > > > > > > > > >>>> I'm really happy that somebody is doing this.  We're
> > > > > > > > > >>>> getting
> > > > > > > > > >>>> a
> > > > > > > > > >>>> real
> > > > > > > > > >>>> impressive feature set!
> > > > > > > > > >>>
> > > > > > > > > >>> Sure. What I meant was that the application only knows
> > > > > > > > > >>> about
> > > > > > > > > >>> KC
> > > > > > > > > >>> tokens
> > > > > > > > > >>> nothing else. It will always receive a KC token
> > > > > > > > > >>> regardless
> > > > > > > > > >>> the
> > > > > > > > > >>> protocol
> > > > > > > > > >>> used
> > > > > > > > > >>> to authenticate the user against a 3rd party IdP (saml,
> > > > > > > > > >>> oidc,
> > > > > > > > > >>> whatever).
> > > > > > > > > >>> The
> > > > > > > > > >>> example I gave was about an user trying to authenticate
> > > > > > > > > >>> against
> > > > > > > > > >>> a
> > > > > > > > > >>> SAML
> > > > > > > > > >>> IdP.
> > > > > > > > > >>> In this case, after a successful authentication on the
> > > > > > > > > >>> IdP,
> > > > > > > > > >>> the
> > > > > > > > > >>> IdP
> > > > > > > > > >>> will
> > > > > > > > > >>> issue a token to KC. Then KC will validate the token,
> > > > > > > > > >>> perform
> > > > > > > > > >>> trust
> > > > > > > > > >>> and
> > > > > > > > > >>> security checks, do user provisioning and attribute/claim
> > > > > > > > > >>> resolution
> > > > > > > > > >>> to
> > > > > > > > > >>> finally issue a KC token and redirect the user to the
> > > > > > > > > >>> application.
> > > > > > > > > >>> If
> > > > > > > > > >>> the
> > > > > > > > > >>> app is configured to use openid in KC then it will
> > > > > > > > > >>> receive
> > > > > > > > > >>> a
> > > > > > > > > >>> openid
> > > > > > > > > >>> token
> > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > >>>
> > > > > > > > > >>> The other scenario is pretty much the same. The
> > > > > > > > > >>> difference
> > > > > > > > > >>> is
> > > > > > > > > >>> that
> > > > > > > > > >>> KC
> > > > > > > > > >>> will
> > > > > > > > > >>> not issue its own token but just replay the token issued
> > > > > > > > > >>> by
> > > > > > > > > >>> the
> > > > > > > > > >>> 3rd
> > > > > > > > > >>> party
> > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > >>>
> > > > > > > > > >>> I agree that this config goes at the realm level. For
> > > > > > > > > >>> instance,
> > > > > > > > > >>> to
> > > > > > > > > >>> create
> > > > > > > > > >>> and
> > > > > > > > > >>> enable providers for being used. However, I think we
> > > > > > > > > >>> would
> > > > > > > > > >>> need
> > > > > > > > > >>> some
> > > > > > > > > >>> specific configuration for applications as well.
> > > > > > > > > >>> Specially
> > > > > > > > > >>> when
> > > > > > > > > >>> defining
> > > > > > > > > >>> default roles, mapping attributes. Another example of
> > > > > > > > > >>> application
> > > > > > > > > >>> config
> > > > > > > > > >>> is
> > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define
> > > > > > > > > >>> scopes
> > > > > > > > > >>> per-application.
> > > > > > > > > >>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> --
> > > > > > > > > >>>> Bill Burke
> > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > >>>> _______________________________________________
> > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > >>>>
> > > > > > > > > >>> _______________________________________________
> > > > > > > > > >>> 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
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-dev mailing list
> > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > > 
> > 
> 


From psilva at redhat.com  Fri Dec  5 08:14:55 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 Dec 2014 08:14:55 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1861805773.11275595.1417784132116.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1861805773.11275595.1417784132116.JavaMail.zimbra@redhat.com>
Message-ID: <170776080.25343241.1417785295239.JavaMail.zimbra@redhat.com>

No problem.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Friday, December 5, 2014 10:55:32 AM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 1:45:24 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, December 5, 2014 10:22:10 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Looks good. I reckon we can combine the two pages. What about if the 'Add
> > provider' drop-down is:
> > 
> >   OpenID
> >   SAML
> >   ------
> >   Google
> >   GitHub
> >   Facebook
> >   Twitter
> > 
> > Let's drop social on/off and instead have a enable/disable button on each
> > provider.
> 
> Sure.
> 
> > 
> > Also, would be nice if users could set a name or alias for a provider
> > instance. This would make the callback url easier to use (instead of
> > callback/<UUID> it's callback/<alias>). The user federation providers have
> > this.
> 
> One of my first tries was using an alias, just like that. But I preferred
> using the UUID and make the configuration more easier. Beside that, the
> callback url is just a copy and paste, so I think an alias would not bring
> so much usability, but add one more step when configuring providers.
> 
> However, if this is an usability requirement for KC I can change that.

Please do. If it uses a UUID it also requires updating the provider if you have to re-create the provider for whatever reason. For example I've got keys I use for dev/testing and I've just set the callback to http://localhost:8080/auth/callback/google. As long as I can re-create the provider with the same alias I don't have to touch Google, but if it's a generated UUID I always have to.

> 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > In one of our last discussions, you suggested to leave Social as it is.
> > > Although IMO I think we can have a single place to manage both social and
> > > user-defined identity providers. Social ones are just OOTB and
> > > pre-configured identity providers now.
> > > 
> > > That said, today I'm using separated tabs for social and user-defined.
> > > Please, take a look at [1] for more details on how the UI looks like.
> > > 
> > > I've changed social UI a bit in order to provide a specific page for
> > > create/update. I've also added a "Show Secret" link to display the
> > > client_secret in clear text if user wants to.
> > > 
> > > Beside the enable/disable button, I think another good thing to do is
> > > specify
> > > a default role(s) for each provider. That can be useful if applications
> > > want
> > > to perform any kind of authorization based on the identity provider or
> > > authentication method used to authenticate an user (eg.: useful for
> > > adaptative or multi-level access control). We can also use the "amr"
> > > claim
> > > in the ID Token, which seems KC is not considering at all. The latter is
> > > an
> > > important thing to think of, regardless this broker work I'm doing.
> > > 
> > > [1]
> > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Having a separate enable/disable for each provider would be good. If
> > > you're
> > > leaving the social tab as is and adding a separate tab for configuring
> > > brokered idp's then we should leave the social enable/disable button,
> > > otherwise it depends how it'll look like in the end.
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Hi,
> > > > 
> > > >    Social has a button to enable/disable it. I'm wondering what to do
> > > >    with
> > > >    the brokered identity providers. Shall we add a similar flag for
> > > >    that
> > > >    ?
> > > > 
> > > >    I was also wondering if the best would be a flag in a per provider
> > > >    basis.
> > > >    So we can disable/enable a specific provider (social or brokered),
> > > >    instead of doing that for all.
> > > > 
> > > > Regards.
> > > > Pedro Igor
> > > > 
> > > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > I'll go for it then. Will remove the icon url from the model and
> > > > > > leave
> > > > > > that
> > > > > > for users if they want to provide icons for their identity
> > > > > > providers.
> > > > > > 
> > > > > > My point is that icons can be usually served by the same
> > > > > > server/application
> > > > > > or proxy, so download images are not such a big deal. Also, the
> > > > > > icon
> > > > > > url
> > > > > > is
> > > > > > part of the freemarker model and people can do what ever they want
> > > > > > with
> > > > > > it.
> > > > > > What I think will also help in your future plans.
> > > > > 
> > > > > I'm not following. Are you saying that if a named image
> > > > > 'my-provider.png'
> > > > > is
> > > > > loaded from a theme, then you can override it in another theme?
> > > > > 
> > > > > If so, that's basically the same as having a css class 'my-provider'
> > > > > in
> > > > > a
> > > > > theme. With the exception that with an image you end up with having
> > > > > to
> > > > > require a image per provider per theme per language, which could be a
> > > > > lot
> > > > > of
> > > > > images for a single provider. Also, buttons for accessibility should
> > > > > be
> > > > > defined with text and css, not images that can't be interpreted. You
> > > > > also
> > > > > still need to modify the theme, so I don't see any benefits.
> > > > 
> > > > You are right. Having a icon url per provider does not makes sense if
> > > > there
> > > > are requirements to change images accordingly to a theme or language.
> > > > CSS
> > > > makes life easier.
> > > > 
> > > > Will remove that property from the model.
> > > > 
> > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Users can now specify a Icon Url to be rendered on the login page
> > > > > > > when
> > > > > > > social
> > > > > > > or any other identity provider is configured. So we just load the
> > > > > > > image
> > > > > > > the
> > > > > > > url entered by the user.
> > > > > > > 
> > > > > > > Are you saying that users should change the theme or customize
> > > > > > > css
> > > > > > > if
> > > > > > > they
> > > > > > > only want to change an icon for a provider ?
> > > > > > 
> > > > > > Yes, there's many issues with having a icon url:
> > > > > > 
> > > > > > * Won't work for internationalization - we don't have this now, but
> > > > > > we
> > > > > > will
> > > > > > * Image is not a good button - CSS is much better
> > > > > > * Doesn't support themes - we allow users to switch l&f by
> > > > > > switching
> > > > > > themes,
> > > > > > but that won't work for a icon url. In the future we may also
> > > > > > support
> > > > > > multiple themes per-realm, for example to depending on the devices
> > > > > > (one
> > > > > > theme for mobiles, one for desktops, etc)
> > > > > > * Requires the URL to be hosted somewhere - why require a separate
> > > > > > call
> > > > > > to
> > > > > > download an image (to a separate server maybe) if it can simply be
> > > > > > defined
> > > > > > in a single CSS file?
> > > > > > 
> > > > > > Rather than add additional places to define look and feel
> > > > > > components
> > > > > > we
> > > > > > should in the future make it easier to add/customize themes.
> > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > All look and feel related things including images and stylesheets
> > > > > > > should
> > > > > > > be
> > > > > > > part of themes. This is to allow customizing them in the theme.
> > > > > > > Also,
> > > > > > > an
> > > > > > > image is not the correct way to render a button, it should be
> > > > > > > defined
> > > > > > > in
> > > > > > > CSS.
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > You shouldn't have icon images for social providers. They
> > > > > > > > should
> > > > > > > > be
> > > > > > > > specified
> > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > >     Anyone know where I can get the icons images for social
> > > > > > > > >     providers
> > > > > > > > >     ?
> > > > > > > > >     It
> > > > > > > > >     seems zocial defines them encoded in some way in CSS. I
> > > > > > > > >     need
> > > > > > > > >     that
> > > > > > > > >     to
> > > > > > > > >     provide default images if user does not specify their
> > > > > > > > >     own.
> > > > > > > > > 
> > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > 
> > > > > > > > > Regards.
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Hi guys,
> > > > > > > > > 
> > > > > > > > >    I've done some initial work covering both persistence and
> > > > > > > > >    brokering.
> > > > > > > > >    No
> > > > > > > > >    UI, yet. I'm focused on the model, rest api and brokering
> > > > > > > > >    functionality
> > > > > > > > >    for now.
> > > > > > > > > 
> > > > > > > > >    What I have is enough to decide if we are aligned about
> > > > > > > > >    this
> > > > > > > > >    functionality. So you can understand how the model (and
> > > > > > > > >    persistence),
> > > > > > > > >    rest api and brokering functionality looks like. Can we
> > > > > > > > >    schedule
> > > > > > > > >    a
> > > > > > > > >    meeting ?
> > > > > > > > > 
> > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > 
> > > > > > > > > [1]
> > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > 
> > > > > > > > > Regards.
> > > > > > > > > Pedro Igor
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > > (@RolesAllowed)
> > > > > > > > > based
> > > > > > > > > on either realm roles or the roles of one specific
> > > > > > > > > application.
> > > > > > > > > This
> > > > > > > > > is
> > > > > > > > > related to 1) too.
> > > > > > > > > 
> > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > > > > >
> > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > > >> I just wanted to quickly list the additional work we
> > > > > > > > > >> discussed
> > > > > > > > > >> so
> > > > > > > > > >> everyone
> > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > >>
> > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an
> > > > > > > > > >> external
> > > > > > > > > >> token
> > > > > > > > > >> to
> > > > > > > > > >> a KC token? For example an external token with attribute
> > > > > > > > > >> 'group'
> > > > > > > > > >> that
> > > > > > > > > >> contains 'sales' and 'manager' could be mapped to
> > > > > > > > > >> 'manager'
> > > > > > > > > >> role
> > > > > > > > > >> for
> > > > > > > > > >> 'sales app in a KC token. Could we use Drools? This could
> > > > > > > > > >> also
> > > > > > > > > >> be
> > > > > > > > > >> used
> > > > > > > > > >> in
> > > > > > > > > >> user federation to allow more complex mapping of
> > > > > > > > > >> roles/groups
> > > > > > > > > >> than
> > > > > > > > > >> a
> > > > > > > > > >> simple 1-1
> > > > > > > > > >> 2) Retrieving tokens - if an application wants to retrieve
> > > > > > > > > >> the
> > > > > > > > > >> external
> > > > > > > > > >> token (for example to view Facebook friends if user logged
> > > > > > > > > >> in
> > > > > > > > > >> with
> > > > > > > > > >> Facebook)
> > > > > > > > > >> 3) Configure scope - currently for social we only request
> > > > > > > > > >> a
> > > > > > > > > >> very
> > > > > > > > > >> limited
> > > > > > > > > >> scope (basic profile and email), to for example view
> > > > > > > > > >> Facebook
> > > > > > > > > >> friends
> > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > >> 4) Selecting provider - currently in social (and for first
> > > > > > > > > >> pass
> > > > > > > > > >> of
> > > > > > > > > >> brokering) we have an icon user has to select, but can we
> > > > > > > > > >> select
> > > > > > > > > >> the
> > > > > > > > > >> provider in a different way (for example ask user for
> > > > > > > > > >> email,
> > > > > > > > > >> and
> > > > > > > > > >> select
> > > > > > > > > >> based on email domain)
> > > > > > > > > >> 5) Gateway - don't create a KC token, but just forward the
> > > > > > > > > >> external
> > > > > > > > > >> token
> > > > > > > > > >>
> > > > > > > > > >> IMO 1) is a killer feature, as it would allow companies to
> > > > > > > > > >> add
> > > > > > > > > >> external
> > > > > > > > > >> users without having to modify their applications. Issue
> > > > > > > > > >> with
> > > > > > > > > >> 5)
> > > > > > > > > >> is
> > > > > > > > > >> that
> > > > > > > > > >> applications need to understand more than one token, which
> > > > > > > > > >> would
> > > > > > > > > >> require
> > > > > > > > > >> rewriting applications.
> > > > > > > > > >>
> > > > > > > > > >> This work is also somewhat related to other authentication
> > > > > > > > > >> mechanisms
> > > > > > > > > >> (for
> > > > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > > > >>
> > > > > > > > > >> ----- Original Message -----
> > > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > >>> Authentication
> > > > > > > > > >>> Broker
> > > > > > > > > >>>
> > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > >>>> Authentication
> > > > > > > > > >>>> Broker
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > > > >>>>> Hi,
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Would like to start a discussion about how to
> > > > > > > > > >>>>>        enable
> > > > > > > > > >>>>>        KC
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        an
> > > > > > > > > >>>>>        Authentication Broker in order to supported
> > > > > > > > > >>>>>        Chained
> > > > > > > > > >>>>>        Federation
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        also Identity Federation. First of all, some
> > > > > > > > > >>>>>        background
> > > > > > > > > >>>>>        about
> > > > > > > > > >>>>>        what
> > > > > > > > > >>>>>        this is all about.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > > > > > >>>>>        authentication
> > > > > > > > > >>>>>        (correct
> > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>            1) Local authentication (based on some
> > > > > > > > > >>>>>            credential
> > > > > > > > > >>>>>            type
> > > > > > > > > >>>>>            enabled
> > > > > > > > > >>>>>            to
> > > > > > > > > >>>>>            a realm)
> > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Local authentication is about authenticating the
> > > > > > > > > >>>>>        user
> > > > > > > > > >>>>>        locally
> > > > > > > > > >>>>>        using
> > > > > > > > > >>>>>        KC's own identity store. Nothing special here.
> > > > > > > > > >>>>>        And
> > > > > > > > > >>>>>        Social
> > > > > > > > > >>>>>        Authentication which allows users to choose the
> > > > > > > > > >>>>>        Social
> > > > > > > > > >>>>>        IdP
> > > > > > > > > >>>>>        they
> > > > > > > > > >>>>>        want
> > > > > > > > > >>>>>        to authenticate with. In this case, the IdP is
> > > > > > > > > >>>>>        always
> > > > > > > > > >>>>>        one
> > > > > > > > > >>>>>        of
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        built-in social providers supported by KC such
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        Facebook,
> > > > > > > > > >>>>>        Google,
> > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        When doing social, the user is automatically
> > > > > > > > > >>>>>        provisioned
> > > > > > > > > >>>>>        in
> > > > > > > > > >>>>>        KC
> > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > >>>>>        authentication.
> > > > > > > > > >>>>>        The
> > > > > > > > > >>>>>        user
> > > > > > > > > >>>>>        does
> > > > > > > > > >>>>>        not
> > > > > > > > > >>>>>        need to fill a registration form and can access
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        very
> > > > > > > > > >>>>>        quickly. During the provisioning some basic
> > > > > > > > > >>>>>        information
> > > > > > > > > >>>>>        is
> > > > > > > > > >>>>>        retrieved
> > > > > > > > > >>>>>        from the social provider such as email,
> > > > > > > > > >>>>>        firstname
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        so
> > > > > > > > > >>>>>        forth.
> > > > > > > > > >>>>>        These
> > > > > > > > > >>>>>        are very basic information, any other
> > > > > > > > > >>>>>        information
> > > > > > > > > >>>>>        such
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        those
> > > > > > > > > >>>>>        related with authorization policies - eg.: roles
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        groups
> > > > > > > > > >>>>>        -
> > > > > > > > > >>>>>        must
> > > > > > > > > >>>>>        be
> > > > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        Another important characteristic of social
> > > > > > > > > >>>>>        authentication
> > > > > > > > > >>>>>        is
> > > > > > > > > >>>>>        that
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        application receives a KC token and not the
> > > > > > > > > >>>>>        token
> > > > > > > > > >>>>>        that
> > > > > > > > > >>>>>        was
> > > > > > > > > >>>>>        issued by
> > > > > > > > > >>>>>        the social IdP during the authentication
> > > > > > > > > >>>>>        process.
> > > > > > > > > >>>>>        If
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        wants to consume resources from the resource
> > > > > > > > > >>>>>        provider
> > > > > > > > > >>>>>        he
> > > > > > > > > >>>>>        was
> > > > > > > > > >>>>>        authenticated it must obtain the access
> > > > > > > > > >>>>>        token(again)
> > > > > > > > > >>>>>        by
> > > > > > > > > >>>>>        itself
> > > > > > > > > >>>>>        prior
> > > > > > > > > >>>>>        to invoke the resource provider API. Assuming
> > > > > > > > > >>>>>        all
> > > > > > > > > >>>>>        those
> > > > > > > > > >>>>>        social
> > > > > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        That said, the Authentication Broker
> > > > > > > > > >>>>>        functionality
> > > > > > > > > >>>>>        aims
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        cover
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        same use cases but with a lot of more
> > > > > > > > > >>>>>        flexibility
> > > > > > > > > >>>>>        on
> > > > > > > > > >>>>>        how
> > > > > > > > > >>>>>        you
> > > > > > > > > >>>>>        setup
> > > > > > > > > >>>>>        identity providers(not only social ones) and the
> > > > > > > > > >>>>>        different
> > > > > > > > > >>>>>        federation
> > > > > > > > > >>>>>        protocols they may support such as SAML, OpenID,
> > > > > > > > > >>>>>        oAuth
> > > > > > > > > >>>>>        and
> > > > > > > > > >>>>>        so
> > > > > > > > > >>>>>        forth.
> > > > > > > > > >>>>>        This is useful when an enterprise is providing
> > > > > > > > > >>>>>        services
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        different
> > > > > > > > > >>>>>        customers(IdP) and does not want to manage many
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        many
> > > > > > > > > >>>>>        relationships. When using a broker, the
> > > > > > > > > >>>>>        authentication
> > > > > > > > > >>>>>        steps
> > > > > > > > > >>>>>        are
> > > > > > > > > >>>>>        pretty much the same when you are using social
> > > > > > > > > >>>>>        authentication,
> > > > > > > > > >>>>>        with
> > > > > > > > > >>>>>        important differences on how you support
> > > > > > > > > >>>>>        different
> > > > > > > > > >>>>>        identity
> > > > > > > > > >>>>>        providers, different federation protocols, how
> > > > > > > > > >>>>>        users
> > > > > > > > > >>>>>        are
> > > > > > > > > >>>>>        provisioned
> > > > > > > > > >>>>>        and how claims and attributes are resolved.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        The brokering functionality can be done in two
> > > > > > > > > >>>>>        ways
> > > > > > > > > >>>>>        depending
> > > > > > > > > >>>>>        if
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        broker service is acting as a gateway or not.
> > > > > > > > > >>>>>        When
> > > > > > > > > >>>>>        acting
> > > > > > > > > >>>>>        as
> > > > > > > > > >>>>>        a
> > > > > > > > > >>>>>        gateway, the broker will respond to the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        same
> > > > > > > > > >>>>>        token
> > > > > > > > > >>>>>        issued by the trusted identity provider. For
> > > > > > > > > >>>>>        instance,
> > > > > > > > > >>>>>        if
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        user
> > > > > > > > > >>>>>        selects a SAML IdP to authenticate with, the
> > > > > > > > > >>>>>        application
> > > > > > > > > >>>>>        will
> > > > > > > > > >>>>>        receive
> > > > > > > > > >>>>>        a SAML Response. In this case, the application
> > > > > > > > > >>>>>        must
> > > > > > > > > >>>>>        also
> > > > > > > > > >>>>>        be
> > > > > > > > > >>>>>        prepared
> > > > > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        However, the broker service can also be used to
> > > > > > > > > >>>>>        completely
> > > > > > > > > >>>>>        abstract
> > > > > > > > > >>>>>        from the application the protocol used to
> > > > > > > > > >>>>>        authenticate
> > > > > > > > > >>>>>        an
> > > > > > > > > >>>>>        user.
> > > > > > > > > >>>>>        In
> > > > > > > > > >>>>>        this case, the application will just receive an
> > > > > > > > > >>>>>        ordinary
> > > > > > > > > >>>>>        KC
> > > > > > > > > >>>>>        token
> > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        In both cases, the broker acts as an
> > > > > > > > > >>>>>        intermediary
> > > > > > > > > >>>>>        where
> > > > > > > > > >>>>>        specific
> > > > > > > > > >>>>>        security policies can be applied when users try
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        authenticate
> > > > > > > > > >>>>>        themselves against a 3rd party IdP. That brings
> > > > > > > > > >>>>>        a
> > > > > > > > > >>>>>        lot
> > > > > > > > > >>>>>        of
> > > > > > > > > >>>>>        value
> > > > > > > > > >>>>>        when
> > > > > > > > > >>>>>        you think about auditing, authorization and how
> > > > > > > > > >>>>>        users
> > > > > > > > > >>>>>        are
> > > > > > > > > >>>>>        provisioned
> > > > > > > > > >>>>>        when federation of identities is needed. This
> > > > > > > > > >>>>>        also
> > > > > > > > > >>>>>        allows
> > > > > > > > > >>>>>        existing
> > > > > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        benefit
> > > > > > > > > >>>>>        from KC's support for cloud, rest and mobile use
> > > > > > > > > >>>>>        cases.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>        I think this is enough to start a discussion.
> > > > > > > > > >>>>>        I've
> > > > > > > > > >>>>>        an
> > > > > > > > > >>>>>        initial
> > > > > > > > > >>>>>        discussion with Stian about all that and we
> > > > > > > > > >>>>>        agreed
> > > > > > > > > >>>>>        that
> > > > > > > > > >>>>>        abstract
> > > > > > > > > >>>>>        the
> > > > > > > > > >>>>>        protocol from applications should be
> > > > > > > > > >>>>>        prioritized.
> > > > > > > > > >>>>>        The
> > > > > > > > > >>>>>        main
> > > > > > > > > >>>>>        reason is
> > > > > > > > > >>>>>        that it makes life easier for applications so
> > > > > > > > > >>>>>        they
> > > > > > > > > >>>>>        only
> > > > > > > > > >>>>>        need
> > > > > > > > > >>>>>        to
> > > > > > > > > >>>>>        know
> > > > > > > > > >>>>>        about KC tokens and nothing else. However that
> > > > > > > > > >>>>>        brings
> > > > > > > > > >>>>>        some
> > > > > > > > > >>>>>        new
> > > > > > > > > >>>>>        requirements around user provisioning and
> > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > >>>>>        resolution
> > > > > > > > > >>>>>        or mapping. But that would be another thread.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > > > > >>>> applications"?
> > > > > > > > > >>>> Not
> > > > > > > > > >>>> sure what you mean by that.  IDP federation should be
> > > > > > > > > >>>> configured
> > > > > > > > > >>>> at
> > > > > > > > > >>>> the
> > > > > > > > > >>>> realm level and really has nothing to do with
> > > > > > > > > >>>> applications.
> > > > > > > > > >>>>
> > > > > > > > > >>>> I'm really happy that somebody is doing this.  We're
> > > > > > > > > >>>> getting
> > > > > > > > > >>>> a
> > > > > > > > > >>>> real
> > > > > > > > > >>>> impressive feature set!
> > > > > > > > > >>>
> > > > > > > > > >>> Sure. What I meant was that the application only knows
> > > > > > > > > >>> about
> > > > > > > > > >>> KC
> > > > > > > > > >>> tokens
> > > > > > > > > >>> nothing else. It will always receive a KC token
> > > > > > > > > >>> regardless
> > > > > > > > > >>> the
> > > > > > > > > >>> protocol
> > > > > > > > > >>> used
> > > > > > > > > >>> to authenticate the user against a 3rd party IdP (saml,
> > > > > > > > > >>> oidc,
> > > > > > > > > >>> whatever).
> > > > > > > > > >>> The
> > > > > > > > > >>> example I gave was about an user trying to authenticate
> > > > > > > > > >>> against
> > > > > > > > > >>> a
> > > > > > > > > >>> SAML
> > > > > > > > > >>> IdP.
> > > > > > > > > >>> In this case, after a successful authentication on the
> > > > > > > > > >>> IdP,
> > > > > > > > > >>> the
> > > > > > > > > >>> IdP
> > > > > > > > > >>> will
> > > > > > > > > >>> issue a token to KC. Then KC will validate the token,
> > > > > > > > > >>> perform
> > > > > > > > > >>> trust
> > > > > > > > > >>> and
> > > > > > > > > >>> security checks, do user provisioning and attribute/claim
> > > > > > > > > >>> resolution
> > > > > > > > > >>> to
> > > > > > > > > >>> finally issue a KC token and redirect the user to the
> > > > > > > > > >>> application.
> > > > > > > > > >>> If
> > > > > > > > > >>> the
> > > > > > > > > >>> app is configured to use openid in KC then it will
> > > > > > > > > >>> receive
> > > > > > > > > >>> a
> > > > > > > > > >>> openid
> > > > > > > > > >>> token
> > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > >>>
> > > > > > > > > >>> The other scenario is pretty much the same. The
> > > > > > > > > >>> difference
> > > > > > > > > >>> is
> > > > > > > > > >>> that
> > > > > > > > > >>> KC
> > > > > > > > > >>> will
> > > > > > > > > >>> not issue its own token but just replay the token issued
> > > > > > > > > >>> by
> > > > > > > > > >>> the
> > > > > > > > > >>> 3rd
> > > > > > > > > >>> party
> > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > >>>
> > > > > > > > > >>> I agree that this config goes at the realm level. For
> > > > > > > > > >>> instance,
> > > > > > > > > >>> to
> > > > > > > > > >>> create
> > > > > > > > > >>> and
> > > > > > > > > >>> enable providers for being used. However, I think we
> > > > > > > > > >>> would
> > > > > > > > > >>> need
> > > > > > > > > >>> some
> > > > > > > > > >>> specific configuration for applications as well.
> > > > > > > > > >>> Specially
> > > > > > > > > >>> when
> > > > > > > > > >>> defining
> > > > > > > > > >>> default roles, mapping attributes. Another example of
> > > > > > > > > >>> application
> > > > > > > > > >>> config
> > > > > > > > > >>> is
> > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define
> > > > > > > > > >>> scopes
> > > > > > > > > >>> per-application.
> > > > > > > > > >>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> --
> > > > > > > > > >>>> Bill Burke
> > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > >>>> _______________________________________________
> > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > >>>>
> > > > > > > > > >>> _______________________________________________
> > > > > > > > > >>> 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
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-dev mailing list
> > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > > 
> > 
> 


From bburke at redhat.com  Fri Dec  5 08:28:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 08:28:56 -0500
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>	<917317697.8592600.1417520535452.JavaMail.zimbra@redhat.com>	<247503077.22638589.1417521321488.JavaMail.zimbra@redhat.com>	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
Message-ID: <5481B318.9080609@redhat.com>

Get rid of the social button?

On 12/5/2014 3:15 AM, Stian Thorgersen wrote:
> Having a separate enable/disable for each provider would be good. If you're leaving the social tab as is and adding a separate tab for configuring brokered idp's then we should leave the social enable/disable button, otherwise it depends how it'll look like in the end.
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 5 December, 2014 2:29:37 AM
>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>
>> Hi,
>>
>>     Social has a button to enable/disable it. I'm wondering what to do with
>>     the brokered identity providers. Shall we add a similar flag for that ?
>>
>>     I was also wondering if the best would be a flag in a per provider basis.
>>     So we can disable/enable a specific provider (social or brokered),
>>     instead of doing that for all.
>>
>> Regards.
>> Pedro Igor
>>
>> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, December 2, 2014 10:42:11 AM
>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>
>> ----- Original Message -----
>>> From: "Stian Thorgersen" <stian at redhat.com>
>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, December 2, 2014 10:23:24 AM
>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 2 December, 2014 1:13:08 PM
>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>>
>>>> I'll go for it then. Will remove the icon url from the model and leave
>>>> that
>>>> for users if they want to provide icons for their identity providers.
>>>>
>>>> My point is that icons can be usually served by the same
>>>> server/application
>>>> or proxy, so download images are not such a big deal. Also, the icon url
>>>> is
>>>> part of the freemarker model and people can do what ever they want with
>>>> it.
>>>> What I think will also help in your future plans.
>>>
>>> I'm not following. Are you saying that if a named image 'my-provider.png'
>>> is
>>> loaded from a theme, then you can override it in another theme?
>>>
>>> If so, that's basically the same as having a css class 'my-provider' in a
>>> theme. With the exception that with an image you end up with having to
>>> require a image per provider per theme per language, which could be a lot
>>> of
>>> images for a single provider. Also, buttons for accessibility should be
>>> defined with text and css, not images that can't be interpreted. You also
>>> still need to modify the theme, so I don't see any benefits.
>>
>> You are right. Having a icon url per provider does not makes sense if there
>> are requirements to change images accordingly to a theme or language. CSS
>> makes life easier.
>>
>> Will remove that property from the model.
>>
>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, December 2, 2014 10:04:33 AM
>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Tuesday, 2 December, 2014 12:55:21 PM
>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>> Broker
>>>>>
>>>>> Users can now specify a Icon Url to be rendered on the login page when
>>>>> social
>>>>> or any other identity provider is configured. So we just load the image
>>>>> the
>>>>> url entered by the user.
>>>>>
>>>>> Are you saying that users should change the theme or customize css if
>>>>> they
>>>>> only want to change an icon for a provider ?
>>>>
>>>> Yes, there's many issues with having a icon url:
>>>>
>>>> * Won't work for internationalization - we don't have this now, but we
>>>> will
>>>> * Image is not a good button - CSS is much better
>>>> * Doesn't support themes - we allow users to switch l&f by switching
>>>> themes,
>>>> but that won't work for a icon url. In the future we may also support
>>>> multiple themes per-realm, for example to depending on the devices (one
>>>> theme for mobiles, one for desktops, etc)
>>>> * Requires the URL to be hosted somewhere - why require a separate call
>>>> to
>>>> download an image (to a separate server maybe) if it can simply be
>>>> defined
>>>> in a single CSS file?
>>>>
>>>> Rather than add additional places to define look and feel components we
>>>> should in the future make it easier to add/customize themes.
>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Tuesday, December 2, 2014 9:42:15 AM
>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>> Broker
>>>>>
>>>>> All look and feel related things including images and stylesheets
>>>>> should
>>>>> be
>>>>> part of themes. This is to allow customizing them in the theme. Also,
>>>>> an
>>>>> image is not the correct way to render a button, it should be defined
>>>>> in
>>>>> CSS.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Tuesday, 2 December, 2014 12:34:45 PM
>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>>> Broker
>>>>>>
>>>>>> You shouldn't have icon images for social providers. They should be
>>>>>> specified
>>>>>> as part of the theme in CSS as is now.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Tuesday, 2 December, 2014 12:22:21 PM
>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>>>> Broker
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>      Anyone know where I can get the icons images for social
>>>>>>>      providers
>>>>>>>      ?
>>>>>>>      It
>>>>>>>      seems zocial defines them encoded in some way in CSS. I need
>>>>>>>      that
>>>>>>>      to
>>>>>>>      provide default images if user does not specify their own.
>>>>>>>
>>>>>>>      Or is still possible to use zocial ones ?
>>>>>>>
>>>>>>> Regards.
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Thursday, November 27, 2014 9:01:38 PM
>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>>>> Broker
>>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>>     I've done some initial work covering both persistence and
>>>>>>>     brokering.
>>>>>>>     No
>>>>>>>     UI, yet. I'm focused on the model, rest api and brokering
>>>>>>>     functionality
>>>>>>>     for now.
>>>>>>>
>>>>>>>     What I have is enough to decide if we are aligned about this
>>>>>>>     functionality. So you can understand how the model (and
>>>>>>>     persistence),
>>>>>>>     rest api and brokering functionality looks like. Can we schedule
>>>>>>>     a
>>>>>>>     meeting ?
>>>>>>>
>>>>>>>     Btw, my branch is here [1].
>>>>>>>
>>>>>>> [1]
>>>>>>> https://github.com/pedroigor/keycloak/tree/authentication-broker2
>>>>>>>
>>>>>>> Regards.
>>>>>>> Pedro Igor
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Thursday, November 20, 2014 2:48:49 PM
>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>>>> Broker
>>>>>>>
>>>>>>> Currently adapters can only make authz decisions (@RolesAllowed)
>>>>>>> based
>>>>>>> on either realm roles or the roles of one specific application.
>>>>>>> This
>>>>>>> is
>>>>>>> related to 1) too.
>>>>>>>
>>>>>>> On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
>>>>>>>> 1) Sounds like something definitely worth aiming for.
>>>>>>>>
>>>>>>>> On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
>>>>>>>>> I just wanted to quickly list the additional work we discussed
>>>>>>>>> so
>>>>>>>>> everyone
>>>>>>>>> can think about it (in no particular order):
>>>>>>>>>
>>>>>>>>> 1) Mapping of tokens - how do we deal with mapping of an
>>>>>>>>> external
>>>>>>>>> token
>>>>>>>>> to
>>>>>>>>> a KC token? For example an external token with attribute 'group'
>>>>>>>>> that
>>>>>>>>> contains 'sales' and 'manager' could be mapped to 'manager' role
>>>>>>>>> for
>>>>>>>>> 'sales app in a KC token. Could we use Drools? This could also
>>>>>>>>> be
>>>>>>>>> used
>>>>>>>>> in
>>>>>>>>> user federation to allow more complex mapping of roles/groups
>>>>>>>>> than
>>>>>>>>> a
>>>>>>>>> simple 1-1
>>>>>>>>> 2) Retrieving tokens - if an application wants to retrieve the
>>>>>>>>> external
>>>>>>>>> token (for example to view Facebook friends if user logged in
>>>>>>>>> with
>>>>>>>>> Facebook)
>>>>>>>>> 3) Configure scope - currently for social we only request a very
>>>>>>>>> limited
>>>>>>>>> scope (basic profile and email), to for example view Facebook
>>>>>>>>> friends
>>>>>>>>> we'd need to ask for that as well
>>>>>>>>> 4) Selecting provider - currently in social (and for first pass
>>>>>>>>> of
>>>>>>>>> brokering) we have an icon user has to select, but can we select
>>>>>>>>> the
>>>>>>>>> provider in a different way (for example ask user for email, and
>>>>>>>>> select
>>>>>>>>> based on email domain)
>>>>>>>>> 5) Gateway - don't create a KC token, but just forward the
>>>>>>>>> external
>>>>>>>>> token
>>>>>>>>>
>>>>>>>>> IMO 1) is a killer feature, as it would allow companies to add
>>>>>>>>> external
>>>>>>>>> users without having to modify their applications. Issue with 5)
>>>>>>>>> is
>>>>>>>>> that
>>>>>>>>> applications need to understand more than one token, which would
>>>>>>>>> require
>>>>>>>>> rewriting applications.
>>>>>>>>>
>>>>>>>>> This work is also somewhat related to other authentication
>>>>>>>>> mechanisms
>>>>>>>>> (for
>>>>>>>>> example Kerberos ticket, LDAP and passwordless).
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
>>>>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and
>>>>>>>>>> Authentication
>>>>>>>>>> Broker
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
>>>>>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and
>>>>>>>>>>> Authentication
>>>>>>>>>>> Broker
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>         Would like to start a discussion about how to enable
>>>>>>>>>>>>         KC
>>>>>>>>>>>>         as
>>>>>>>>>>>>         an
>>>>>>>>>>>>         Authentication Broker in order to supported Chained
>>>>>>>>>>>>         Federation
>>>>>>>>>>>>         and
>>>>>>>>>>>>         also Identity Federation. First of all, some
>>>>>>>>>>>>         background
>>>>>>>>>>>>         about
>>>>>>>>>>>>         what
>>>>>>>>>>>>         this is all about.
>>>>>>>>>>>>
>>>>>>>>>>>>         Currently KeyCloak provides two basic types of
>>>>>>>>>>>>         authentication
>>>>>>>>>>>>         (correct
>>>>>>>>>>>>         me if I'm wrong, please):
>>>>>>>>>>>>
>>>>>>>>>>>>             1) Local authentication (based on some credential
>>>>>>>>>>>>             type
>>>>>>>>>>>>             enabled
>>>>>>>>>>>>             to
>>>>>>>>>>>>             a realm)
>>>>>>>>>>>>             2) Social authentication
>>>>>>>>>>>>
>>>>>>>>>>>>         Local authentication is about authenticating the user
>>>>>>>>>>>>         locally
>>>>>>>>>>>>         using
>>>>>>>>>>>>         KC's own identity store. Nothing special here. And
>>>>>>>>>>>>         Social
>>>>>>>>>>>>         Authentication which allows users to choose the Social
>>>>>>>>>>>>         IdP
>>>>>>>>>>>>         they
>>>>>>>>>>>>         want
>>>>>>>>>>>>         to authenticate with. In this case, the IdP is always
>>>>>>>>>>>>         one
>>>>>>>>>>>>         of
>>>>>>>>>>>>         the
>>>>>>>>>>>>         built-in social providers supported by KC such as
>>>>>>>>>>>>         Facebook,
>>>>>>>>>>>>         Google,
>>>>>>>>>>>>         Twitter, Github and so forth.
>>>>>>>>>>>>
>>>>>>>>>>>>         When doing social, the user is automatically
>>>>>>>>>>>>         provisioned
>>>>>>>>>>>>         in
>>>>>>>>>>>>         KC
>>>>>>>>>>>>         identity store after a successful authentication. The
>>>>>>>>>>>>         user
>>>>>>>>>>>>         does
>>>>>>>>>>>>         not
>>>>>>>>>>>>         need to fill a registration form and can access the
>>>>>>>>>>>>         application
>>>>>>>>>>>>         very
>>>>>>>>>>>>         quickly. During the provisioning some basic
>>>>>>>>>>>>         information
>>>>>>>>>>>>         is
>>>>>>>>>>>>         retrieved
>>>>>>>>>>>>         from the social provider such as email, firstname and
>>>>>>>>>>>>         so
>>>>>>>>>>>>         forth.
>>>>>>>>>>>>         These
>>>>>>>>>>>>         are very basic information, any other information such
>>>>>>>>>>>>         as
>>>>>>>>>>>>         those
>>>>>>>>>>>>         related with authorization policies - eg.: roles and
>>>>>>>>>>>>         groups
>>>>>>>>>>>>         -
>>>>>>>>>>>>         must
>>>>>>>>>>>>         be
>>>>>>>>>>>>         defined later via KC's admin console.
>>>>>>>>>>>>
>>>>>>>>>>>>         Another important characteristic of social
>>>>>>>>>>>>         authentication
>>>>>>>>>>>>         is
>>>>>>>>>>>>         that
>>>>>>>>>>>>         the
>>>>>>>>>>>>         application receives a KC token and not the token that
>>>>>>>>>>>>         was
>>>>>>>>>>>>         issued by
>>>>>>>>>>>>         the social IdP during the authentication process. If
>>>>>>>>>>>>         the
>>>>>>>>>>>>         application
>>>>>>>>>>>>         wants to consume resources from the resource provider
>>>>>>>>>>>>         he
>>>>>>>>>>>>         was
>>>>>>>>>>>>         authenticated it must obtain the access token(again)
>>>>>>>>>>>>         by
>>>>>>>>>>>>         itself
>>>>>>>>>>>>         prior
>>>>>>>>>>>>         to invoke the resource provider API. Assuming all
>>>>>>>>>>>>         those
>>>>>>>>>>>>         social
>>>>>>>>>>>>         providers are based on oAuth 1.0 or 2.0.
>>>>>>>>>>>>
>>>>>>>>>>>>         That said, the Authentication Broker functionality
>>>>>>>>>>>>         aims
>>>>>>>>>>>>         to
>>>>>>>>>>>>         cover
>>>>>>>>>>>>         the
>>>>>>>>>>>>         same use cases but with a lot of more flexibility on
>>>>>>>>>>>>         how
>>>>>>>>>>>>         you
>>>>>>>>>>>>         setup
>>>>>>>>>>>>         identity providers(not only social ones) and the
>>>>>>>>>>>>         different
>>>>>>>>>>>>         federation
>>>>>>>>>>>>         protocols they may support such as SAML, OpenID, oAuth
>>>>>>>>>>>>         and
>>>>>>>>>>>>         so
>>>>>>>>>>>>         forth.
>>>>>>>>>>>>         This is useful when an enterprise is providing
>>>>>>>>>>>>         services
>>>>>>>>>>>>         to
>>>>>>>>>>>>         different
>>>>>>>>>>>>         customers(IdP) and does not want to manage many to
>>>>>>>>>>>>         many
>>>>>>>>>>>>         relationships. When using a broker, the authentication
>>>>>>>>>>>>         steps
>>>>>>>>>>>>         are
>>>>>>>>>>>>         pretty much the same when you are using social
>>>>>>>>>>>>         authentication,
>>>>>>>>>>>>         with
>>>>>>>>>>>>         important differences on how you support different
>>>>>>>>>>>>         identity
>>>>>>>>>>>>         providers, different federation protocols, how users
>>>>>>>>>>>>         are
>>>>>>>>>>>>         provisioned
>>>>>>>>>>>>         and how claims and attributes are resolved.
>>>>>>>>>>>>
>>>>>>>>>>>>         The brokering functionality can be done in two ways
>>>>>>>>>>>>         depending
>>>>>>>>>>>>         if
>>>>>>>>>>>>         the
>>>>>>>>>>>>         broker service is acting as a gateway or not. When
>>>>>>>>>>>>         acting
>>>>>>>>>>>>         as
>>>>>>>>>>>>         a
>>>>>>>>>>>>         gateway, the broker will respond to the application
>>>>>>>>>>>>         the
>>>>>>>>>>>>         same
>>>>>>>>>>>>         token
>>>>>>>>>>>>         issued by the trusted identity provider. For instance,
>>>>>>>>>>>>         if
>>>>>>>>>>>>         the
>>>>>>>>>>>>         user
>>>>>>>>>>>>         selects a SAML IdP to authenticate with, the
>>>>>>>>>>>>         application
>>>>>>>>>>>>         will
>>>>>>>>>>>>         receive
>>>>>>>>>>>>         a SAML Response. In this case, the application must
>>>>>>>>>>>>         also
>>>>>>>>>>>>         be
>>>>>>>>>>>>         prepared
>>>>>>>>>>>>         to handle a specific federation protocol.
>>>>>>>>>>>>
>>>>>>>>>>>>         However, the broker service can also be used to
>>>>>>>>>>>>         completely
>>>>>>>>>>>>         abstract
>>>>>>>>>>>>         from the application the protocol used to authenticate
>>>>>>>>>>>>         an
>>>>>>>>>>>>         user.
>>>>>>>>>>>>         In
>>>>>>>>>>>>         this case, the application will just receive an
>>>>>>>>>>>>         ordinary
>>>>>>>>>>>>         KC
>>>>>>>>>>>>         token
>>>>>>>>>>>>         after a successful authentication.
>>>>>>>>>>>>
>>>>>>>>>>>>         In both cases, the broker acts as an intermediary
>>>>>>>>>>>>         where
>>>>>>>>>>>>         specific
>>>>>>>>>>>>         security policies can be applied when users try to
>>>>>>>>>>>>         authenticate
>>>>>>>>>>>>         themselves against a 3rd party IdP. That brings a lot
>>>>>>>>>>>>         of
>>>>>>>>>>>>         value
>>>>>>>>>>>>         when
>>>>>>>>>>>>         you think about auditing, authorization and how users
>>>>>>>>>>>>         are
>>>>>>>>>>>>         provisioned
>>>>>>>>>>>>         when federation of identities is needed. This also
>>>>>>>>>>>>         allows
>>>>>>>>>>>>         existing
>>>>>>>>>>>>         security infrastructures (eg.: SAML-based
>>>>>>>>>>>>         infrastructures)
>>>>>>>>>>>>         to
>>>>>>>>>>>>         benefit
>>>>>>>>>>>>         from KC's support for cloud, rest and mobile use
>>>>>>>>>>>>         cases.
>>>>>>>>>>>>
>>>>>>>>>>>>         I think this is enough to start a discussion. I've an
>>>>>>>>>>>>         initial
>>>>>>>>>>>>         discussion with Stian about all that and we agreed
>>>>>>>>>>>>         that
>>>>>>>>>>>>         abstract
>>>>>>>>>>>>         the
>>>>>>>>>>>>         protocol from applications should be prioritized. The
>>>>>>>>>>>>         main
>>>>>>>>>>>>         reason is
>>>>>>>>>>>>         that it makes life easier for applications so they
>>>>>>>>>>>>         only
>>>>>>>>>>>>         need
>>>>>>>>>>>>         to
>>>>>>>>>>>>         know
>>>>>>>>>>>>         about KC tokens and nothing else. However that brings
>>>>>>>>>>>>         some
>>>>>>>>>>>>         new
>>>>>>>>>>>>         requirements around user provisioning and
>>>>>>>>>>>>         claim/attribute
>>>>>>>>>>>>         resolution
>>>>>>>>>>>>         or mapping. But that would be another thread.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Can you elaborate on "abstract the protocol from
>>>>>>>>>>> applications"?
>>>>>>>>>>> Not
>>>>>>>>>>> sure what you mean by that.  IDP federation should be
>>>>>>>>>>> configured
>>>>>>>>>>> at
>>>>>>>>>>> the
>>>>>>>>>>> realm level and really has nothing to do with applications.
>>>>>>>>>>>
>>>>>>>>>>> I'm really happy that somebody is doing this.  We're getting a
>>>>>>>>>>> real
>>>>>>>>>>> impressive feature set!
>>>>>>>>>>
>>>>>>>>>> Sure. What I meant was that the application only knows about KC
>>>>>>>>>> tokens
>>>>>>>>>> nothing else. It will always receive a KC token regardless the
>>>>>>>>>> protocol
>>>>>>>>>> used
>>>>>>>>>> to authenticate the user against a 3rd party IdP (saml, oidc,
>>>>>>>>>> whatever).
>>>>>>>>>> The
>>>>>>>>>> example I gave was about an user trying to authenticate against
>>>>>>>>>> a
>>>>>>>>>> SAML
>>>>>>>>>> IdP.
>>>>>>>>>> In this case, after a successful authentication on the IdP, the
>>>>>>>>>> IdP
>>>>>>>>>> will
>>>>>>>>>> issue a token to KC. Then KC will validate the token, perform
>>>>>>>>>> trust
>>>>>>>>>> and
>>>>>>>>>> security checks, do user provisioning and attribute/claim
>>>>>>>>>> resolution
>>>>>>>>>> to
>>>>>>>>>> finally issue a KC token and redirect the user to the
>>>>>>>>>> application.
>>>>>>>>>> If
>>>>>>>>>> the
>>>>>>>>>> app is configured to use openid in KC then it will receive a
>>>>>>>>>> openid
>>>>>>>>>> token
>>>>>>>>>> from KC, not saml ...
>>>>>>>>>>
>>>>>>>>>> The other scenario is pretty much the same. The difference is
>>>>>>>>>> that
>>>>>>>>>> KC
>>>>>>>>>> will
>>>>>>>>>> not issue its own token but just replay the token issued by the
>>>>>>>>>> 3rd
>>>>>>>>>> party
>>>>>>>>>> IdP to the service provider.
>>>>>>>>>>
>>>>>>>>>> I agree that this config goes at the realm level. For instance,
>>>>>>>>>> to
>>>>>>>>>> create
>>>>>>>>>> and
>>>>>>>>>> enable providers for being used. However, I think we would need
>>>>>>>>>> some
>>>>>>>>>> specific configuration for applications as well. Specially when
>>>>>>>>>> defining
>>>>>>>>>> default roles, mapping attributes. Another example of
>>>>>>>>>> application
>>>>>>>>>> config
>>>>>>>>>> is
>>>>>>>>>> when using a OIDC/oAuth IdP. You may want to define scopes
>>>>>>>>>> per-application.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Bill Burke
>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
> _______________________________________________
> 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 Dec  5 08:33:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 08:33:45 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <5481B318.9080609@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<5481B318.9080609@redhat.com>
Message-ID: <1557601322.11298031.1417786425846.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 2:28:56 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Get rid of the social button?

Yes, that's the idea. One place to configure Identity Providers in general instead of one for "enterprise" and one for social. 

Initially I thought keeping social separate would be best, but looking at Pedro's screenshots it seems it would work well to combine the two.

> 
> On 12/5/2014 3:15 AM, Stian Thorgersen wrote:
> > Having a separate enable/disable for each provider would be good. If you're
> > leaving the social tab as is and adding a separate tab for configuring
> > brokered idp's then we should leave the social enable/disable button,
> > otherwise it depends how it'll look like in the end.
> >
> > ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 5 December, 2014 2:29:37 AM
> >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>
> >> Hi,
> >>
> >>     Social has a button to enable/disable it. I'm wondering what to do
> >>     with
> >>     the brokered identity providers. Shall we add a similar flag for that
> >>     ?
> >>
> >>     I was also wondering if the best would be a flag in a per provider
> >>     basis.
> >>     So we can disable/enable a specific provider (social or brokered),
> >>     instead of doing that for all.
> >>
> >> Regards.
> >> Pedro Igor
> >>
> >> ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, December 2, 2014 10:42:11 AM
> >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>
> >> ----- Original Message -----
> >>> From: "Stian Thorgersen" <stian at redhat.com>
> >>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, December 2, 2014 10:23:24 AM
> >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 2 December, 2014 1:13:08 PM
> >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>>>
> >>>> I'll go for it then. Will remove the icon url from the model and leave
> >>>> that
> >>>> for users if they want to provide icons for their identity providers.
> >>>>
> >>>> My point is that icons can be usually served by the same
> >>>> server/application
> >>>> or proxy, so download images are not such a big deal. Also, the icon url
> >>>> is
> >>>> part of the freemarker model and people can do what ever they want with
> >>>> it.
> >>>> What I think will also help in your future plans.
> >>>
> >>> I'm not following. Are you saying that if a named image 'my-provider.png'
> >>> is
> >>> loaded from a theme, then you can override it in another theme?
> >>>
> >>> If so, that's basically the same as having a css class 'my-provider' in a
> >>> theme. With the exception that with an image you end up with having to
> >>> require a image per provider per theme per language, which could be a lot
> >>> of
> >>> images for a single provider. Also, buttons for accessibility should be
> >>> defined with text and css, not images that can't be interpreted. You also
> >>> still need to modify the theme, so I don't see any benefits.
> >>
> >> You are right. Having a icon url per provider does not makes sense if
> >> there
> >> are requirements to change images accordingly to a theme or language. CSS
> >> makes life easier.
> >>
> >> Will remove that property from the model.
> >>
> >>>
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, December 2, 2014 10:04:33 AM
> >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Tuesday, 2 December, 2014 12:55:21 PM
> >>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>>>> Broker
> >>>>>
> >>>>> Users can now specify a Icon Url to be rendered on the login page when
> >>>>> social
> >>>>> or any other identity provider is configured. So we just load the image
> >>>>> the
> >>>>> url entered by the user.
> >>>>>
> >>>>> Are you saying that users should change the theme or customize css if
> >>>>> they
> >>>>> only want to change an icon for a provider ?
> >>>>
> >>>> Yes, there's many issues with having a icon url:
> >>>>
> >>>> * Won't work for internationalization - we don't have this now, but we
> >>>> will
> >>>> * Image is not a good button - CSS is much better
> >>>> * Doesn't support themes - we allow users to switch l&f by switching
> >>>> themes,
> >>>> but that won't work for a icon url. In the future we may also support
> >>>> multiple themes per-realm, for example to depending on the devices (one
> >>>> theme for mobiles, one for desktops, etc)
> >>>> * Requires the URL to be hosted somewhere - why require a separate call
> >>>> to
> >>>> download an image (to a separate server maybe) if it can simply be
> >>>> defined
> >>>> in a single CSS file?
> >>>>
> >>>> Rather than add additional places to define look and feel components we
> >>>> should in the future make it easier to add/customize themes.
> >>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Tuesday, December 2, 2014 9:42:15 AM
> >>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>>>> Broker
> >>>>>
> >>>>> All look and feel related things including images and stylesheets
> >>>>> should
> >>>>> be
> >>>>> part of themes. This is to allow customizing them in the theme. Also,
> >>>>> an
> >>>>> image is not the correct way to render a button, it should be defined
> >>>>> in
> >>>>> CSS.
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Tuesday, 2 December, 2014 12:34:45 PM
> >>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>>>>> Broker
> >>>>>>
> >>>>>> You shouldn't have icon images for social providers. They should be
> >>>>>> specified
> >>>>>> as part of the theme in CSS as is now.
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>> To: "Bill Burke" <bburke at redhat.com>
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Tuesday, 2 December, 2014 12:22:21 PM
> >>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>>>>>> Broker
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>      Anyone know where I can get the icons images for social
> >>>>>>>      providers
> >>>>>>>      ?
> >>>>>>>      It
> >>>>>>>      seems zocial defines them encoded in some way in CSS. I need
> >>>>>>>      that
> >>>>>>>      to
> >>>>>>>      provide default images if user does not specify their own.
> >>>>>>>
> >>>>>>>      Or is still possible to use zocial ones ?
> >>>>>>>
> >>>>>>> Regards.
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>> To: "Bill Burke" <bburke at redhat.com>
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Thursday, November 27, 2014 9:01:38 PM
> >>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>>>>>> Broker
> >>>>>>>
> >>>>>>> Hi guys,
> >>>>>>>
> >>>>>>>     I've done some initial work covering both persistence and
> >>>>>>>     brokering.
> >>>>>>>     No
> >>>>>>>     UI, yet. I'm focused on the model, rest api and brokering
> >>>>>>>     functionality
> >>>>>>>     for now.
> >>>>>>>
> >>>>>>>     What I have is enough to decide if we are aligned about this
> >>>>>>>     functionality. So you can understand how the model (and
> >>>>>>>     persistence),
> >>>>>>>     rest api and brokering functionality looks like. Can we schedule
> >>>>>>>     a
> >>>>>>>     meeting ?
> >>>>>>>
> >>>>>>>     Btw, my branch is here [1].
> >>>>>>>
> >>>>>>> [1]
> >>>>>>> https://github.com/pedroigor/keycloak/tree/authentication-broker2
> >>>>>>>
> >>>>>>> Regards.
> >>>>>>> Pedro Igor
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Thursday, November 20, 2014 2:48:49 PM
> >>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>>>>>> Broker
> >>>>>>>
> >>>>>>> Currently adapters can only make authz decisions (@RolesAllowed)
> >>>>>>> based
> >>>>>>> on either realm roles or the roles of one specific application.
> >>>>>>> This
> >>>>>>> is
> >>>>>>> related to 1) too.
> >>>>>>>
> >>>>>>> On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> >>>>>>>> 1) Sounds like something definitely worth aiming for.
> >>>>>>>>
> >>>>>>>> On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> >>>>>>>>> I just wanted to quickly list the additional work we discussed
> >>>>>>>>> so
> >>>>>>>>> everyone
> >>>>>>>>> can think about it (in no particular order):
> >>>>>>>>>
> >>>>>>>>> 1) Mapping of tokens - how do we deal with mapping of an
> >>>>>>>>> external
> >>>>>>>>> token
> >>>>>>>>> to
> >>>>>>>>> a KC token? For example an external token with attribute 'group'
> >>>>>>>>> that
> >>>>>>>>> contains 'sales' and 'manager' could be mapped to 'manager' role
> >>>>>>>>> for
> >>>>>>>>> 'sales app in a KC token. Could we use Drools? This could also
> >>>>>>>>> be
> >>>>>>>>> used
> >>>>>>>>> in
> >>>>>>>>> user federation to allow more complex mapping of roles/groups
> >>>>>>>>> than
> >>>>>>>>> a
> >>>>>>>>> simple 1-1
> >>>>>>>>> 2) Retrieving tokens - if an application wants to retrieve the
> >>>>>>>>> external
> >>>>>>>>> token (for example to view Facebook friends if user logged in
> >>>>>>>>> with
> >>>>>>>>> Facebook)
> >>>>>>>>> 3) Configure scope - currently for social we only request a very
> >>>>>>>>> limited
> >>>>>>>>> scope (basic profile and email), to for example view Facebook
> >>>>>>>>> friends
> >>>>>>>>> we'd need to ask for that as well
> >>>>>>>>> 4) Selecting provider - currently in social (and for first pass
> >>>>>>>>> of
> >>>>>>>>> brokering) we have an icon user has to select, but can we select
> >>>>>>>>> the
> >>>>>>>>> provider in a different way (for example ask user for email, and
> >>>>>>>>> select
> >>>>>>>>> based on email domain)
> >>>>>>>>> 5) Gateway - don't create a KC token, but just forward the
> >>>>>>>>> external
> >>>>>>>>> token
> >>>>>>>>>
> >>>>>>>>> IMO 1) is a killer feature, as it would allow companies to add
> >>>>>>>>> external
> >>>>>>>>> users without having to modify their applications. Issue with 5)
> >>>>>>>>> is
> >>>>>>>>> that
> >>>>>>>>> applications need to understand more than one token, which would
> >>>>>>>>> require
> >>>>>>>>> rewriting applications.
> >>>>>>>>>
> >>>>>>>>> This work is also somewhat related to other authentication
> >>>>>>>>> mechanisms
> >>>>>>>>> (for
> >>>>>>>>> example Kerberos ticket, LDAP and passwordless).
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>>>>> To: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>>>>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> >>>>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and
> >>>>>>>>>> Authentication
> >>>>>>>>>> Broker
> >>>>>>>>>>
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> >>>>>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and
> >>>>>>>>>>> Authentication
> >>>>>>>>>>> Broker
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>>         Would like to start a discussion about how to enable
> >>>>>>>>>>>>         KC
> >>>>>>>>>>>>         as
> >>>>>>>>>>>>         an
> >>>>>>>>>>>>         Authentication Broker in order to supported Chained
> >>>>>>>>>>>>         Federation
> >>>>>>>>>>>>         and
> >>>>>>>>>>>>         also Identity Federation. First of all, some
> >>>>>>>>>>>>         background
> >>>>>>>>>>>>         about
> >>>>>>>>>>>>         what
> >>>>>>>>>>>>         this is all about.
> >>>>>>>>>>>>
> >>>>>>>>>>>>         Currently KeyCloak provides two basic types of
> >>>>>>>>>>>>         authentication
> >>>>>>>>>>>>         (correct
> >>>>>>>>>>>>         me if I'm wrong, please):
> >>>>>>>>>>>>
> >>>>>>>>>>>>             1) Local authentication (based on some credential
> >>>>>>>>>>>>             type
> >>>>>>>>>>>>             enabled
> >>>>>>>>>>>>             to
> >>>>>>>>>>>>             a realm)
> >>>>>>>>>>>>             2) Social authentication
> >>>>>>>>>>>>
> >>>>>>>>>>>>         Local authentication is about authenticating the user
> >>>>>>>>>>>>         locally
> >>>>>>>>>>>>         using
> >>>>>>>>>>>>         KC's own identity store. Nothing special here. And
> >>>>>>>>>>>>         Social
> >>>>>>>>>>>>         Authentication which allows users to choose the Social
> >>>>>>>>>>>>         IdP
> >>>>>>>>>>>>         they
> >>>>>>>>>>>>         want
> >>>>>>>>>>>>         to authenticate with. In this case, the IdP is always
> >>>>>>>>>>>>         one
> >>>>>>>>>>>>         of
> >>>>>>>>>>>>         the
> >>>>>>>>>>>>         built-in social providers supported by KC such as
> >>>>>>>>>>>>         Facebook,
> >>>>>>>>>>>>         Google,
> >>>>>>>>>>>>         Twitter, Github and so forth.
> >>>>>>>>>>>>
> >>>>>>>>>>>>         When doing social, the user is automatically
> >>>>>>>>>>>>         provisioned
> >>>>>>>>>>>>         in
> >>>>>>>>>>>>         KC
> >>>>>>>>>>>>         identity store after a successful authentication. The
> >>>>>>>>>>>>         user
> >>>>>>>>>>>>         does
> >>>>>>>>>>>>         not
> >>>>>>>>>>>>         need to fill a registration form and can access the
> >>>>>>>>>>>>         application
> >>>>>>>>>>>>         very
> >>>>>>>>>>>>         quickly. During the provisioning some basic
> >>>>>>>>>>>>         information
> >>>>>>>>>>>>         is
> >>>>>>>>>>>>         retrieved
> >>>>>>>>>>>>         from the social provider such as email, firstname and
> >>>>>>>>>>>>         so
> >>>>>>>>>>>>         forth.
> >>>>>>>>>>>>         These
> >>>>>>>>>>>>         are very basic information, any other information such
> >>>>>>>>>>>>         as
> >>>>>>>>>>>>         those
> >>>>>>>>>>>>         related with authorization policies - eg.: roles and
> >>>>>>>>>>>>         groups
> >>>>>>>>>>>>         -
> >>>>>>>>>>>>         must
> >>>>>>>>>>>>         be
> >>>>>>>>>>>>         defined later via KC's admin console.
> >>>>>>>>>>>>
> >>>>>>>>>>>>         Another important characteristic of social
> >>>>>>>>>>>>         authentication
> >>>>>>>>>>>>         is
> >>>>>>>>>>>>         that
> >>>>>>>>>>>>         the
> >>>>>>>>>>>>         application receives a KC token and not the token that
> >>>>>>>>>>>>         was
> >>>>>>>>>>>>         issued by
> >>>>>>>>>>>>         the social IdP during the authentication process. If
> >>>>>>>>>>>>         the
> >>>>>>>>>>>>         application
> >>>>>>>>>>>>         wants to consume resources from the resource provider
> >>>>>>>>>>>>         he
> >>>>>>>>>>>>         was
> >>>>>>>>>>>>         authenticated it must obtain the access token(again)
> >>>>>>>>>>>>         by
> >>>>>>>>>>>>         itself
> >>>>>>>>>>>>         prior
> >>>>>>>>>>>>         to invoke the resource provider API. Assuming all
> >>>>>>>>>>>>         those
> >>>>>>>>>>>>         social
> >>>>>>>>>>>>         providers are based on oAuth 1.0 or 2.0.
> >>>>>>>>>>>>
> >>>>>>>>>>>>         That said, the Authentication Broker functionality
> >>>>>>>>>>>>         aims
> >>>>>>>>>>>>         to
> >>>>>>>>>>>>         cover
> >>>>>>>>>>>>         the
> >>>>>>>>>>>>         same use cases but with a lot of more flexibility on
> >>>>>>>>>>>>         how
> >>>>>>>>>>>>         you
> >>>>>>>>>>>>         setup
> >>>>>>>>>>>>         identity providers(not only social ones) and the
> >>>>>>>>>>>>         different
> >>>>>>>>>>>>         federation
> >>>>>>>>>>>>         protocols they may support such as SAML, OpenID, oAuth
> >>>>>>>>>>>>         and
> >>>>>>>>>>>>         so
> >>>>>>>>>>>>         forth.
> >>>>>>>>>>>>         This is useful when an enterprise is providing
> >>>>>>>>>>>>         services
> >>>>>>>>>>>>         to
> >>>>>>>>>>>>         different
> >>>>>>>>>>>>         customers(IdP) and does not want to manage many to
> >>>>>>>>>>>>         many
> >>>>>>>>>>>>         relationships. When using a broker, the authentication
> >>>>>>>>>>>>         steps
> >>>>>>>>>>>>         are
> >>>>>>>>>>>>         pretty much the same when you are using social
> >>>>>>>>>>>>         authentication,
> >>>>>>>>>>>>         with
> >>>>>>>>>>>>         important differences on how you support different
> >>>>>>>>>>>>         identity
> >>>>>>>>>>>>         providers, different federation protocols, how users
> >>>>>>>>>>>>         are
> >>>>>>>>>>>>         provisioned
> >>>>>>>>>>>>         and how claims and attributes are resolved.
> >>>>>>>>>>>>
> >>>>>>>>>>>>         The brokering functionality can be done in two ways
> >>>>>>>>>>>>         depending
> >>>>>>>>>>>>         if
> >>>>>>>>>>>>         the
> >>>>>>>>>>>>         broker service is acting as a gateway or not. When
> >>>>>>>>>>>>         acting
> >>>>>>>>>>>>         as
> >>>>>>>>>>>>         a
> >>>>>>>>>>>>         gateway, the broker will respond to the application
> >>>>>>>>>>>>         the
> >>>>>>>>>>>>         same
> >>>>>>>>>>>>         token
> >>>>>>>>>>>>         issued by the trusted identity provider. For instance,
> >>>>>>>>>>>>         if
> >>>>>>>>>>>>         the
> >>>>>>>>>>>>         user
> >>>>>>>>>>>>         selects a SAML IdP to authenticate with, the
> >>>>>>>>>>>>         application
> >>>>>>>>>>>>         will
> >>>>>>>>>>>>         receive
> >>>>>>>>>>>>         a SAML Response. In this case, the application must
> >>>>>>>>>>>>         also
> >>>>>>>>>>>>         be
> >>>>>>>>>>>>         prepared
> >>>>>>>>>>>>         to handle a specific federation protocol.
> >>>>>>>>>>>>
> >>>>>>>>>>>>         However, the broker service can also be used to
> >>>>>>>>>>>>         completely
> >>>>>>>>>>>>         abstract
> >>>>>>>>>>>>         from the application the protocol used to authenticate
> >>>>>>>>>>>>         an
> >>>>>>>>>>>>         user.
> >>>>>>>>>>>>         In
> >>>>>>>>>>>>         this case, the application will just receive an
> >>>>>>>>>>>>         ordinary
> >>>>>>>>>>>>         KC
> >>>>>>>>>>>>         token
> >>>>>>>>>>>>         after a successful authentication.
> >>>>>>>>>>>>
> >>>>>>>>>>>>         In both cases, the broker acts as an intermediary
> >>>>>>>>>>>>         where
> >>>>>>>>>>>>         specific
> >>>>>>>>>>>>         security policies can be applied when users try to
> >>>>>>>>>>>>         authenticate
> >>>>>>>>>>>>         themselves against a 3rd party IdP. That brings a lot
> >>>>>>>>>>>>         of
> >>>>>>>>>>>>         value
> >>>>>>>>>>>>         when
> >>>>>>>>>>>>         you think about auditing, authorization and how users
> >>>>>>>>>>>>         are
> >>>>>>>>>>>>         provisioned
> >>>>>>>>>>>>         when federation of identities is needed. This also
> >>>>>>>>>>>>         allows
> >>>>>>>>>>>>         existing
> >>>>>>>>>>>>         security infrastructures (eg.: SAML-based
> >>>>>>>>>>>>         infrastructures)
> >>>>>>>>>>>>         to
> >>>>>>>>>>>>         benefit
> >>>>>>>>>>>>         from KC's support for cloud, rest and mobile use
> >>>>>>>>>>>>         cases.
> >>>>>>>>>>>>
> >>>>>>>>>>>>         I think this is enough to start a discussion. I've an
> >>>>>>>>>>>>         initial
> >>>>>>>>>>>>         discussion with Stian about all that and we agreed
> >>>>>>>>>>>>         that
> >>>>>>>>>>>>         abstract
> >>>>>>>>>>>>         the
> >>>>>>>>>>>>         protocol from applications should be prioritized. The
> >>>>>>>>>>>>         main
> >>>>>>>>>>>>         reason is
> >>>>>>>>>>>>         that it makes life easier for applications so they
> >>>>>>>>>>>>         only
> >>>>>>>>>>>>         need
> >>>>>>>>>>>>         to
> >>>>>>>>>>>>         know
> >>>>>>>>>>>>         about KC tokens and nothing else. However that brings
> >>>>>>>>>>>>         some
> >>>>>>>>>>>>         new
> >>>>>>>>>>>>         requirements around user provisioning and
> >>>>>>>>>>>>         claim/attribute
> >>>>>>>>>>>>         resolution
> >>>>>>>>>>>>         or mapping. But that would be another thread.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Can you elaborate on "abstract the protocol from
> >>>>>>>>>>> applications"?
> >>>>>>>>>>> Not
> >>>>>>>>>>> sure what you mean by that.  IDP federation should be
> >>>>>>>>>>> configured
> >>>>>>>>>>> at
> >>>>>>>>>>> the
> >>>>>>>>>>> realm level and really has nothing to do with applications.
> >>>>>>>>>>>
> >>>>>>>>>>> I'm really happy that somebody is doing this.  We're getting a
> >>>>>>>>>>> real
> >>>>>>>>>>> impressive feature set!
> >>>>>>>>>>
> >>>>>>>>>> Sure. What I meant was that the application only knows about KC
> >>>>>>>>>> tokens
> >>>>>>>>>> nothing else. It will always receive a KC token regardless the
> >>>>>>>>>> protocol
> >>>>>>>>>> used
> >>>>>>>>>> to authenticate the user against a 3rd party IdP (saml, oidc,
> >>>>>>>>>> whatever).
> >>>>>>>>>> The
> >>>>>>>>>> example I gave was about an user trying to authenticate against
> >>>>>>>>>> a
> >>>>>>>>>> SAML
> >>>>>>>>>> IdP.
> >>>>>>>>>> In this case, after a successful authentication on the IdP, the
> >>>>>>>>>> IdP
> >>>>>>>>>> will
> >>>>>>>>>> issue a token to KC. Then KC will validate the token, perform
> >>>>>>>>>> trust
> >>>>>>>>>> and
> >>>>>>>>>> security checks, do user provisioning and attribute/claim
> >>>>>>>>>> resolution
> >>>>>>>>>> to
> >>>>>>>>>> finally issue a KC token and redirect the user to the
> >>>>>>>>>> application.
> >>>>>>>>>> If
> >>>>>>>>>> the
> >>>>>>>>>> app is configured to use openid in KC then it will receive a
> >>>>>>>>>> openid
> >>>>>>>>>> token
> >>>>>>>>>> from KC, not saml ...
> >>>>>>>>>>
> >>>>>>>>>> The other scenario is pretty much the same. The difference is
> >>>>>>>>>> that
> >>>>>>>>>> KC
> >>>>>>>>>> will
> >>>>>>>>>> not issue its own token but just replay the token issued by the
> >>>>>>>>>> 3rd
> >>>>>>>>>> party
> >>>>>>>>>> IdP to the service provider.
> >>>>>>>>>>
> >>>>>>>>>> I agree that this config goes at the realm level. For instance,
> >>>>>>>>>> to
> >>>>>>>>>> create
> >>>>>>>>>> and
> >>>>>>>>>> enable providers for being used. However, I think we would need
> >>>>>>>>>> some
> >>>>>>>>>> specific configuration for applications as well. Specially when
> >>>>>>>>>> defining
> >>>>>>>>>> default roles, mapping attributes. Another example of
> >>>>>>>>>> application
> >>>>>>>>>> config
> >>>>>>>>>> is
> >>>>>>>>>> when using a OIDC/oAuth IdP. You may want to define scopes
> >>>>>>>>>> per-application.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Bill Burke
> >>>>>>>>>>> JBoss, a division of Red Hat
> >>>>>>>>>>> http://bill.burkecentral.com
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> keycloak-dev mailing list
> >>>>>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> 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
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> keycloak-dev mailing list
> >>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> keycloak-dev mailing list
> >>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> keycloak-dev mailing list
> >>>>>> keycloak-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> > _______________________________________________
> > 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 psilva at redhat.com  Fri Dec  5 08:36:14 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 Dec 2014 08:36:14 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
Message-ID: <691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, December 5, 2014 10:59:08 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> Another related thing. We've had a few people ask to be able to login to
> Keycloak on mobiles using the native social login mechanism.
> 
> I think the best way to do that is to use the direct grant api and make it
> possible to call that endpoint passing a IdP id and a token instead of
> username and password.
> 
> WDYT?

The broker endpoint expects the idp id in order to start the authentication process. Today, the endpoint also expects KCs authorization code in order to validate requests from clients and use it as a state to validate responses from the trusted idps.

This authorization code is a blocker for this use case, given that mobile don't have this code and just want to start the authentication.

A possible solution would be to change the broker to also accept a client_id to reference the mobile app and perform some validations based on that. Something like that:

1) Mobile displays a Facebook button
2) User clicks the button and mobile sends a request to KC Broker with the idp id and his client_id.
3) KC Broker checks if the client_id is valid and creates a temporary authorization code.
4) KC Broker redirect mobile to the chosen IdP to perform authentication.
5) KC Broker receives a response from the IdP, generate its own token and send it back to mobile

Makes sense ?

> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 5 December, 2014 1:45:24 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Looks good. I reckon we can combine the two pages. What about if the 'Add
> > > provider' drop-down is:
> > > 
> > >   OpenID
> > >   SAML
> > >   ------
> > >   Google
> > >   GitHub
> > >   Facebook
> > >   Twitter
> > > 
> > > Let's drop social on/off and instead have a enable/disable button on each
> > > provider.
> > 
> > Sure.
> > 
> > > 
> > > Also, would be nice if users could set a name or alias for a provider
> > > instance. This would make the callback url easier to use (instead of
> > > callback/<UUID> it's callback/<alias>). The user federation providers
> > > have
> > > this.
> > 
> > One of my first tries was using an alias, just like that. But I preferred
> > using the UUID and make the configuration more easier. Beside that, the
> > callback url is just a copy and paste, so I think an alias would not bring
> > so much usability, but add one more step when configuring providers.
> > 
> > However, if this is an usability requirement for KC I can change that.
> > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > In one of our last discussions, you suggested to leave Social as it is.
> > > > Although IMO I think we can have a single place to manage both social
> > > > and
> > > > user-defined identity providers. Social ones are just OOTB and
> > > > pre-configured identity providers now.
> > > > 
> > > > That said, today I'm using separated tabs for social and user-defined.
> > > > Please, take a look at [1] for more details on how the UI looks like.
> > > > 
> > > > I've changed social UI a bit in order to provide a specific page for
> > > > create/update. I've also added a "Show Secret" link to display the
> > > > client_secret in clear text if user wants to.
> > > > 
> > > > Beside the enable/disable button, I think another good thing to do is
> > > > specify
> > > > a default role(s) for each provider. That can be useful if applications
> > > > want
> > > > to perform any kind of authorization based on the identity provider or
> > > > authentication method used to authenticate an user (eg.: useful for
> > > > adaptative or multi-level access control). We can also use the "amr"
> > > > claim
> > > > in the ID Token, which seems KC is not considering at all. The latter
> > > > is
> > > > an
> > > > important thing to think of, regardless this broker work I'm doing.
> > > > 
> > > > [1]
> > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > 
> > > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Having a separate enable/disable for each provider would be good. If
> > > > you're
> > > > leaving the social tab as is and adding a separate tab for configuring
> > > > brokered idp's then we should leave the social enable/disable button,
> > > > otherwise it depends how it'll look like in the end.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Hi,
> > > > > 
> > > > >    Social has a button to enable/disable it. I'm wondering what to do
> > > > >    with
> > > > >    the brokered identity providers. Shall we add a similar flag for
> > > > >    that
> > > > >    ?
> > > > > 
> > > > >    I was also wondering if the best would be a flag in a per provider
> > > > >    basis.
> > > > >    So we can disable/enable a specific provider (social or brokered),
> > > > >    instead of doing that for all.
> > > > > 
> > > > > Regards.
> > > > > Pedro Igor
> > > > > 
> > > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > I'll go for it then. Will remove the icon url from the model and
> > > > > > > leave
> > > > > > > that
> > > > > > > for users if they want to provide icons for their identity
> > > > > > > providers.
> > > > > > > 
> > > > > > > My point is that icons can be usually served by the same
> > > > > > > server/application
> > > > > > > or proxy, so download images are not such a big deal. Also, the
> > > > > > > icon
> > > > > > > url
> > > > > > > is
> > > > > > > part of the freemarker model and people can do what ever they
> > > > > > > want
> > > > > > > with
> > > > > > > it.
> > > > > > > What I think will also help in your future plans.
> > > > > > 
> > > > > > I'm not following. Are you saying that if a named image
> > > > > > 'my-provider.png'
> > > > > > is
> > > > > > loaded from a theme, then you can override it in another theme?
> > > > > > 
> > > > > > If so, that's basically the same as having a css class
> > > > > > 'my-provider'
> > > > > > in
> > > > > > a
> > > > > > theme. With the exception that with an image you end up with having
> > > > > > to
> > > > > > require a image per provider per theme per language, which could be
> > > > > > a
> > > > > > lot
> > > > > > of
> > > > > > images for a single provider. Also, buttons for accessibility
> > > > > > should
> > > > > > be
> > > > > > defined with text and css, not images that can't be interpreted.
> > > > > > You
> > > > > > also
> > > > > > still need to modify the theme, so I don't see any benefits.
> > > > > 
> > > > > You are right. Having a icon url per provider does not makes sense if
> > > > > there
> > > > > are requirements to change images accordingly to a theme or language.
> > > > > CSS
> > > > > makes life easier.
> > > > > 
> > > > > Will remove that property from the model.
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > Users can now specify a Icon Url to be rendered on the login
> > > > > > > > page
> > > > > > > > when
> > > > > > > > social
> > > > > > > > or any other identity provider is configured. So we just load
> > > > > > > > the
> > > > > > > > image
> > > > > > > > the
> > > > > > > > url entered by the user.
> > > > > > > > 
> > > > > > > > Are you saying that users should change the theme or customize
> > > > > > > > css
> > > > > > > > if
> > > > > > > > they
> > > > > > > > only want to change an icon for a provider ?
> > > > > > > 
> > > > > > > Yes, there's many issues with having a icon url:
> > > > > > > 
> > > > > > > * Won't work for internationalization - we don't have this now,
> > > > > > > but
> > > > > > > we
> > > > > > > will
> > > > > > > * Image is not a good button - CSS is much better
> > > > > > > * Doesn't support themes - we allow users to switch l&f by
> > > > > > > switching
> > > > > > > themes,
> > > > > > > but that won't work for a icon url. In the future we may also
> > > > > > > support
> > > > > > > multiple themes per-realm, for example to depending on the
> > > > > > > devices
> > > > > > > (one
> > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > * Requires the URL to be hosted somewhere - why require a
> > > > > > > separate
> > > > > > > call
> > > > > > > to
> > > > > > > download an image (to a separate server maybe) if it can simply
> > > > > > > be
> > > > > > > defined
> > > > > > > in a single CSS file?
> > > > > > > 
> > > > > > > Rather than add additional places to define look and feel
> > > > > > > components
> > > > > > > we
> > > > > > > should in the future make it easier to add/customize themes.
> > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > All look and feel related things including images and
> > > > > > > > stylesheets
> > > > > > > > should
> > > > > > > > be
> > > > > > > > part of themes. This is to allow customizing them in the theme.
> > > > > > > > Also,
> > > > > > > > an
> > > > > > > > image is not the correct way to render a button, it should be
> > > > > > > > defined
> > > > > > > > in
> > > > > > > > CSS.
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > You shouldn't have icon images for social providers. They
> > > > > > > > > should
> > > > > > > > > be
> > > > > > > > > specified
> > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > >     Anyone know where I can get the icons images for social
> > > > > > > > > >     providers
> > > > > > > > > >     ?
> > > > > > > > > >     It
> > > > > > > > > >     seems zocial defines them encoded in some way in CSS. I
> > > > > > > > > >     need
> > > > > > > > > >     that
> > > > > > > > > >     to
> > > > > > > > > >     provide default images if user does not specify their
> > > > > > > > > >     own.
> > > > > > > > > > 
> > > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > > 
> > > > > > > > > > Regards.
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > Hi guys,
> > > > > > > > > > 
> > > > > > > > > >    I've done some initial work covering both persistence
> > > > > > > > > >    and
> > > > > > > > > >    brokering.
> > > > > > > > > >    No
> > > > > > > > > >    UI, yet. I'm focused on the model, rest api and
> > > > > > > > > >    brokering
> > > > > > > > > >    functionality
> > > > > > > > > >    for now.
> > > > > > > > > > 
> > > > > > > > > >    What I have is enough to decide if we are aligned about
> > > > > > > > > >    this
> > > > > > > > > >    functionality. So you can understand how the model (and
> > > > > > > > > >    persistence),
> > > > > > > > > >    rest api and brokering functionality looks like. Can we
> > > > > > > > > >    schedule
> > > > > > > > > >    a
> > > > > > > > > >    meeting ?
> > > > > > > > > > 
> > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > 
> > > > > > > > > > [1]
> > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > 
> > > > > > > > > > Regards.
> > > > > > > > > > Pedro Igor
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > based
> > > > > > > > > > on either realm roles or the roles of one specific
> > > > > > > > > > application.
> > > > > > > > > > This
> > > > > > > > > > is
> > > > > > > > > > related to 1) too.
> > > > > > > > > > 
> > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > > > > > >
> > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > > > >> I just wanted to quickly list the additional work we
> > > > > > > > > > >> discussed
> > > > > > > > > > >> so
> > > > > > > > > > >> everyone
> > > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > > >>
> > > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an
> > > > > > > > > > >> external
> > > > > > > > > > >> token
> > > > > > > > > > >> to
> > > > > > > > > > >> a KC token? For example an external token with attribute
> > > > > > > > > > >> 'group'
> > > > > > > > > > >> that
> > > > > > > > > > >> contains 'sales' and 'manager' could be mapped to
> > > > > > > > > > >> 'manager'
> > > > > > > > > > >> role
> > > > > > > > > > >> for
> > > > > > > > > > >> 'sales app in a KC token. Could we use Drools? This
> > > > > > > > > > >> could
> > > > > > > > > > >> also
> > > > > > > > > > >> be
> > > > > > > > > > >> used
> > > > > > > > > > >> in
> > > > > > > > > > >> user federation to allow more complex mapping of
> > > > > > > > > > >> roles/groups
> > > > > > > > > > >> than
> > > > > > > > > > >> a
> > > > > > > > > > >> simple 1-1
> > > > > > > > > > >> 2) Retrieving tokens - if an application wants to
> > > > > > > > > > >> retrieve
> > > > > > > > > > >> the
> > > > > > > > > > >> external
> > > > > > > > > > >> token (for example to view Facebook friends if user
> > > > > > > > > > >> logged
> > > > > > > > > > >> in
> > > > > > > > > > >> with
> > > > > > > > > > >> Facebook)
> > > > > > > > > > >> 3) Configure scope - currently for social we only
> > > > > > > > > > >> request
> > > > > > > > > > >> a
> > > > > > > > > > >> very
> > > > > > > > > > >> limited
> > > > > > > > > > >> scope (basic profile and email), to for example view
> > > > > > > > > > >> Facebook
> > > > > > > > > > >> friends
> > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > >> 4) Selecting provider - currently in social (and for
> > > > > > > > > > >> first
> > > > > > > > > > >> pass
> > > > > > > > > > >> of
> > > > > > > > > > >> brokering) we have an icon user has to select, but can
> > > > > > > > > > >> we
> > > > > > > > > > >> select
> > > > > > > > > > >> the
> > > > > > > > > > >> provider in a different way (for example ask user for
> > > > > > > > > > >> email,
> > > > > > > > > > >> and
> > > > > > > > > > >> select
> > > > > > > > > > >> based on email domain)
> > > > > > > > > > >> 5) Gateway - don't create a KC token, but just forward
> > > > > > > > > > >> the
> > > > > > > > > > >> external
> > > > > > > > > > >> token
> > > > > > > > > > >>
> > > > > > > > > > >> IMO 1) is a killer feature, as it would allow companies
> > > > > > > > > > >> to
> > > > > > > > > > >> add
> > > > > > > > > > >> external
> > > > > > > > > > >> users without having to modify their applications. Issue
> > > > > > > > > > >> with
> > > > > > > > > > >> 5)
> > > > > > > > > > >> is
> > > > > > > > > > >> that
> > > > > > > > > > >> applications need to understand more than one token,
> > > > > > > > > > >> which
> > > > > > > > > > >> would
> > > > > > > > > > >> require
> > > > > > > > > > >> rewriting applications.
> > > > > > > > > > >>
> > > > > > > > > > >> This work is also somewhat related to other
> > > > > > > > > > >> authentication
> > > > > > > > > > >> mechanisms
> > > > > > > > > > >> (for
> > > > > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > > > > >>
> > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > >>> Authentication
> > > > > > > > > > >>> Broker
> > > > > > > > > > >>>
> > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > >>>> Authentication
> > > > > > > > > > >>>> Broker
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > > > > >>>>> Hi,
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        Would like to start a discussion about how to
> > > > > > > > > > >>>>>        enable
> > > > > > > > > > >>>>>        KC
> > > > > > > > > > >>>>>        as
> > > > > > > > > > >>>>>        an
> > > > > > > > > > >>>>>        Authentication Broker in order to supported
> > > > > > > > > > >>>>>        Chained
> > > > > > > > > > >>>>>        Federation
> > > > > > > > > > >>>>>        and
> > > > > > > > > > >>>>>        also Identity Federation. First of all, some
> > > > > > > > > > >>>>>        background
> > > > > > > > > > >>>>>        about
> > > > > > > > > > >>>>>        what
> > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        Currently KeyCloak provides two basic types of
> > > > > > > > > > >>>>>        authentication
> > > > > > > > > > >>>>>        (correct
> > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>            1) Local authentication (based on some
> > > > > > > > > > >>>>>            credential
> > > > > > > > > > >>>>>            type
> > > > > > > > > > >>>>>            enabled
> > > > > > > > > > >>>>>            to
> > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        Local authentication is about authenticating
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        user
> > > > > > > > > > >>>>>        locally
> > > > > > > > > > >>>>>        using
> > > > > > > > > > >>>>>        KC's own identity store. Nothing special here.
> > > > > > > > > > >>>>>        And
> > > > > > > > > > >>>>>        Social
> > > > > > > > > > >>>>>        Authentication which allows users to choose
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        Social
> > > > > > > > > > >>>>>        IdP
> > > > > > > > > > >>>>>        they
> > > > > > > > > > >>>>>        want
> > > > > > > > > > >>>>>        to authenticate with. In this case, the IdP is
> > > > > > > > > > >>>>>        always
> > > > > > > > > > >>>>>        one
> > > > > > > > > > >>>>>        of
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        built-in social providers supported by KC such
> > > > > > > > > > >>>>>        as
> > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > >>>>>        Google,
> > > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        When doing social, the user is automatically
> > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > >>>>>        in
> > > > > > > > > > >>>>>        KC
> > > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > >>>>>        The
> > > > > > > > > > >>>>>        user
> > > > > > > > > > >>>>>        does
> > > > > > > > > > >>>>>        not
> > > > > > > > > > >>>>>        need to fill a registration form and can
> > > > > > > > > > >>>>>        access
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        application
> > > > > > > > > > >>>>>        very
> > > > > > > > > > >>>>>        quickly. During the provisioning some basic
> > > > > > > > > > >>>>>        information
> > > > > > > > > > >>>>>        is
> > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > >>>>>        from the social provider such as email,
> > > > > > > > > > >>>>>        firstname
> > > > > > > > > > >>>>>        and
> > > > > > > > > > >>>>>        so
> > > > > > > > > > >>>>>        forth.
> > > > > > > > > > >>>>>        These
> > > > > > > > > > >>>>>        are very basic information, any other
> > > > > > > > > > >>>>>        information
> > > > > > > > > > >>>>>        such
> > > > > > > > > > >>>>>        as
> > > > > > > > > > >>>>>        those
> > > > > > > > > > >>>>>        related with authorization policies - eg.:
> > > > > > > > > > >>>>>        roles
> > > > > > > > > > >>>>>        and
> > > > > > > > > > >>>>>        groups
> > > > > > > > > > >>>>>        -
> > > > > > > > > > >>>>>        must
> > > > > > > > > > >>>>>        be
> > > > > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        Another important characteristic of social
> > > > > > > > > > >>>>>        authentication
> > > > > > > > > > >>>>>        is
> > > > > > > > > > >>>>>        that
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        application receives a KC token and not the
> > > > > > > > > > >>>>>        token
> > > > > > > > > > >>>>>        that
> > > > > > > > > > >>>>>        was
> > > > > > > > > > >>>>>        issued by
> > > > > > > > > > >>>>>        the social IdP during the authentication
> > > > > > > > > > >>>>>        process.
> > > > > > > > > > >>>>>        If
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        application
> > > > > > > > > > >>>>>        wants to consume resources from the resource
> > > > > > > > > > >>>>>        provider
> > > > > > > > > > >>>>>        he
> > > > > > > > > > >>>>>        was
> > > > > > > > > > >>>>>        authenticated it must obtain the access
> > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > >>>>>        by
> > > > > > > > > > >>>>>        itself
> > > > > > > > > > >>>>>        prior
> > > > > > > > > > >>>>>        to invoke the resource provider API. Assuming
> > > > > > > > > > >>>>>        all
> > > > > > > > > > >>>>>        those
> > > > > > > > > > >>>>>        social
> > > > > > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        That said, the Authentication Broker
> > > > > > > > > > >>>>>        functionality
> > > > > > > > > > >>>>>        aims
> > > > > > > > > > >>>>>        to
> > > > > > > > > > >>>>>        cover
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        same use cases but with a lot of more
> > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > >>>>>        on
> > > > > > > > > > >>>>>        how
> > > > > > > > > > >>>>>        you
> > > > > > > > > > >>>>>        setup
> > > > > > > > > > >>>>>        identity providers(not only social ones) and
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        different
> > > > > > > > > > >>>>>        federation
> > > > > > > > > > >>>>>        protocols they may support such as SAML,
> > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > >>>>>        and
> > > > > > > > > > >>>>>        so
> > > > > > > > > > >>>>>        forth.
> > > > > > > > > > >>>>>        This is useful when an enterprise is providing
> > > > > > > > > > >>>>>        services
> > > > > > > > > > >>>>>        to
> > > > > > > > > > >>>>>        different
> > > > > > > > > > >>>>>        customers(IdP) and does not want to manage
> > > > > > > > > > >>>>>        many
> > > > > > > > > > >>>>>        to
> > > > > > > > > > >>>>>        many
> > > > > > > > > > >>>>>        relationships. When using a broker, the
> > > > > > > > > > >>>>>        authentication
> > > > > > > > > > >>>>>        steps
> > > > > > > > > > >>>>>        are
> > > > > > > > > > >>>>>        pretty much the same when you are using social
> > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > >>>>>        with
> > > > > > > > > > >>>>>        important differences on how you support
> > > > > > > > > > >>>>>        different
> > > > > > > > > > >>>>>        identity
> > > > > > > > > > >>>>>        providers, different federation protocols, how
> > > > > > > > > > >>>>>        users
> > > > > > > > > > >>>>>        are
> > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > >>>>>        and how claims and attributes are resolved.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        The brokering functionality can be done in two
> > > > > > > > > > >>>>>        ways
> > > > > > > > > > >>>>>        depending
> > > > > > > > > > >>>>>        if
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        broker service is acting as a gateway or not.
> > > > > > > > > > >>>>>        When
> > > > > > > > > > >>>>>        acting
> > > > > > > > > > >>>>>        as
> > > > > > > > > > >>>>>        a
> > > > > > > > > > >>>>>        gateway, the broker will respond to the
> > > > > > > > > > >>>>>        application
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        same
> > > > > > > > > > >>>>>        token
> > > > > > > > > > >>>>>        issued by the trusted identity provider. For
> > > > > > > > > > >>>>>        instance,
> > > > > > > > > > >>>>>        if
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        user
> > > > > > > > > > >>>>>        selects a SAML IdP to authenticate with, the
> > > > > > > > > > >>>>>        application
> > > > > > > > > > >>>>>        will
> > > > > > > > > > >>>>>        receive
> > > > > > > > > > >>>>>        a SAML Response. In this case, the application
> > > > > > > > > > >>>>>        must
> > > > > > > > > > >>>>>        also
> > > > > > > > > > >>>>>        be
> > > > > > > > > > >>>>>        prepared
> > > > > > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        However, the broker service can also be used
> > > > > > > > > > >>>>>        to
> > > > > > > > > > >>>>>        completely
> > > > > > > > > > >>>>>        abstract
> > > > > > > > > > >>>>>        from the application the protocol used to
> > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > >>>>>        an
> > > > > > > > > > >>>>>        user.
> > > > > > > > > > >>>>>        In
> > > > > > > > > > >>>>>        this case, the application will just receive
> > > > > > > > > > >>>>>        an
> > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > >>>>>        KC
> > > > > > > > > > >>>>>        token
> > > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        In both cases, the broker acts as an
> > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > >>>>>        where
> > > > > > > > > > >>>>>        specific
> > > > > > > > > > >>>>>        security policies can be applied when users
> > > > > > > > > > >>>>>        try
> > > > > > > > > > >>>>>        to
> > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > >>>>>        themselves against a 3rd party IdP. That
> > > > > > > > > > >>>>>        brings
> > > > > > > > > > >>>>>        a
> > > > > > > > > > >>>>>        lot
> > > > > > > > > > >>>>>        of
> > > > > > > > > > >>>>>        value
> > > > > > > > > > >>>>>        when
> > > > > > > > > > >>>>>        you think about auditing, authorization and
> > > > > > > > > > >>>>>        how
> > > > > > > > > > >>>>>        users
> > > > > > > > > > >>>>>        are
> > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > >>>>>        when federation of identities is needed. This
> > > > > > > > > > >>>>>        also
> > > > > > > > > > >>>>>        allows
> > > > > > > > > > >>>>>        existing
> > > > > > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > >>>>>        to
> > > > > > > > > > >>>>>        benefit
> > > > > > > > > > >>>>>        from KC's support for cloud, rest and mobile
> > > > > > > > > > >>>>>        use
> > > > > > > > > > >>>>>        cases.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>        I think this is enough to start a discussion.
> > > > > > > > > > >>>>>        I've
> > > > > > > > > > >>>>>        an
> > > > > > > > > > >>>>>        initial
> > > > > > > > > > >>>>>        discussion with Stian about all that and we
> > > > > > > > > > >>>>>        agreed
> > > > > > > > > > >>>>>        that
> > > > > > > > > > >>>>>        abstract
> > > > > > > > > > >>>>>        the
> > > > > > > > > > >>>>>        protocol from applications should be
> > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > >>>>>        The
> > > > > > > > > > >>>>>        main
> > > > > > > > > > >>>>>        reason is
> > > > > > > > > > >>>>>        that it makes life easier for applications so
> > > > > > > > > > >>>>>        they
> > > > > > > > > > >>>>>        only
> > > > > > > > > > >>>>>        need
> > > > > > > > > > >>>>>        to
> > > > > > > > > > >>>>>        know
> > > > > > > > > > >>>>>        about KC tokens and nothing else. However that
> > > > > > > > > > >>>>>        brings
> > > > > > > > > > >>>>>        some
> > > > > > > > > > >>>>>        new
> > > > > > > > > > >>>>>        requirements around user provisioning and
> > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > >>>>>        resolution
> > > > > > > > > > >>>>>        or mapping. But that would be another thread.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > > > > > >>>> applications"?
> > > > > > > > > > >>>> Not
> > > > > > > > > > >>>> sure what you mean by that.  IDP federation should be
> > > > > > > > > > >>>> configured
> > > > > > > > > > >>>> at
> > > > > > > > > > >>>> the
> > > > > > > > > > >>>> realm level and really has nothing to do with
> > > > > > > > > > >>>> applications.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> I'm really happy that somebody is doing this.  We're
> > > > > > > > > > >>>> getting
> > > > > > > > > > >>>> a
> > > > > > > > > > >>>> real
> > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > >>>
> > > > > > > > > > >>> Sure. What I meant was that the application only knows
> > > > > > > > > > >>> about
> > > > > > > > > > >>> KC
> > > > > > > > > > >>> tokens
> > > > > > > > > > >>> nothing else. It will always receive a KC token
> > > > > > > > > > >>> regardless
> > > > > > > > > > >>> the
> > > > > > > > > > >>> protocol
> > > > > > > > > > >>> used
> > > > > > > > > > >>> to authenticate the user against a 3rd party IdP (saml,
> > > > > > > > > > >>> oidc,
> > > > > > > > > > >>> whatever).
> > > > > > > > > > >>> The
> > > > > > > > > > >>> example I gave was about an user trying to authenticate
> > > > > > > > > > >>> against
> > > > > > > > > > >>> a
> > > > > > > > > > >>> SAML
> > > > > > > > > > >>> IdP.
> > > > > > > > > > >>> In this case, after a successful authentication on the
> > > > > > > > > > >>> IdP,
> > > > > > > > > > >>> the
> > > > > > > > > > >>> IdP
> > > > > > > > > > >>> will
> > > > > > > > > > >>> issue a token to KC. Then KC will validate the token,
> > > > > > > > > > >>> perform
> > > > > > > > > > >>> trust
> > > > > > > > > > >>> and
> > > > > > > > > > >>> security checks, do user provisioning and
> > > > > > > > > > >>> attribute/claim
> > > > > > > > > > >>> resolution
> > > > > > > > > > >>> to
> > > > > > > > > > >>> finally issue a KC token and redirect the user to the
> > > > > > > > > > >>> application.
> > > > > > > > > > >>> If
> > > > > > > > > > >>> the
> > > > > > > > > > >>> app is configured to use openid in KC then it will
> > > > > > > > > > >>> receive
> > > > > > > > > > >>> a
> > > > > > > > > > >>> openid
> > > > > > > > > > >>> token
> > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > >>>
> > > > > > > > > > >>> The other scenario is pretty much the same. The
> > > > > > > > > > >>> difference
> > > > > > > > > > >>> is
> > > > > > > > > > >>> that
> > > > > > > > > > >>> KC
> > > > > > > > > > >>> will
> > > > > > > > > > >>> not issue its own token but just replay the token
> > > > > > > > > > >>> issued
> > > > > > > > > > >>> by
> > > > > > > > > > >>> the
> > > > > > > > > > >>> 3rd
> > > > > > > > > > >>> party
> > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > >>>
> > > > > > > > > > >>> I agree that this config goes at the realm level. For
> > > > > > > > > > >>> instance,
> > > > > > > > > > >>> to
> > > > > > > > > > >>> create
> > > > > > > > > > >>> and
> > > > > > > > > > >>> enable providers for being used. However, I think we
> > > > > > > > > > >>> would
> > > > > > > > > > >>> need
> > > > > > > > > > >>> some
> > > > > > > > > > >>> specific configuration for applications as well.
> > > > > > > > > > >>> Specially
> > > > > > > > > > >>> when
> > > > > > > > > > >>> defining
> > > > > > > > > > >>> default roles, mapping attributes. Another example of
> > > > > > > > > > >>> application
> > > > > > > > > > >>> config
> > > > > > > > > > >>> is
> > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define
> > > > > > > > > > >>> scopes
> > > > > > > > > > >>> per-application.
> > > > > > > > > > >>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> --
> > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > >>>>
> > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > >>> 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
> > > > > > > > > > 
> > > > > > > > > > _______________________________________________
> > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > 
> > > > > > > > > > _______________________________________________
> > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >
> > > > 
> > > 
> > 
> 


From stian at redhat.com  Fri Dec  5 08:43:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 08:43:32 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
Message-ID: <34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 2:36:14 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, December 5, 2014 10:59:08 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > Another related thing. We've had a few people ask to be able to login to
> > Keycloak on mobiles using the native social login mechanism.
> > 
> > I think the best way to do that is to use the direct grant api and make it
> > possible to call that endpoint passing a IdP id and a token instead of
> > username and password.
> > 
> > WDYT?
> 
> The broker endpoint expects the idp id in order to start the authentication
> process. Today, the endpoint also expects KCs authorization code in order to
> validate requests from clients and use it as a state to validate responses
> from the trusted idps.
> 
> This authorization code is a blocker for this use case, given that mobile
> don't have this code and just want to start the authentication.
> 
> A possible solution would be to change the broker to also accept a client_id
> to reference the mobile app and perform some validations based on that.
> Something like that:
> 
> 1) Mobile displays a Facebook button
> 2) User clicks the button and mobile sends a request to KC Broker with the
> idp id and his client_id.
> 3) KC Broker checks if the client_id is valid and creates a temporary
> authorization code.
> 4) KC Broker redirect mobile to the chosen IdP to perform authentication.
> 5) KC Broker receives a response from the IdP, generate its own token and
> send it back to mobile
> 
> Makes sense ?

No that's not the flow I had in mind. Basically the mobile app authenticates with Facebook through the native mechanisms. The app then has an access token, which it would send to Keycloak on the direct grant api to obtain a Keycloak token. 

Same for other identity providers, the assumption is the app has an out of bounds mechanism to obtain an access token, which is then sent to Keycloak over the direct grant api.

> 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 5 December, 2014 1:45:24 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Looks good. I reckon we can combine the two pages. What about if the
> > > > 'Add
> > > > provider' drop-down is:
> > > > 
> > > >   OpenID
> > > >   SAML
> > > >   ------
> > > >   Google
> > > >   GitHub
> > > >   Facebook
> > > >   Twitter
> > > > 
> > > > Let's drop social on/off and instead have a enable/disable button on
> > > > each
> > > > provider.
> > > 
> > > Sure.
> > > 
> > > > 
> > > > Also, would be nice if users could set a name or alias for a provider
> > > > instance. This would make the callback url easier to use (instead of
> > > > callback/<UUID> it's callback/<alias>). The user federation providers
> > > > have
> > > > this.
> > > 
> > > One of my first tries was using an alias, just like that. But I preferred
> > > using the UUID and make the configuration more easier. Beside that, the
> > > callback url is just a copy and paste, so I think an alias would not
> > > bring
> > > so much usability, but add one more step when configuring providers.
> > > 
> > > However, if this is an usability requirement for KC I can change that.
> > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > In one of our last discussions, you suggested to leave Social as it
> > > > > is.
> > > > > Although IMO I think we can have a single place to manage both social
> > > > > and
> > > > > user-defined identity providers. Social ones are just OOTB and
> > > > > pre-configured identity providers now.
> > > > > 
> > > > > That said, today I'm using separated tabs for social and
> > > > > user-defined.
> > > > > Please, take a look at [1] for more details on how the UI looks like.
> > > > > 
> > > > > I've changed social UI a bit in order to provide a specific page for
> > > > > create/update. I've also added a "Show Secret" link to display the
> > > > > client_secret in clear text if user wants to.
> > > > > 
> > > > > Beside the enable/disable button, I think another good thing to do is
> > > > > specify
> > > > > a default role(s) for each provider. That can be useful if
> > > > > applications
> > > > > want
> > > > > to perform any kind of authorization based on the identity provider
> > > > > or
> > > > > authentication method used to authenticate an user (eg.: useful for
> > > > > adaptative or multi-level access control). We can also use the "amr"
> > > > > claim
> > > > > in the ID Token, which seems KC is not considering at all. The latter
> > > > > is
> > > > > an
> > > > > important thing to think of, regardless this broker work I'm doing.
> > > > > 
> > > > > [1]
> > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > > 
> > > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Having a separate enable/disable for each provider would be good. If
> > > > > you're
> > > > > leaving the social tab as is and adding a separate tab for
> > > > > configuring
> > > > > brokered idp's then we should leave the social enable/disable button,
> > > > > otherwise it depends how it'll look like in the end.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > >    Social has a button to enable/disable it. I'm wondering what to
> > > > > >    do
> > > > > >    with
> > > > > >    the brokered identity providers. Shall we add a similar flag for
> > > > > >    that
> > > > > >    ?
> > > > > > 
> > > > > >    I was also wondering if the best would be a flag in a per
> > > > > >    provider
> > > > > >    basis.
> > > > > >    So we can disable/enable a specific provider (social or
> > > > > >    brokered),
> > > > > >    instead of doing that for all.
> > > > > > 
> > > > > > Regards.
> > > > > > Pedro Igor
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > I'll go for it then. Will remove the icon url from the model
> > > > > > > > and
> > > > > > > > leave
> > > > > > > > that
> > > > > > > > for users if they want to provide icons for their identity
> > > > > > > > providers.
> > > > > > > > 
> > > > > > > > My point is that icons can be usually served by the same
> > > > > > > > server/application
> > > > > > > > or proxy, so download images are not such a big deal. Also, the
> > > > > > > > icon
> > > > > > > > url
> > > > > > > > is
> > > > > > > > part of the freemarker model and people can do what ever they
> > > > > > > > want
> > > > > > > > with
> > > > > > > > it.
> > > > > > > > What I think will also help in your future plans.
> > > > > > > 
> > > > > > > I'm not following. Are you saying that if a named image
> > > > > > > 'my-provider.png'
> > > > > > > is
> > > > > > > loaded from a theme, then you can override it in another theme?
> > > > > > > 
> > > > > > > If so, that's basically the same as having a css class
> > > > > > > 'my-provider'
> > > > > > > in
> > > > > > > a
> > > > > > > theme. With the exception that with an image you end up with
> > > > > > > having
> > > > > > > to
> > > > > > > require a image per provider per theme per language, which could
> > > > > > > be
> > > > > > > a
> > > > > > > lot
> > > > > > > of
> > > > > > > images for a single provider. Also, buttons for accessibility
> > > > > > > should
> > > > > > > be
> > > > > > > defined with text and css, not images that can't be interpreted.
> > > > > > > You
> > > > > > > also
> > > > > > > still need to modify the theme, so I don't see any benefits.
> > > > > > 
> > > > > > You are right. Having a icon url per provider does not makes sense
> > > > > > if
> > > > > > there
> > > > > > are requirements to change images accordingly to a theme or
> > > > > > language.
> > > > > > CSS
> > > > > > makes life easier.
> > > > > > 
> > > > > > Will remove that property from the model.
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Users can now specify a Icon Url to be rendered on the login
> > > > > > > > > page
> > > > > > > > > when
> > > > > > > > > social
> > > > > > > > > or any other identity provider is configured. So we just load
> > > > > > > > > the
> > > > > > > > > image
> > > > > > > > > the
> > > > > > > > > url entered by the user.
> > > > > > > > > 
> > > > > > > > > Are you saying that users should change the theme or
> > > > > > > > > customize
> > > > > > > > > css
> > > > > > > > > if
> > > > > > > > > they
> > > > > > > > > only want to change an icon for a provider ?
> > > > > > > > 
> > > > > > > > Yes, there's many issues with having a icon url:
> > > > > > > > 
> > > > > > > > * Won't work for internationalization - we don't have this now,
> > > > > > > > but
> > > > > > > > we
> > > > > > > > will
> > > > > > > > * Image is not a good button - CSS is much better
> > > > > > > > * Doesn't support themes - we allow users to switch l&f by
> > > > > > > > switching
> > > > > > > > themes,
> > > > > > > > but that won't work for a icon url. In the future we may also
> > > > > > > > support
> > > > > > > > multiple themes per-realm, for example to depending on the
> > > > > > > > devices
> > > > > > > > (one
> > > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > > * Requires the URL to be hosted somewhere - why require a
> > > > > > > > separate
> > > > > > > > call
> > > > > > > > to
> > > > > > > > download an image (to a separate server maybe) if it can simply
> > > > > > > > be
> > > > > > > > defined
> > > > > > > > in a single CSS file?
> > > > > > > > 
> > > > > > > > Rather than add additional places to define look and feel
> > > > > > > > components
> > > > > > > > we
> > > > > > > > should in the future make it easier to add/customize themes.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > All look and feel related things including images and
> > > > > > > > > stylesheets
> > > > > > > > > should
> > > > > > > > > be
> > > > > > > > > part of themes. This is to allow customizing them in the
> > > > > > > > > theme.
> > > > > > > > > Also,
> > > > > > > > > an
> > > > > > > > > image is not the correct way to render a button, it should be
> > > > > > > > > defined
> > > > > > > > > in
> > > > > > > > > CSS.
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > You shouldn't have icon images for social providers. They
> > > > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > specified
> > > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > Hi,
> > > > > > > > > > > 
> > > > > > > > > > >     Anyone know where I can get the icons images for
> > > > > > > > > > >     social
> > > > > > > > > > >     providers
> > > > > > > > > > >     ?
> > > > > > > > > > >     It
> > > > > > > > > > >     seems zocial defines them encoded in some way in CSS.
> > > > > > > > > > >     I
> > > > > > > > > > >     need
> > > > > > > > > > >     that
> > > > > > > > > > >     to
> > > > > > > > > > >     provide default images if user does not specify their
> > > > > > > > > > >     own.
> > > > > > > > > > > 
> > > > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > > > 
> > > > > > > > > > > Regards.
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > Hi guys,
> > > > > > > > > > > 
> > > > > > > > > > >    I've done some initial work covering both persistence
> > > > > > > > > > >    and
> > > > > > > > > > >    brokering.
> > > > > > > > > > >    No
> > > > > > > > > > >    UI, yet. I'm focused on the model, rest api and
> > > > > > > > > > >    brokering
> > > > > > > > > > >    functionality
> > > > > > > > > > >    for now.
> > > > > > > > > > > 
> > > > > > > > > > >    What I have is enough to decide if we are aligned
> > > > > > > > > > >    about
> > > > > > > > > > >    this
> > > > > > > > > > >    functionality. So you can understand how the model
> > > > > > > > > > >    (and
> > > > > > > > > > >    persistence),
> > > > > > > > > > >    rest api and brokering functionality looks like. Can
> > > > > > > > > > >    we
> > > > > > > > > > >    schedule
> > > > > > > > > > >    a
> > > > > > > > > > >    meeting ?
> > > > > > > > > > > 
> > > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > > 
> > > > > > > > > > > [1]
> > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > > 
> > > > > > > > > > > Regards.
> > > > > > > > > > > Pedro Igor
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > > based
> > > > > > > > > > > on either realm roles or the roles of one specific
> > > > > > > > > > > application.
> > > > > > > > > > > This
> > > > > > > > > > > is
> > > > > > > > > > > related to 1) too.
> > > > > > > > > > > 
> > > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > > > > > > >
> > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > > > > >> I just wanted to quickly list the additional work we
> > > > > > > > > > > >> discussed
> > > > > > > > > > > >> so
> > > > > > > > > > > >> everyone
> > > > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > > > >>
> > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of
> > > > > > > > > > > >> an
> > > > > > > > > > > >> external
> > > > > > > > > > > >> token
> > > > > > > > > > > >> to
> > > > > > > > > > > >> a KC token? For example an external token with
> > > > > > > > > > > >> attribute
> > > > > > > > > > > >> 'group'
> > > > > > > > > > > >> that
> > > > > > > > > > > >> contains 'sales' and 'manager' could be mapped to
> > > > > > > > > > > >> 'manager'
> > > > > > > > > > > >> role
> > > > > > > > > > > >> for
> > > > > > > > > > > >> 'sales app in a KC token. Could we use Drools? This
> > > > > > > > > > > >> could
> > > > > > > > > > > >> also
> > > > > > > > > > > >> be
> > > > > > > > > > > >> used
> > > > > > > > > > > >> in
> > > > > > > > > > > >> user federation to allow more complex mapping of
> > > > > > > > > > > >> roles/groups
> > > > > > > > > > > >> than
> > > > > > > > > > > >> a
> > > > > > > > > > > >> simple 1-1
> > > > > > > > > > > >> 2) Retrieving tokens - if an application wants to
> > > > > > > > > > > >> retrieve
> > > > > > > > > > > >> the
> > > > > > > > > > > >> external
> > > > > > > > > > > >> token (for example to view Facebook friends if user
> > > > > > > > > > > >> logged
> > > > > > > > > > > >> in
> > > > > > > > > > > >> with
> > > > > > > > > > > >> Facebook)
> > > > > > > > > > > >> 3) Configure scope - currently for social we only
> > > > > > > > > > > >> request
> > > > > > > > > > > >> a
> > > > > > > > > > > >> very
> > > > > > > > > > > >> limited
> > > > > > > > > > > >> scope (basic profile and email), to for example view
> > > > > > > > > > > >> Facebook
> > > > > > > > > > > >> friends
> > > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > > >> 4) Selecting provider - currently in social (and for
> > > > > > > > > > > >> first
> > > > > > > > > > > >> pass
> > > > > > > > > > > >> of
> > > > > > > > > > > >> brokering) we have an icon user has to select, but can
> > > > > > > > > > > >> we
> > > > > > > > > > > >> select
> > > > > > > > > > > >> the
> > > > > > > > > > > >> provider in a different way (for example ask user for
> > > > > > > > > > > >> email,
> > > > > > > > > > > >> and
> > > > > > > > > > > >> select
> > > > > > > > > > > >> based on email domain)
> > > > > > > > > > > >> 5) Gateway - don't create a KC token, but just forward
> > > > > > > > > > > >> the
> > > > > > > > > > > >> external
> > > > > > > > > > > >> token
> > > > > > > > > > > >>
> > > > > > > > > > > >> IMO 1) is a killer feature, as it would allow
> > > > > > > > > > > >> companies
> > > > > > > > > > > >> to
> > > > > > > > > > > >> add
> > > > > > > > > > > >> external
> > > > > > > > > > > >> users without having to modify their applications.
> > > > > > > > > > > >> Issue
> > > > > > > > > > > >> with
> > > > > > > > > > > >> 5)
> > > > > > > > > > > >> is
> > > > > > > > > > > >> that
> > > > > > > > > > > >> applications need to understand more than one token,
> > > > > > > > > > > >> which
> > > > > > > > > > > >> would
> > > > > > > > > > > >> require
> > > > > > > > > > > >> rewriting applications.
> > > > > > > > > > > >>
> > > > > > > > > > > >> This work is also somewhat related to other
> > > > > > > > > > > >> authentication
> > > > > > > > > > > >> mechanisms
> > > > > > > > > > > >> (for
> > > > > > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > > > > > >>
> > > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > >>> Authentication
> > > > > > > > > > > >>> Broker
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > >>>> Authentication
> > > > > > > > > > > >>>> Broker
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > > > > > >>>>> Hi,
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        Would like to start a discussion about how
> > > > > > > > > > > >>>>>        to
> > > > > > > > > > > >>>>>        enable
> > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > >>>>>        as
> > > > > > > > > > > >>>>>        an
> > > > > > > > > > > >>>>>        Authentication Broker in order to supported
> > > > > > > > > > > >>>>>        Chained
> > > > > > > > > > > >>>>>        Federation
> > > > > > > > > > > >>>>>        and
> > > > > > > > > > > >>>>>        also Identity Federation. First of all, some
> > > > > > > > > > > >>>>>        background
> > > > > > > > > > > >>>>>        about
> > > > > > > > > > > >>>>>        what
> > > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        Currently KeyCloak provides two basic types
> > > > > > > > > > > >>>>>        of
> > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > >>>>>        (correct
> > > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>            1) Local authentication (based on some
> > > > > > > > > > > >>>>>            credential
> > > > > > > > > > > >>>>>            type
> > > > > > > > > > > >>>>>            enabled
> > > > > > > > > > > >>>>>            to
> > > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        Local authentication is about authenticating
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        user
> > > > > > > > > > > >>>>>        locally
> > > > > > > > > > > >>>>>        using
> > > > > > > > > > > >>>>>        KC's own identity store. Nothing special
> > > > > > > > > > > >>>>>        here.
> > > > > > > > > > > >>>>>        And
> > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > >>>>>        Authentication which allows users to choose
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > >>>>>        they
> > > > > > > > > > > >>>>>        want
> > > > > > > > > > > >>>>>        to authenticate with. In this case, the IdP
> > > > > > > > > > > >>>>>        is
> > > > > > > > > > > >>>>>        always
> > > > > > > > > > > >>>>>        one
> > > > > > > > > > > >>>>>        of
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        built-in social providers supported by KC
> > > > > > > > > > > >>>>>        such
> > > > > > > > > > > >>>>>        as
> > > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > > >>>>>        Google,
> > > > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        When doing social, the user is automatically
> > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > >>>>>        in
> > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > >>>>>        The
> > > > > > > > > > > >>>>>        user
> > > > > > > > > > > >>>>>        does
> > > > > > > > > > > >>>>>        not
> > > > > > > > > > > >>>>>        need to fill a registration form and can
> > > > > > > > > > > >>>>>        access
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        application
> > > > > > > > > > > >>>>>        very
> > > > > > > > > > > >>>>>        quickly. During the provisioning some basic
> > > > > > > > > > > >>>>>        information
> > > > > > > > > > > >>>>>        is
> > > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > > >>>>>        from the social provider such as email,
> > > > > > > > > > > >>>>>        firstname
> > > > > > > > > > > >>>>>        and
> > > > > > > > > > > >>>>>        so
> > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > >>>>>        These
> > > > > > > > > > > >>>>>        are very basic information, any other
> > > > > > > > > > > >>>>>        information
> > > > > > > > > > > >>>>>        such
> > > > > > > > > > > >>>>>        as
> > > > > > > > > > > >>>>>        those
> > > > > > > > > > > >>>>>        related with authorization policies - eg.:
> > > > > > > > > > > >>>>>        roles
> > > > > > > > > > > >>>>>        and
> > > > > > > > > > > >>>>>        groups
> > > > > > > > > > > >>>>>        -
> > > > > > > > > > > >>>>>        must
> > > > > > > > > > > >>>>>        be
> > > > > > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        Another important characteristic of social
> > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > >>>>>        is
> > > > > > > > > > > >>>>>        that
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        application receives a KC token and not the
> > > > > > > > > > > >>>>>        token
> > > > > > > > > > > >>>>>        that
> > > > > > > > > > > >>>>>        was
> > > > > > > > > > > >>>>>        issued by
> > > > > > > > > > > >>>>>        the social IdP during the authentication
> > > > > > > > > > > >>>>>        process.
> > > > > > > > > > > >>>>>        If
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        application
> > > > > > > > > > > >>>>>        wants to consume resources from the resource
> > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > >>>>>        he
> > > > > > > > > > > >>>>>        was
> > > > > > > > > > > >>>>>        authenticated it must obtain the access
> > > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > > >>>>>        by
> > > > > > > > > > > >>>>>        itself
> > > > > > > > > > > >>>>>        prior
> > > > > > > > > > > >>>>>        to invoke the resource provider API.
> > > > > > > > > > > >>>>>        Assuming
> > > > > > > > > > > >>>>>        all
> > > > > > > > > > > >>>>>        those
> > > > > > > > > > > >>>>>        social
> > > > > > > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        That said, the Authentication Broker
> > > > > > > > > > > >>>>>        functionality
> > > > > > > > > > > >>>>>        aims
> > > > > > > > > > > >>>>>        to
> > > > > > > > > > > >>>>>        cover
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        same use cases but with a lot of more
> > > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > > >>>>>        on
> > > > > > > > > > > >>>>>        how
> > > > > > > > > > > >>>>>        you
> > > > > > > > > > > >>>>>        setup
> > > > > > > > > > > >>>>>        identity providers(not only social ones) and
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        different
> > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > >>>>>        protocols they may support such as SAML,
> > > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > > >>>>>        and
> > > > > > > > > > > >>>>>        so
> > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > >>>>>        This is useful when an enterprise is
> > > > > > > > > > > >>>>>        providing
> > > > > > > > > > > >>>>>        services
> > > > > > > > > > > >>>>>        to
> > > > > > > > > > > >>>>>        different
> > > > > > > > > > > >>>>>        customers(IdP) and does not want to manage
> > > > > > > > > > > >>>>>        many
> > > > > > > > > > > >>>>>        to
> > > > > > > > > > > >>>>>        many
> > > > > > > > > > > >>>>>        relationships. When using a broker, the
> > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > >>>>>        steps
> > > > > > > > > > > >>>>>        are
> > > > > > > > > > > >>>>>        pretty much the same when you are using
> > > > > > > > > > > >>>>>        social
> > > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > > >>>>>        with
> > > > > > > > > > > >>>>>        important differences on how you support
> > > > > > > > > > > >>>>>        different
> > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > >>>>>        providers, different federation protocols,
> > > > > > > > > > > >>>>>        how
> > > > > > > > > > > >>>>>        users
> > > > > > > > > > > >>>>>        are
> > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > >>>>>        and how claims and attributes are resolved.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        The brokering functionality can be done in
> > > > > > > > > > > >>>>>        two
> > > > > > > > > > > >>>>>        ways
> > > > > > > > > > > >>>>>        depending
> > > > > > > > > > > >>>>>        if
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        broker service is acting as a gateway or
> > > > > > > > > > > >>>>>        not.
> > > > > > > > > > > >>>>>        When
> > > > > > > > > > > >>>>>        acting
> > > > > > > > > > > >>>>>        as
> > > > > > > > > > > >>>>>        a
> > > > > > > > > > > >>>>>        gateway, the broker will respond to the
> > > > > > > > > > > >>>>>        application
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        same
> > > > > > > > > > > >>>>>        token
> > > > > > > > > > > >>>>>        issued by the trusted identity provider. For
> > > > > > > > > > > >>>>>        instance,
> > > > > > > > > > > >>>>>        if
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        user
> > > > > > > > > > > >>>>>        selects a SAML IdP to authenticate with, the
> > > > > > > > > > > >>>>>        application
> > > > > > > > > > > >>>>>        will
> > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > >>>>>        a SAML Response. In this case, the
> > > > > > > > > > > >>>>>        application
> > > > > > > > > > > >>>>>        must
> > > > > > > > > > > >>>>>        also
> > > > > > > > > > > >>>>>        be
> > > > > > > > > > > >>>>>        prepared
> > > > > > > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        However, the broker service can also be used
> > > > > > > > > > > >>>>>        to
> > > > > > > > > > > >>>>>        completely
> > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > >>>>>        from the application the protocol used to
> > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > >>>>>        an
> > > > > > > > > > > >>>>>        user.
> > > > > > > > > > > >>>>>        In
> > > > > > > > > > > >>>>>        this case, the application will just receive
> > > > > > > > > > > >>>>>        an
> > > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > >>>>>        token
> > > > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        In both cases, the broker acts as an
> > > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > > >>>>>        where
> > > > > > > > > > > >>>>>        specific
> > > > > > > > > > > >>>>>        security policies can be applied when users
> > > > > > > > > > > >>>>>        try
> > > > > > > > > > > >>>>>        to
> > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > >>>>>        themselves against a 3rd party IdP. That
> > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > >>>>>        a
> > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > >>>>>        of
> > > > > > > > > > > >>>>>        value
> > > > > > > > > > > >>>>>        when
> > > > > > > > > > > >>>>>        you think about auditing, authorization and
> > > > > > > > > > > >>>>>        how
> > > > > > > > > > > >>>>>        users
> > > > > > > > > > > >>>>>        are
> > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > >>>>>        when federation of identities is needed.
> > > > > > > > > > > >>>>>        This
> > > > > > > > > > > >>>>>        also
> > > > > > > > > > > >>>>>        allows
> > > > > > > > > > > >>>>>        existing
> > > > > > > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > > >>>>>        to
> > > > > > > > > > > >>>>>        benefit
> > > > > > > > > > > >>>>>        from KC's support for cloud, rest and mobile
> > > > > > > > > > > >>>>>        use
> > > > > > > > > > > >>>>>        cases.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>        I think this is enough to start a
> > > > > > > > > > > >>>>>        discussion.
> > > > > > > > > > > >>>>>        I've
> > > > > > > > > > > >>>>>        an
> > > > > > > > > > > >>>>>        initial
> > > > > > > > > > > >>>>>        discussion with Stian about all that and we
> > > > > > > > > > > >>>>>        agreed
> > > > > > > > > > > >>>>>        that
> > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > >>>>>        the
> > > > > > > > > > > >>>>>        protocol from applications should be
> > > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > > >>>>>        The
> > > > > > > > > > > >>>>>        main
> > > > > > > > > > > >>>>>        reason is
> > > > > > > > > > > >>>>>        that it makes life easier for applications
> > > > > > > > > > > >>>>>        so
> > > > > > > > > > > >>>>>        they
> > > > > > > > > > > >>>>>        only
> > > > > > > > > > > >>>>>        need
> > > > > > > > > > > >>>>>        to
> > > > > > > > > > > >>>>>        know
> > > > > > > > > > > >>>>>        about KC tokens and nothing else. However
> > > > > > > > > > > >>>>>        that
> > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > >>>>>        some
> > > > > > > > > > > >>>>>        new
> > > > > > > > > > > >>>>>        requirements around user provisioning and
> > > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > > >>>>>        resolution
> > > > > > > > > > > >>>>>        or mapping. But that would be another
> > > > > > > > > > > >>>>>        thread.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > > > > > > >>>> applications"?
> > > > > > > > > > > >>>> Not
> > > > > > > > > > > >>>> sure what you mean by that.  IDP federation should
> > > > > > > > > > > >>>> be
> > > > > > > > > > > >>>> configured
> > > > > > > > > > > >>>> at
> > > > > > > > > > > >>>> the
> > > > > > > > > > > >>>> realm level and really has nothing to do with
> > > > > > > > > > > >>>> applications.
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> I'm really happy that somebody is doing this.  We're
> > > > > > > > > > > >>>> getting
> > > > > > > > > > > >>>> a
> > > > > > > > > > > >>>> real
> > > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> Sure. What I meant was that the application only
> > > > > > > > > > > >>> knows
> > > > > > > > > > > >>> about
> > > > > > > > > > > >>> KC
> > > > > > > > > > > >>> tokens
> > > > > > > > > > > >>> nothing else. It will always receive a KC token
> > > > > > > > > > > >>> regardless
> > > > > > > > > > > >>> the
> > > > > > > > > > > >>> protocol
> > > > > > > > > > > >>> used
> > > > > > > > > > > >>> to authenticate the user against a 3rd party IdP
> > > > > > > > > > > >>> (saml,
> > > > > > > > > > > >>> oidc,
> > > > > > > > > > > >>> whatever).
> > > > > > > > > > > >>> The
> > > > > > > > > > > >>> example I gave was about an user trying to
> > > > > > > > > > > >>> authenticate
> > > > > > > > > > > >>> against
> > > > > > > > > > > >>> a
> > > > > > > > > > > >>> SAML
> > > > > > > > > > > >>> IdP.
> > > > > > > > > > > >>> In this case, after a successful authentication on
> > > > > > > > > > > >>> the
> > > > > > > > > > > >>> IdP,
> > > > > > > > > > > >>> the
> > > > > > > > > > > >>> IdP
> > > > > > > > > > > >>> will
> > > > > > > > > > > >>> issue a token to KC. Then KC will validate the token,
> > > > > > > > > > > >>> perform
> > > > > > > > > > > >>> trust
> > > > > > > > > > > >>> and
> > > > > > > > > > > >>> security checks, do user provisioning and
> > > > > > > > > > > >>> attribute/claim
> > > > > > > > > > > >>> resolution
> > > > > > > > > > > >>> to
> > > > > > > > > > > >>> finally issue a KC token and redirect the user to the
> > > > > > > > > > > >>> application.
> > > > > > > > > > > >>> If
> > > > > > > > > > > >>> the
> > > > > > > > > > > >>> app is configured to use openid in KC then it will
> > > > > > > > > > > >>> receive
> > > > > > > > > > > >>> a
> > > > > > > > > > > >>> openid
> > > > > > > > > > > >>> token
> > > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> The other scenario is pretty much the same. The
> > > > > > > > > > > >>> difference
> > > > > > > > > > > >>> is
> > > > > > > > > > > >>> that
> > > > > > > > > > > >>> KC
> > > > > > > > > > > >>> will
> > > > > > > > > > > >>> not issue its own token but just replay the token
> > > > > > > > > > > >>> issued
> > > > > > > > > > > >>> by
> > > > > > > > > > > >>> the
> > > > > > > > > > > >>> 3rd
> > > > > > > > > > > >>> party
> > > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> I agree that this config goes at the realm level. For
> > > > > > > > > > > >>> instance,
> > > > > > > > > > > >>> to
> > > > > > > > > > > >>> create
> > > > > > > > > > > >>> and
> > > > > > > > > > > >>> enable providers for being used. However, I think we
> > > > > > > > > > > >>> would
> > > > > > > > > > > >>> need
> > > > > > > > > > > >>> some
> > > > > > > > > > > >>> specific configuration for applications as well.
> > > > > > > > > > > >>> Specially
> > > > > > > > > > > >>> when
> > > > > > > > > > > >>> defining
> > > > > > > > > > > >>> default roles, mapping attributes. Another example of
> > > > > > > > > > > >>> application
> > > > > > > > > > > >>> config
> > > > > > > > > > > >>> is
> > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define
> > > > > > > > > > > >>> scopes
> > > > > > > > > > > >>> per-application.
> > > > > > > > > > > >>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> --
> > > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > >>> 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
> > > > > > > > > > > 
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > 
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > 
> > > > > > > > > > _______________________________________________
> > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > >
> > > > > 
> > > > 
> > > 
> > 
> 


From bburke at redhat.com  Fri Dec  5 08:44:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 08:44:11 -0500
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1557601322.11298031.1417786425846.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1935001211.8606786.1417521873598.JavaMail.zimbra@redhat.com>
	<2001023478.22647480.1417522388253.JavaMail.zimbra@redhat.com>
	<1410182377.8621584.1417523004247.JavaMail.zimbra@redhat.com>
	<1413146237.22657374.1417524131218.JavaMail.zimbra@redhat.com>
	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<5481B318.9080609@redhat.com>
	<1557601322.11298031.1417786425846.JavaMail.zimbra@redhat.com>
Message-ID: <5481B6AB.9070006@redhat.com>



On 12/5/2014 8:33 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 5 December, 2014 2:28:56 PM
>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>
>> Get rid of the social button?
>
> Yes, that's the idea. One place to configure Identity Providers in general instead of one for "enterprise" and one for social.
>
> Initially I thought keeping social separate would be best, but looking at Pedro's screenshots it seems it would work well to combine the two.
>

Yeah, I wanted to get rid of that before, but was too lazy as I knew I'd 
have to redo the screencast.


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

From bburke at redhat.com  Fri Dec  5 08:45:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 08:45:57 -0500
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>	<839818721.25152317.1417742977841.JavaMail.zimbra@redhat.com>	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
Message-ID: <5481B715.1020909@redhat.com>



On 12/5/2014 8:43 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 5 December, 2014 2:36:14 PM
>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>
>> ----- Original Message -----
>>> From: "Stian Thorgersen" <stian at redhat.com>
>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Friday, December 5, 2014 10:59:08 AM
>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>
>>> Another related thing. We've had a few people ask to be able to login to
>>> Keycloak on mobiles using the native social login mechanism.
>>>
>>> I think the best way to do that is to use the direct grant api and make it
>>> possible to call that endpoint passing a IdP id and a token instead of
>>> username and password.
>>>
>>> WDYT?
>>
>> The broker endpoint expects the idp id in order to start the authentication
>> process. Today, the endpoint also expects KCs authorization code in order to
>> validate requests from clients and use it as a state to validate responses
>> from the trusted idps.
>>
>> This authorization code is a blocker for this use case, given that mobile
>> don't have this code and just want to start the authentication.
>>
>> A possible solution would be to change the broker to also accept a client_id
>> to reference the mobile app and perform some validations based on that.
>> Something like that:
>>
>> 1) Mobile displays a Facebook button
>> 2) User clicks the button and mobile sends a request to KC Broker with the
>> idp id and his client_id.
>> 3) KC Broker checks if the client_id is valid and creates a temporary
>> authorization code.
>> 4) KC Broker redirect mobile to the chosen IdP to perform authentication.
>> 5) KC Broker receives a response from the IdP, generate its own token and
>> send it back to mobile
>>
>> Makes sense ?
>
> No that's not the flow I had in mind. Basically the mobile app authenticates with Facebook through the native mechanisms. The app then has an access token, which it would send to Keycloak on the direct grant api to obtain a Keycloak token.
>
> Same for other identity providers, the assumption is the app has an out of bounds mechanism to obtain an access token, which is then sent to Keycloak over the direct grant api.
>

How would/could that work exactly?  Do social providers sign the token 
somehow?  Can the token be verified?



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

From stian at redhat.com  Fri Dec  5 08:55:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 08:55:34 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <5481B715.1020909@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
	<5481B715.1020909@redhat.com>
Message-ID: <1246483027.11327875.1417787734480.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 2:45:57 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> 
> On 12/5/2014 8:43 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 5 December, 2014 2:36:14 PM
> >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>
> >> ----- Original Message -----
> >>> From: "Stian Thorgersen" <stian at redhat.com>
> >>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Friday, December 5, 2014 10:59:08 AM
> >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>>
> >>> Another related thing. We've had a few people ask to be able to login to
> >>> Keycloak on mobiles using the native social login mechanism.
> >>>
> >>> I think the best way to do that is to use the direct grant api and make
> >>> it
> >>> possible to call that endpoint passing a IdP id and a token instead of
> >>> username and password.
> >>>
> >>> WDYT?
> >>
> >> The broker endpoint expects the idp id in order to start the
> >> authentication
> >> process. Today, the endpoint also expects KCs authorization code in order
> >> to
> >> validate requests from clients and use it as a state to validate responses
> >> from the trusted idps.
> >>
> >> This authorization code is a blocker for this use case, given that mobile
> >> don't have this code and just want to start the authentication.
> >>
> >> A possible solution would be to change the broker to also accept a
> >> client_id
> >> to reference the mobile app and perform some validations based on that.
> >> Something like that:
> >>
> >> 1) Mobile displays a Facebook button
> >> 2) User clicks the button and mobile sends a request to KC Broker with the
> >> idp id and his client_id.
> >> 3) KC Broker checks if the client_id is valid and creates a temporary
> >> authorization code.
> >> 4) KC Broker redirect mobile to the chosen IdP to perform authentication.
> >> 5) KC Broker receives a response from the IdP, generate its own token and
> >> send it back to mobile
> >>
> >> Makes sense ?
> >
> > No that's not the flow I had in mind. Basically the mobile app
> > authenticates with Facebook through the native mechanisms. The app then
> > has an access token, which it would send to Keycloak on the direct grant
> > api to obtain a Keycloak token.
> >
> > Same for other identity providers, the assumption is the app has an out of
> > bounds mechanism to obtain an access token, which is then sent to Keycloak
> > over the direct grant api.
> >
> 
> How would/could that work exactly?  Do social providers sign the token
> somehow?  Can the token be verified?

I think we should invoke the IdP to verify the token rather than verify it locally.

All the social providers we have at the moment first retrieve a token, then use it to obtain the user profile. I assumed we'd just skip the first step and just use the supplied token to retrieve the user profile.

For OpenID Connect providers there's the UserInfo endpoint that can be used. That'll both verify the token as well as provide us with the user profile.

Not sure about SAML.

> 
> 
> 
> --
> 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 Dec  5 08:57:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 08:57:15 -0500
Subject: [keycloak-dev] vision vs. infinite configurability
Message-ID: <5481B9BB.9080403@redhat.com>

Users want Keycloak to work like their existing solutions.  Users have 
peculiar use cases they need to solve.  As engineers, we want to satisfy 
our customer's needs so we add option after option.

This worries me...

We have to constantly think about the Keycloak "vision".  We need to 
continually think about how users *should* use Keycloak rather than how 
they want to use it.  Every time we add a new configuration option to 
keycloak we add complexity.  We make keycloak harder to understand and 
use.  We need to keep this in mind as we go forward over the next few 
months.   When customers ask for a new feature we need to ask them or think:

* Is there an existing way to do this?
* Should we allow this option?
* Is there a better way to solve the customer's need?

A big one is: Can we enforce specify policies to make Keycloak easier to 
configure?  For example, as a SAML IDP, we can say, sorry, but any SP 
needs to be able to handle signed saml documets.  we don't need to 
provide the config switch to not sign a document.  Get what I mean?

BTW, this is why I get so pissy whenever you guys want to add another 
SPI or config switch.  I know how these types of things snowball as a 
project ages.  You can collapse under the weight of them.  Having a 
"vision" helps tremendously as you tell users how they should be doing 
security rather than just doing whatever they want.

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

From psilva at redhat.com  Fri Dec  5 08:57:46 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 Dec 2014 08:57:46 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<2060646462.11167910.1417767315815.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
Message-ID: <1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, December 5, 2014 11:43:32 AM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 5 December, 2014 2:36:14 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, December 5, 2014 10:59:08 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > Another related thing. We've had a few people ask to be able to login to
> > > Keycloak on mobiles using the native social login mechanism.
> > > 
> > > I think the best way to do that is to use the direct grant api and make
> > > it
> > > possible to call that endpoint passing a IdP id and a token instead of
> > > username and password.
> > > 
> > > WDYT?
> > 
> > The broker endpoint expects the idp id in order to start the authentication
> > process. Today, the endpoint also expects KCs authorization code in order
> > to
> > validate requests from clients and use it as a state to validate responses
> > from the trusted idps.
> > 
> > This authorization code is a blocker for this use case, given that mobile
> > don't have this code and just want to start the authentication.
> > 
> > A possible solution would be to change the broker to also accept a
> > client_id
> > to reference the mobile app and perform some validations based on that.
> > Something like that:
> > 
> > 1) Mobile displays a Facebook button
> > 2) User clicks the button and mobile sends a request to KC Broker with the
> > idp id and his client_id.
> > 3) KC Broker checks if the client_id is valid and creates a temporary
> > authorization code.
> > 4) KC Broker redirect mobile to the chosen IdP to perform authentication.
> > 5) KC Broker receives a response from the IdP, generate its own token and
> > send it back to mobile
> > 
> > Makes sense ?
> 
> No that's not the flow I had in mind. Basically the mobile app authenticates
> with Facebook through the native mechanisms. The app then has an access
> token, which it would send to Keycloak on the direct grant api to obtain a
> Keycloak token.

Ahh, now I get what you mean :)

Yes, what you said is enough. Then we just need to validate the access token (eg.: using a tokeninfo endpoint).

But I think we can also consider that use case I mentioned. You may want to login without forcing the user to redirect to KC login page.

> 
> Same for other identity providers, the assumption is the app has an out of
> bounds mechanism to obtain an access token, which is then sent to Keycloak
> over the direct grant api.
> 
> > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 5 December, 2014 1:45:24 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Looks good. I reckon we can combine the two pages. What about if the
> > > > > 'Add
> > > > > provider' drop-down is:
> > > > > 
> > > > >   OpenID
> > > > >   SAML
> > > > >   ------
> > > > >   Google
> > > > >   GitHub
> > > > >   Facebook
> > > > >   Twitter
> > > > > 
> > > > > Let's drop social on/off and instead have a enable/disable button on
> > > > > each
> > > > > provider.
> > > > 
> > > > Sure.
> > > > 
> > > > > 
> > > > > Also, would be nice if users could set a name or alias for a provider
> > > > > instance. This would make the callback url easier to use (instead of
> > > > > callback/<UUID> it's callback/<alias>). The user federation providers
> > > > > have
> > > > > this.
> > > > 
> > > > One of my first tries was using an alias, just like that. But I
> > > > preferred
> > > > using the UUID and make the configuration more easier. Beside that, the
> > > > callback url is just a copy and paste, so I think an alias would not
> > > > bring
> > > > so much usability, but add one more step when configuring providers.
> > > > 
> > > > However, if this is an usability requirement for KC I can change that.
> > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > In one of our last discussions, you suggested to leave Social as it
> > > > > > is.
> > > > > > Although IMO I think we can have a single place to manage both
> > > > > > social
> > > > > > and
> > > > > > user-defined identity providers. Social ones are just OOTB and
> > > > > > pre-configured identity providers now.
> > > > > > 
> > > > > > That said, today I'm using separated tabs for social and
> > > > > > user-defined.
> > > > > > Please, take a look at [1] for more details on how the UI looks
> > > > > > like.
> > > > > > 
> > > > > > I've changed social UI a bit in order to provide a specific page
> > > > > > for
> > > > > > create/update. I've also added a "Show Secret" link to display the
> > > > > > client_secret in clear text if user wants to.
> > > > > > 
> > > > > > Beside the enable/disable button, I think another good thing to do
> > > > > > is
> > > > > > specify
> > > > > > a default role(s) for each provider. That can be useful if
> > > > > > applications
> > > > > > want
> > > > > > to perform any kind of authorization based on the identity provider
> > > > > > or
> > > > > > authentication method used to authenticate an user (eg.: useful for
> > > > > > adaptative or multi-level access control). We can also use the
> > > > > > "amr"
> > > > > > claim
> > > > > > in the ID Token, which seems KC is not considering at all. The
> > > > > > latter
> > > > > > is
> > > > > > an
> > > > > > important thing to think of, regardless this broker work I'm doing.
> > > > > > 
> > > > > > [1]
> > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Having a separate enable/disable for each provider would be good.
> > > > > > If
> > > > > > you're
> > > > > > leaving the social tab as is and adding a separate tab for
> > > > > > configuring
> > > > > > brokered idp's then we should leave the social enable/disable
> > > > > > button,
> > > > > > otherwise it depends how it'll look like in the end.
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > >    Social has a button to enable/disable it. I'm wondering what
> > > > > > >    to
> > > > > > >    do
> > > > > > >    with
> > > > > > >    the brokered identity providers. Shall we add a similar flag
> > > > > > >    for
> > > > > > >    that
> > > > > > >    ?
> > > > > > > 
> > > > > > >    I was also wondering if the best would be a flag in a per
> > > > > > >    provider
> > > > > > >    basis.
> > > > > > >    So we can disable/enable a specific provider (social or
> > > > > > >    brokered),
> > > > > > >    instead of doing that for all.
> > > > > > > 
> > > > > > > Regards.
> > > > > > > Pedro Igor
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > I'll go for it then. Will remove the icon url from the model
> > > > > > > > > and
> > > > > > > > > leave
> > > > > > > > > that
> > > > > > > > > for users if they want to provide icons for their identity
> > > > > > > > > providers.
> > > > > > > > > 
> > > > > > > > > My point is that icons can be usually served by the same
> > > > > > > > > server/application
> > > > > > > > > or proxy, so download images are not such a big deal. Also,
> > > > > > > > > the
> > > > > > > > > icon
> > > > > > > > > url
> > > > > > > > > is
> > > > > > > > > part of the freemarker model and people can do what ever they
> > > > > > > > > want
> > > > > > > > > with
> > > > > > > > > it.
> > > > > > > > > What I think will also help in your future plans.
> > > > > > > > 
> > > > > > > > I'm not following. Are you saying that if a named image
> > > > > > > > 'my-provider.png'
> > > > > > > > is
> > > > > > > > loaded from a theme, then you can override it in another theme?
> > > > > > > > 
> > > > > > > > If so, that's basically the same as having a css class
> > > > > > > > 'my-provider'
> > > > > > > > in
> > > > > > > > a
> > > > > > > > theme. With the exception that with an image you end up with
> > > > > > > > having
> > > > > > > > to
> > > > > > > > require a image per provider per theme per language, which
> > > > > > > > could
> > > > > > > > be
> > > > > > > > a
> > > > > > > > lot
> > > > > > > > of
> > > > > > > > images for a single provider. Also, buttons for accessibility
> > > > > > > > should
> > > > > > > > be
> > > > > > > > defined with text and css, not images that can't be
> > > > > > > > interpreted.
> > > > > > > > You
> > > > > > > > also
> > > > > > > > still need to modify the theme, so I don't see any benefits.
> > > > > > > 
> > > > > > > You are right. Having a icon url per provider does not makes
> > > > > > > sense
> > > > > > > if
> > > > > > > there
> > > > > > > are requirements to change images accordingly to a theme or
> > > > > > > language.
> > > > > > > CSS
> > > > > > > makes life easier.
> > > > > > > 
> > > > > > > Will remove that property from the model.
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > Users can now specify a Icon Url to be rendered on the
> > > > > > > > > > login
> > > > > > > > > > page
> > > > > > > > > > when
> > > > > > > > > > social
> > > > > > > > > > or any other identity provider is configured. So we just
> > > > > > > > > > load
> > > > > > > > > > the
> > > > > > > > > > image
> > > > > > > > > > the
> > > > > > > > > > url entered by the user.
> > > > > > > > > > 
> > > > > > > > > > Are you saying that users should change the theme or
> > > > > > > > > > customize
> > > > > > > > > > css
> > > > > > > > > > if
> > > > > > > > > > they
> > > > > > > > > > only want to change an icon for a provider ?
> > > > > > > > > 
> > > > > > > > > Yes, there's many issues with having a icon url:
> > > > > > > > > 
> > > > > > > > > * Won't work for internationalization - we don't have this
> > > > > > > > > now,
> > > > > > > > > but
> > > > > > > > > we
> > > > > > > > > will
> > > > > > > > > * Image is not a good button - CSS is much better
> > > > > > > > > * Doesn't support themes - we allow users to switch l&f by
> > > > > > > > > switching
> > > > > > > > > themes,
> > > > > > > > > but that won't work for a icon url. In the future we may also
> > > > > > > > > support
> > > > > > > > > multiple themes per-realm, for example to depending on the
> > > > > > > > > devices
> > > > > > > > > (one
> > > > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > > > * Requires the URL to be hosted somewhere - why require a
> > > > > > > > > separate
> > > > > > > > > call
> > > > > > > > > to
> > > > > > > > > download an image (to a separate server maybe) if it can
> > > > > > > > > simply
> > > > > > > > > be
> > > > > > > > > defined
> > > > > > > > > in a single CSS file?
> > > > > > > > > 
> > > > > > > > > Rather than add additional places to define look and feel
> > > > > > > > > components
> > > > > > > > > we
> > > > > > > > > should in the future make it easier to add/customize themes.
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > All look and feel related things including images and
> > > > > > > > > > stylesheets
> > > > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > part of themes. This is to allow customizing them in the
> > > > > > > > > > theme.
> > > > > > > > > > Also,
> > > > > > > > > > an
> > > > > > > > > > image is not the correct way to render a button, it should
> > > > > > > > > > be
> > > > > > > > > > defined
> > > > > > > > > > in
> > > > > > > > > > CSS.
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > You shouldn't have icon images for social providers. They
> > > > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > specified
> > > > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > >     Anyone know where I can get the icons images for
> > > > > > > > > > > >     social
> > > > > > > > > > > >     providers
> > > > > > > > > > > >     ?
> > > > > > > > > > > >     It
> > > > > > > > > > > >     seems zocial defines them encoded in some way in
> > > > > > > > > > > >     CSS.
> > > > > > > > > > > >     I
> > > > > > > > > > > >     need
> > > > > > > > > > > >     that
> > > > > > > > > > > >     to
> > > > > > > > > > > >     provide default images if user does not specify
> > > > > > > > > > > >     their
> > > > > > > > > > > >     own.
> > > > > > > > > > > > 
> > > > > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > > > > 
> > > > > > > > > > > > Regards.
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > 
> > > > > > > > > > > >    I've done some initial work covering both
> > > > > > > > > > > >    persistence
> > > > > > > > > > > >    and
> > > > > > > > > > > >    brokering.
> > > > > > > > > > > >    No
> > > > > > > > > > > >    UI, yet. I'm focused on the model, rest api and
> > > > > > > > > > > >    brokering
> > > > > > > > > > > >    functionality
> > > > > > > > > > > >    for now.
> > > > > > > > > > > > 
> > > > > > > > > > > >    What I have is enough to decide if we are aligned
> > > > > > > > > > > >    about
> > > > > > > > > > > >    this
> > > > > > > > > > > >    functionality. So you can understand how the model
> > > > > > > > > > > >    (and
> > > > > > > > > > > >    persistence),
> > > > > > > > > > > >    rest api and brokering functionality looks like. Can
> > > > > > > > > > > >    we
> > > > > > > > > > > >    schedule
> > > > > > > > > > > >    a
> > > > > > > > > > > >    meeting ?
> > > > > > > > > > > > 
> > > > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > > > 
> > > > > > > > > > > > [1]
> > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > > > 
> > > > > > > > > > > > Regards.
> > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > > > based
> > > > > > > > > > > > on either realm roles or the roles of one specific
> > > > > > > > > > > > application.
> > > > > > > > > > > > This
> > > > > > > > > > > > is
> > > > > > > > > > > > related to 1) too.
> > > > > > > > > > > > 
> > > > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > > > > > > 1) Sounds like something definitely worth aiming for.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > > > > > >> I just wanted to quickly list the additional work we
> > > > > > > > > > > > >> discussed
> > > > > > > > > > > > >> so
> > > > > > > > > > > > >> everyone
> > > > > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping
> > > > > > > > > > > > >> of
> > > > > > > > > > > > >> an
> > > > > > > > > > > > >> external
> > > > > > > > > > > > >> token
> > > > > > > > > > > > >> to
> > > > > > > > > > > > >> a KC token? For example an external token with
> > > > > > > > > > > > >> attribute
> > > > > > > > > > > > >> 'group'
> > > > > > > > > > > > >> that
> > > > > > > > > > > > >> contains 'sales' and 'manager' could be mapped to
> > > > > > > > > > > > >> 'manager'
> > > > > > > > > > > > >> role
> > > > > > > > > > > > >> for
> > > > > > > > > > > > >> 'sales app in a KC token. Could we use Drools? This
> > > > > > > > > > > > >> could
> > > > > > > > > > > > >> also
> > > > > > > > > > > > >> be
> > > > > > > > > > > > >> used
> > > > > > > > > > > > >> in
> > > > > > > > > > > > >> user federation to allow more complex mapping of
> > > > > > > > > > > > >> roles/groups
> > > > > > > > > > > > >> than
> > > > > > > > > > > > >> a
> > > > > > > > > > > > >> simple 1-1
> > > > > > > > > > > > >> 2) Retrieving tokens - if an application wants to
> > > > > > > > > > > > >> retrieve
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> external
> > > > > > > > > > > > >> token (for example to view Facebook friends if user
> > > > > > > > > > > > >> logged
> > > > > > > > > > > > >> in
> > > > > > > > > > > > >> with
> > > > > > > > > > > > >> Facebook)
> > > > > > > > > > > > >> 3) Configure scope - currently for social we only
> > > > > > > > > > > > >> request
> > > > > > > > > > > > >> a
> > > > > > > > > > > > >> very
> > > > > > > > > > > > >> limited
> > > > > > > > > > > > >> scope (basic profile and email), to for example view
> > > > > > > > > > > > >> Facebook
> > > > > > > > > > > > >> friends
> > > > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > > > >> 4) Selecting provider - currently in social (and for
> > > > > > > > > > > > >> first
> > > > > > > > > > > > >> pass
> > > > > > > > > > > > >> of
> > > > > > > > > > > > >> brokering) we have an icon user has to select, but
> > > > > > > > > > > > >> can
> > > > > > > > > > > > >> we
> > > > > > > > > > > > >> select
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> provider in a different way (for example ask user
> > > > > > > > > > > > >> for
> > > > > > > > > > > > >> email,
> > > > > > > > > > > > >> and
> > > > > > > > > > > > >> select
> > > > > > > > > > > > >> based on email domain)
> > > > > > > > > > > > >> 5) Gateway - don't create a KC token, but just
> > > > > > > > > > > > >> forward
> > > > > > > > > > > > >> the
> > > > > > > > > > > > >> external
> > > > > > > > > > > > >> token
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> IMO 1) is a killer feature, as it would allow
> > > > > > > > > > > > >> companies
> > > > > > > > > > > > >> to
> > > > > > > > > > > > >> add
> > > > > > > > > > > > >> external
> > > > > > > > > > > > >> users without having to modify their applications.
> > > > > > > > > > > > >> Issue
> > > > > > > > > > > > >> with
> > > > > > > > > > > > >> 5)
> > > > > > > > > > > > >> is
> > > > > > > > > > > > >> that
> > > > > > > > > > > > >> applications need to understand more than one token,
> > > > > > > > > > > > >> which
> > > > > > > > > > > > >> would
> > > > > > > > > > > > >> require
> > > > > > > > > > > > >> rewriting applications.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> This work is also somewhat related to other
> > > > > > > > > > > > >> authentication
> > > > > > > > > > > > >> mechanisms
> > > > > > > > > > > > >> (for
> > > > > > > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > >>> Authentication
> > > > > > > > > > > > >>> Broker
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > >>>> Authentication
> > > > > > > > > > > > >>>> Broker
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > > > > > > >>>>> Hi,
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        Would like to start a discussion about how
> > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > >>>>>        enable
> > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > >>>>>        Authentication Broker in order to
> > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > >>>>>        Chained
> > > > > > > > > > > > >>>>>        Federation
> > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > >>>>>        also Identity Federation. First of all,
> > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > >>>>>        background
> > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > >>>>>        what
> > > > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        Currently KeyCloak provides two basic
> > > > > > > > > > > > >>>>>        types
> > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > >>>>>        (correct
> > > > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>            1) Local authentication (based on some
> > > > > > > > > > > > >>>>>            credential
> > > > > > > > > > > > >>>>>            type
> > > > > > > > > > > > >>>>>            enabled
> > > > > > > > > > > > >>>>>            to
> > > > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        Local authentication is about
> > > > > > > > > > > > >>>>>        authenticating
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > >>>>>        locally
> > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > >>>>>        KC's own identity store. Nothing special
> > > > > > > > > > > > >>>>>        here.
> > > > > > > > > > > > >>>>>        And
> > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > >>>>>        Authentication which allows users to
> > > > > > > > > > > > >>>>>        choose
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > >>>>>        to authenticate with. In this case, the
> > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > >>>>>        always
> > > > > > > > > > > > >>>>>        one
> > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        built-in social providers supported by KC
> > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > > > >>>>>        Google,
> > > > > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        When doing social, the user is
> > > > > > > > > > > > >>>>>        automatically
> > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > >>>>>        does
> > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > >>>>>        need to fill a registration form and can
> > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > >>>>>        very
> > > > > > > > > > > > >>>>>        quickly. During the provisioning some
> > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > > > >>>>>        from the social provider such as email,
> > > > > > > > > > > > >>>>>        firstname
> > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > >>>>>        These
> > > > > > > > > > > > >>>>>        are very basic information, any other
> > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > >>>>>        related with authorization policies - eg.:
> > > > > > > > > > > > >>>>>        roles
> > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > >>>>>        groups
> > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        Another important characteristic of social
> > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        application receives a KC token and not
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > >>>>>        issued by
> > > > > > > > > > > > >>>>>        the social IdP during the authentication
> > > > > > > > > > > > >>>>>        process.
> > > > > > > > > > > > >>>>>        If
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > >>>>>        wants to consume resources from the
> > > > > > > > > > > > >>>>>        resource
> > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > >>>>>        he
> > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > >>>>>        authenticated it must obtain the access
> > > > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > >>>>>        itself
> > > > > > > > > > > > >>>>>        prior
> > > > > > > > > > > > >>>>>        to invoke the resource provider API.
> > > > > > > > > > > > >>>>>        Assuming
> > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        That said, the Authentication Broker
> > > > > > > > > > > > >>>>>        functionality
> > > > > > > > > > > > >>>>>        aims
> > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > >>>>>        cover
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        same use cases but with a lot of more
> > > > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > > > >>>>>        on
> > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > >>>>>        setup
> > > > > > > > > > > > >>>>>        identity providers(not only social ones)
> > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > >>>>>        protocols they may support such as SAML,
> > > > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > >>>>>        This is useful when an enterprise is
> > > > > > > > > > > > >>>>>        providing
> > > > > > > > > > > > >>>>>        services
> > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > >>>>>        customers(IdP) and does not want to manage
> > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > >>>>>        relationships. When using a broker, the
> > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > >>>>>        steps
> > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > >>>>>        pretty much the same when you are using
> > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > > > >>>>>        with
> > > > > > > > > > > > >>>>>        important differences on how you support
> > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > > >>>>>        providers, different federation protocols,
> > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > >>>>>        and how claims and attributes are
> > > > > > > > > > > > >>>>>        resolved.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        The brokering functionality can be done in
> > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > >>>>>        ways
> > > > > > > > > > > > >>>>>        depending
> > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        broker service is acting as a gateway or
> > > > > > > > > > > > >>>>>        not.
> > > > > > > > > > > > >>>>>        When
> > > > > > > > > > > > >>>>>        acting
> > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > >>>>>        gateway, the broker will respond to the
> > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        same
> > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > >>>>>        issued by the trusted identity provider.
> > > > > > > > > > > > >>>>>        For
> > > > > > > > > > > > >>>>>        instance,
> > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > >>>>>        selects a SAML IdP to authenticate with,
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > >>>>>        a SAML Response. In this case, the
> > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > >>>>>        prepared
> > > > > > > > > > > > >>>>>        to handle a specific federation protocol.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        However, the broker service can also be
> > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > >>>>>        completely
> > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > >>>>>        from the application the protocol used to
> > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > >>>>>        user.
> > > > > > > > > > > > >>>>>        In
> > > > > > > > > > > > >>>>>        this case, the application will just
> > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        In both cases, the broker acts as an
> > > > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > > > >>>>>        where
> > > > > > > > > > > > >>>>>        specific
> > > > > > > > > > > > >>>>>        security policies can be applied when
> > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > >>>>>        try
> > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > >>>>>        themselves against a 3rd party IdP. That
> > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > >>>>>        value
> > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > >>>>>        you think about auditing, authorization
> > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > >>>>>        when federation of identities is needed.
> > > > > > > > > > > > >>>>>        This
> > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > >>>>>        allows
> > > > > > > > > > > > >>>>>        existing
> > > > > > > > > > > > >>>>>        security infrastructures (eg.: SAML-based
> > > > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > >>>>>        benefit
> > > > > > > > > > > > >>>>>        from KC's support for cloud, rest and
> > > > > > > > > > > > >>>>>        mobile
> > > > > > > > > > > > >>>>>        use
> > > > > > > > > > > > >>>>>        cases.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>        I think this is enough to start a
> > > > > > > > > > > > >>>>>        discussion.
> > > > > > > > > > > > >>>>>        I've
> > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > >>>>>        initial
> > > > > > > > > > > > >>>>>        discussion with Stian about all that and
> > > > > > > > > > > > >>>>>        we
> > > > > > > > > > > > >>>>>        agreed
> > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > >>>>>        protocol from applications should be
> > > > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > >>>>>        main
> > > > > > > > > > > > >>>>>        reason is
> > > > > > > > > > > > >>>>>        that it makes life easier for applications
> > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > >>>>>        only
> > > > > > > > > > > > >>>>>        need
> > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > >>>>>        know
> > > > > > > > > > > > >>>>>        about KC tokens and nothing else. However
> > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > >>>>>        new
> > > > > > > > > > > > >>>>>        requirements around user provisioning and
> > > > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > > > >>>>>        resolution
> > > > > > > > > > > > >>>>>        or mapping. But that would be another
> > > > > > > > > > > > >>>>>        thread.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > > > > > > > >>>> applications"?
> > > > > > > > > > > > >>>> Not
> > > > > > > > > > > > >>>> sure what you mean by that.  IDP federation should
> > > > > > > > > > > > >>>> be
> > > > > > > > > > > > >>>> configured
> > > > > > > > > > > > >>>> at
> > > > > > > > > > > > >>>> the
> > > > > > > > > > > > >>>> realm level and really has nothing to do with
> > > > > > > > > > > > >>>> applications.
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> I'm really happy that somebody is doing this.
> > > > > > > > > > > > >>>> We're
> > > > > > > > > > > > >>>> getting
> > > > > > > > > > > > >>>> a
> > > > > > > > > > > > >>>> real
> > > > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> Sure. What I meant was that the application only
> > > > > > > > > > > > >>> knows
> > > > > > > > > > > > >>> about
> > > > > > > > > > > > >>> KC
> > > > > > > > > > > > >>> tokens
> > > > > > > > > > > > >>> nothing else. It will always receive a KC token
> > > > > > > > > > > > >>> regardless
> > > > > > > > > > > > >>> the
> > > > > > > > > > > > >>> protocol
> > > > > > > > > > > > >>> used
> > > > > > > > > > > > >>> to authenticate the user against a 3rd party IdP
> > > > > > > > > > > > >>> (saml,
> > > > > > > > > > > > >>> oidc,
> > > > > > > > > > > > >>> whatever).
> > > > > > > > > > > > >>> The
> > > > > > > > > > > > >>> example I gave was about an user trying to
> > > > > > > > > > > > >>> authenticate
> > > > > > > > > > > > >>> against
> > > > > > > > > > > > >>> a
> > > > > > > > > > > > >>> SAML
> > > > > > > > > > > > >>> IdP.
> > > > > > > > > > > > >>> In this case, after a successful authentication on
> > > > > > > > > > > > >>> the
> > > > > > > > > > > > >>> IdP,
> > > > > > > > > > > > >>> the
> > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > >>> will
> > > > > > > > > > > > >>> issue a token to KC. Then KC will validate the
> > > > > > > > > > > > >>> token,
> > > > > > > > > > > > >>> perform
> > > > > > > > > > > > >>> trust
> > > > > > > > > > > > >>> and
> > > > > > > > > > > > >>> security checks, do user provisioning and
> > > > > > > > > > > > >>> attribute/claim
> > > > > > > > > > > > >>> resolution
> > > > > > > > > > > > >>> to
> > > > > > > > > > > > >>> finally issue a KC token and redirect the user to
> > > > > > > > > > > > >>> the
> > > > > > > > > > > > >>> application.
> > > > > > > > > > > > >>> If
> > > > > > > > > > > > >>> the
> > > > > > > > > > > > >>> app is configured to use openid in KC then it will
> > > > > > > > > > > > >>> receive
> > > > > > > > > > > > >>> a
> > > > > > > > > > > > >>> openid
> > > > > > > > > > > > >>> token
> > > > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> The other scenario is pretty much the same. The
> > > > > > > > > > > > >>> difference
> > > > > > > > > > > > >>> is
> > > > > > > > > > > > >>> that
> > > > > > > > > > > > >>> KC
> > > > > > > > > > > > >>> will
> > > > > > > > > > > > >>> not issue its own token but just replay the token
> > > > > > > > > > > > >>> issued
> > > > > > > > > > > > >>> by
> > > > > > > > > > > > >>> the
> > > > > > > > > > > > >>> 3rd
> > > > > > > > > > > > >>> party
> > > > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> I agree that this config goes at the realm level.
> > > > > > > > > > > > >>> For
> > > > > > > > > > > > >>> instance,
> > > > > > > > > > > > >>> to
> > > > > > > > > > > > >>> create
> > > > > > > > > > > > >>> and
> > > > > > > > > > > > >>> enable providers for being used. However, I think
> > > > > > > > > > > > >>> we
> > > > > > > > > > > > >>> would
> > > > > > > > > > > > >>> need
> > > > > > > > > > > > >>> some
> > > > > > > > > > > > >>> specific configuration for applications as well.
> > > > > > > > > > > > >>> Specially
> > > > > > > > > > > > >>> when
> > > > > > > > > > > > >>> defining
> > > > > > > > > > > > >>> default roles, mapping attributes. Another example
> > > > > > > > > > > > >>> of
> > > > > > > > > > > > >>> application
> > > > > > > > > > > > >>> config
> > > > > > > > > > > > >>> is
> > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define
> > > > > > > > > > > > >>> scopes
> > > > > > > > > > > > >>> per-application.
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> --
> > > > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > > >>> 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
> > > > > > > > > > > > 
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > 
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > 
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > keycloak-dev mailing list
> > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > >
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From bburke at redhat.com  Fri Dec  5 09:01:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 09:01:16 -0500
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1246483027.11327875.1417787734480.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
	<5481B715.1020909@redhat.com>
	<1246483027.11327875.1417787734480.JavaMail.zimbra@redhat.com>
Message-ID: <5481BAAC.8030101@redhat.com>



On 12/5/2014 8:55 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 5 December, 2014 2:45:57 PM
>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>
>>
>>
>> On 12/5/2014 8:43 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 5 December, 2014 2:36:14 PM
>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>>
>>>> ----- Original Message -----
>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, December 5, 2014 10:59:08 AM
>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>>>
>>>>> Another related thing. We've had a few people ask to be able to login to
>>>>> Keycloak on mobiles using the native social login mechanism.
>>>>>
>>>>> I think the best way to do that is to use the direct grant api and make
>>>>> it
>>>>> possible to call that endpoint passing a IdP id and a token instead of
>>>>> username and password.
>>>>>
>>>>> WDYT?
>>>>
>>>> The broker endpoint expects the idp id in order to start the
>>>> authentication
>>>> process. Today, the endpoint also expects KCs authorization code in order
>>>> to
>>>> validate requests from clients and use it as a state to validate responses
>>>> from the trusted idps.
>>>>
>>>> This authorization code is a blocker for this use case, given that mobile
>>>> don't have this code and just want to start the authentication.
>>>>
>>>> A possible solution would be to change the broker to also accept a
>>>> client_id
>>>> to reference the mobile app and perform some validations based on that.
>>>> Something like that:
>>>>
>>>> 1) Mobile displays a Facebook button
>>>> 2) User clicks the button and mobile sends a request to KC Broker with the
>>>> idp id and his client_id.
>>>> 3) KC Broker checks if the client_id is valid and creates a temporary
>>>> authorization code.
>>>> 4) KC Broker redirect mobile to the chosen IdP to perform authentication.
>>>> 5) KC Broker receives a response from the IdP, generate its own token and
>>>> send it back to mobile
>>>>
>>>> Makes sense ?
>>>
>>> No that's not the flow I had in mind. Basically the mobile app
>>> authenticates with Facebook through the native mechanisms. The app then
>>> has an access token, which it would send to Keycloak on the direct grant
>>> api to obtain a Keycloak token.
>>>
>>> Same for other identity providers, the assumption is the app has an out of
>>> bounds mechanism to obtain an access token, which is then sent to Keycloak
>>> over the direct grant api.
>>>
>>
>> How would/could that work exactly?  Do social providers sign the token
>> somehow?  Can the token be verified?
>
> I think we should invoke the IdP to verify the token rather than verify it locally.
>
> All the social providers we have at the moment first retrieve a token, then use it to obtain the user profile. I assumed we'd just skip the first step and just use the supplied token to retrieve the user profile.
>
> For OpenID Connect providers there's the UserInfo endpoint that can be used. That'll both verify the token as well as provide us with the user profile.
>
> Not sure about SAML.
>
Keycloak doesn't even need to be involved unless you want an access token.

IMO, define a solid way on how you would like it to look and work.  Then 
worry later whether or not a specification fits the model.


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

From stian at redhat.com  Fri Dec  5 09:05:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 09:05:19 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <5481BAAC.8030101@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
	<5481B715.1020909@redhat.com>
	<1246483027.11327875.1417787734480.JavaMail.zimbra@redhat.com>
	<5481BAAC.8030101@redhat.com>
Message-ID: <2002651725.11374027.1417788319544.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, 5 December, 2014 3:01:16 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> 
> On 12/5/2014 8:55 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 5 December, 2014 2:45:57 PM
> >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>
> >>
> >>
> >> On 12/5/2014 8:43 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, 5 December, 2014 2:36:14 PM
> >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Friday, December 5, 2014 10:59:08 AM
> >>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>>>> Broker
> >>>>>
> >>>>> Another related thing. We've had a few people ask to be able to login
> >>>>> to
> >>>>> Keycloak on mobiles using the native social login mechanism.
> >>>>>
> >>>>> I think the best way to do that is to use the direct grant api and make
> >>>>> it
> >>>>> possible to call that endpoint passing a IdP id and a token instead of
> >>>>> username and password.
> >>>>>
> >>>>> WDYT?
> >>>>
> >>>> The broker endpoint expects the idp id in order to start the
> >>>> authentication
> >>>> process. Today, the endpoint also expects KCs authorization code in
> >>>> order
> >>>> to
> >>>> validate requests from clients and use it as a state to validate
> >>>> responses
> >>>> from the trusted idps.
> >>>>
> >>>> This authorization code is a blocker for this use case, given that
> >>>> mobile
> >>>> don't have this code and just want to start the authentication.
> >>>>
> >>>> A possible solution would be to change the broker to also accept a
> >>>> client_id
> >>>> to reference the mobile app and perform some validations based on that.
> >>>> Something like that:
> >>>>
> >>>> 1) Mobile displays a Facebook button
> >>>> 2) User clicks the button and mobile sends a request to KC Broker with
> >>>> the
> >>>> idp id and his client_id.
> >>>> 3) KC Broker checks if the client_id is valid and creates a temporary
> >>>> authorization code.
> >>>> 4) KC Broker redirect mobile to the chosen IdP to perform
> >>>> authentication.
> >>>> 5) KC Broker receives a response from the IdP, generate its own token
> >>>> and
> >>>> send it back to mobile
> >>>>
> >>>> Makes sense ?
> >>>
> >>> No that's not the flow I had in mind. Basically the mobile app
> >>> authenticates with Facebook through the native mechanisms. The app then
> >>> has an access token, which it would send to Keycloak on the direct grant
> >>> api to obtain a Keycloak token.
> >>>
> >>> Same for other identity providers, the assumption is the app has an out
> >>> of
> >>> bounds mechanism to obtain an access token, which is then sent to
> >>> Keycloak
> >>> over the direct grant api.
> >>>
> >>
> >> How would/could that work exactly?  Do social providers sign the token
> >> somehow?  Can the token be verified?
> >
> > I think we should invoke the IdP to verify the token rather than verify it
> > locally.
> >
> > All the social providers we have at the moment first retrieve a token, then
> > use it to obtain the user profile. I assumed we'd just skip the first step
> > and just use the supplied token to retrieve the user profile.
> >
> > For OpenID Connect providers there's the UserInfo endpoint that can be
> > used. That'll both verify the token as well as provide us with the user
> > profile.
> >
> > Not sure about SAML.
> >
> Keycloak doesn't even need to be involved unless you want an access token.
> 
> IMO, define a solid way on how you would like it to look and work.  Then
> worry later whether or not a specification fits the model.

It basically boils down to not everyone wants to use the recommended login flows we have. With our login screen a social buttons on the page. There's at least 3 users that's asked how they can integrate with the native login experiences provided by Google and Facebook on mobiles to login to Keycloak.

They'll have a token from Facebook or Google, but need a token from Keycloak to be able to invoke their own apps.

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

From stian at redhat.com  Fri Dec  5 09:07:37 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 09:07:37 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<2131724929.25260557.1417781333595.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
	<1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>
Message-ID: <4760322.11384589.1417788457523.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 2:57:46 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, December 5, 2014 11:43:32 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 5 December, 2014 2:36:14 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, December 5, 2014 10:59:08 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > Another related thing. We've had a few people ask to be able to login
> > > > to
> > > > Keycloak on mobiles using the native social login mechanism.
> > > > 
> > > > I think the best way to do that is to use the direct grant api and make
> > > > it
> > > > possible to call that endpoint passing a IdP id and a token instead of
> > > > username and password.
> > > > 
> > > > WDYT?
> > > 
> > > The broker endpoint expects the idp id in order to start the
> > > authentication
> > > process. Today, the endpoint also expects KCs authorization code in order
> > > to
> > > validate requests from clients and use it as a state to validate
> > > responses
> > > from the trusted idps.
> > > 
> > > This authorization code is a blocker for this use case, given that mobile
> > > don't have this code and just want to start the authentication.
> > > 
> > > A possible solution would be to change the broker to also accept a
> > > client_id
> > > to reference the mobile app and perform some validations based on that.
> > > Something like that:
> > > 
> > > 1) Mobile displays a Facebook button
> > > 2) User clicks the button and mobile sends a request to KC Broker with
> > > the
> > > idp id and his client_id.
> > > 3) KC Broker checks if the client_id is valid and creates a temporary
> > > authorization code.
> > > 4) KC Broker redirect mobile to the chosen IdP to perform authentication.
> > > 5) KC Broker receives a response from the IdP, generate its own token and
> > > send it back to mobile
> > > 
> > > Makes sense ?
> > 
> > No that's not the flow I had in mind. Basically the mobile app
> > authenticates
> > with Facebook through the native mechanisms. The app then has an access
> > token, which it would send to Keycloak on the direct grant api to obtain a
> > Keycloak token.
> 
> Ahh, now I get what you mean :)
> 
> Yes, what you said is enough. Then we just need to validate the access token
> (eg.: using a tokeninfo endpoint).
> 
> But I think we can also consider that use case I mentioned. You may want to
> login without forcing the user to redirect to KC login page.

We could just add a query param to the login url that lets you pick the IdP to use by alias?

  For example auth/.../login?client_id=...&auth_method=google

> 
> > 
> > Same for other identity providers, the assumption is the app has an out of
> > bounds mechanism to obtain an access token, which is then sent to Keycloak
> > over the direct grant api.
> > 
> > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, 5 December, 2014 1:45:24 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Looks good. I reckon we can combine the two pages. What about if
> > > > > > the
> > > > > > 'Add
> > > > > > provider' drop-down is:
> > > > > > 
> > > > > >   OpenID
> > > > > >   SAML
> > > > > >   ------
> > > > > >   Google
> > > > > >   GitHub
> > > > > >   Facebook
> > > > > >   Twitter
> > > > > > 
> > > > > > Let's drop social on/off and instead have a enable/disable button
> > > > > > on
> > > > > > each
> > > > > > provider.
> > > > > 
> > > > > Sure.
> > > > > 
> > > > > > 
> > > > > > Also, would be nice if users could set a name or alias for a
> > > > > > provider
> > > > > > instance. This would make the callback url easier to use (instead
> > > > > > of
> > > > > > callback/<UUID> it's callback/<alias>). The user federation
> > > > > > providers
> > > > > > have
> > > > > > this.
> > > > > 
> > > > > One of my first tries was using an alias, just like that. But I
> > > > > preferred
> > > > > using the UUID and make the configuration more easier. Beside that,
> > > > > the
> > > > > callback url is just a copy and paste, so I think an alias would not
> > > > > bring
> > > > > so much usability, but add one more step when configuring providers.
> > > > > 
> > > > > However, if this is an usability requirement for KC I can change
> > > > > that.
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > In one of our last discussions, you suggested to leave Social as
> > > > > > > it
> > > > > > > is.
> > > > > > > Although IMO I think we can have a single place to manage both
> > > > > > > social
> > > > > > > and
> > > > > > > user-defined identity providers. Social ones are just OOTB and
> > > > > > > pre-configured identity providers now.
> > > > > > > 
> > > > > > > That said, today I'm using separated tabs for social and
> > > > > > > user-defined.
> > > > > > > Please, take a look at [1] for more details on how the UI looks
> > > > > > > like.
> > > > > > > 
> > > > > > > I've changed social UI a bit in order to provide a specific page
> > > > > > > for
> > > > > > > create/update. I've also added a "Show Secret" link to display
> > > > > > > the
> > > > > > > client_secret in clear text if user wants to.
> > > > > > > 
> > > > > > > Beside the enable/disable button, I think another good thing to
> > > > > > > do
> > > > > > > is
> > > > > > > specify
> > > > > > > a default role(s) for each provider. That can be useful if
> > > > > > > applications
> > > > > > > want
> > > > > > > to perform any kind of authorization based on the identity
> > > > > > > provider
> > > > > > > or
> > > > > > > authentication method used to authenticate an user (eg.: useful
> > > > > > > for
> > > > > > > adaptative or multi-level access control). We can also use the
> > > > > > > "amr"
> > > > > > > claim
> > > > > > > in the ID Token, which seems KC is not considering at all. The
> > > > > > > latter
> > > > > > > is
> > > > > > > an
> > > > > > > important thing to think of, regardless this broker work I'm
> > > > > > > doing.
> > > > > > > 
> > > > > > > [1]
> > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Having a separate enable/disable for each provider would be good.
> > > > > > > If
> > > > > > > you're
> > > > > > > leaving the social tab as is and adding a separate tab for
> > > > > > > configuring
> > > > > > > brokered idp's then we should leave the social enable/disable
> > > > > > > button,
> > > > > > > otherwise it depends how it'll look like in the end.
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > >    Social has a button to enable/disable it. I'm wondering what
> > > > > > > >    to
> > > > > > > >    do
> > > > > > > >    with
> > > > > > > >    the brokered identity providers. Shall we add a similar flag
> > > > > > > >    for
> > > > > > > >    that
> > > > > > > >    ?
> > > > > > > > 
> > > > > > > >    I was also wondering if the best would be a flag in a per
> > > > > > > >    provider
> > > > > > > >    basis.
> > > > > > > >    So we can disable/enable a specific provider (social or
> > > > > > > >    brokered),
> > > > > > > >    instead of doing that for all.
> > > > > > > > 
> > > > > > > > Regards.
> > > > > > > > Pedro Igor
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > I'll go for it then. Will remove the icon url from the
> > > > > > > > > > model
> > > > > > > > > > and
> > > > > > > > > > leave
> > > > > > > > > > that
> > > > > > > > > > for users if they want to provide icons for their identity
> > > > > > > > > > providers.
> > > > > > > > > > 
> > > > > > > > > > My point is that icons can be usually served by the same
> > > > > > > > > > server/application
> > > > > > > > > > or proxy, so download images are not such a big deal. Also,
> > > > > > > > > > the
> > > > > > > > > > icon
> > > > > > > > > > url
> > > > > > > > > > is
> > > > > > > > > > part of the freemarker model and people can do what ever
> > > > > > > > > > they
> > > > > > > > > > want
> > > > > > > > > > with
> > > > > > > > > > it.
> > > > > > > > > > What I think will also help in your future plans.
> > > > > > > > > 
> > > > > > > > > I'm not following. Are you saying that if a named image
> > > > > > > > > 'my-provider.png'
> > > > > > > > > is
> > > > > > > > > loaded from a theme, then you can override it in another
> > > > > > > > > theme?
> > > > > > > > > 
> > > > > > > > > If so, that's basically the same as having a css class
> > > > > > > > > 'my-provider'
> > > > > > > > > in
> > > > > > > > > a
> > > > > > > > > theme. With the exception that with an image you end up with
> > > > > > > > > having
> > > > > > > > > to
> > > > > > > > > require a image per provider per theme per language, which
> > > > > > > > > could
> > > > > > > > > be
> > > > > > > > > a
> > > > > > > > > lot
> > > > > > > > > of
> > > > > > > > > images for a single provider. Also, buttons for accessibility
> > > > > > > > > should
> > > > > > > > > be
> > > > > > > > > defined with text and css, not images that can't be
> > > > > > > > > interpreted.
> > > > > > > > > You
> > > > > > > > > also
> > > > > > > > > still need to modify the theme, so I don't see any benefits.
> > > > > > > > 
> > > > > > > > You are right. Having a icon url per provider does not makes
> > > > > > > > sense
> > > > > > > > if
> > > > > > > > there
> > > > > > > > are requirements to change images accordingly to a theme or
> > > > > > > > language.
> > > > > > > > CSS
> > > > > > > > makes life easier.
> > > > > > > > 
> > > > > > > > Will remove that property from the model.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > Users can now specify a Icon Url to be rendered on the
> > > > > > > > > > > login
> > > > > > > > > > > page
> > > > > > > > > > > when
> > > > > > > > > > > social
> > > > > > > > > > > or any other identity provider is configured. So we just
> > > > > > > > > > > load
> > > > > > > > > > > the
> > > > > > > > > > > image
> > > > > > > > > > > the
> > > > > > > > > > > url entered by the user.
> > > > > > > > > > > 
> > > > > > > > > > > Are you saying that users should change the theme or
> > > > > > > > > > > customize
> > > > > > > > > > > css
> > > > > > > > > > > if
> > > > > > > > > > > they
> > > > > > > > > > > only want to change an icon for a provider ?
> > > > > > > > > > 
> > > > > > > > > > Yes, there's many issues with having a icon url:
> > > > > > > > > > 
> > > > > > > > > > * Won't work for internationalization - we don't have this
> > > > > > > > > > now,
> > > > > > > > > > but
> > > > > > > > > > we
> > > > > > > > > > will
> > > > > > > > > > * Image is not a good button - CSS is much better
> > > > > > > > > > * Doesn't support themes - we allow users to switch l&f by
> > > > > > > > > > switching
> > > > > > > > > > themes,
> > > > > > > > > > but that won't work for a icon url. In the future we may
> > > > > > > > > > also
> > > > > > > > > > support
> > > > > > > > > > multiple themes per-realm, for example to depending on the
> > > > > > > > > > devices
> > > > > > > > > > (one
> > > > > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > > > > * Requires the URL to be hosted somewhere - why require a
> > > > > > > > > > separate
> > > > > > > > > > call
> > > > > > > > > > to
> > > > > > > > > > download an image (to a separate server maybe) if it can
> > > > > > > > > > simply
> > > > > > > > > > be
> > > > > > > > > > defined
> > > > > > > > > > in a single CSS file?
> > > > > > > > > > 
> > > > > > > > > > Rather than add additional places to define look and feel
> > > > > > > > > > components
> > > > > > > > > > we
> > > > > > > > > > should in the future make it easier to add/customize
> > > > > > > > > > themes.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > All look and feel related things including images and
> > > > > > > > > > > stylesheets
> > > > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > part of themes. This is to allow customizing them in the
> > > > > > > > > > > theme.
> > > > > > > > > > > Also,
> > > > > > > > > > > an
> > > > > > > > > > > image is not the correct way to render a button, it
> > > > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > defined
> > > > > > > > > > > in
> > > > > > > > > > > CSS.
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > You shouldn't have icon images for social providers.
> > > > > > > > > > > > They
> > > > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > specified
> > > > > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > 
> > > > > > > > > > > > >     Anyone know where I can get the icons images for
> > > > > > > > > > > > >     social
> > > > > > > > > > > > >     providers
> > > > > > > > > > > > >     ?
> > > > > > > > > > > > >     It
> > > > > > > > > > > > >     seems zocial defines them encoded in some way in
> > > > > > > > > > > > >     CSS.
> > > > > > > > > > > > >     I
> > > > > > > > > > > > >     need
> > > > > > > > > > > > >     that
> > > > > > > > > > > > >     to
> > > > > > > > > > > > >     provide default images if user does not specify
> > > > > > > > > > > > >     their
> > > > > > > > > > > > >     own.
> > > > > > > > > > > > > 
> > > > > > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    I've done some initial work covering both
> > > > > > > > > > > > >    persistence
> > > > > > > > > > > > >    and
> > > > > > > > > > > > >    brokering.
> > > > > > > > > > > > >    No
> > > > > > > > > > > > >    UI, yet. I'm focused on the model, rest api and
> > > > > > > > > > > > >    brokering
> > > > > > > > > > > > >    functionality
> > > > > > > > > > > > >    for now.
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    What I have is enough to decide if we are aligned
> > > > > > > > > > > > >    about
> > > > > > > > > > > > >    this
> > > > > > > > > > > > >    functionality. So you can understand how the model
> > > > > > > > > > > > >    (and
> > > > > > > > > > > > >    persistence),
> > > > > > > > > > > > >    rest api and brokering functionality looks like.
> > > > > > > > > > > > >    Can
> > > > > > > > > > > > >    we
> > > > > > > > > > > > >    schedule
> > > > > > > > > > > > >    a
> > > > > > > > > > > > >    meeting ?
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > > > > 
> > > > > > > > > > > > > [1]
> > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > > > > based
> > > > > > > > > > > > > on either realm roles or the roles of one specific
> > > > > > > > > > > > > application.
> > > > > > > > > > > > > This
> > > > > > > > > > > > > is
> > > > > > > > > > > > > related to 1) too.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > > > > > > > 1) Sounds like something definitely worth aiming
> > > > > > > > > > > > > > for.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > > > > > > >> I just wanted to quickly list the additional work
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> discussed
> > > > > > > > > > > > > >> so
> > > > > > > > > > > > > >> everyone
> > > > > > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping
> > > > > > > > > > > > > >> of
> > > > > > > > > > > > > >> an
> > > > > > > > > > > > > >> external
> > > > > > > > > > > > > >> token
> > > > > > > > > > > > > >> to
> > > > > > > > > > > > > >> a KC token? For example an external token with
> > > > > > > > > > > > > >> attribute
> > > > > > > > > > > > > >> 'group'
> > > > > > > > > > > > > >> that
> > > > > > > > > > > > > >> contains 'sales' and 'manager' could be mapped to
> > > > > > > > > > > > > >> 'manager'
> > > > > > > > > > > > > >> role
> > > > > > > > > > > > > >> for
> > > > > > > > > > > > > >> 'sales app in a KC token. Could we use Drools?
> > > > > > > > > > > > > >> This
> > > > > > > > > > > > > >> could
> > > > > > > > > > > > > >> also
> > > > > > > > > > > > > >> be
> > > > > > > > > > > > > >> used
> > > > > > > > > > > > > >> in
> > > > > > > > > > > > > >> user federation to allow more complex mapping of
> > > > > > > > > > > > > >> roles/groups
> > > > > > > > > > > > > >> than
> > > > > > > > > > > > > >> a
> > > > > > > > > > > > > >> simple 1-1
> > > > > > > > > > > > > >> 2) Retrieving tokens - if an application wants to
> > > > > > > > > > > > > >> retrieve
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> external
> > > > > > > > > > > > > >> token (for example to view Facebook friends if
> > > > > > > > > > > > > >> user
> > > > > > > > > > > > > >> logged
> > > > > > > > > > > > > >> in
> > > > > > > > > > > > > >> with
> > > > > > > > > > > > > >> Facebook)
> > > > > > > > > > > > > >> 3) Configure scope - currently for social we only
> > > > > > > > > > > > > >> request
> > > > > > > > > > > > > >> a
> > > > > > > > > > > > > >> very
> > > > > > > > > > > > > >> limited
> > > > > > > > > > > > > >> scope (basic profile and email), to for example
> > > > > > > > > > > > > >> view
> > > > > > > > > > > > > >> Facebook
> > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > > > > >> 4) Selecting provider - currently in social (and
> > > > > > > > > > > > > >> for
> > > > > > > > > > > > > >> first
> > > > > > > > > > > > > >> pass
> > > > > > > > > > > > > >> of
> > > > > > > > > > > > > >> brokering) we have an icon user has to select, but
> > > > > > > > > > > > > >> can
> > > > > > > > > > > > > >> we
> > > > > > > > > > > > > >> select
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> provider in a different way (for example ask user
> > > > > > > > > > > > > >> for
> > > > > > > > > > > > > >> email,
> > > > > > > > > > > > > >> and
> > > > > > > > > > > > > >> select
> > > > > > > > > > > > > >> based on email domain)
> > > > > > > > > > > > > >> 5) Gateway - don't create a KC token, but just
> > > > > > > > > > > > > >> forward
> > > > > > > > > > > > > >> the
> > > > > > > > > > > > > >> external
> > > > > > > > > > > > > >> token
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> IMO 1) is a killer feature, as it would allow
> > > > > > > > > > > > > >> companies
> > > > > > > > > > > > > >> to
> > > > > > > > > > > > > >> add
> > > > > > > > > > > > > >> external
> > > > > > > > > > > > > >> users without having to modify their applications.
> > > > > > > > > > > > > >> Issue
> > > > > > > > > > > > > >> with
> > > > > > > > > > > > > >> 5)
> > > > > > > > > > > > > >> is
> > > > > > > > > > > > > >> that
> > > > > > > > > > > > > >> applications need to understand more than one
> > > > > > > > > > > > > >> token,
> > > > > > > > > > > > > >> which
> > > > > > > > > > > > > >> would
> > > > > > > > > > > > > >> require
> > > > > > > > > > > > > >> rewriting applications.
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> This work is also somewhat related to other
> > > > > > > > > > > > > >> authentication
> > > > > > > > > > > > > >> mechanisms
> > > > > > > > > > > > > >> (for
> > > > > > > > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > >>> Authentication
> > > > > > > > > > > > > >>> Broker
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > >>>> and
> > > > > > > > > > > > > >>>> Authentication
> > > > > > > > > > > > > >>>> Broker
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > > > > > > > >>>>> Hi,
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        Would like to start a discussion about
> > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > >>>>>        enable
> > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > >>>>>        Authentication Broker in order to
> > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > >>>>>        Chained
> > > > > > > > > > > > > >>>>>        Federation
> > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > >>>>>        also Identity Federation. First of all,
> > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > >>>>>        background
> > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > >>>>>        what
> > > > > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        Currently KeyCloak provides two basic
> > > > > > > > > > > > > >>>>>        types
> > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > >>>>>        (correct
> > > > > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>            1) Local authentication (based on
> > > > > > > > > > > > > >>>>>            some
> > > > > > > > > > > > > >>>>>            credential
> > > > > > > > > > > > > >>>>>            type
> > > > > > > > > > > > > >>>>>            enabled
> > > > > > > > > > > > > >>>>>            to
> > > > > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        Local authentication is about
> > > > > > > > > > > > > >>>>>        authenticating
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > >>>>>        locally
> > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > >>>>>        KC's own identity store. Nothing special
> > > > > > > > > > > > > >>>>>        here.
> > > > > > > > > > > > > >>>>>        And
> > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > >>>>>        Authentication which allows users to
> > > > > > > > > > > > > >>>>>        choose
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > > >>>>>        to authenticate with. In this case, the
> > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > >>>>>        always
> > > > > > > > > > > > > >>>>>        one
> > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        built-in social providers supported by
> > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > > > > >>>>>        Google,
> > > > > > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        When doing social, the user is
> > > > > > > > > > > > > >>>>>        automatically
> > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > >>>>>        does
> > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > >>>>>        need to fill a registration form and can
> > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > >>>>>        very
> > > > > > > > > > > > > >>>>>        quickly. During the provisioning some
> > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > > > > >>>>>        from the social provider such as email,
> > > > > > > > > > > > > >>>>>        firstname
> > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > >>>>>        These
> > > > > > > > > > > > > >>>>>        are very basic information, any other
> > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > >>>>>        related with authorization policies -
> > > > > > > > > > > > > >>>>>        eg.:
> > > > > > > > > > > > > >>>>>        roles
> > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > >>>>>        groups
> > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        Another important characteristic of
> > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        application receives a KC token and not
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > >>>>>        issued by
> > > > > > > > > > > > > >>>>>        the social IdP during the authentication
> > > > > > > > > > > > > >>>>>        process.
> > > > > > > > > > > > > >>>>>        If
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > >>>>>        wants to consume resources from the
> > > > > > > > > > > > > >>>>>        resource
> > > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > > >>>>>        he
> > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > >>>>>        authenticated it must obtain the access
> > > > > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > >>>>>        itself
> > > > > > > > > > > > > >>>>>        prior
> > > > > > > > > > > > > >>>>>        to invoke the resource provider API.
> > > > > > > > > > > > > >>>>>        Assuming
> > > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > >>>>>        providers are based on oAuth 1.0 or 2.0.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        That said, the Authentication Broker
> > > > > > > > > > > > > >>>>>        functionality
> > > > > > > > > > > > > >>>>>        aims
> > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > >>>>>        cover
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        same use cases but with a lot of more
> > > > > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > > > > >>>>>        on
> > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > >>>>>        setup
> > > > > > > > > > > > > >>>>>        identity providers(not only social ones)
> > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > >>>>>        protocols they may support such as SAML,
> > > > > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > >>>>>        This is useful when an enterprise is
> > > > > > > > > > > > > >>>>>        providing
> > > > > > > > > > > > > >>>>>        services
> > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > >>>>>        customers(IdP) and does not want to
> > > > > > > > > > > > > >>>>>        manage
> > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > >>>>>        relationships. When using a broker, the
> > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > >>>>>        steps
> > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > >>>>>        pretty much the same when you are using
> > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > > > > >>>>>        with
> > > > > > > > > > > > > >>>>>        important differences on how you support
> > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > > > >>>>>        providers, different federation
> > > > > > > > > > > > > >>>>>        protocols,
> > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > >>>>>        and how claims and attributes are
> > > > > > > > > > > > > >>>>>        resolved.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        The brokering functionality can be done
> > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > > >>>>>        ways
> > > > > > > > > > > > > >>>>>        depending
> > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        broker service is acting as a gateway or
> > > > > > > > > > > > > >>>>>        not.
> > > > > > > > > > > > > >>>>>        When
> > > > > > > > > > > > > >>>>>        acting
> > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > >>>>>        gateway, the broker will respond to the
> > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        same
> > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > >>>>>        issued by the trusted identity provider.
> > > > > > > > > > > > > >>>>>        For
> > > > > > > > > > > > > >>>>>        instance,
> > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > >>>>>        selects a SAML IdP to authenticate with,
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > >>>>>        a SAML Response. In this case, the
> > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > >>>>>        prepared
> > > > > > > > > > > > > >>>>>        to handle a specific federation
> > > > > > > > > > > > > >>>>>        protocol.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        However, the broker service can also be
> > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > >>>>>        completely
> > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > >>>>>        from the application the protocol used
> > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > >>>>>        user.
> > > > > > > > > > > > > >>>>>        In
> > > > > > > > > > > > > >>>>>        this case, the application will just
> > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        In both cases, the broker acts as an
> > > > > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > > > > >>>>>        where
> > > > > > > > > > > > > >>>>>        specific
> > > > > > > > > > > > > >>>>>        security policies can be applied when
> > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > >>>>>        try
> > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > >>>>>        themselves against a 3rd party IdP. That
> > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > >>>>>        value
> > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > >>>>>        you think about auditing, authorization
> > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > >>>>>        when federation of identities is needed.
> > > > > > > > > > > > > >>>>>        This
> > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > >>>>>        allows
> > > > > > > > > > > > > >>>>>        existing
> > > > > > > > > > > > > >>>>>        security infrastructures (eg.:
> > > > > > > > > > > > > >>>>>        SAML-based
> > > > > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > >>>>>        benefit
> > > > > > > > > > > > > >>>>>        from KC's support for cloud, rest and
> > > > > > > > > > > > > >>>>>        mobile
> > > > > > > > > > > > > >>>>>        use
> > > > > > > > > > > > > >>>>>        cases.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>        I think this is enough to start a
> > > > > > > > > > > > > >>>>>        discussion.
> > > > > > > > > > > > > >>>>>        I've
> > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > >>>>>        initial
> > > > > > > > > > > > > >>>>>        discussion with Stian about all that and
> > > > > > > > > > > > > >>>>>        we
> > > > > > > > > > > > > >>>>>        agreed
> > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > >>>>>        protocol from applications should be
> > > > > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > >>>>>        main
> > > > > > > > > > > > > >>>>>        reason is
> > > > > > > > > > > > > >>>>>        that it makes life easier for
> > > > > > > > > > > > > >>>>>        applications
> > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > >>>>>        only
> > > > > > > > > > > > > >>>>>        need
> > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > >>>>>        know
> > > > > > > > > > > > > >>>>>        about KC tokens and nothing else.
> > > > > > > > > > > > > >>>>>        However
> > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > >>>>>        new
> > > > > > > > > > > > > >>>>>        requirements around user provisioning
> > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > > > > >>>>>        resolution
> > > > > > > > > > > > > >>>>>        or mapping. But that would be another
> > > > > > > > > > > > > >>>>>        thread.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> Can you elaborate on "abstract the protocol from
> > > > > > > > > > > > > >>>> applications"?
> > > > > > > > > > > > > >>>> Not
> > > > > > > > > > > > > >>>> sure what you mean by that.  IDP federation
> > > > > > > > > > > > > >>>> should
> > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > >>>> configured
> > > > > > > > > > > > > >>>> at
> > > > > > > > > > > > > >>>> the
> > > > > > > > > > > > > >>>> realm level and really has nothing to do with
> > > > > > > > > > > > > >>>> applications.
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> I'm really happy that somebody is doing this.
> > > > > > > > > > > > > >>>> We're
> > > > > > > > > > > > > >>>> getting
> > > > > > > > > > > > > >>>> a
> > > > > > > > > > > > > >>>> real
> > > > > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> Sure. What I meant was that the application only
> > > > > > > > > > > > > >>> knows
> > > > > > > > > > > > > >>> about
> > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > >>> tokens
> > > > > > > > > > > > > >>> nothing else. It will always receive a KC token
> > > > > > > > > > > > > >>> regardless
> > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > >>> protocol
> > > > > > > > > > > > > >>> used
> > > > > > > > > > > > > >>> to authenticate the user against a 3rd party IdP
> > > > > > > > > > > > > >>> (saml,
> > > > > > > > > > > > > >>> oidc,
> > > > > > > > > > > > > >>> whatever).
> > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > >>> example I gave was about an user trying to
> > > > > > > > > > > > > >>> authenticate
> > > > > > > > > > > > > >>> against
> > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > >>> SAML
> > > > > > > > > > > > > >>> IdP.
> > > > > > > > > > > > > >>> In this case, after a successful authentication
> > > > > > > > > > > > > >>> on
> > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > >>> IdP,
> > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > >>> issue a token to KC. Then KC will validate the
> > > > > > > > > > > > > >>> token,
> > > > > > > > > > > > > >>> perform
> > > > > > > > > > > > > >>> trust
> > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > >>> security checks, do user provisioning and
> > > > > > > > > > > > > >>> attribute/claim
> > > > > > > > > > > > > >>> resolution
> > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > >>> finally issue a KC token and redirect the user to
> > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > >>> application.
> > > > > > > > > > > > > >>> If
> > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > >>> app is configured to use openid in KC then it
> > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > >>> receive
> > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > >>> openid
> > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> The other scenario is pretty much the same. The
> > > > > > > > > > > > > >>> difference
> > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > >>> that
> > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > >>> not issue its own token but just replay the token
> > > > > > > > > > > > > >>> issued
> > > > > > > > > > > > > >>> by
> > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > >>> 3rd
> > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> I agree that this config goes at the realm level.
> > > > > > > > > > > > > >>> For
> > > > > > > > > > > > > >>> instance,
> > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > >>> create
> > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > >>> enable providers for being used. However, I think
> > > > > > > > > > > > > >>> we
> > > > > > > > > > > > > >>> would
> > > > > > > > > > > > > >>> need
> > > > > > > > > > > > > >>> some
> > > > > > > > > > > > > >>> specific configuration for applications as well.
> > > > > > > > > > > > > >>> Specially
> > > > > > > > > > > > > >>> when
> > > > > > > > > > > > > >>> defining
> > > > > > > > > > > > > >>> default roles, mapping attributes. Another
> > > > > > > > > > > > > >>> example
> > > > > > > > > > > > > >>> of
> > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > >>> config
> > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to
> > > > > > > > > > > > > >>> define
> > > > > > > > > > > > > >>> scopes
> > > > > > > > > > > > > >>> per-application.
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> --
> > > > > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > > > >>> 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
> > > > > > > > > > > > > 
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > 
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > 
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-dev mailing list
> > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > >
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From psilva at redhat.com  Fri Dec  5 09:15:42 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 Dec 2014 09:15:42 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <4760322.11384589.1417788457523.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
	<1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>
	<4760322.11384589.1417788457523.JavaMail.zimbra@redhat.com>
Message-ID: <711831466.25373681.1417788942317.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, December 5, 2014 12:07:37 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 5 December, 2014 2:57:46 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, December 5, 2014 11:43:32 AM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 5 December, 2014 2:36:14 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, December 5, 2014 10:59:08 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > Another related thing. We've had a few people ask to be able to login
> > > > > to
> > > > > Keycloak on mobiles using the native social login mechanism.
> > > > > 
> > > > > I think the best way to do that is to use the direct grant api and
> > > > > make
> > > > > it
> > > > > possible to call that endpoint passing a IdP id and a token instead
> > > > > of
> > > > > username and password.
> > > > > 
> > > > > WDYT?
> > > > 
> > > > The broker endpoint expects the idp id in order to start the
> > > > authentication
> > > > process. Today, the endpoint also expects KCs authorization code in
> > > > order
> > > > to
> > > > validate requests from clients and use it as a state to validate
> > > > responses
> > > > from the trusted idps.
> > > > 
> > > > This authorization code is a blocker for this use case, given that
> > > > mobile
> > > > don't have this code and just want to start the authentication.
> > > > 
> > > > A possible solution would be to change the broker to also accept a
> > > > client_id
> > > > to reference the mobile app and perform some validations based on that.
> > > > Something like that:
> > > > 
> > > > 1) Mobile displays a Facebook button
> > > > 2) User clicks the button and mobile sends a request to KC Broker with
> > > > the
> > > > idp id and his client_id.
> > > > 3) KC Broker checks if the client_id is valid and creates a temporary
> > > > authorization code.
> > > > 4) KC Broker redirect mobile to the chosen IdP to perform
> > > > authentication.
> > > > 5) KC Broker receives a response from the IdP, generate its own token
> > > > and
> > > > send it back to mobile
> > > > 
> > > > Makes sense ?
> > > 
> > > No that's not the flow I had in mind. Basically the mobile app
> > > authenticates
> > > with Facebook through the native mechanisms. The app then has an access
> > > token, which it would send to Keycloak on the direct grant api to obtain
> > > a
> > > Keycloak token.
> > 
> > Ahh, now I get what you mean :)
> > 
> > Yes, what you said is enough. Then we just need to validate the access
> > token
> > (eg.: using a tokeninfo endpoint).
> > 
> > But I think we can also consider that use case I mentioned. You may want to
> > login without forcing the user to redirect to KC login page.
> 
> We could just add a query param to the login url that lets you pick the IdP
> to use by alias?
> 
>   For example auth/.../login?client_id=...&auth_method=google

Yes, just like my previously example, we need the client_id. The idp id/alias is already there.

Btw, regarding SAML. SAML does not provide a "validation" endpoint like oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the specs for that. What can be done here is validate SAML assertions against a WS-Trust STS. Or just trust the assertion based on the signature and others standards info along it.

We can also take a closer look at the oAuth2 SAML bearer token profile and see if it helps.

> 
> > 
> > > 
> > > Same for other identity providers, the assumption is the app has an out
> > > of
> > > bounds mechanism to obtain an access token, which is then sent to
> > > Keycloak
> > > over the direct grant api.
> > > 
> > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, 5 December, 2014 1:45:24 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Looks good. I reckon we can combine the two pages. What about if
> > > > > > > the
> > > > > > > 'Add
> > > > > > > provider' drop-down is:
> > > > > > > 
> > > > > > >   OpenID
> > > > > > >   SAML
> > > > > > >   ------
> > > > > > >   Google
> > > > > > >   GitHub
> > > > > > >   Facebook
> > > > > > >   Twitter
> > > > > > > 
> > > > > > > Let's drop social on/off and instead have a enable/disable button
> > > > > > > on
> > > > > > > each
> > > > > > > provider.
> > > > > > 
> > > > > > Sure.
> > > > > > 
> > > > > > > 
> > > > > > > Also, would be nice if users could set a name or alias for a
> > > > > > > provider
> > > > > > > instance. This would make the callback url easier to use (instead
> > > > > > > of
> > > > > > > callback/<UUID> it's callback/<alias>). The user federation
> > > > > > > providers
> > > > > > > have
> > > > > > > this.
> > > > > > 
> > > > > > One of my first tries was using an alias, just like that. But I
> > > > > > preferred
> > > > > > using the UUID and make the configuration more easier. Beside that,
> > > > > > the
> > > > > > callback url is just a copy and paste, so I think an alias would
> > > > > > not
> > > > > > bring
> > > > > > so much usability, but add one more step when configuring
> > > > > > providers.
> > > > > > 
> > > > > > However, if this is an usability requirement for KC I can change
> > > > > > that.
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > In one of our last discussions, you suggested to leave Social
> > > > > > > > as
> > > > > > > > it
> > > > > > > > is.
> > > > > > > > Although IMO I think we can have a single place to manage both
> > > > > > > > social
> > > > > > > > and
> > > > > > > > user-defined identity providers. Social ones are just OOTB and
> > > > > > > > pre-configured identity providers now.
> > > > > > > > 
> > > > > > > > That said, today I'm using separated tabs for social and
> > > > > > > > user-defined.
> > > > > > > > Please, take a look at [1] for more details on how the UI looks
> > > > > > > > like.
> > > > > > > > 
> > > > > > > > I've changed social UI a bit in order to provide a specific
> > > > > > > > page
> > > > > > > > for
> > > > > > > > create/update. I've also added a "Show Secret" link to display
> > > > > > > > the
> > > > > > > > client_secret in clear text if user wants to.
> > > > > > > > 
> > > > > > > > Beside the enable/disable button, I think another good thing to
> > > > > > > > do
> > > > > > > > is
> > > > > > > > specify
> > > > > > > > a default role(s) for each provider. That can be useful if
> > > > > > > > applications
> > > > > > > > want
> > > > > > > > to perform any kind of authorization based on the identity
> > > > > > > > provider
> > > > > > > > or
> > > > > > > > authentication method used to authenticate an user (eg.: useful
> > > > > > > > for
> > > > > > > > adaptative or multi-level access control). We can also use the
> > > > > > > > "amr"
> > > > > > > > claim
> > > > > > > > in the ID Token, which seems KC is not considering at all. The
> > > > > > > > latter
> > > > > > > > is
> > > > > > > > an
> > > > > > > > important thing to think of, regardless this broker work I'm
> > > > > > > > doing.
> > > > > > > > 
> > > > > > > > [1]
> > > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > Having a separate enable/disable for each provider would be
> > > > > > > > good.
> > > > > > > > If
> > > > > > > > you're
> > > > > > > > leaving the social tab as is and adding a separate tab for
> > > > > > > > configuring
> > > > > > > > brokered idp's then we should leave the social enable/disable
> > > > > > > > button,
> > > > > > > > otherwise it depends how it'll look like in the end.
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > >    Social has a button to enable/disable it. I'm wondering
> > > > > > > > >    what
> > > > > > > > >    to
> > > > > > > > >    do
> > > > > > > > >    with
> > > > > > > > >    the brokered identity providers. Shall we add a similar
> > > > > > > > >    flag
> > > > > > > > >    for
> > > > > > > > >    that
> > > > > > > > >    ?
> > > > > > > > > 
> > > > > > > > >    I was also wondering if the best would be a flag in a per
> > > > > > > > >    provider
> > > > > > > > >    basis.
> > > > > > > > >    So we can disable/enable a specific provider (social or
> > > > > > > > >    brokered),
> > > > > > > > >    instead of doing that for all.
> > > > > > > > > 
> > > > > > > > > Regards.
> > > > > > > > > Pedro Igor
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > I'll go for it then. Will remove the icon url from the
> > > > > > > > > > > model
> > > > > > > > > > > and
> > > > > > > > > > > leave
> > > > > > > > > > > that
> > > > > > > > > > > for users if they want to provide icons for their
> > > > > > > > > > > identity
> > > > > > > > > > > providers.
> > > > > > > > > > > 
> > > > > > > > > > > My point is that icons can be usually served by the same
> > > > > > > > > > > server/application
> > > > > > > > > > > or proxy, so download images are not such a big deal.
> > > > > > > > > > > Also,
> > > > > > > > > > > the
> > > > > > > > > > > icon
> > > > > > > > > > > url
> > > > > > > > > > > is
> > > > > > > > > > > part of the freemarker model and people can do what ever
> > > > > > > > > > > they
> > > > > > > > > > > want
> > > > > > > > > > > with
> > > > > > > > > > > it.
> > > > > > > > > > > What I think will also help in your future plans.
> > > > > > > > > > 
> > > > > > > > > > I'm not following. Are you saying that if a named image
> > > > > > > > > > 'my-provider.png'
> > > > > > > > > > is
> > > > > > > > > > loaded from a theme, then you can override it in another
> > > > > > > > > > theme?
> > > > > > > > > > 
> > > > > > > > > > If so, that's basically the same as having a css class
> > > > > > > > > > 'my-provider'
> > > > > > > > > > in
> > > > > > > > > > a
> > > > > > > > > > theme. With the exception that with an image you end up
> > > > > > > > > > with
> > > > > > > > > > having
> > > > > > > > > > to
> > > > > > > > > > require a image per provider per theme per language, which
> > > > > > > > > > could
> > > > > > > > > > be
> > > > > > > > > > a
> > > > > > > > > > lot
> > > > > > > > > > of
> > > > > > > > > > images for a single provider. Also, buttons for
> > > > > > > > > > accessibility
> > > > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > defined with text and css, not images that can't be
> > > > > > > > > > interpreted.
> > > > > > > > > > You
> > > > > > > > > > also
> > > > > > > > > > still need to modify the theme, so I don't see any
> > > > > > > > > > benefits.
> > > > > > > > > 
> > > > > > > > > You are right. Having a icon url per provider does not makes
> > > > > > > > > sense
> > > > > > > > > if
> > > > > > > > > there
> > > > > > > > > are requirements to change images accordingly to a theme or
> > > > > > > > > language.
> > > > > > > > > CSS
> > > > > > > > > makes life easier.
> > > > > > > > > 
> > > > > > > > > Will remove that property from the model.
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > Users can now specify a Icon Url to be rendered on the
> > > > > > > > > > > > login
> > > > > > > > > > > > page
> > > > > > > > > > > > when
> > > > > > > > > > > > social
> > > > > > > > > > > > or any other identity provider is configured. So we
> > > > > > > > > > > > just
> > > > > > > > > > > > load
> > > > > > > > > > > > the
> > > > > > > > > > > > image
> > > > > > > > > > > > the
> > > > > > > > > > > > url entered by the user.
> > > > > > > > > > > > 
> > > > > > > > > > > > Are you saying that users should change the theme or
> > > > > > > > > > > > customize
> > > > > > > > > > > > css
> > > > > > > > > > > > if
> > > > > > > > > > > > they
> > > > > > > > > > > > only want to change an icon for a provider ?
> > > > > > > > > > > 
> > > > > > > > > > > Yes, there's many issues with having a icon url:
> > > > > > > > > > > 
> > > > > > > > > > > * Won't work for internationalization - we don't have
> > > > > > > > > > > this
> > > > > > > > > > > now,
> > > > > > > > > > > but
> > > > > > > > > > > we
> > > > > > > > > > > will
> > > > > > > > > > > * Image is not a good button - CSS is much better
> > > > > > > > > > > * Doesn't support themes - we allow users to switch l&f
> > > > > > > > > > > by
> > > > > > > > > > > switching
> > > > > > > > > > > themes,
> > > > > > > > > > > but that won't work for a icon url. In the future we may
> > > > > > > > > > > also
> > > > > > > > > > > support
> > > > > > > > > > > multiple themes per-realm, for example to depending on
> > > > > > > > > > > the
> > > > > > > > > > > devices
> > > > > > > > > > > (one
> > > > > > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > > > > > * Requires the URL to be hosted somewhere - why require a
> > > > > > > > > > > separate
> > > > > > > > > > > call
> > > > > > > > > > > to
> > > > > > > > > > > download an image (to a separate server maybe) if it can
> > > > > > > > > > > simply
> > > > > > > > > > > be
> > > > > > > > > > > defined
> > > > > > > > > > > in a single CSS file?
> > > > > > > > > > > 
> > > > > > > > > > > Rather than add additional places to define look and feel
> > > > > > > > > > > components
> > > > > > > > > > > we
> > > > > > > > > > > should in the future make it easier to add/customize
> > > > > > > > > > > themes.
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > All look and feel related things including images and
> > > > > > > > > > > > stylesheets
> > > > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > part of themes. This is to allow customizing them in
> > > > > > > > > > > > the
> > > > > > > > > > > > theme.
> > > > > > > > > > > > Also,
> > > > > > > > > > > > an
> > > > > > > > > > > > image is not the correct way to render a button, it
> > > > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > defined
> > > > > > > > > > > > in
> > > > > > > > > > > > CSS.
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > You shouldn't have icon images for social providers.
> > > > > > > > > > > > > They
> > > > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > specified
> > > > > > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >     Anyone know where I can get the icons images
> > > > > > > > > > > > > >     for
> > > > > > > > > > > > > >     social
> > > > > > > > > > > > > >     providers
> > > > > > > > > > > > > >     ?
> > > > > > > > > > > > > >     It
> > > > > > > > > > > > > >     seems zocial defines them encoded in some way
> > > > > > > > > > > > > >     in
> > > > > > > > > > > > > >     CSS.
> > > > > > > > > > > > > >     I
> > > > > > > > > > > > > >     need
> > > > > > > > > > > > > >     that
> > > > > > > > > > > > > >     to
> > > > > > > > > > > > > >     provide default images if user does not specify
> > > > > > > > > > > > > >     their
> > > > > > > > > > > > > >     own.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    I've done some initial work covering both
> > > > > > > > > > > > > >    persistence
> > > > > > > > > > > > > >    and
> > > > > > > > > > > > > >    brokering.
> > > > > > > > > > > > > >    No
> > > > > > > > > > > > > >    UI, yet. I'm focused on the model, rest api and
> > > > > > > > > > > > > >    brokering
> > > > > > > > > > > > > >    functionality
> > > > > > > > > > > > > >    for now.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    What I have is enough to decide if we are
> > > > > > > > > > > > > >    aligned
> > > > > > > > > > > > > >    about
> > > > > > > > > > > > > >    this
> > > > > > > > > > > > > >    functionality. So you can understand how the
> > > > > > > > > > > > > >    model
> > > > > > > > > > > > > >    (and
> > > > > > > > > > > > > >    persistence),
> > > > > > > > > > > > > >    rest api and brokering functionality looks like.
> > > > > > > > > > > > > >    Can
> > > > > > > > > > > > > >    we
> > > > > > > > > > > > > >    schedule
> > > > > > > > > > > > > >    a
> > > > > > > > > > > > > >    meeting ?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > > > > > based
> > > > > > > > > > > > > > on either realm roles or the roles of one specific
> > > > > > > > > > > > > > application.
> > > > > > > > > > > > > > This
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > related to 1) too.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz wrote:
> > > > > > > > > > > > > > > 1) Sounds like something definitely worth aiming
> > > > > > > > > > > > > > > for.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > > > > > > > >> I just wanted to quickly list the additional
> > > > > > > > > > > > > > >> work
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> discussed
> > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > >> everyone
> > > > > > > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with
> > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > >> a KC token? For example an external token with
> > > > > > > > > > > > > > >> attribute
> > > > > > > > > > > > > > >> 'group'
> > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > >> contains 'sales' and 'manager' could be mapped
> > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > >> 'manager'
> > > > > > > > > > > > > > >> role
> > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > >> 'sales app in a KC token. Could we use Drools?
> > > > > > > > > > > > > > >> This
> > > > > > > > > > > > > > >> could
> > > > > > > > > > > > > > >> also
> > > > > > > > > > > > > > >> be
> > > > > > > > > > > > > > >> used
> > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > >> user federation to allow more complex mapping of
> > > > > > > > > > > > > > >> roles/groups
> > > > > > > > > > > > > > >> than
> > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > >> simple 1-1
> > > > > > > > > > > > > > >> 2) Retrieving tokens - if an application wants
> > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > >> retrieve
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > >> token (for example to view Facebook friends if
> > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > >> logged
> > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > >> Facebook)
> > > > > > > > > > > > > > >> 3) Configure scope - currently for social we
> > > > > > > > > > > > > > >> only
> > > > > > > > > > > > > > >> request
> > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > >> very
> > > > > > > > > > > > > > >> limited
> > > > > > > > > > > > > > >> scope (basic profile and email), to for example
> > > > > > > > > > > > > > >> view
> > > > > > > > > > > > > > >> Facebook
> > > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > > > > > >> 4) Selecting provider - currently in social (and
> > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > >> first
> > > > > > > > > > > > > > >> pass
> > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > >> brokering) we have an icon user has to select,
> > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > >> can
> > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> provider in a different way (for example ask
> > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > >> email,
> > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > >> based on email domain)
> > > > > > > > > > > > > > >> 5) Gateway - don't create a KC token, but just
> > > > > > > > > > > > > > >> forward
> > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> IMO 1) is a killer feature, as it would allow
> > > > > > > > > > > > > > >> companies
> > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > >> add
> > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > >> users without having to modify their
> > > > > > > > > > > > > > >> applications.
> > > > > > > > > > > > > > >> Issue
> > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > >> 5)
> > > > > > > > > > > > > > >> is
> > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > >> applications need to understand more than one
> > > > > > > > > > > > > > >> token,
> > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > >> would
> > > > > > > > > > > > > > >> require
> > > > > > > > > > > > > > >> rewriting applications.
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> This work is also somewhat related to other
> > > > > > > > > > > > > > >> authentication
> > > > > > > > > > > > > > >> mechanisms
> > > > > > > > > > > > > > >> (for
> > > > > > > > > > > > > > >> example Kerberos ticket, LDAP and passwordless).
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > >>> Authentication
> > > > > > > > > > > > > > >>> Broker
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM
> > > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > >>>> and
> > > > > > > > > > > > > > >>>> Authentication
> > > > > > > > > > > > > > >>>> Broker
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote:
> > > > > > > > > > > > > > >>>>> Hi,
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        Would like to start a discussion about
> > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > >>>>>        enable
> > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > >>>>>        Authentication Broker in order to
> > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > >>>>>        Chained
> > > > > > > > > > > > > > >>>>>        Federation
> > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > >>>>>        also Identity Federation. First of
> > > > > > > > > > > > > > >>>>>        all,
> > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > >>>>>        background
> > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > >>>>>        what
> > > > > > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        Currently KeyCloak provides two basic
> > > > > > > > > > > > > > >>>>>        types
> > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > >>>>>        (correct
> > > > > > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>            1) Local authentication (based on
> > > > > > > > > > > > > > >>>>>            some
> > > > > > > > > > > > > > >>>>>            credential
> > > > > > > > > > > > > > >>>>>            type
> > > > > > > > > > > > > > >>>>>            enabled
> > > > > > > > > > > > > > >>>>>            to
> > > > > > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        Local authentication is about
> > > > > > > > > > > > > > >>>>>        authenticating
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > >>>>>        locally
> > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > >>>>>        KC's own identity store. Nothing
> > > > > > > > > > > > > > >>>>>        special
> > > > > > > > > > > > > > >>>>>        here.
> > > > > > > > > > > > > > >>>>>        And
> > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > >>>>>        Authentication which allows users to
> > > > > > > > > > > > > > >>>>>        choose
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > > > >>>>>        to authenticate with. In this case,
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > >>>>>        always
> > > > > > > > > > > > > > >>>>>        one
> > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        built-in social providers supported by
> > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > > > > > >>>>>        Google,
> > > > > > > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        When doing social, the user is
> > > > > > > > > > > > > > >>>>>        automatically
> > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > >>>>>        does
> > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > >>>>>        need to fill a registration form and
> > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > >>>>>        very
> > > > > > > > > > > > > > >>>>>        quickly. During the provisioning some
> > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > > > > > >>>>>        from the social provider such as
> > > > > > > > > > > > > > >>>>>        email,
> > > > > > > > > > > > > > >>>>>        firstname
> > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > >>>>>        These
> > > > > > > > > > > > > > >>>>>        are very basic information, any other
> > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > >>>>>        related with authorization policies -
> > > > > > > > > > > > > > >>>>>        eg.:
> > > > > > > > > > > > > > >>>>>        roles
> > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > >>>>>        groups
> > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > >>>>>        defined later via KC's admin console.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        Another important characteristic of
> > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        application receives a KC token and
> > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > >>>>>        issued by
> > > > > > > > > > > > > > >>>>>        the social IdP during the
> > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > >>>>>        process.
> > > > > > > > > > > > > > >>>>>        If
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > >>>>>        wants to consume resources from the
> > > > > > > > > > > > > > >>>>>        resource
> > > > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > > > >>>>>        he
> > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > >>>>>        authenticated it must obtain the
> > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > >>>>>        itself
> > > > > > > > > > > > > > >>>>>        prior
> > > > > > > > > > > > > > >>>>>        to invoke the resource provider API.
> > > > > > > > > > > > > > >>>>>        Assuming
> > > > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > >>>>>        providers are based on oAuth 1.0 or
> > > > > > > > > > > > > > >>>>>        2.0.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        That said, the Authentication Broker
> > > > > > > > > > > > > > >>>>>        functionality
> > > > > > > > > > > > > > >>>>>        aims
> > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > >>>>>        cover
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        same use cases but with a lot of more
> > > > > > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > > > > > >>>>>        on
> > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > > >>>>>        setup
> > > > > > > > > > > > > > >>>>>        identity providers(not only social
> > > > > > > > > > > > > > >>>>>        ones)
> > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > >>>>>        protocols they may support such as
> > > > > > > > > > > > > > >>>>>        SAML,
> > > > > > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > >>>>>        This is useful when an enterprise is
> > > > > > > > > > > > > > >>>>>        providing
> > > > > > > > > > > > > > >>>>>        services
> > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > >>>>>        customers(IdP) and does not want to
> > > > > > > > > > > > > > >>>>>        manage
> > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > >>>>>        relationships. When using a broker,
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > >>>>>        steps
> > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > >>>>>        pretty much the same when you are
> > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > > > > > >>>>>        with
> > > > > > > > > > > > > > >>>>>        important differences on how you
> > > > > > > > > > > > > > >>>>>        support
> > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > > > > >>>>>        providers, different federation
> > > > > > > > > > > > > > >>>>>        protocols,
> > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > >>>>>        and how claims and attributes are
> > > > > > > > > > > > > > >>>>>        resolved.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        The brokering functionality can be
> > > > > > > > > > > > > > >>>>>        done
> > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > > > >>>>>        ways
> > > > > > > > > > > > > > >>>>>        depending
> > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        broker service is acting as a gateway
> > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > >>>>>        not.
> > > > > > > > > > > > > > >>>>>        When
> > > > > > > > > > > > > > >>>>>        acting
> > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > >>>>>        gateway, the broker will respond to
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        same
> > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > >>>>>        issued by the trusted identity
> > > > > > > > > > > > > > >>>>>        provider.
> > > > > > > > > > > > > > >>>>>        For
> > > > > > > > > > > > > > >>>>>        instance,
> > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > >>>>>        selects a SAML IdP to authenticate
> > > > > > > > > > > > > > >>>>>        with,
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > >>>>>        a SAML Response. In this case, the
> > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > >>>>>        prepared
> > > > > > > > > > > > > > >>>>>        to handle a specific federation
> > > > > > > > > > > > > > >>>>>        protocol.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        However, the broker service can also
> > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > >>>>>        completely
> > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > >>>>>        from the application the protocol used
> > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > >>>>>        user.
> > > > > > > > > > > > > > >>>>>        In
> > > > > > > > > > > > > > >>>>>        this case, the application will just
> > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        In both cases, the broker acts as an
> > > > > > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > > > > > >>>>>        where
> > > > > > > > > > > > > > >>>>>        specific
> > > > > > > > > > > > > > >>>>>        security policies can be applied when
> > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > >>>>>        try
> > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > >>>>>        themselves against a 3rd party IdP.
> > > > > > > > > > > > > > >>>>>        That
> > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > >>>>>        value
> > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > >>>>>        you think about auditing,
> > > > > > > > > > > > > > >>>>>        authorization
> > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > >>>>>        when federation of identities is
> > > > > > > > > > > > > > >>>>>        needed.
> > > > > > > > > > > > > > >>>>>        This
> > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > >>>>>        allows
> > > > > > > > > > > > > > >>>>>        existing
> > > > > > > > > > > > > > >>>>>        security infrastructures (eg.:
> > > > > > > > > > > > > > >>>>>        SAML-based
> > > > > > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > >>>>>        benefit
> > > > > > > > > > > > > > >>>>>        from KC's support for cloud, rest and
> > > > > > > > > > > > > > >>>>>        mobile
> > > > > > > > > > > > > > >>>>>        use
> > > > > > > > > > > > > > >>>>>        cases.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>        I think this is enough to start a
> > > > > > > > > > > > > > >>>>>        discussion.
> > > > > > > > > > > > > > >>>>>        I've
> > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > >>>>>        initial
> > > > > > > > > > > > > > >>>>>        discussion with Stian about all that
> > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > >>>>>        we
> > > > > > > > > > > > > > >>>>>        agreed
> > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > >>>>>        protocol from applications should be
> > > > > > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > >>>>>        main
> > > > > > > > > > > > > > >>>>>        reason is
> > > > > > > > > > > > > > >>>>>        that it makes life easier for
> > > > > > > > > > > > > > >>>>>        applications
> > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > >>>>>        only
> > > > > > > > > > > > > > >>>>>        need
> > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > >>>>>        know
> > > > > > > > > > > > > > >>>>>        about KC tokens and nothing else.
> > > > > > > > > > > > > > >>>>>        However
> > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > >>>>>        new
> > > > > > > > > > > > > > >>>>>        requirements around user provisioning
> > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > > > > > >>>>>        resolution
> > > > > > > > > > > > > > >>>>>        or mapping. But that would be another
> > > > > > > > > > > > > > >>>>>        thread.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> Can you elaborate on "abstract the protocol
> > > > > > > > > > > > > > >>>> from
> > > > > > > > > > > > > > >>>> applications"?
> > > > > > > > > > > > > > >>>> Not
> > > > > > > > > > > > > > >>>> sure what you mean by that.  IDP federation
> > > > > > > > > > > > > > >>>> should
> > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > >>>> configured
> > > > > > > > > > > > > > >>>> at
> > > > > > > > > > > > > > >>>> the
> > > > > > > > > > > > > > >>>> realm level and really has nothing to do with
> > > > > > > > > > > > > > >>>> applications.
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> I'm really happy that somebody is doing this.
> > > > > > > > > > > > > > >>>> We're
> > > > > > > > > > > > > > >>>> getting
> > > > > > > > > > > > > > >>>> a
> > > > > > > > > > > > > > >>>> real
> > > > > > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> Sure. What I meant was that the application
> > > > > > > > > > > > > > >>> only
> > > > > > > > > > > > > > >>> knows
> > > > > > > > > > > > > > >>> about
> > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > >>> tokens
> > > > > > > > > > > > > > >>> nothing else. It will always receive a KC token
> > > > > > > > > > > > > > >>> regardless
> > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > >>> protocol
> > > > > > > > > > > > > > >>> used
> > > > > > > > > > > > > > >>> to authenticate the user against a 3rd party
> > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > >>> (saml,
> > > > > > > > > > > > > > >>> oidc,
> > > > > > > > > > > > > > >>> whatever).
> > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > >>> example I gave was about an user trying to
> > > > > > > > > > > > > > >>> authenticate
> > > > > > > > > > > > > > >>> against
> > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > >>> SAML
> > > > > > > > > > > > > > >>> IdP.
> > > > > > > > > > > > > > >>> In this case, after a successful authentication
> > > > > > > > > > > > > > >>> on
> > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > >>> IdP,
> > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > >>> issue a token to KC. Then KC will validate the
> > > > > > > > > > > > > > >>> token,
> > > > > > > > > > > > > > >>> perform
> > > > > > > > > > > > > > >>> trust
> > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > >>> security checks, do user provisioning and
> > > > > > > > > > > > > > >>> attribute/claim
> > > > > > > > > > > > > > >>> resolution
> > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > >>> finally issue a KC token and redirect the user
> > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > >>> application.
> > > > > > > > > > > > > > >>> If
> > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > >>> app is configured to use openid in KC then it
> > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > >>> receive
> > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > >>> openid
> > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> The other scenario is pretty much the same. The
> > > > > > > > > > > > > > >>> difference
> > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > >>> that
> > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > >>> not issue its own token but just replay the
> > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > >>> issued
> > > > > > > > > > > > > > >>> by
> > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > >>> 3rd
> > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> I agree that this config goes at the realm
> > > > > > > > > > > > > > >>> level.
> > > > > > > > > > > > > > >>> For
> > > > > > > > > > > > > > >>> instance,
> > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > >>> create
> > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > >>> enable providers for being used. However, I
> > > > > > > > > > > > > > >>> think
> > > > > > > > > > > > > > >>> we
> > > > > > > > > > > > > > >>> would
> > > > > > > > > > > > > > >>> need
> > > > > > > > > > > > > > >>> some
> > > > > > > > > > > > > > >>> specific configuration for applications as
> > > > > > > > > > > > > > >>> well.
> > > > > > > > > > > > > > >>> Specially
> > > > > > > > > > > > > > >>> when
> > > > > > > > > > > > > > >>> defining
> > > > > > > > > > > > > > >>> default roles, mapping attributes. Another
> > > > > > > > > > > > > > >>> example
> > > > > > > > > > > > > > >>> of
> > > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > > >>> config
> > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to
> > > > > > > > > > > > > > >>> define
> > > > > > > > > > > > > > >>> scopes
> > > > > > > > > > > > > > >>> per-application.
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> --
> > > > > > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > > > > >>> 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
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > 
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > >
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From stian at redhat.com  Fri Dec  5 09:23:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 09:23:53 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <711831466.25373681.1417788942317.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
	<1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>
	<4760322.11384589.1417788457523.JavaMail.zimbra@redhat.com>
	<711831466.25373681.1417788942317.JavaMail.zimbra@redhat.com>
Message-ID: <48451523.11412244.1417789433189.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 3:15:42 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, December 5, 2014 12:07:37 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 5 December, 2014 2:57:46 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, December 5, 2014 11:43:32 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, 5 December, 2014 2:36:14 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, December 5, 2014 10:59:08 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > Another related thing. We've had a few people ask to be able to
> > > > > > login
> > > > > > to
> > > > > > Keycloak on mobiles using the native social login mechanism.
> > > > > > 
> > > > > > I think the best way to do that is to use the direct grant api and
> > > > > > make
> > > > > > it
> > > > > > possible to call that endpoint passing a IdP id and a token instead
> > > > > > of
> > > > > > username and password.
> > > > > > 
> > > > > > WDYT?
> > > > > 
> > > > > The broker endpoint expects the idp id in order to start the
> > > > > authentication
> > > > > process. Today, the endpoint also expects KCs authorization code in
> > > > > order
> > > > > to
> > > > > validate requests from clients and use it as a state to validate
> > > > > responses
> > > > > from the trusted idps.
> > > > > 
> > > > > This authorization code is a blocker for this use case, given that
> > > > > mobile
> > > > > don't have this code and just want to start the authentication.
> > > > > 
> > > > > A possible solution would be to change the broker to also accept a
> > > > > client_id
> > > > > to reference the mobile app and perform some validations based on
> > > > > that.
> > > > > Something like that:
> > > > > 
> > > > > 1) Mobile displays a Facebook button
> > > > > 2) User clicks the button and mobile sends a request to KC Broker
> > > > > with
> > > > > the
> > > > > idp id and his client_id.
> > > > > 3) KC Broker checks if the client_id is valid and creates a temporary
> > > > > authorization code.
> > > > > 4) KC Broker redirect mobile to the chosen IdP to perform
> > > > > authentication.
> > > > > 5) KC Broker receives a response from the IdP, generate its own token
> > > > > and
> > > > > send it back to mobile
> > > > > 
> > > > > Makes sense ?
> > > > 
> > > > No that's not the flow I had in mind. Basically the mobile app
> > > > authenticates
> > > > with Facebook through the native mechanisms. The app then has an access
> > > > token, which it would send to Keycloak on the direct grant api to
> > > > obtain
> > > > a
> > > > Keycloak token.
> > > 
> > > Ahh, now I get what you mean :)
> > > 
> > > Yes, what you said is enough. Then we just need to validate the access
> > > token
> > > (eg.: using a tokeninfo endpoint).
> > > 
> > > But I think we can also consider that use case I mentioned. You may want
> > > to
> > > login without forcing the user to redirect to KC login page.
> > 
> > We could just add a query param to the login url that lets you pick the IdP
> > to use by alias?
> > 
> >   For example auth/.../login?client_id=...&auth_method=google
> 
> Yes, just like my previously example, we need the client_id. The idp id/alias
> is already there.

Sure, was just saying it should be the same URL as the regular login page, but with one extra param to specify the IdP.

> 
> Btw, regarding SAML. SAML does not provide a "validation" endpoint like
> oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the
> specs for that. What can be done here is validate SAML assertions against a
> WS-Trust STS. Or just trust the assertion based on the signature and others
> standards info along it.
> 
> We can also take a closer look at the oAuth2 SAML bearer token profile and
> see if it helps.

If we could have it for social and OpenID Connect providers for now that'd be good.

> 
> > 
> > > 
> > > > 
> > > > Same for other identity providers, the assumption is the app has an out
> > > > of
> > > > bounds mechanism to obtain an access token, which is then sent to
> > > > Keycloak
> > > > over the direct grant api.
> > > > 
> > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Friday, 5 December, 2014 1:45:24 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > Looks good. I reckon we can combine the two pages. What about
> > > > > > > > if
> > > > > > > > the
> > > > > > > > 'Add
> > > > > > > > provider' drop-down is:
> > > > > > > > 
> > > > > > > >   OpenID
> > > > > > > >   SAML
> > > > > > > >   ------
> > > > > > > >   Google
> > > > > > > >   GitHub
> > > > > > > >   Facebook
> > > > > > > >   Twitter
> > > > > > > > 
> > > > > > > > Let's drop social on/off and instead have a enable/disable
> > > > > > > > button
> > > > > > > > on
> > > > > > > > each
> > > > > > > > provider.
> > > > > > > 
> > > > > > > Sure.
> > > > > > > 
> > > > > > > > 
> > > > > > > > Also, would be nice if users could set a name or alias for a
> > > > > > > > provider
> > > > > > > > instance. This would make the callback url easier to use
> > > > > > > > (instead
> > > > > > > > of
> > > > > > > > callback/<UUID> it's callback/<alias>). The user federation
> > > > > > > > providers
> > > > > > > > have
> > > > > > > > this.
> > > > > > > 
> > > > > > > One of my first tries was using an alias, just like that. But I
> > > > > > > preferred
> > > > > > > using the UUID and make the configuration more easier. Beside
> > > > > > > that,
> > > > > > > the
> > > > > > > callback url is just a copy and paste, so I think an alias would
> > > > > > > not
> > > > > > > bring
> > > > > > > so much usability, but add one more step when configuring
> > > > > > > providers.
> > > > > > > 
> > > > > > > However, if this is an usability requirement for KC I can change
> > > > > > > that.
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > In one of our last discussions, you suggested to leave Social
> > > > > > > > > as
> > > > > > > > > it
> > > > > > > > > is.
> > > > > > > > > Although IMO I think we can have a single place to manage
> > > > > > > > > both
> > > > > > > > > social
> > > > > > > > > and
> > > > > > > > > user-defined identity providers. Social ones are just OOTB
> > > > > > > > > and
> > > > > > > > > pre-configured identity providers now.
> > > > > > > > > 
> > > > > > > > > That said, today I'm using separated tabs for social and
> > > > > > > > > user-defined.
> > > > > > > > > Please, take a look at [1] for more details on how the UI
> > > > > > > > > looks
> > > > > > > > > like.
> > > > > > > > > 
> > > > > > > > > I've changed social UI a bit in order to provide a specific
> > > > > > > > > page
> > > > > > > > > for
> > > > > > > > > create/update. I've also added a "Show Secret" link to
> > > > > > > > > display
> > > > > > > > > the
> > > > > > > > > client_secret in clear text if user wants to.
> > > > > > > > > 
> > > > > > > > > Beside the enable/disable button, I think another good thing
> > > > > > > > > to
> > > > > > > > > do
> > > > > > > > > is
> > > > > > > > > specify
> > > > > > > > > a default role(s) for each provider. That can be useful if
> > > > > > > > > applications
> > > > > > > > > want
> > > > > > > > > to perform any kind of authorization based on the identity
> > > > > > > > > provider
> > > > > > > > > or
> > > > > > > > > authentication method used to authenticate an user (eg.:
> > > > > > > > > useful
> > > > > > > > > for
> > > > > > > > > adaptative or multi-level access control). We can also use
> > > > > > > > > the
> > > > > > > > > "amr"
> > > > > > > > > claim
> > > > > > > > > in the ID Token, which seems KC is not considering at all.
> > > > > > > > > The
> > > > > > > > > latter
> > > > > > > > > is
> > > > > > > > > an
> > > > > > > > > important thing to think of, regardless this broker work I'm
> > > > > > > > > doing.
> > > > > > > > > 
> > > > > > > > > [1]
> > > > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Having a separate enable/disable for each provider would be
> > > > > > > > > good.
> > > > > > > > > If
> > > > > > > > > you're
> > > > > > > > > leaving the social tab as is and adding a separate tab for
> > > > > > > > > configuring
> > > > > > > > > brokered idp's then we should leave the social enable/disable
> > > > > > > > > button,
> > > > > > > > > otherwise it depends how it'll look like in the end.
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > >    Social has a button to enable/disable it. I'm wondering
> > > > > > > > > >    what
> > > > > > > > > >    to
> > > > > > > > > >    do
> > > > > > > > > >    with
> > > > > > > > > >    the brokered identity providers. Shall we add a similar
> > > > > > > > > >    flag
> > > > > > > > > >    for
> > > > > > > > > >    that
> > > > > > > > > >    ?
> > > > > > > > > > 
> > > > > > > > > >    I was also wondering if the best would be a flag in a
> > > > > > > > > >    per
> > > > > > > > > >    provider
> > > > > > > > > >    basis.
> > > > > > > > > >    So we can disable/enable a specific provider (social or
> > > > > > > > > >    brokered),
> > > > > > > > > >    instead of doing that for all.
> > > > > > > > > > 
> > > > > > > > > > Regards.
> > > > > > > > > > Pedro Igor
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > I'll go for it then. Will remove the icon url from the
> > > > > > > > > > > > model
> > > > > > > > > > > > and
> > > > > > > > > > > > leave
> > > > > > > > > > > > that
> > > > > > > > > > > > for users if they want to provide icons for their
> > > > > > > > > > > > identity
> > > > > > > > > > > > providers.
> > > > > > > > > > > > 
> > > > > > > > > > > > My point is that icons can be usually served by the
> > > > > > > > > > > > same
> > > > > > > > > > > > server/application
> > > > > > > > > > > > or proxy, so download images are not such a big deal.
> > > > > > > > > > > > Also,
> > > > > > > > > > > > the
> > > > > > > > > > > > icon
> > > > > > > > > > > > url
> > > > > > > > > > > > is
> > > > > > > > > > > > part of the freemarker model and people can do what
> > > > > > > > > > > > ever
> > > > > > > > > > > > they
> > > > > > > > > > > > want
> > > > > > > > > > > > with
> > > > > > > > > > > > it.
> > > > > > > > > > > > What I think will also help in your future plans.
> > > > > > > > > > > 
> > > > > > > > > > > I'm not following. Are you saying that if a named image
> > > > > > > > > > > 'my-provider.png'
> > > > > > > > > > > is
> > > > > > > > > > > loaded from a theme, then you can override it in another
> > > > > > > > > > > theme?
> > > > > > > > > > > 
> > > > > > > > > > > If so, that's basically the same as having a css class
> > > > > > > > > > > 'my-provider'
> > > > > > > > > > > in
> > > > > > > > > > > a
> > > > > > > > > > > theme. With the exception that with an image you end up
> > > > > > > > > > > with
> > > > > > > > > > > having
> > > > > > > > > > > to
> > > > > > > > > > > require a image per provider per theme per language,
> > > > > > > > > > > which
> > > > > > > > > > > could
> > > > > > > > > > > be
> > > > > > > > > > > a
> > > > > > > > > > > lot
> > > > > > > > > > > of
> > > > > > > > > > > images for a single provider. Also, buttons for
> > > > > > > > > > > accessibility
> > > > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > defined with text and css, not images that can't be
> > > > > > > > > > > interpreted.
> > > > > > > > > > > You
> > > > > > > > > > > also
> > > > > > > > > > > still need to modify the theme, so I don't see any
> > > > > > > > > > > benefits.
> > > > > > > > > > 
> > > > > > > > > > You are right. Having a icon url per provider does not
> > > > > > > > > > makes
> > > > > > > > > > sense
> > > > > > > > > > if
> > > > > > > > > > there
> > > > > > > > > > are requirements to change images accordingly to a theme or
> > > > > > > > > > language.
> > > > > > > > > > CSS
> > > > > > > > > > makes life easier.
> > > > > > > > > > 
> > > > > > > > > > Will remove that property from the model.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Users can now specify a Icon Url to be rendered on
> > > > > > > > > > > > > the
> > > > > > > > > > > > > login
> > > > > > > > > > > > > page
> > > > > > > > > > > > > when
> > > > > > > > > > > > > social
> > > > > > > > > > > > > or any other identity provider is configured. So we
> > > > > > > > > > > > > just
> > > > > > > > > > > > > load
> > > > > > > > > > > > > the
> > > > > > > > > > > > > image
> > > > > > > > > > > > > the
> > > > > > > > > > > > > url entered by the user.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Are you saying that users should change the theme or
> > > > > > > > > > > > > customize
> > > > > > > > > > > > > css
> > > > > > > > > > > > > if
> > > > > > > > > > > > > they
> > > > > > > > > > > > > only want to change an icon for a provider ?
> > > > > > > > > > > > 
> > > > > > > > > > > > Yes, there's many issues with having a icon url:
> > > > > > > > > > > > 
> > > > > > > > > > > > * Won't work for internationalization - we don't have
> > > > > > > > > > > > this
> > > > > > > > > > > > now,
> > > > > > > > > > > > but
> > > > > > > > > > > > we
> > > > > > > > > > > > will
> > > > > > > > > > > > * Image is not a good button - CSS is much better
> > > > > > > > > > > > * Doesn't support themes - we allow users to switch l&f
> > > > > > > > > > > > by
> > > > > > > > > > > > switching
> > > > > > > > > > > > themes,
> > > > > > > > > > > > but that won't work for a icon url. In the future we
> > > > > > > > > > > > may
> > > > > > > > > > > > also
> > > > > > > > > > > > support
> > > > > > > > > > > > multiple themes per-realm, for example to depending on
> > > > > > > > > > > > the
> > > > > > > > > > > > devices
> > > > > > > > > > > > (one
> > > > > > > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > > > > > > * Requires the URL to be hosted somewhere - why require
> > > > > > > > > > > > a
> > > > > > > > > > > > separate
> > > > > > > > > > > > call
> > > > > > > > > > > > to
> > > > > > > > > > > > download an image (to a separate server maybe) if it
> > > > > > > > > > > > can
> > > > > > > > > > > > simply
> > > > > > > > > > > > be
> > > > > > > > > > > > defined
> > > > > > > > > > > > in a single CSS file?
> > > > > > > > > > > > 
> > > > > > > > > > > > Rather than add additional places to define look and
> > > > > > > > > > > > feel
> > > > > > > > > > > > components
> > > > > > > > > > > > we
> > > > > > > > > > > > should in the future make it easier to add/customize
> > > > > > > > > > > > themes.
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > All look and feel related things including images and
> > > > > > > > > > > > > stylesheets
> > > > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > part of themes. This is to allow customizing them in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > theme.
> > > > > > > > > > > > > Also,
> > > > > > > > > > > > > an
> > > > > > > > > > > > > image is not the correct way to render a button, it
> > > > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > defined
> > > > > > > > > > > > > in
> > > > > > > > > > > > > CSS.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > You shouldn't have icon images for social
> > > > > > > > > > > > > > providers.
> > > > > > > > > > > > > > They
> > > > > > > > > > > > > > should
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > specified
> > > > > > > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >     Anyone know where I can get the icons images
> > > > > > > > > > > > > > >     for
> > > > > > > > > > > > > > >     social
> > > > > > > > > > > > > > >     providers
> > > > > > > > > > > > > > >     ?
> > > > > > > > > > > > > > >     It
> > > > > > > > > > > > > > >     seems zocial defines them encoded in some way
> > > > > > > > > > > > > > >     in
> > > > > > > > > > > > > > >     CSS.
> > > > > > > > > > > > > > >     I
> > > > > > > > > > > > > > >     need
> > > > > > > > > > > > > > >     that
> > > > > > > > > > > > > > >     to
> > > > > > > > > > > > > > >     provide default images if user does not
> > > > > > > > > > > > > > >     specify
> > > > > > > > > > > > > > >     their
> > > > > > > > > > > > > > >     own.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >    I've done some initial work covering both
> > > > > > > > > > > > > > >    persistence
> > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > >    brokering.
> > > > > > > > > > > > > > >    No
> > > > > > > > > > > > > > >    UI, yet. I'm focused on the model, rest api
> > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > >    brokering
> > > > > > > > > > > > > > >    functionality
> > > > > > > > > > > > > > >    for now.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >    What I have is enough to decide if we are
> > > > > > > > > > > > > > >    aligned
> > > > > > > > > > > > > > >    about
> > > > > > > > > > > > > > >    this
> > > > > > > > > > > > > > >    functionality. So you can understand how the
> > > > > > > > > > > > > > >    model
> > > > > > > > > > > > > > >    (and
> > > > > > > > > > > > > > >    persistence),
> > > > > > > > > > > > > > >    rest api and brokering functionality looks
> > > > > > > > > > > > > > >    like.
> > > > > > > > > > > > > > >    Can
> > > > > > > > > > > > > > >    we
> > > > > > > > > > > > > > >    schedule
> > > > > > > > > > > > > > >    a
> > > > > > > > > > > > > > >    meeting ?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Currently adapters can only make authz decisions
> > > > > > > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > on either realm roles or the roles of one
> > > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > > application.
> > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > related to 1) too.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > 1) Sounds like something definitely worth
> > > > > > > > > > > > > > > > aiming
> > > > > > > > > > > > > > > > for.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote:
> > > > > > > > > > > > > > > >> I just wanted to quickly list the additional
> > > > > > > > > > > > > > > >> work
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> discussed
> > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > >> everyone
> > > > > > > > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with
> > > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > >> a KC token? For example an external token with
> > > > > > > > > > > > > > > >> attribute
> > > > > > > > > > > > > > > >> 'group'
> > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > >> contains 'sales' and 'manager' could be mapped
> > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > >> 'manager'
> > > > > > > > > > > > > > > >> role
> > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > >> 'sales app in a KC token. Could we use Drools?
> > > > > > > > > > > > > > > >> This
> > > > > > > > > > > > > > > >> could
> > > > > > > > > > > > > > > >> also
> > > > > > > > > > > > > > > >> be
> > > > > > > > > > > > > > > >> used
> > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > >> user federation to allow more complex mapping
> > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > >> roles/groups
> > > > > > > > > > > > > > > >> than
> > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > >> simple 1-1
> > > > > > > > > > > > > > > >> 2) Retrieving tokens - if an application wants
> > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > >> retrieve
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > >> token (for example to view Facebook friends if
> > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > >> logged
> > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > >> Facebook)
> > > > > > > > > > > > > > > >> 3) Configure scope - currently for social we
> > > > > > > > > > > > > > > >> only
> > > > > > > > > > > > > > > >> request
> > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > >> very
> > > > > > > > > > > > > > > >> limited
> > > > > > > > > > > > > > > >> scope (basic profile and email), to for
> > > > > > > > > > > > > > > >> example
> > > > > > > > > > > > > > > >> view
> > > > > > > > > > > > > > > >> Facebook
> > > > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > > > > > > >> 4) Selecting provider - currently in social
> > > > > > > > > > > > > > > >> (and
> > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > >> first
> > > > > > > > > > > > > > > >> pass
> > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > >> brokering) we have an icon user has to select,
> > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > >> can
> > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> provider in a different way (for example ask
> > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > >> email,
> > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > >> based on email domain)
> > > > > > > > > > > > > > > >> 5) Gateway - don't create a KC token, but just
> > > > > > > > > > > > > > > >> forward
> > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> IMO 1) is a killer feature, as it would allow
> > > > > > > > > > > > > > > >> companies
> > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > >> add
> > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > >> users without having to modify their
> > > > > > > > > > > > > > > >> applications.
> > > > > > > > > > > > > > > >> Issue
> > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > >> 5)
> > > > > > > > > > > > > > > >> is
> > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > >> applications need to understand more than one
> > > > > > > > > > > > > > > >> token,
> > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > >> would
> > > > > > > > > > > > > > > >> require
> > > > > > > > > > > > > > > >> rewriting applications.
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> This work is also somewhat related to other
> > > > > > > > > > > > > > > >> authentication
> > > > > > > > > > > > > > > >> mechanisms
> > > > > > > > > > > > > > > >> (for
> > > > > > > > > > > > > > > >> example Kerberos ticket, LDAP and
> > > > > > > > > > > > > > > >> passwordless).
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > > > > > > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM
> > > > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > >>> Identity
> > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > >>> Authentication
> > > > > > > > > > > > > > > >>> Broker
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52
> > > > > > > > > > > > > > > >>>> PM
> > > > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > >>>> Identity
> > > > > > > > > > > > > > > >>>> and
> > > > > > > > > > > > > > > >>>> Authentication
> > > > > > > > > > > > > > > >>>> Broker
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva
> > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > >>>>> Hi,
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        Would like to start a discussion
> > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > >>>>>        enable
> > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > >>>>>        Authentication Broker in order to
> > > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > > >>>>>        Chained
> > > > > > > > > > > > > > > >>>>>        Federation
> > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > >>>>>        also Identity Federation. First of
> > > > > > > > > > > > > > > >>>>>        all,
> > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > >>>>>        background
> > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > >>>>>        what
> > > > > > > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        Currently KeyCloak provides two
> > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > >>>>>        types
> > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > >>>>>        (correct
> > > > > > > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>            1) Local authentication (based
> > > > > > > > > > > > > > > >>>>>            on
> > > > > > > > > > > > > > > >>>>>            some
> > > > > > > > > > > > > > > >>>>>            credential
> > > > > > > > > > > > > > > >>>>>            type
> > > > > > > > > > > > > > > >>>>>            enabled
> > > > > > > > > > > > > > > >>>>>            to
> > > > > > > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        Local authentication is about
> > > > > > > > > > > > > > > >>>>>        authenticating
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > >>>>>        locally
> > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > >>>>>        KC's own identity store. Nothing
> > > > > > > > > > > > > > > >>>>>        special
> > > > > > > > > > > > > > > >>>>>        here.
> > > > > > > > > > > > > > > >>>>>        And
> > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > >>>>>        Authentication which allows users to
> > > > > > > > > > > > > > > >>>>>        choose
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > > > > >>>>>        to authenticate with. In this case,
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > >>>>>        always
> > > > > > > > > > > > > > > >>>>>        one
> > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        built-in social providers supported
> > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > > > > > > >>>>>        Google,
> > > > > > > > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        When doing social, the user is
> > > > > > > > > > > > > > > >>>>>        automatically
> > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > >>>>>        does
> > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > >>>>>        need to fill a registration form and
> > > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > >>>>>        very
> > > > > > > > > > > > > > > >>>>>        quickly. During the provisioning
> > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > > > > > > >>>>>        from the social provider such as
> > > > > > > > > > > > > > > >>>>>        email,
> > > > > > > > > > > > > > > >>>>>        firstname
> > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > >>>>>        These
> > > > > > > > > > > > > > > >>>>>        are very basic information, any
> > > > > > > > > > > > > > > >>>>>        other
> > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > >>>>>        related with authorization policies
> > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > >>>>>        eg.:
> > > > > > > > > > > > > > > >>>>>        roles
> > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > >>>>>        groups
> > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > >>>>>        defined later via KC's admin
> > > > > > > > > > > > > > > >>>>>        console.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        Another important characteristic of
> > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        application receives a KC token and
> > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > >>>>>        issued by
> > > > > > > > > > > > > > > >>>>>        the social IdP during the
> > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > >>>>>        process.
> > > > > > > > > > > > > > > >>>>>        If
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > >>>>>        wants to consume resources from the
> > > > > > > > > > > > > > > >>>>>        resource
> > > > > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > > > > >>>>>        he
> > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > >>>>>        authenticated it must obtain the
> > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > >>>>>        itself
> > > > > > > > > > > > > > > >>>>>        prior
> > > > > > > > > > > > > > > >>>>>        to invoke the resource provider API.
> > > > > > > > > > > > > > > >>>>>        Assuming
> > > > > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > >>>>>        providers are based on oAuth 1.0 or
> > > > > > > > > > > > > > > >>>>>        2.0.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        That said, the Authentication Broker
> > > > > > > > > > > > > > > >>>>>        functionality
> > > > > > > > > > > > > > > >>>>>        aims
> > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > >>>>>        cover
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        same use cases but with a lot of
> > > > > > > > > > > > > > > >>>>>        more
> > > > > > > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > > > > > > >>>>>        on
> > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > > > >>>>>        setup
> > > > > > > > > > > > > > > >>>>>        identity providers(not only social
> > > > > > > > > > > > > > > >>>>>        ones)
> > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > > >>>>>        protocols they may support such as
> > > > > > > > > > > > > > > >>>>>        SAML,
> > > > > > > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > >>>>>        This is useful when an enterprise is
> > > > > > > > > > > > > > > >>>>>        providing
> > > > > > > > > > > > > > > >>>>>        services
> > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > >>>>>        customers(IdP) and does not want to
> > > > > > > > > > > > > > > >>>>>        manage
> > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > >>>>>        relationships. When using a broker,
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > >>>>>        steps
> > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > >>>>>        pretty much the same when you are
> > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > > > > > > >>>>>        with
> > > > > > > > > > > > > > > >>>>>        important differences on how you
> > > > > > > > > > > > > > > >>>>>        support
> > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > > > > > >>>>>        providers, different federation
> > > > > > > > > > > > > > > >>>>>        protocols,
> > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > >>>>>        and how claims and attributes are
> > > > > > > > > > > > > > > >>>>>        resolved.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        The brokering functionality can be
> > > > > > > > > > > > > > > >>>>>        done
> > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > > > > >>>>>        ways
> > > > > > > > > > > > > > > >>>>>        depending
> > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        broker service is acting as a
> > > > > > > > > > > > > > > >>>>>        gateway
> > > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > > >>>>>        not.
> > > > > > > > > > > > > > > >>>>>        When
> > > > > > > > > > > > > > > >>>>>        acting
> > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > >>>>>        gateway, the broker will respond to
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        same
> > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > >>>>>        issued by the trusted identity
> > > > > > > > > > > > > > > >>>>>        provider.
> > > > > > > > > > > > > > > >>>>>        For
> > > > > > > > > > > > > > > >>>>>        instance,
> > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > >>>>>        selects a SAML IdP to authenticate
> > > > > > > > > > > > > > > >>>>>        with,
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > >>>>>        a SAML Response. In this case, the
> > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > >>>>>        prepared
> > > > > > > > > > > > > > > >>>>>        to handle a specific federation
> > > > > > > > > > > > > > > >>>>>        protocol.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        However, the broker service can also
> > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > >>>>>        completely
> > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > >>>>>        from the application the protocol
> > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > >>>>>        user.
> > > > > > > > > > > > > > > >>>>>        In
> > > > > > > > > > > > > > > >>>>>        this case, the application will just
> > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        In both cases, the broker acts as an
> > > > > > > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > > > > > > >>>>>        where
> > > > > > > > > > > > > > > >>>>>        specific
> > > > > > > > > > > > > > > >>>>>        security policies can be applied
> > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > >>>>>        try
> > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > >>>>>        themselves against a 3rd party IdP.
> > > > > > > > > > > > > > > >>>>>        That
> > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > >>>>>        value
> > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > >>>>>        you think about auditing,
> > > > > > > > > > > > > > > >>>>>        authorization
> > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > >>>>>        when federation of identities is
> > > > > > > > > > > > > > > >>>>>        needed.
> > > > > > > > > > > > > > > >>>>>        This
> > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > >>>>>        allows
> > > > > > > > > > > > > > > >>>>>        existing
> > > > > > > > > > > > > > > >>>>>        security infrastructures (eg.:
> > > > > > > > > > > > > > > >>>>>        SAML-based
> > > > > > > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > >>>>>        benefit
> > > > > > > > > > > > > > > >>>>>        from KC's support for cloud, rest
> > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > >>>>>        mobile
> > > > > > > > > > > > > > > >>>>>        use
> > > > > > > > > > > > > > > >>>>>        cases.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>        I think this is enough to start a
> > > > > > > > > > > > > > > >>>>>        discussion.
> > > > > > > > > > > > > > > >>>>>        I've
> > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > >>>>>        initial
> > > > > > > > > > > > > > > >>>>>        discussion with Stian about all that
> > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > >>>>>        we
> > > > > > > > > > > > > > > >>>>>        agreed
> > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > >>>>>        protocol from applications should be
> > > > > > > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > >>>>>        main
> > > > > > > > > > > > > > > >>>>>        reason is
> > > > > > > > > > > > > > > >>>>>        that it makes life easier for
> > > > > > > > > > > > > > > >>>>>        applications
> > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > >>>>>        only
> > > > > > > > > > > > > > > >>>>>        need
> > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > >>>>>        know
> > > > > > > > > > > > > > > >>>>>        about KC tokens and nothing else.
> > > > > > > > > > > > > > > >>>>>        However
> > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > >>>>>        new
> > > > > > > > > > > > > > > >>>>>        requirements around user
> > > > > > > > > > > > > > > >>>>>        provisioning
> > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > > > > > > >>>>>        resolution
> > > > > > > > > > > > > > > >>>>>        or mapping. But that would be
> > > > > > > > > > > > > > > >>>>>        another
> > > > > > > > > > > > > > > >>>>>        thread.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>> Can you elaborate on "abstract the protocol
> > > > > > > > > > > > > > > >>>> from
> > > > > > > > > > > > > > > >>>> applications"?
> > > > > > > > > > > > > > > >>>> Not
> > > > > > > > > > > > > > > >>>> sure what you mean by that.  IDP federation
> > > > > > > > > > > > > > > >>>> should
> > > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > > >>>> configured
> > > > > > > > > > > > > > > >>>> at
> > > > > > > > > > > > > > > >>>> the
> > > > > > > > > > > > > > > >>>> realm level and really has nothing to do
> > > > > > > > > > > > > > > >>>> with
> > > > > > > > > > > > > > > >>>> applications.
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>> I'm really happy that somebody is doing
> > > > > > > > > > > > > > > >>>> this.
> > > > > > > > > > > > > > > >>>> We're
> > > > > > > > > > > > > > > >>>> getting
> > > > > > > > > > > > > > > >>>> a
> > > > > > > > > > > > > > > >>>> real
> > > > > > > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> Sure. What I meant was that the application
> > > > > > > > > > > > > > > >>> only
> > > > > > > > > > > > > > > >>> knows
> > > > > > > > > > > > > > > >>> about
> > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > >>> tokens
> > > > > > > > > > > > > > > >>> nothing else. It will always receive a KC
> > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > >>> regardless
> > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > >>> protocol
> > > > > > > > > > > > > > > >>> used
> > > > > > > > > > > > > > > >>> to authenticate the user against a 3rd party
> > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > >>> (saml,
> > > > > > > > > > > > > > > >>> oidc,
> > > > > > > > > > > > > > > >>> whatever).
> > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > >>> example I gave was about an user trying to
> > > > > > > > > > > > > > > >>> authenticate
> > > > > > > > > > > > > > > >>> against
> > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > >>> SAML
> > > > > > > > > > > > > > > >>> IdP.
> > > > > > > > > > > > > > > >>> In this case, after a successful
> > > > > > > > > > > > > > > >>> authentication
> > > > > > > > > > > > > > > >>> on
> > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > >>> IdP,
> > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > >>> issue a token to KC. Then KC will validate
> > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > >>> token,
> > > > > > > > > > > > > > > >>> perform
> > > > > > > > > > > > > > > >>> trust
> > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > >>> security checks, do user provisioning and
> > > > > > > > > > > > > > > >>> attribute/claim
> > > > > > > > > > > > > > > >>> resolution
> > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > >>> finally issue a KC token and redirect the
> > > > > > > > > > > > > > > >>> user
> > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > >>> application.
> > > > > > > > > > > > > > > >>> If
> > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > >>> app is configured to use openid in KC then it
> > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > >>> receive
> > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > >>> openid
> > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> The other scenario is pretty much the same.
> > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > >>> difference
> > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > >>> that
> > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > >>> not issue its own token but just replay the
> > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > >>> issued
> > > > > > > > > > > > > > > >>> by
> > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > >>> 3rd
> > > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> I agree that this config goes at the realm
> > > > > > > > > > > > > > > >>> level.
> > > > > > > > > > > > > > > >>> For
> > > > > > > > > > > > > > > >>> instance,
> > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > >>> create
> > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > >>> enable providers for being used. However, I
> > > > > > > > > > > > > > > >>> think
> > > > > > > > > > > > > > > >>> we
> > > > > > > > > > > > > > > >>> would
> > > > > > > > > > > > > > > >>> need
> > > > > > > > > > > > > > > >>> some
> > > > > > > > > > > > > > > >>> specific configuration for applications as
> > > > > > > > > > > > > > > >>> well.
> > > > > > > > > > > > > > > >>> Specially
> > > > > > > > > > > > > > > >>> when
> > > > > > > > > > > > > > > >>> defining
> > > > > > > > > > > > > > > >>> default roles, mapping attributes. Another
> > > > > > > > > > > > > > > >>> example
> > > > > > > > > > > > > > > >>> of
> > > > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > > > >>> config
> > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to
> > > > > > > > > > > > > > > >>> define
> > > > > > > > > > > > > > > >>> scopes
> > > > > > > > > > > > > > > >>> per-application.
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>> --
> > > > > > > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > > > > > >>> 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
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > _______________________________________________
> > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > >
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From psilva at redhat.com  Fri Dec  5 09:29:08 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 Dec 2014 09:29:08 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <48451523.11412244.1417789433189.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
	<1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>
	<4760322.11384589.1417788457523.JavaMail.zimbra@redhat.com>
	<711831466.25373681.1417788942317.JavaMail.zimbra@redhat.com>
	<48451523.11412244.1417789433189.JavaMail.zimbra@redhat.com>
Message-ID: <1535438172.25382344.1417789748360.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, December 5, 2014 12:23:53 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 5 December, 2014 3:15:42 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, December 5, 2014 12:07:37 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 5 December, 2014 2:57:46 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, December 5, 2014 11:43:32 AM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, 5 December, 2014 2:36:14 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Friday, December 5, 2014 10:59:08 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > Another related thing. We've had a few people ask to be able to
> > > > > > > login
> > > > > > > to
> > > > > > > Keycloak on mobiles using the native social login mechanism.
> > > > > > > 
> > > > > > > I think the best way to do that is to use the direct grant api
> > > > > > > and
> > > > > > > make
> > > > > > > it
> > > > > > > possible to call that endpoint passing a IdP id and a token
> > > > > > > instead
> > > > > > > of
> > > > > > > username and password.
> > > > > > > 
> > > > > > > WDYT?
> > > > > > 
> > > > > > The broker endpoint expects the idp id in order to start the
> > > > > > authentication
> > > > > > process. Today, the endpoint also expects KCs authorization code in
> > > > > > order
> > > > > > to
> > > > > > validate requests from clients and use it as a state to validate
> > > > > > responses
> > > > > > from the trusted idps.
> > > > > > 
> > > > > > This authorization code is a blocker for this use case, given that
> > > > > > mobile
> > > > > > don't have this code and just want to start the authentication.
> > > > > > 
> > > > > > A possible solution would be to change the broker to also accept a
> > > > > > client_id
> > > > > > to reference the mobile app and perform some validations based on
> > > > > > that.
> > > > > > Something like that:
> > > > > > 
> > > > > > 1) Mobile displays a Facebook button
> > > > > > 2) User clicks the button and mobile sends a request to KC Broker
> > > > > > with
> > > > > > the
> > > > > > idp id and his client_id.
> > > > > > 3) KC Broker checks if the client_id is valid and creates a
> > > > > > temporary
> > > > > > authorization code.
> > > > > > 4) KC Broker redirect mobile to the chosen IdP to perform
> > > > > > authentication.
> > > > > > 5) KC Broker receives a response from the IdP, generate its own
> > > > > > token
> > > > > > and
> > > > > > send it back to mobile
> > > > > > 
> > > > > > Makes sense ?
> > > > > 
> > > > > No that's not the flow I had in mind. Basically the mobile app
> > > > > authenticates
> > > > > with Facebook through the native mechanisms. The app then has an
> > > > > access
> > > > > token, which it would send to Keycloak on the direct grant api to
> > > > > obtain
> > > > > a
> > > > > Keycloak token.
> > > > 
> > > > Ahh, now I get what you mean :)
> > > > 
> > > > Yes, what you said is enough. Then we just need to validate the access
> > > > token
> > > > (eg.: using a tokeninfo endpoint).
> > > > 
> > > > But I think we can also consider that use case I mentioned. You may
> > > > want
> > > > to
> > > > login without forcing the user to redirect to KC login page.
> > > 
> > > We could just add a query param to the login url that lets you pick the
> > > IdP
> > > to use by alias?
> > > 
> > >   For example auth/.../login?client_id=...&auth_method=google
> > 
> > Yes, just like my previously example, we need the client_id. The idp
> > id/alias
> > is already there.
> 
> Sure, was just saying it should be the same URL as the regular login page,
> but with one extra param to specify the IdP.
> 
> > 
> > Btw, regarding SAML. SAML does not provide a "validation" endpoint like
> > oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the
> > specs for that. What can be done here is validate SAML assertions against a
> > WS-Trust STS. Or just trust the assertion based on the signature and others
> > standards info along it.
> > 
> > We can also take a closer look at the oAuth2 SAML bearer token profile and
> > see if it helps.
> 
> If we could have it for social and OpenID Connect providers for now that'd be
> good.

Deal. I'll do that.

What about that use case I mentioned ? The one about mobile asking to broker (not previously issued access_token) an identity provider ?

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > Same for other identity providers, the assumption is the app has an
> > > > > out
> > > > > of
> > > > > bounds mechanism to obtain an access token, which is then sent to
> > > > > Keycloak
> > > > > over the direct grant api.
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Friday, 5 December, 2014 1:45:24 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Looks good. I reckon we can combine the two pages. What about
> > > > > > > > > if
> > > > > > > > > the
> > > > > > > > > 'Add
> > > > > > > > > provider' drop-down is:
> > > > > > > > > 
> > > > > > > > >   OpenID
> > > > > > > > >   SAML
> > > > > > > > >   ------
> > > > > > > > >   Google
> > > > > > > > >   GitHub
> > > > > > > > >   Facebook
> > > > > > > > >   Twitter
> > > > > > > > > 
> > > > > > > > > Let's drop social on/off and instead have a enable/disable
> > > > > > > > > button
> > > > > > > > > on
> > > > > > > > > each
> > > > > > > > > provider.
> > > > > > > > 
> > > > > > > > Sure.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Also, would be nice if users could set a name or alias for a
> > > > > > > > > provider
> > > > > > > > > instance. This would make the callback url easier to use
> > > > > > > > > (instead
> > > > > > > > > of
> > > > > > > > > callback/<UUID> it's callback/<alias>). The user federation
> > > > > > > > > providers
> > > > > > > > > have
> > > > > > > > > this.
> > > > > > > > 
> > > > > > > > One of my first tries was using an alias, just like that. But I
> > > > > > > > preferred
> > > > > > > > using the UUID and make the configuration more easier. Beside
> > > > > > > > that,
> > > > > > > > the
> > > > > > > > callback url is just a copy and paste, so I think an alias
> > > > > > > > would
> > > > > > > > not
> > > > > > > > bring
> > > > > > > > so much usability, but add one more step when configuring
> > > > > > > > providers.
> > > > > > > > 
> > > > > > > > However, if this is an usability requirement for KC I can
> > > > > > > > change
> > > > > > > > that.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > In one of our last discussions, you suggested to leave
> > > > > > > > > > Social
> > > > > > > > > > as
> > > > > > > > > > it
> > > > > > > > > > is.
> > > > > > > > > > Although IMO I think we can have a single place to manage
> > > > > > > > > > both
> > > > > > > > > > social
> > > > > > > > > > and
> > > > > > > > > > user-defined identity providers. Social ones are just OOTB
> > > > > > > > > > and
> > > > > > > > > > pre-configured identity providers now.
> > > > > > > > > > 
> > > > > > > > > > That said, today I'm using separated tabs for social and
> > > > > > > > > > user-defined.
> > > > > > > > > > Please, take a look at [1] for more details on how the UI
> > > > > > > > > > looks
> > > > > > > > > > like.
> > > > > > > > > > 
> > > > > > > > > > I've changed social UI a bit in order to provide a specific
> > > > > > > > > > page
> > > > > > > > > > for
> > > > > > > > > > create/update. I've also added a "Show Secret" link to
> > > > > > > > > > display
> > > > > > > > > > the
> > > > > > > > > > client_secret in clear text if user wants to.
> > > > > > > > > > 
> > > > > > > > > > Beside the enable/disable button, I think another good
> > > > > > > > > > thing
> > > > > > > > > > to
> > > > > > > > > > do
> > > > > > > > > > is
> > > > > > > > > > specify
> > > > > > > > > > a default role(s) for each provider. That can be useful if
> > > > > > > > > > applications
> > > > > > > > > > want
> > > > > > > > > > to perform any kind of authorization based on the identity
> > > > > > > > > > provider
> > > > > > > > > > or
> > > > > > > > > > authentication method used to authenticate an user (eg.:
> > > > > > > > > > useful
> > > > > > > > > > for
> > > > > > > > > > adaptative or multi-level access control). We can also use
> > > > > > > > > > the
> > > > > > > > > > "amr"
> > > > > > > > > > claim
> > > > > > > > > > in the ID Token, which seems KC is not considering at all.
> > > > > > > > > > The
> > > > > > > > > > latter
> > > > > > > > > > is
> > > > > > > > > > an
> > > > > > > > > > important thing to think of, regardless this broker work
> > > > > > > > > > I'm
> > > > > > > > > > doing.
> > > > > > > > > > 
> > > > > > > > > > [1]
> > > > > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > Having a separate enable/disable for each provider would be
> > > > > > > > > > good.
> > > > > > > > > > If
> > > > > > > > > > you're
> > > > > > > > > > leaving the social tab as is and adding a separate tab for
> > > > > > > > > > configuring
> > > > > > > > > > brokered idp's then we should leave the social
> > > > > > > > > > enable/disable
> > > > > > > > > > button,
> > > > > > > > > > otherwise it depends how it'll look like in the end.
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > Hi,
> > > > > > > > > > > 
> > > > > > > > > > >    Social has a button to enable/disable it. I'm
> > > > > > > > > > >    wondering
> > > > > > > > > > >    what
> > > > > > > > > > >    to
> > > > > > > > > > >    do
> > > > > > > > > > >    with
> > > > > > > > > > >    the brokered identity providers. Shall we add a
> > > > > > > > > > >    similar
> > > > > > > > > > >    flag
> > > > > > > > > > >    for
> > > > > > > > > > >    that
> > > > > > > > > > >    ?
> > > > > > > > > > > 
> > > > > > > > > > >    I was also wondering if the best would be a flag in a
> > > > > > > > > > >    per
> > > > > > > > > > >    provider
> > > > > > > > > > >    basis.
> > > > > > > > > > >    So we can disable/enable a specific provider (social
> > > > > > > > > > >    or
> > > > > > > > > > >    brokered),
> > > > > > > > > > >    instead of doing that for all.
> > > > > > > > > > > 
> > > > > > > > > > > Regards.
> > > > > > > > > > > Pedro Igor
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I'll go for it then. Will remove the icon url from
> > > > > > > > > > > > > the
> > > > > > > > > > > > > model
> > > > > > > > > > > > > and
> > > > > > > > > > > > > leave
> > > > > > > > > > > > > that
> > > > > > > > > > > > > for users if they want to provide icons for their
> > > > > > > > > > > > > identity
> > > > > > > > > > > > > providers.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > My point is that icons can be usually served by the
> > > > > > > > > > > > > same
> > > > > > > > > > > > > server/application
> > > > > > > > > > > > > or proxy, so download images are not such a big deal.
> > > > > > > > > > > > > Also,
> > > > > > > > > > > > > the
> > > > > > > > > > > > > icon
> > > > > > > > > > > > > url
> > > > > > > > > > > > > is
> > > > > > > > > > > > > part of the freemarker model and people can do what
> > > > > > > > > > > > > ever
> > > > > > > > > > > > > they
> > > > > > > > > > > > > want
> > > > > > > > > > > > > with
> > > > > > > > > > > > > it.
> > > > > > > > > > > > > What I think will also help in your future plans.
> > > > > > > > > > > > 
> > > > > > > > > > > > I'm not following. Are you saying that if a named image
> > > > > > > > > > > > 'my-provider.png'
> > > > > > > > > > > > is
> > > > > > > > > > > > loaded from a theme, then you can override it in
> > > > > > > > > > > > another
> > > > > > > > > > > > theme?
> > > > > > > > > > > > 
> > > > > > > > > > > > If so, that's basically the same as having a css class
> > > > > > > > > > > > 'my-provider'
> > > > > > > > > > > > in
> > > > > > > > > > > > a
> > > > > > > > > > > > theme. With the exception that with an image you end up
> > > > > > > > > > > > with
> > > > > > > > > > > > having
> > > > > > > > > > > > to
> > > > > > > > > > > > require a image per provider per theme per language,
> > > > > > > > > > > > which
> > > > > > > > > > > > could
> > > > > > > > > > > > be
> > > > > > > > > > > > a
> > > > > > > > > > > > lot
> > > > > > > > > > > > of
> > > > > > > > > > > > images for a single provider. Also, buttons for
> > > > > > > > > > > > accessibility
> > > > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > defined with text and css, not images that can't be
> > > > > > > > > > > > interpreted.
> > > > > > > > > > > > You
> > > > > > > > > > > > also
> > > > > > > > > > > > still need to modify the theme, so I don't see any
> > > > > > > > > > > > benefits.
> > > > > > > > > > > 
> > > > > > > > > > > You are right. Having a icon url per provider does not
> > > > > > > > > > > makes
> > > > > > > > > > > sense
> > > > > > > > > > > if
> > > > > > > > > > > there
> > > > > > > > > > > are requirements to change images accordingly to a theme
> > > > > > > > > > > or
> > > > > > > > > > > language.
> > > > > > > > > > > CSS
> > > > > > > > > > > makes life easier.
> > > > > > > > > > > 
> > > > > > > > > > > Will remove that property from the model.
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Users can now specify a Icon Url to be rendered on
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > login
> > > > > > > > > > > > > > page
> > > > > > > > > > > > > > when
> > > > > > > > > > > > > > social
> > > > > > > > > > > > > > or any other identity provider is configured. So we
> > > > > > > > > > > > > > just
> > > > > > > > > > > > > > load
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > image
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > url entered by the user.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Are you saying that users should change the theme
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > customize
> > > > > > > > > > > > > > css
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > they
> > > > > > > > > > > > > > only want to change an icon for a provider ?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Yes, there's many issues with having a icon url:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > * Won't work for internationalization - we don't have
> > > > > > > > > > > > > this
> > > > > > > > > > > > > now,
> > > > > > > > > > > > > but
> > > > > > > > > > > > > we
> > > > > > > > > > > > > will
> > > > > > > > > > > > > * Image is not a good button - CSS is much better
> > > > > > > > > > > > > * Doesn't support themes - we allow users to switch
> > > > > > > > > > > > > l&f
> > > > > > > > > > > > > by
> > > > > > > > > > > > > switching
> > > > > > > > > > > > > themes,
> > > > > > > > > > > > > but that won't work for a icon url. In the future we
> > > > > > > > > > > > > may
> > > > > > > > > > > > > also
> > > > > > > > > > > > > support
> > > > > > > > > > > > > multiple themes per-realm, for example to depending
> > > > > > > > > > > > > on
> > > > > > > > > > > > > the
> > > > > > > > > > > > > devices
> > > > > > > > > > > > > (one
> > > > > > > > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > > > > > > > * Requires the URL to be hosted somewhere - why
> > > > > > > > > > > > > require
> > > > > > > > > > > > > a
> > > > > > > > > > > > > separate
> > > > > > > > > > > > > call
> > > > > > > > > > > > > to
> > > > > > > > > > > > > download an image (to a separate server maybe) if it
> > > > > > > > > > > > > can
> > > > > > > > > > > > > simply
> > > > > > > > > > > > > be
> > > > > > > > > > > > > defined
> > > > > > > > > > > > > in a single CSS file?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Rather than add additional places to define look and
> > > > > > > > > > > > > feel
> > > > > > > > > > > > > components
> > > > > > > > > > > > > we
> > > > > > > > > > > > > should in the future make it easier to add/customize
> > > > > > > > > > > > > themes.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > All look and feel related things including images
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > stylesheets
> > > > > > > > > > > > > > should
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > part of themes. This is to allow customizing them
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > theme.
> > > > > > > > > > > > > > Also,
> > > > > > > > > > > > > > an
> > > > > > > > > > > > > > image is not the correct way to render a button, it
> > > > > > > > > > > > > > should
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > defined
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > CSS.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > You shouldn't have icon images for social
> > > > > > > > > > > > > > > providers.
> > > > > > > > > > > > > > > They
> > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > specified
> > > > > > > > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >     Anyone know where I can get the icons
> > > > > > > > > > > > > > > >     images
> > > > > > > > > > > > > > > >     for
> > > > > > > > > > > > > > > >     social
> > > > > > > > > > > > > > > >     providers
> > > > > > > > > > > > > > > >     ?
> > > > > > > > > > > > > > > >     It
> > > > > > > > > > > > > > > >     seems zocial defines them encoded in some
> > > > > > > > > > > > > > > >     way
> > > > > > > > > > > > > > > >     in
> > > > > > > > > > > > > > > >     CSS.
> > > > > > > > > > > > > > > >     I
> > > > > > > > > > > > > > > >     need
> > > > > > > > > > > > > > > >     that
> > > > > > > > > > > > > > > >     to
> > > > > > > > > > > > > > > >     provide default images if user does not
> > > > > > > > > > > > > > > >     specify
> > > > > > > > > > > > > > > >     their
> > > > > > > > > > > > > > > >     own.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >    I've done some initial work covering both
> > > > > > > > > > > > > > > >    persistence
> > > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > > >    brokering.
> > > > > > > > > > > > > > > >    No
> > > > > > > > > > > > > > > >    UI, yet. I'm focused on the model, rest api
> > > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > > >    brokering
> > > > > > > > > > > > > > > >    functionality
> > > > > > > > > > > > > > > >    for now.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >    What I have is enough to decide if we are
> > > > > > > > > > > > > > > >    aligned
> > > > > > > > > > > > > > > >    about
> > > > > > > > > > > > > > > >    this
> > > > > > > > > > > > > > > >    functionality. So you can understand how the
> > > > > > > > > > > > > > > >    model
> > > > > > > > > > > > > > > >    (and
> > > > > > > > > > > > > > > >    persistence),
> > > > > > > > > > > > > > > >    rest api and brokering functionality looks
> > > > > > > > > > > > > > > >    like.
> > > > > > > > > > > > > > > >    Can
> > > > > > > > > > > > > > > >    we
> > > > > > > > > > > > > > > >    schedule
> > > > > > > > > > > > > > > >    a
> > > > > > > > > > > > > > > >    meeting ?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Currently adapters can only make authz
> > > > > > > > > > > > > > > > decisions
> > > > > > > > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > on either realm roles or the roles of one
> > > > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > > > application.
> > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > related to 1) too.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > 1) Sounds like something definitely worth
> > > > > > > > > > > > > > > > > aiming
> > > > > > > > > > > > > > > > > for.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >> I just wanted to quickly list the additional
> > > > > > > > > > > > > > > > >> work
> > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > >> discussed
> > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > >> everyone
> > > > > > > > > > > > > > > > >> can think about it (in no particular order):
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with
> > > > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > >> a KC token? For example an external token
> > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > >> attribute
> > > > > > > > > > > > > > > > >> 'group'
> > > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > > >> contains 'sales' and 'manager' could be
> > > > > > > > > > > > > > > > >> mapped
> > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > >> 'manager'
> > > > > > > > > > > > > > > > >> role
> > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > >> 'sales app in a KC token. Could we use
> > > > > > > > > > > > > > > > >> Drools?
> > > > > > > > > > > > > > > > >> This
> > > > > > > > > > > > > > > > >> could
> > > > > > > > > > > > > > > > >> also
> > > > > > > > > > > > > > > > >> be
> > > > > > > > > > > > > > > > >> used
> > > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > > >> user federation to allow more complex
> > > > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > >> roles/groups
> > > > > > > > > > > > > > > > >> than
> > > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > > >> simple 1-1
> > > > > > > > > > > > > > > > >> 2) Retrieving tokens - if an application
> > > > > > > > > > > > > > > > >> wants
> > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > >> retrieve
> > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > >> token (for example to view Facebook friends
> > > > > > > > > > > > > > > > >> if
> > > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > > >> logged
> > > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > >> Facebook)
> > > > > > > > > > > > > > > > >> 3) Configure scope - currently for social we
> > > > > > > > > > > > > > > > >> only
> > > > > > > > > > > > > > > > >> request
> > > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > > >> very
> > > > > > > > > > > > > > > > >> limited
> > > > > > > > > > > > > > > > >> scope (basic profile and email), to for
> > > > > > > > > > > > > > > > >> example
> > > > > > > > > > > > > > > > >> view
> > > > > > > > > > > > > > > > >> Facebook
> > > > > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > > > > > > > >> 4) Selecting provider - currently in social
> > > > > > > > > > > > > > > > >> (and
> > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > >> first
> > > > > > > > > > > > > > > > >> pass
> > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > >> brokering) we have an icon user has to
> > > > > > > > > > > > > > > > >> select,
> > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > >> can
> > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > >> provider in a different way (for example ask
> > > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > >> email,
> > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > > >> based on email domain)
> > > > > > > > > > > > > > > > >> 5) Gateway - don't create a KC token, but
> > > > > > > > > > > > > > > > >> just
> > > > > > > > > > > > > > > > >> forward
> > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> IMO 1) is a killer feature, as it would
> > > > > > > > > > > > > > > > >> allow
> > > > > > > > > > > > > > > > >> companies
> > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > >> add
> > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > >> users without having to modify their
> > > > > > > > > > > > > > > > >> applications.
> > > > > > > > > > > > > > > > >> Issue
> > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > >> 5)
> > > > > > > > > > > > > > > > >> is
> > > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > > >> applications need to understand more than
> > > > > > > > > > > > > > > > >> one
> > > > > > > > > > > > > > > > >> token,
> > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > >> would
> > > > > > > > > > > > > > > > >> require
> > > > > > > > > > > > > > > > >> rewriting applications.
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> This work is also somewhat related to other
> > > > > > > > > > > > > > > > >> authentication
> > > > > > > > > > > > > > > > >> mechanisms
> > > > > > > > > > > > > > > > >> (for
> > > > > > > > > > > > > > > > >> example Kerberos ticket, LDAP and
> > > > > > > > > > > > > > > > >> passwordless).
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > > > > > > > >>> From: "Pedro Igor Silva"
> > > > > > > > > > > > > > > > >>> <psilva at redhat.com>
> > > > > > > > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58
> > > > > > > > > > > > > > > > >>> PM
> > > > > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > >>> Identity
> > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > >>> Authentication
> > > > > > > > > > > > > > > > >>> Broker
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52
> > > > > > > > > > > > > > > > >>>> PM
> > > > > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > >>>> Identity
> > > > > > > > > > > > > > > > >>>> and
> > > > > > > > > > > > > > > > >>>> Authentication
> > > > > > > > > > > > > > > > >>>> Broker
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva
> > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > >>>>> Hi,
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        Would like to start a discussion
> > > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        enable
> > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > >>>>>        Authentication Broker in order to
> > > > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > > > >>>>>        Chained
> > > > > > > > > > > > > > > > >>>>>        Federation
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        also Identity Federation. First of
> > > > > > > > > > > > > > > > >>>>>        all,
> > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > >>>>>        background
> > > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > > >>>>>        what
> > > > > > > > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        Currently KeyCloak provides two
> > > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > > >>>>>        types
> > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > >>>>>        (correct
> > > > > > > > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>            1) Local authentication (based
> > > > > > > > > > > > > > > > >>>>>            on
> > > > > > > > > > > > > > > > >>>>>            some
> > > > > > > > > > > > > > > > >>>>>            credential
> > > > > > > > > > > > > > > > >>>>>            type
> > > > > > > > > > > > > > > > >>>>>            enabled
> > > > > > > > > > > > > > > > >>>>>            to
> > > > > > > > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        Local authentication is about
> > > > > > > > > > > > > > > > >>>>>        authenticating
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > >>>>>        locally
> > > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > > >>>>>        KC's own identity store. Nothing
> > > > > > > > > > > > > > > > >>>>>        special
> > > > > > > > > > > > > > > > >>>>>        here.
> > > > > > > > > > > > > > > > >>>>>        And
> > > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > > >>>>>        Authentication which allows users
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        choose
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > > > > > >>>>>        to authenticate with. In this
> > > > > > > > > > > > > > > > >>>>>        case,
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > >>>>>        always
> > > > > > > > > > > > > > > > >>>>>        one
> > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        built-in social providers
> > > > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > > > > > > > >>>>>        Google,
> > > > > > > > > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        When doing social, the user is
> > > > > > > > > > > > > > > > >>>>>        automatically
> > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > >>>>>        identity store after a successful
> > > > > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > >>>>>        does
> > > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > > >>>>>        need to fill a registration form
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > >>>>>        very
> > > > > > > > > > > > > > > > >>>>>        quickly. During the provisioning
> > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > > > > > > > >>>>>        from the social provider such as
> > > > > > > > > > > > > > > > >>>>>        email,
> > > > > > > > > > > > > > > > >>>>>        firstname
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > > >>>>>        These
> > > > > > > > > > > > > > > > >>>>>        are very basic information, any
> > > > > > > > > > > > > > > > >>>>>        other
> > > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > > >>>>>        related with authorization
> > > > > > > > > > > > > > > > >>>>>        policies
> > > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > > >>>>>        eg.:
> > > > > > > > > > > > > > > > >>>>>        roles
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        groups
> > > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > >>>>>        defined later via KC's admin
> > > > > > > > > > > > > > > > >>>>>        console.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        Another important characteristic
> > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        application receives a KC token
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > > >>>>>        issued by
> > > > > > > > > > > > > > > > >>>>>        the social IdP during the
> > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > >>>>>        process.
> > > > > > > > > > > > > > > > >>>>>        If
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > >>>>>        wants to consume resources from
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        resource
> > > > > > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > > > > > >>>>>        he
> > > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > > >>>>>        authenticated it must obtain the
> > > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > > >>>>>        itself
> > > > > > > > > > > > > > > > >>>>>        prior
> > > > > > > > > > > > > > > > >>>>>        to invoke the resource provider
> > > > > > > > > > > > > > > > >>>>>        API.
> > > > > > > > > > > > > > > > >>>>>        Assuming
> > > > > > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > >>>>>        providers are based on oAuth 1.0
> > > > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > > > >>>>>        2.0.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        That said, the Authentication
> > > > > > > > > > > > > > > > >>>>>        Broker
> > > > > > > > > > > > > > > > >>>>>        functionality
> > > > > > > > > > > > > > > > >>>>>        aims
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        cover
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        same use cases but with a lot of
> > > > > > > > > > > > > > > > >>>>>        more
> > > > > > > > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > > > > > > > >>>>>        on
> > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > > > > >>>>>        setup
> > > > > > > > > > > > > > > > >>>>>        identity providers(not only social
> > > > > > > > > > > > > > > > >>>>>        ones)
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > > > >>>>>        protocols they may support such as
> > > > > > > > > > > > > > > > >>>>>        SAML,
> > > > > > > > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > > >>>>>        This is useful when an enterprise
> > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > >>>>>        providing
> > > > > > > > > > > > > > > > >>>>>        services
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > >>>>>        customers(IdP) and does not want
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        manage
> > > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > > >>>>>        relationships. When using a
> > > > > > > > > > > > > > > > >>>>>        broker,
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > >>>>>        steps
> > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > >>>>>        pretty much the same when you are
> > > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > > > > > > > >>>>>        with
> > > > > > > > > > > > > > > > >>>>>        important differences on how you
> > > > > > > > > > > > > > > > >>>>>        support
> > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > > > > > > >>>>>        providers, different federation
> > > > > > > > > > > > > > > > >>>>>        protocols,
> > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > >>>>>        and how claims and attributes are
> > > > > > > > > > > > > > > > >>>>>        resolved.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        The brokering functionality can be
> > > > > > > > > > > > > > > > >>>>>        done
> > > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > > > > > >>>>>        ways
> > > > > > > > > > > > > > > > >>>>>        depending
> > > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        broker service is acting as a
> > > > > > > > > > > > > > > > >>>>>        gateway
> > > > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > > > >>>>>        not.
> > > > > > > > > > > > > > > > >>>>>        When
> > > > > > > > > > > > > > > > >>>>>        acting
> > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > >>>>>        gateway, the broker will respond
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        same
> > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > >>>>>        issued by the trusted identity
> > > > > > > > > > > > > > > > >>>>>        provider.
> > > > > > > > > > > > > > > > >>>>>        For
> > > > > > > > > > > > > > > > >>>>>        instance,
> > > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > >>>>>        selects a SAML IdP to authenticate
> > > > > > > > > > > > > > > > >>>>>        with,
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > > >>>>>        a SAML Response. In this case, the
> > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > >>>>>        prepared
> > > > > > > > > > > > > > > > >>>>>        to handle a specific federation
> > > > > > > > > > > > > > > > >>>>>        protocol.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        However, the broker service can
> > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        completely
> > > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > > >>>>>        from the application the protocol
> > > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > >>>>>        user.
> > > > > > > > > > > > > > > > >>>>>        In
> > > > > > > > > > > > > > > > >>>>>        this case, the application will
> > > > > > > > > > > > > > > > >>>>>        just
> > > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > >>>>>        after a successful authentication.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        In both cases, the broker acts as
> > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > > > > > > > >>>>>        where
> > > > > > > > > > > > > > > > >>>>>        specific
> > > > > > > > > > > > > > > > >>>>>        security policies can be applied
> > > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > >>>>>        try
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > >>>>>        themselves against a 3rd party
> > > > > > > > > > > > > > > > >>>>>        IdP.
> > > > > > > > > > > > > > > > >>>>>        That
> > > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > >>>>>        value
> > > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > > >>>>>        you think about auditing,
> > > > > > > > > > > > > > > > >>>>>        authorization
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > >>>>>        when federation of identities is
> > > > > > > > > > > > > > > > >>>>>        needed.
> > > > > > > > > > > > > > > > >>>>>        This
> > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > >>>>>        allows
> > > > > > > > > > > > > > > > >>>>>        existing
> > > > > > > > > > > > > > > > >>>>>        security infrastructures (eg.:
> > > > > > > > > > > > > > > > >>>>>        SAML-based
> > > > > > > > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        benefit
> > > > > > > > > > > > > > > > >>>>>        from KC's support for cloud, rest
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        mobile
> > > > > > > > > > > > > > > > >>>>>        use
> > > > > > > > > > > > > > > > >>>>>        cases.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>        I think this is enough to start a
> > > > > > > > > > > > > > > > >>>>>        discussion.
> > > > > > > > > > > > > > > > >>>>>        I've
> > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > >>>>>        initial
> > > > > > > > > > > > > > > > >>>>>        discussion with Stian about all
> > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        we
> > > > > > > > > > > > > > > > >>>>>        agreed
> > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > >>>>>        protocol from applications should
> > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > > >>>>>        main
> > > > > > > > > > > > > > > > >>>>>        reason is
> > > > > > > > > > > > > > > > >>>>>        that it makes life easier for
> > > > > > > > > > > > > > > > >>>>>        applications
> > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > > >>>>>        only
> > > > > > > > > > > > > > > > >>>>>        need
> > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > >>>>>        know
> > > > > > > > > > > > > > > > >>>>>        about KC tokens and nothing else.
> > > > > > > > > > > > > > > > >>>>>        However
> > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > >>>>>        new
> > > > > > > > > > > > > > > > >>>>>        requirements around user
> > > > > > > > > > > > > > > > >>>>>        provisioning
> > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > > > > > > > >>>>>        resolution
> > > > > > > > > > > > > > > > >>>>>        or mapping. But that would be
> > > > > > > > > > > > > > > > >>>>>        another
> > > > > > > > > > > > > > > > >>>>>        thread.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>> Can you elaborate on "abstract the
> > > > > > > > > > > > > > > > >>>> protocol
> > > > > > > > > > > > > > > > >>>> from
> > > > > > > > > > > > > > > > >>>> applications"?
> > > > > > > > > > > > > > > > >>>> Not
> > > > > > > > > > > > > > > > >>>> sure what you mean by that.  IDP
> > > > > > > > > > > > > > > > >>>> federation
> > > > > > > > > > > > > > > > >>>> should
> > > > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > > > >>>> configured
> > > > > > > > > > > > > > > > >>>> at
> > > > > > > > > > > > > > > > >>>> the
> > > > > > > > > > > > > > > > >>>> realm level and really has nothing to do
> > > > > > > > > > > > > > > > >>>> with
> > > > > > > > > > > > > > > > >>>> applications.
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>> I'm really happy that somebody is doing
> > > > > > > > > > > > > > > > >>>> this.
> > > > > > > > > > > > > > > > >>>> We're
> > > > > > > > > > > > > > > > >>>> getting
> > > > > > > > > > > > > > > > >>>> a
> > > > > > > > > > > > > > > > >>>> real
> > > > > > > > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>> Sure. What I meant was that the application
> > > > > > > > > > > > > > > > >>> only
> > > > > > > > > > > > > > > > >>> knows
> > > > > > > > > > > > > > > > >>> about
> > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > >>> tokens
> > > > > > > > > > > > > > > > >>> nothing else. It will always receive a KC
> > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > >>> regardless
> > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > >>> protocol
> > > > > > > > > > > > > > > > >>> used
> > > > > > > > > > > > > > > > >>> to authenticate the user against a 3rd
> > > > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > > >>> (saml,
> > > > > > > > > > > > > > > > >>> oidc,
> > > > > > > > > > > > > > > > >>> whatever).
> > > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > > >>> example I gave was about an user trying to
> > > > > > > > > > > > > > > > >>> authenticate
> > > > > > > > > > > > > > > > >>> against
> > > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > > >>> SAML
> > > > > > > > > > > > > > > > >>> IdP.
> > > > > > > > > > > > > > > > >>> In this case, after a successful
> > > > > > > > > > > > > > > > >>> authentication
> > > > > > > > > > > > > > > > >>> on
> > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > >>> IdP,
> > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > >>> issue a token to KC. Then KC will validate
> > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > >>> token,
> > > > > > > > > > > > > > > > >>> perform
> > > > > > > > > > > > > > > > >>> trust
> > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > >>> security checks, do user provisioning and
> > > > > > > > > > > > > > > > >>> attribute/claim
> > > > > > > > > > > > > > > > >>> resolution
> > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > >>> finally issue a KC token and redirect the
> > > > > > > > > > > > > > > > >>> user
> > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > >>> application.
> > > > > > > > > > > > > > > > >>> If
> > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > >>> app is configured to use openid in KC then
> > > > > > > > > > > > > > > > >>> it
> > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > >>> receive
> > > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > > >>> openid
> > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>> The other scenario is pretty much the same.
> > > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > > >>> difference
> > > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > > >>> that
> > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > >>> not issue its own token but just replay the
> > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > >>> issued
> > > > > > > > > > > > > > > > >>> by
> > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > >>> 3rd
> > > > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>> I agree that this config goes at the realm
> > > > > > > > > > > > > > > > >>> level.
> > > > > > > > > > > > > > > > >>> For
> > > > > > > > > > > > > > > > >>> instance,
> > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > >>> create
> > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > >>> enable providers for being used. However, I
> > > > > > > > > > > > > > > > >>> think
> > > > > > > > > > > > > > > > >>> we
> > > > > > > > > > > > > > > > >>> would
> > > > > > > > > > > > > > > > >>> need
> > > > > > > > > > > > > > > > >>> some
> > > > > > > > > > > > > > > > >>> specific configuration for applications as
> > > > > > > > > > > > > > > > >>> well.
> > > > > > > > > > > > > > > > >>> Specially
> > > > > > > > > > > > > > > > >>> when
> > > > > > > > > > > > > > > > >>> defining
> > > > > > > > > > > > > > > > >>> default roles, mapping attributes. Another
> > > > > > > > > > > > > > > > >>> example
> > > > > > > > > > > > > > > > >>> of
> > > > > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > > > > >>> config
> > > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want
> > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > >>> define
> > > > > > > > > > > > > > > > >>> scopes
> > > > > > > > > > > > > > > > >>> per-application.
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>> --
> > > > > > > > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > > > > > > >>> 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
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From stian at redhat.com  Fri Dec  5 09:36:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 09:36:53 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1535438172.25382344.1417789748360.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
	<1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>
	<4760322.11384589.1417788457523.JavaMail.zimbra@redhat.com>
	<711831466.25373681.1417788942317.JavaMail.zimbra@redhat.com>
	<48451523.11412244.1417789433189.JavaMail.zimbra@redhat.com>
	<1535438172.25382344.1417789748360.JavaMail.zimbra@redhat.com>
Message-ID: <1841207631.11425021.1417790213219.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 3:29:08 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, December 5, 2014 12:23:53 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 5 December, 2014 3:15:42 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, December 5, 2014 12:07:37 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, 5 December, 2014 2:57:46 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, December 5, 2014 11:43:32 AM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Friday, 5 December, 2014 2:36:14 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Friday, December 5, 2014 10:59:08 AM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > Another related thing. We've had a few people ask to be able to
> > > > > > > > login
> > > > > > > > to
> > > > > > > > Keycloak on mobiles using the native social login mechanism.
> > > > > > > > 
> > > > > > > > I think the best way to do that is to use the direct grant api
> > > > > > > > and
> > > > > > > > make
> > > > > > > > it
> > > > > > > > possible to call that endpoint passing a IdP id and a token
> > > > > > > > instead
> > > > > > > > of
> > > > > > > > username and password.
> > > > > > > > 
> > > > > > > > WDYT?
> > > > > > > 
> > > > > > > The broker endpoint expects the idp id in order to start the
> > > > > > > authentication
> > > > > > > process. Today, the endpoint also expects KCs authorization code
> > > > > > > in
> > > > > > > order
> > > > > > > to
> > > > > > > validate requests from clients and use it as a state to validate
> > > > > > > responses
> > > > > > > from the trusted idps.
> > > > > > > 
> > > > > > > This authorization code is a blocker for this use case, given
> > > > > > > that
> > > > > > > mobile
> > > > > > > don't have this code and just want to start the authentication.
> > > > > > > 
> > > > > > > A possible solution would be to change the broker to also accept
> > > > > > > a
> > > > > > > client_id
> > > > > > > to reference the mobile app and perform some validations based on
> > > > > > > that.
> > > > > > > Something like that:
> > > > > > > 
> > > > > > > 1) Mobile displays a Facebook button
> > > > > > > 2) User clicks the button and mobile sends a request to KC Broker
> > > > > > > with
> > > > > > > the
> > > > > > > idp id and his client_id.
> > > > > > > 3) KC Broker checks if the client_id is valid and creates a
> > > > > > > temporary
> > > > > > > authorization code.
> > > > > > > 4) KC Broker redirect mobile to the chosen IdP to perform
> > > > > > > authentication.
> > > > > > > 5) KC Broker receives a response from the IdP, generate its own
> > > > > > > token
> > > > > > > and
> > > > > > > send it back to mobile
> > > > > > > 
> > > > > > > Makes sense ?
> > > > > > 
> > > > > > No that's not the flow I had in mind. Basically the mobile app
> > > > > > authenticates
> > > > > > with Facebook through the native mechanisms. The app then has an
> > > > > > access
> > > > > > token, which it would send to Keycloak on the direct grant api to
> > > > > > obtain
> > > > > > a
> > > > > > Keycloak token.
> > > > > 
> > > > > Ahh, now I get what you mean :)
> > > > > 
> > > > > Yes, what you said is enough. Then we just need to validate the
> > > > > access
> > > > > token
> > > > > (eg.: using a tokeninfo endpoint).
> > > > > 
> > > > > But I think we can also consider that use case I mentioned. You may
> > > > > want
> > > > > to
> > > > > login without forcing the user to redirect to KC login page.
> > > > 
> > > > We could just add a query param to the login url that lets you pick the
> > > > IdP
> > > > to use by alias?
> > > > 
> > > >   For example auth/.../login?client_id=...&auth_method=google
> > > 
> > > Yes, just like my previously example, we need the client_id. The idp
> > > id/alias
> > > is already there.
> > 
> > Sure, was just saying it should be the same URL as the regular login page,
> > but with one extra param to specify the IdP.
> > 
> > > 
> > > Btw, regarding SAML. SAML does not provide a "validation" endpoint like
> > > oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the
> > > specs for that. What can be done here is validate SAML assertions against
> > > a
> > > WS-Trust STS. Or just trust the assertion based on the signature and
> > > others
> > > standards info along it.
> > > 
> > > We can also take a closer look at the oAuth2 SAML bearer token profile
> > > and
> > > see if it helps.
> > 
> > If we could have it for social and OpenID Connect providers for now that'd
> > be
> > good.
> 
> Deal. I'll do that.
> 
> What about that use case I mentioned ? The one about mobile asking to broker
> (not previously issued access_token) an identity provider ?

Sounds like a nice feature, but I'm not sure if anyone would use it. It also has a bit of an issue related to adapters, as they would have to have some support for it. For example we added a while back the login_hint query param from OpenID Connect, which is really only usable from the JS adapter currently.

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > Same for other identity providers, the assumption is the app has an
> > > > > > out
> > > > > > of
> > > > > > bounds mechanism to obtain an access token, which is then sent to
> > > > > > Keycloak
> > > > > > over the direct grant api.
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Friday, 5 December, 2014 1:45:24 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > Looks good. I reckon we can combine the two pages. What
> > > > > > > > > > about
> > > > > > > > > > if
> > > > > > > > > > the
> > > > > > > > > > 'Add
> > > > > > > > > > provider' drop-down is:
> > > > > > > > > > 
> > > > > > > > > >   OpenID
> > > > > > > > > >   SAML
> > > > > > > > > >   ------
> > > > > > > > > >   Google
> > > > > > > > > >   GitHub
> > > > > > > > > >   Facebook
> > > > > > > > > >   Twitter
> > > > > > > > > > 
> > > > > > > > > > Let's drop social on/off and instead have a enable/disable
> > > > > > > > > > button
> > > > > > > > > > on
> > > > > > > > > > each
> > > > > > > > > > provider.
> > > > > > > > > 
> > > > > > > > > Sure.
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Also, would be nice if users could set a name or alias for
> > > > > > > > > > a
> > > > > > > > > > provider
> > > > > > > > > > instance. This would make the callback url easier to use
> > > > > > > > > > (instead
> > > > > > > > > > of
> > > > > > > > > > callback/<UUID> it's callback/<alias>). The user federation
> > > > > > > > > > providers
> > > > > > > > > > have
> > > > > > > > > > this.
> > > > > > > > > 
> > > > > > > > > One of my first tries was using an alias, just like that. But
> > > > > > > > > I
> > > > > > > > > preferred
> > > > > > > > > using the UUID and make the configuration more easier. Beside
> > > > > > > > > that,
> > > > > > > > > the
> > > > > > > > > callback url is just a copy and paste, so I think an alias
> > > > > > > > > would
> > > > > > > > > not
> > > > > > > > > bring
> > > > > > > > > so much usability, but add one more step when configuring
> > > > > > > > > providers.
> > > > > > > > > 
> > > > > > > > > However, if this is an usability requirement for KC I can
> > > > > > > > > change
> > > > > > > > > that.
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > In one of our last discussions, you suggested to leave
> > > > > > > > > > > Social
> > > > > > > > > > > as
> > > > > > > > > > > it
> > > > > > > > > > > is.
> > > > > > > > > > > Although IMO I think we can have a single place to manage
> > > > > > > > > > > both
> > > > > > > > > > > social
> > > > > > > > > > > and
> > > > > > > > > > > user-defined identity providers. Social ones are just
> > > > > > > > > > > OOTB
> > > > > > > > > > > and
> > > > > > > > > > > pre-configured identity providers now.
> > > > > > > > > > > 
> > > > > > > > > > > That said, today I'm using separated tabs for social and
> > > > > > > > > > > user-defined.
> > > > > > > > > > > Please, take a look at [1] for more details on how the UI
> > > > > > > > > > > looks
> > > > > > > > > > > like.
> > > > > > > > > > > 
> > > > > > > > > > > I've changed social UI a bit in order to provide a
> > > > > > > > > > > specific
> > > > > > > > > > > page
> > > > > > > > > > > for
> > > > > > > > > > > create/update. I've also added a "Show Secret" link to
> > > > > > > > > > > display
> > > > > > > > > > > the
> > > > > > > > > > > client_secret in clear text if user wants to.
> > > > > > > > > > > 
> > > > > > > > > > > Beside the enable/disable button, I think another good
> > > > > > > > > > > thing
> > > > > > > > > > > to
> > > > > > > > > > > do
> > > > > > > > > > > is
> > > > > > > > > > > specify
> > > > > > > > > > > a default role(s) for each provider. That can be useful
> > > > > > > > > > > if
> > > > > > > > > > > applications
> > > > > > > > > > > want
> > > > > > > > > > > to perform any kind of authorization based on the
> > > > > > > > > > > identity
> > > > > > > > > > > provider
> > > > > > > > > > > or
> > > > > > > > > > > authentication method used to authenticate an user (eg.:
> > > > > > > > > > > useful
> > > > > > > > > > > for
> > > > > > > > > > > adaptative or multi-level access control). We can also
> > > > > > > > > > > use
> > > > > > > > > > > the
> > > > > > > > > > > "amr"
> > > > > > > > > > > claim
> > > > > > > > > > > in the ID Token, which seems KC is not considering at
> > > > > > > > > > > all.
> > > > > > > > > > > The
> > > > > > > > > > > latter
> > > > > > > > > > > is
> > > > > > > > > > > an
> > > > > > > > > > > important thing to think of, regardless this broker work
> > > > > > > > > > > I'm
> > > > > > > > > > > doing.
> > > > > > > > > > > 
> > > > > > > > > > > [1]
> > > > > > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > Having a separate enable/disable for each provider would
> > > > > > > > > > > be
> > > > > > > > > > > good.
> > > > > > > > > > > If
> > > > > > > > > > > you're
> > > > > > > > > > > leaving the social tab as is and adding a separate tab
> > > > > > > > > > > for
> > > > > > > > > > > configuring
> > > > > > > > > > > brokered idp's then we should leave the social
> > > > > > > > > > > enable/disable
> > > > > > > > > > > button,
> > > > > > > > > > > otherwise it depends how it'll look like in the end.
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > >    Social has a button to enable/disable it. I'm
> > > > > > > > > > > >    wondering
> > > > > > > > > > > >    what
> > > > > > > > > > > >    to
> > > > > > > > > > > >    do
> > > > > > > > > > > >    with
> > > > > > > > > > > >    the brokered identity providers. Shall we add a
> > > > > > > > > > > >    similar
> > > > > > > > > > > >    flag
> > > > > > > > > > > >    for
> > > > > > > > > > > >    that
> > > > > > > > > > > >    ?
> > > > > > > > > > > > 
> > > > > > > > > > > >    I was also wondering if the best would be a flag in
> > > > > > > > > > > >    a
> > > > > > > > > > > >    per
> > > > > > > > > > > >    provider
> > > > > > > > > > > >    basis.
> > > > > > > > > > > >    So we can disable/enable a specific provider (social
> > > > > > > > > > > >    or
> > > > > > > > > > > >    brokered),
> > > > > > > > > > > >    instead of doing that for all.
> > > > > > > > > > > > 
> > > > > > > > > > > > Regards.
> > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I'll go for it then. Will remove the icon url from
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > model
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > leave
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > for users if they want to provide icons for their
> > > > > > > > > > > > > > identity
> > > > > > > > > > > > > > providers.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > My point is that icons can be usually served by the
> > > > > > > > > > > > > > same
> > > > > > > > > > > > > > server/application
> > > > > > > > > > > > > > or proxy, so download images are not such a big
> > > > > > > > > > > > > > deal.
> > > > > > > > > > > > > > Also,
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > icon
> > > > > > > > > > > > > > url
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > part of the freemarker model and people can do what
> > > > > > > > > > > > > > ever
> > > > > > > > > > > > > > they
> > > > > > > > > > > > > > want
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > it.
> > > > > > > > > > > > > > What I think will also help in your future plans.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I'm not following. Are you saying that if a named
> > > > > > > > > > > > > image
> > > > > > > > > > > > > 'my-provider.png'
> > > > > > > > > > > > > is
> > > > > > > > > > > > > loaded from a theme, then you can override it in
> > > > > > > > > > > > > another
> > > > > > > > > > > > > theme?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > If so, that's basically the same as having a css
> > > > > > > > > > > > > class
> > > > > > > > > > > > > 'my-provider'
> > > > > > > > > > > > > in
> > > > > > > > > > > > > a
> > > > > > > > > > > > > theme. With the exception that with an image you end
> > > > > > > > > > > > > up
> > > > > > > > > > > > > with
> > > > > > > > > > > > > having
> > > > > > > > > > > > > to
> > > > > > > > > > > > > require a image per provider per theme per language,
> > > > > > > > > > > > > which
> > > > > > > > > > > > > could
> > > > > > > > > > > > > be
> > > > > > > > > > > > > a
> > > > > > > > > > > > > lot
> > > > > > > > > > > > > of
> > > > > > > > > > > > > images for a single provider. Also, buttons for
> > > > > > > > > > > > > accessibility
> > > > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > defined with text and css, not images that can't be
> > > > > > > > > > > > > interpreted.
> > > > > > > > > > > > > You
> > > > > > > > > > > > > also
> > > > > > > > > > > > > still need to modify the theme, so I don't see any
> > > > > > > > > > > > > benefits.
> > > > > > > > > > > > 
> > > > > > > > > > > > You are right. Having a icon url per provider does not
> > > > > > > > > > > > makes
> > > > > > > > > > > > sense
> > > > > > > > > > > > if
> > > > > > > > > > > > there
> > > > > > > > > > > > are requirements to change images accordingly to a
> > > > > > > > > > > > theme
> > > > > > > > > > > > or
> > > > > > > > > > > > language.
> > > > > > > > > > > > CSS
> > > > > > > > > > > > makes life easier.
> > > > > > > > > > > > 
> > > > > > > > > > > > Will remove that property from the model.
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Users can now specify a Icon Url to be rendered
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > login
> > > > > > > > > > > > > > > page
> > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > social
> > > > > > > > > > > > > > > or any other identity provider is configured. So
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > just
> > > > > > > > > > > > > > > load
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > image
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > url entered by the user.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Are you saying that users should change the theme
> > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > customize
> > > > > > > > > > > > > > > css
> > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > only want to change an icon for a provider ?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Yes, there's many issues with having a icon url:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > * Won't work for internationalization - we don't
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > this
> > > > > > > > > > > > > > now,
> > > > > > > > > > > > > > but
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > * Image is not a good button - CSS is much better
> > > > > > > > > > > > > > * Doesn't support themes - we allow users to switch
> > > > > > > > > > > > > > l&f
> > > > > > > > > > > > > > by
> > > > > > > > > > > > > > switching
> > > > > > > > > > > > > > themes,
> > > > > > > > > > > > > > but that won't work for a icon url. In the future
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > may
> > > > > > > > > > > > > > also
> > > > > > > > > > > > > > support
> > > > > > > > > > > > > > multiple themes per-realm, for example to depending
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > devices
> > > > > > > > > > > > > > (one
> > > > > > > > > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > > > > > > > > * Requires the URL to be hosted somewhere - why
> > > > > > > > > > > > > > require
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > separate
> > > > > > > > > > > > > > call
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > download an image (to a separate server maybe) if
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > can
> > > > > > > > > > > > > > simply
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > defined
> > > > > > > > > > > > > > in a single CSS file?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Rather than add additional places to define look
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > feel
> > > > > > > > > > > > > > components
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > should in the future make it easier to
> > > > > > > > > > > > > > add/customize
> > > > > > > > > > > > > > themes.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > All look and feel related things including images
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > stylesheets
> > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > part of themes. This is to allow customizing them
> > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > theme.
> > > > > > > > > > > > > > > Also,
> > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > image is not the correct way to render a button,
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > defined
> > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > CSS.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > You shouldn't have icon images for social
> > > > > > > > > > > > > > > > providers.
> > > > > > > > > > > > > > > > They
> > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > specified
> > > > > > > > > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >     Anyone know where I can get the icons
> > > > > > > > > > > > > > > > >     images
> > > > > > > > > > > > > > > > >     for
> > > > > > > > > > > > > > > > >     social
> > > > > > > > > > > > > > > > >     providers
> > > > > > > > > > > > > > > > >     ?
> > > > > > > > > > > > > > > > >     It
> > > > > > > > > > > > > > > > >     seems zocial defines them encoded in some
> > > > > > > > > > > > > > > > >     way
> > > > > > > > > > > > > > > > >     in
> > > > > > > > > > > > > > > > >     CSS.
> > > > > > > > > > > > > > > > >     I
> > > > > > > > > > > > > > > > >     need
> > > > > > > > > > > > > > > > >     that
> > > > > > > > > > > > > > > > >     to
> > > > > > > > > > > > > > > > >     provide default images if user does not
> > > > > > > > > > > > > > > > >     specify
> > > > > > > > > > > > > > > > >     their
> > > > > > > > > > > > > > > > >     own.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >     Or is still possible to use zocial ones ?
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM
> > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >    I've done some initial work covering both
> > > > > > > > > > > > > > > > >    persistence
> > > > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > > > >    brokering.
> > > > > > > > > > > > > > > > >    No
> > > > > > > > > > > > > > > > >    UI, yet. I'm focused on the model, rest
> > > > > > > > > > > > > > > > >    api
> > > > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > > > >    brokering
> > > > > > > > > > > > > > > > >    functionality
> > > > > > > > > > > > > > > > >    for now.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >    What I have is enough to decide if we are
> > > > > > > > > > > > > > > > >    aligned
> > > > > > > > > > > > > > > > >    about
> > > > > > > > > > > > > > > > >    this
> > > > > > > > > > > > > > > > >    functionality. So you can understand how
> > > > > > > > > > > > > > > > >    the
> > > > > > > > > > > > > > > > >    model
> > > > > > > > > > > > > > > > >    (and
> > > > > > > > > > > > > > > > >    persistence),
> > > > > > > > > > > > > > > > >    rest api and brokering functionality looks
> > > > > > > > > > > > > > > > >    like.
> > > > > > > > > > > > > > > > >    Can
> > > > > > > > > > > > > > > > >    we
> > > > > > > > > > > > > > > > >    schedule
> > > > > > > > > > > > > > > > >    a
> > > > > > > > > > > > > > > > >    meeting ?
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM
> > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Currently adapters can only make authz
> > > > > > > > > > > > > > > > > decisions
> > > > > > > > > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > on either realm roles or the roles of one
> > > > > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > > > > application.
> > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > related to 1) too.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > 1) Sounds like something definitely worth
> > > > > > > > > > > > > > > > > > aiming
> > > > > > > > > > > > > > > > > > for.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >> I just wanted to quickly list the
> > > > > > > > > > > > > > > > > >> additional
> > > > > > > > > > > > > > > > > >> work
> > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > >> discussed
> > > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > > >> everyone
> > > > > > > > > > > > > > > > > >> can think about it (in no particular
> > > > > > > > > > > > > > > > > >> order):
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with
> > > > > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > >> a KC token? For example an external token
> > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > >> attribute
> > > > > > > > > > > > > > > > > >> 'group'
> > > > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > > > >> contains 'sales' and 'manager' could be
> > > > > > > > > > > > > > > > > >> mapped
> > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > >> 'manager'
> > > > > > > > > > > > > > > > > >> role
> > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > >> 'sales app in a KC token. Could we use
> > > > > > > > > > > > > > > > > >> Drools?
> > > > > > > > > > > > > > > > > >> This
> > > > > > > > > > > > > > > > > >> could
> > > > > > > > > > > > > > > > > >> also
> > > > > > > > > > > > > > > > > >> be
> > > > > > > > > > > > > > > > > >> used
> > > > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > > > >> user federation to allow more complex
> > > > > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > > >> roles/groups
> > > > > > > > > > > > > > > > > >> than
> > > > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > > > >> simple 1-1
> > > > > > > > > > > > > > > > > >> 2) Retrieving tokens - if an application
> > > > > > > > > > > > > > > > > >> wants
> > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > >> retrieve
> > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > >> token (for example to view Facebook
> > > > > > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > > > > > >> if
> > > > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > > > >> logged
> > > > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > >> Facebook)
> > > > > > > > > > > > > > > > > >> 3) Configure scope - currently for social
> > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > >> only
> > > > > > > > > > > > > > > > > >> request
> > > > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > > > >> very
> > > > > > > > > > > > > > > > > >> limited
> > > > > > > > > > > > > > > > > >> scope (basic profile and email), to for
> > > > > > > > > > > > > > > > > >> example
> > > > > > > > > > > > > > > > > >> view
> > > > > > > > > > > > > > > > > >> Facebook
> > > > > > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > > > > > > > > >> 4) Selecting provider - currently in
> > > > > > > > > > > > > > > > > >> social
> > > > > > > > > > > > > > > > > >> (and
> > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > >> first
> > > > > > > > > > > > > > > > > >> pass
> > > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > > >> brokering) we have an icon user has to
> > > > > > > > > > > > > > > > > >> select,
> > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > >> can
> > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > >> provider in a different way (for example
> > > > > > > > > > > > > > > > > >> ask
> > > > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > >> email,
> > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > > > >> based on email domain)
> > > > > > > > > > > > > > > > > >> 5) Gateway - don't create a KC token, but
> > > > > > > > > > > > > > > > > >> just
> > > > > > > > > > > > > > > > > >> forward
> > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> IMO 1) is a killer feature, as it would
> > > > > > > > > > > > > > > > > >> allow
> > > > > > > > > > > > > > > > > >> companies
> > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > >> add
> > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > >> users without having to modify their
> > > > > > > > > > > > > > > > > >> applications.
> > > > > > > > > > > > > > > > > >> Issue
> > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > >> 5)
> > > > > > > > > > > > > > > > > >> is
> > > > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > > > >> applications need to understand more than
> > > > > > > > > > > > > > > > > >> one
> > > > > > > > > > > > > > > > > >> token,
> > > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > > >> would
> > > > > > > > > > > > > > > > > >> require
> > > > > > > > > > > > > > > > > >> rewriting applications.
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> This work is also somewhat related to
> > > > > > > > > > > > > > > > > >> other
> > > > > > > > > > > > > > > > > >> authentication
> > > > > > > > > > > > > > > > > >> mechanisms
> > > > > > > > > > > > > > > > > >> (for
> > > > > > > > > > > > > > > > > >> example Kerberos ticket, LDAP and
> > > > > > > > > > > > > > > > > >> passwordless).
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > > > > > > > > >>> From: "Pedro Igor Silva"
> > > > > > > > > > > > > > > > > >>> <psilva at redhat.com>
> > > > > > > > > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014
> > > > > > > > > > > > > > > > > >>> 8:27:58
> > > > > > > > > > > > > > > > > >>> PM
> > > > > > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > >>> Identity
> > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > >>> Authentication
> > > > > > > > > > > > > > > > > >>> Broker
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014
> > > > > > > > > > > > > > > > > >>>> 4:39:52
> > > > > > > > > > > > > > > > > >>>> PM
> > > > > > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > >>>> Identity
> > > > > > > > > > > > > > > > > >>>> and
> > > > > > > > > > > > > > > > > >>>> Authentication
> > > > > > > > > > > > > > > > > >>>> Broker
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva
> > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > >>>>> Hi,
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        Would like to start a discussion
> > > > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        enable
> > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > >>>>>        Authentication Broker in order
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > > > > >>>>>        Chained
> > > > > > > > > > > > > > > > > >>>>>        Federation
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        also Identity Federation. First
> > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > >>>>>        all,
> > > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > > >>>>>        background
> > > > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > > > >>>>>        what
> > > > > > > > > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        Currently KeyCloak provides two
> > > > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > > > >>>>>        types
> > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > >>>>>        (correct
> > > > > > > > > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>            1) Local authentication
> > > > > > > > > > > > > > > > > >>>>>            (based
> > > > > > > > > > > > > > > > > >>>>>            on
> > > > > > > > > > > > > > > > > >>>>>            some
> > > > > > > > > > > > > > > > > >>>>>            credential
> > > > > > > > > > > > > > > > > >>>>>            type
> > > > > > > > > > > > > > > > > >>>>>            enabled
> > > > > > > > > > > > > > > > > >>>>>            to
> > > > > > > > > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        Local authentication is about
> > > > > > > > > > > > > > > > > >>>>>        authenticating
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > > >>>>>        locally
> > > > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > > > >>>>>        KC's own identity store. Nothing
> > > > > > > > > > > > > > > > > >>>>>        special
> > > > > > > > > > > > > > > > > >>>>>        here.
> > > > > > > > > > > > > > > > > >>>>>        And
> > > > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > > > >>>>>        Authentication which allows
> > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        choose
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > > > > > > >>>>>        to authenticate with. In this
> > > > > > > > > > > > > > > > > >>>>>        case,
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > >>>>>        always
> > > > > > > > > > > > > > > > > >>>>>        one
> > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        built-in social providers
> > > > > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > > > > > > > > >>>>>        Google,
> > > > > > > > > > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        When doing social, the user is
> > > > > > > > > > > > > > > > > >>>>>        automatically
> > > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > >>>>>        identity store after a
> > > > > > > > > > > > > > > > > >>>>>        successful
> > > > > > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > > >>>>>        does
> > > > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > > > >>>>>        need to fill a registration form
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > >>>>>        very
> > > > > > > > > > > > > > > > > >>>>>        quickly. During the provisioning
> > > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > > > > > > > > >>>>>        from the social provider such as
> > > > > > > > > > > > > > > > > >>>>>        email,
> > > > > > > > > > > > > > > > > >>>>>        firstname
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > > > >>>>>        These
> > > > > > > > > > > > > > > > > >>>>>        are very basic information, any
> > > > > > > > > > > > > > > > > >>>>>        other
> > > > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > > > >>>>>        related with authorization
> > > > > > > > > > > > > > > > > >>>>>        policies
> > > > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > > > >>>>>        eg.:
> > > > > > > > > > > > > > > > > >>>>>        roles
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        groups
> > > > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > >>>>>        defined later via KC's admin
> > > > > > > > > > > > > > > > > >>>>>        console.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        Another important characteristic
> > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        application receives a KC token
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > > > >>>>>        issued by
> > > > > > > > > > > > > > > > > >>>>>        the social IdP during the
> > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > >>>>>        process.
> > > > > > > > > > > > > > > > > >>>>>        If
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > >>>>>        wants to consume resources from
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        resource
> > > > > > > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > > > > > > >>>>>        he
> > > > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > > > >>>>>        authenticated it must obtain the
> > > > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > > > >>>>>        itself
> > > > > > > > > > > > > > > > > >>>>>        prior
> > > > > > > > > > > > > > > > > >>>>>        to invoke the resource provider
> > > > > > > > > > > > > > > > > >>>>>        API.
> > > > > > > > > > > > > > > > > >>>>>        Assuming
> > > > > > > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > >>>>>        providers are based on oAuth 1.0
> > > > > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > > > > >>>>>        2.0.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        That said, the Authentication
> > > > > > > > > > > > > > > > > >>>>>        Broker
> > > > > > > > > > > > > > > > > >>>>>        functionality
> > > > > > > > > > > > > > > > > >>>>>        aims
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        cover
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        same use cases but with a lot of
> > > > > > > > > > > > > > > > > >>>>>        more
> > > > > > > > > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > > > > > > > > >>>>>        on
> > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > > > > > >>>>>        setup
> > > > > > > > > > > > > > > > > >>>>>        identity providers(not only
> > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > >>>>>        ones)
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > > > > >>>>>        protocols they may support such
> > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > >>>>>        SAML,
> > > > > > > > > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > > > >>>>>        This is useful when an
> > > > > > > > > > > > > > > > > >>>>>        enterprise
> > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > >>>>>        providing
> > > > > > > > > > > > > > > > > >>>>>        services
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > > >>>>>        customers(IdP) and does not want
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        manage
> > > > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > > > >>>>>        relationships. When using a
> > > > > > > > > > > > > > > > > >>>>>        broker,
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > >>>>>        steps
> > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > >>>>>        pretty much the same when you
> > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > > > > > > > > >>>>>        with
> > > > > > > > > > > > > > > > > >>>>>        important differences on how you
> > > > > > > > > > > > > > > > > >>>>>        support
> > > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > > > > > > > >>>>>        providers, different federation
> > > > > > > > > > > > > > > > > >>>>>        protocols,
> > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > > >>>>>        and how claims and attributes
> > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > >>>>>        resolved.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        The brokering functionality can
> > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > >>>>>        done
> > > > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > > > > > > >>>>>        ways
> > > > > > > > > > > > > > > > > >>>>>        depending
> > > > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        broker service is acting as a
> > > > > > > > > > > > > > > > > >>>>>        gateway
> > > > > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > > > > >>>>>        not.
> > > > > > > > > > > > > > > > > >>>>>        When
> > > > > > > > > > > > > > > > > >>>>>        acting
> > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > >>>>>        gateway, the broker will respond
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        same
> > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > >>>>>        issued by the trusted identity
> > > > > > > > > > > > > > > > > >>>>>        provider.
> > > > > > > > > > > > > > > > > >>>>>        For
> > > > > > > > > > > > > > > > > >>>>>        instance,
> > > > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > > >>>>>        selects a SAML IdP to
> > > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > > >>>>>        with,
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > > > >>>>>        a SAML Response. In this case,
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > >>>>>        prepared
> > > > > > > > > > > > > > > > > >>>>>        to handle a specific federation
> > > > > > > > > > > > > > > > > >>>>>        protocol.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        However, the broker service can
> > > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        completely
> > > > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > > > >>>>>        from the application the
> > > > > > > > > > > > > > > > > >>>>>        protocol
> > > > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > >>>>>        user.
> > > > > > > > > > > > > > > > > >>>>>        In
> > > > > > > > > > > > > > > > > >>>>>        this case, the application will
> > > > > > > > > > > > > > > > > >>>>>        just
> > > > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > >>>>>        after a successful
> > > > > > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        In both cases, the broker acts
> > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > > > > > > > > >>>>>        where
> > > > > > > > > > > > > > > > > >>>>>        specific
> > > > > > > > > > > > > > > > > >>>>>        security policies can be applied
> > > > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > >>>>>        try
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > > >>>>>        themselves against a 3rd party
> > > > > > > > > > > > > > > > > >>>>>        IdP.
> > > > > > > > > > > > > > > > > >>>>>        That
> > > > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > >>>>>        value
> > > > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > > > >>>>>        you think about auditing,
> > > > > > > > > > > > > > > > > >>>>>        authorization
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > > >>>>>        when federation of identities is
> > > > > > > > > > > > > > > > > >>>>>        needed.
> > > > > > > > > > > > > > > > > >>>>>        This
> > > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > > >>>>>        allows
> > > > > > > > > > > > > > > > > >>>>>        existing
> > > > > > > > > > > > > > > > > >>>>>        security infrastructures (eg.:
> > > > > > > > > > > > > > > > > >>>>>        SAML-based
> > > > > > > > > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        benefit
> > > > > > > > > > > > > > > > > >>>>>        from KC's support for cloud,
> > > > > > > > > > > > > > > > > >>>>>        rest
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        mobile
> > > > > > > > > > > > > > > > > >>>>>        use
> > > > > > > > > > > > > > > > > >>>>>        cases.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>        I think this is enough to start
> > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > >>>>>        discussion.
> > > > > > > > > > > > > > > > > >>>>>        I've
> > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > >>>>>        initial
> > > > > > > > > > > > > > > > > >>>>>        discussion with Stian about all
> > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        we
> > > > > > > > > > > > > > > > > >>>>>        agreed
> > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > >>>>>        protocol from applications
> > > > > > > > > > > > > > > > > >>>>>        should
> > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > > > >>>>>        main
> > > > > > > > > > > > > > > > > >>>>>        reason is
> > > > > > > > > > > > > > > > > >>>>>        that it makes life easier for
> > > > > > > > > > > > > > > > > >>>>>        applications
> > > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > > > >>>>>        only
> > > > > > > > > > > > > > > > > >>>>>        need
> > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > >>>>>        know
> > > > > > > > > > > > > > > > > >>>>>        about KC tokens and nothing
> > > > > > > > > > > > > > > > > >>>>>        else.
> > > > > > > > > > > > > > > > > >>>>>        However
> > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > > >>>>>        new
> > > > > > > > > > > > > > > > > >>>>>        requirements around user
> > > > > > > > > > > > > > > > > >>>>>        provisioning
> > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > > > > > > > > >>>>>        resolution
> > > > > > > > > > > > > > > > > >>>>>        or mapping. But that would be
> > > > > > > > > > > > > > > > > >>>>>        another
> > > > > > > > > > > > > > > > > >>>>>        thread.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>> Can you elaborate on "abstract the
> > > > > > > > > > > > > > > > > >>>> protocol
> > > > > > > > > > > > > > > > > >>>> from
> > > > > > > > > > > > > > > > > >>>> applications"?
> > > > > > > > > > > > > > > > > >>>> Not
> > > > > > > > > > > > > > > > > >>>> sure what you mean by that.  IDP
> > > > > > > > > > > > > > > > > >>>> federation
> > > > > > > > > > > > > > > > > >>>> should
> > > > > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > > > > >>>> configured
> > > > > > > > > > > > > > > > > >>>> at
> > > > > > > > > > > > > > > > > >>>> the
> > > > > > > > > > > > > > > > > >>>> realm level and really has nothing to do
> > > > > > > > > > > > > > > > > >>>> with
> > > > > > > > > > > > > > > > > >>>> applications.
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>> I'm really happy that somebody is doing
> > > > > > > > > > > > > > > > > >>>> this.
> > > > > > > > > > > > > > > > > >>>> We're
> > > > > > > > > > > > > > > > > >>>> getting
> > > > > > > > > > > > > > > > > >>>> a
> > > > > > > > > > > > > > > > > >>>> real
> > > > > > > > > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> Sure. What I meant was that the
> > > > > > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > > > > > >>> only
> > > > > > > > > > > > > > > > > >>> knows
> > > > > > > > > > > > > > > > > >>> about
> > > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > > >>> tokens
> > > > > > > > > > > > > > > > > >>> nothing else. It will always receive a KC
> > > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > > >>> regardless
> > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > >>> protocol
> > > > > > > > > > > > > > > > > >>> used
> > > > > > > > > > > > > > > > > >>> to authenticate the user against a 3rd
> > > > > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > > > >>> (saml,
> > > > > > > > > > > > > > > > > >>> oidc,
> > > > > > > > > > > > > > > > > >>> whatever).
> > > > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > > > >>> example I gave was about an user trying
> > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > >>> authenticate
> > > > > > > > > > > > > > > > > >>> against
> > > > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > > > >>> SAML
> > > > > > > > > > > > > > > > > >>> IdP.
> > > > > > > > > > > > > > > > > >>> In this case, after a successful
> > > > > > > > > > > > > > > > > >>> authentication
> > > > > > > > > > > > > > > > > >>> on
> > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > >>> IdP,
> > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > > >>> issue a token to KC. Then KC will
> > > > > > > > > > > > > > > > > >>> validate
> > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > >>> token,
> > > > > > > > > > > > > > > > > >>> perform
> > > > > > > > > > > > > > > > > >>> trust
> > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > >>> security checks, do user provisioning and
> > > > > > > > > > > > > > > > > >>> attribute/claim
> > > > > > > > > > > > > > > > > >>> resolution
> > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > >>> finally issue a KC token and redirect the
> > > > > > > > > > > > > > > > > >>> user
> > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > >>> application.
> > > > > > > > > > > > > > > > > >>> If
> > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > >>> app is configured to use openid in KC
> > > > > > > > > > > > > > > > > >>> then
> > > > > > > > > > > > > > > > > >>> it
> > > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > > >>> receive
> > > > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > > > >>> openid
> > > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> The other scenario is pretty much the
> > > > > > > > > > > > > > > > > >>> same.
> > > > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > > > >>> difference
> > > > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > > > >>> that
> > > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > > >>> not issue its own token but just replay
> > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > > >>> issued
> > > > > > > > > > > > > > > > > >>> by
> > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > >>> 3rd
> > > > > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> I agree that this config goes at the
> > > > > > > > > > > > > > > > > >>> realm
> > > > > > > > > > > > > > > > > >>> level.
> > > > > > > > > > > > > > > > > >>> For
> > > > > > > > > > > > > > > > > >>> instance,
> > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > >>> create
> > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > >>> enable providers for being used. However,
> > > > > > > > > > > > > > > > > >>> I
> > > > > > > > > > > > > > > > > >>> think
> > > > > > > > > > > > > > > > > >>> we
> > > > > > > > > > > > > > > > > >>> would
> > > > > > > > > > > > > > > > > >>> need
> > > > > > > > > > > > > > > > > >>> some
> > > > > > > > > > > > > > > > > >>> specific configuration for applications
> > > > > > > > > > > > > > > > > >>> as
> > > > > > > > > > > > > > > > > >>> well.
> > > > > > > > > > > > > > > > > >>> Specially
> > > > > > > > > > > > > > > > > >>> when
> > > > > > > > > > > > > > > > > >>> defining
> > > > > > > > > > > > > > > > > >>> default roles, mapping attributes.
> > > > > > > > > > > > > > > > > >>> Another
> > > > > > > > > > > > > > > > > >>> example
> > > > > > > > > > > > > > > > > >>> of
> > > > > > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > > > > > >>> config
> > > > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want
> > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > >>> define
> > > > > > > > > > > > > > > > > >>> scopes
> > > > > > > > > > > > > > > > > >>> per-application.
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>> --
> > > > > > > > > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > > > > > > > >>> 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
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From psilva at redhat.com  Fri Dec  5 09:41:49 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 Dec 2014 09:41:49 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1841207631.11425021.1417790213219.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>
	<1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>
	<4760322.11384589.1417788457523.JavaMail.zimbra@redhat.com>
	<711831466.25373681.1417788942317.JavaMail.zimbra@redhat.com>
	<48451523.11412244.1417789433189.JavaMail.zimbra@redhat.com>
	<1535438172.25382344.1417789748360.JavaMail.zimbra@redhat.com>
	<1841207631.11425021.1417790213219.JavaMail.zimbra@redhat.com>
Message-ID: <1028521915.25390433.1417790509554.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, December 5, 2014 12:36:53 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 5 December, 2014 3:29:08 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, December 5, 2014 12:23:53 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 5 December, 2014 3:15:42 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, December 5, 2014 12:07:37 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, 5 December, 2014 2:57:46 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Friday, December 5, 2014 11:43:32 AM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Friday, 5 December, 2014 2:36:14 PM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Friday, December 5, 2014 10:59:08 AM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > Another related thing. We've had a few people ask to be able
> > > > > > > > > to
> > > > > > > > > login
> > > > > > > > > to
> > > > > > > > > Keycloak on mobiles using the native social login mechanism.
> > > > > > > > > 
> > > > > > > > > I think the best way to do that is to use the direct grant
> > > > > > > > > api
> > > > > > > > > and
> > > > > > > > > make
> > > > > > > > > it
> > > > > > > > > possible to call that endpoint passing a IdP id and a token
> > > > > > > > > instead
> > > > > > > > > of
> > > > > > > > > username and password.
> > > > > > > > > 
> > > > > > > > > WDYT?
> > > > > > > > 
> > > > > > > > The broker endpoint expects the idp id in order to start the
> > > > > > > > authentication
> > > > > > > > process. Today, the endpoint also expects KCs authorization
> > > > > > > > code
> > > > > > > > in
> > > > > > > > order
> > > > > > > > to
> > > > > > > > validate requests from clients and use it as a state to
> > > > > > > > validate
> > > > > > > > responses
> > > > > > > > from the trusted idps.
> > > > > > > > 
> > > > > > > > This authorization code is a blocker for this use case, given
> > > > > > > > that
> > > > > > > > mobile
> > > > > > > > don't have this code and just want to start the authentication.
> > > > > > > > 
> > > > > > > > A possible solution would be to change the broker to also
> > > > > > > > accept
> > > > > > > > a
> > > > > > > > client_id
> > > > > > > > to reference the mobile app and perform some validations based
> > > > > > > > on
> > > > > > > > that.
> > > > > > > > Something like that:
> > > > > > > > 
> > > > > > > > 1) Mobile displays a Facebook button
> > > > > > > > 2) User clicks the button and mobile sends a request to KC
> > > > > > > > Broker
> > > > > > > > with
> > > > > > > > the
> > > > > > > > idp id and his client_id.
> > > > > > > > 3) KC Broker checks if the client_id is valid and creates a
> > > > > > > > temporary
> > > > > > > > authorization code.
> > > > > > > > 4) KC Broker redirect mobile to the chosen IdP to perform
> > > > > > > > authentication.
> > > > > > > > 5) KC Broker receives a response from the IdP, generate its own
> > > > > > > > token
> > > > > > > > and
> > > > > > > > send it back to mobile
> > > > > > > > 
> > > > > > > > Makes sense ?
> > > > > > > 
> > > > > > > No that's not the flow I had in mind. Basically the mobile app
> > > > > > > authenticates
> > > > > > > with Facebook through the native mechanisms. The app then has an
> > > > > > > access
> > > > > > > token, which it would send to Keycloak on the direct grant api to
> > > > > > > obtain
> > > > > > > a
> > > > > > > Keycloak token.
> > > > > > 
> > > > > > Ahh, now I get what you mean :)
> > > > > > 
> > > > > > Yes, what you said is enough. Then we just need to validate the
> > > > > > access
> > > > > > token
> > > > > > (eg.: using a tokeninfo endpoint).
> > > > > > 
> > > > > > But I think we can also consider that use case I mentioned. You may
> > > > > > want
> > > > > > to
> > > > > > login without forcing the user to redirect to KC login page.
> > > > > 
> > > > > We could just add a query param to the login url that lets you pick
> > > > > the
> > > > > IdP
> > > > > to use by alias?
> > > > > 
> > > > >   For example auth/.../login?client_id=...&auth_method=google
> > > > 
> > > > Yes, just like my previously example, we need the client_id. The idp
> > > > id/alias
> > > > is already there.
> > > 
> > > Sure, was just saying it should be the same URL as the regular login
> > > page,
> > > but with one extra param to specify the IdP.
> > > 
> > > > 
> > > > Btw, regarding SAML. SAML does not provide a "validation" endpoint like
> > > > oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the
> > > > specs for that. What can be done here is validate SAML assertions
> > > > against
> > > > a
> > > > WS-Trust STS. Or just trust the assertion based on the signature and
> > > > others
> > > > standards info along it.
> > > > 
> > > > We can also take a closer look at the oAuth2 SAML bearer token profile
> > > > and
> > > > see if it helps.
> > > 
> > > If we could have it for social and OpenID Connect providers for now
> > > that'd
> > > be
> > > good.
> > 
> > Deal. I'll do that.
> > 
> > What about that use case I mentioned ? The one about mobile asking to
> > broker
> > (not previously issued access_token) an identity provider ?
> 
> Sounds like a nice feature, but I'm not sure if anyone would use it. It also
> has a bit of an issue related to adapters, as they would have to have some
> support for it. For example we added a while back the login_hint query param
> from OpenID Connect, which is really only usable from the JS adapter
> currently.

How does mobile authenticate with KC today ? Users are redirect to KC login page in a web view ?

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Same for other identity providers, the assumption is the app has
> > > > > > > an
> > > > > > > out
> > > > > > > of
> > > > > > > bounds mechanism to obtain an access token, which is then sent to
> > > > > > > Keycloak
> > > > > > > over the direct grant api.
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Friday, 5 December, 2014 1:45:24 PM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > Looks good. I reckon we can combine the two pages. What
> > > > > > > > > > > about
> > > > > > > > > > > if
> > > > > > > > > > > the
> > > > > > > > > > > 'Add
> > > > > > > > > > > provider' drop-down is:
> > > > > > > > > > > 
> > > > > > > > > > >   OpenID
> > > > > > > > > > >   SAML
> > > > > > > > > > >   ------
> > > > > > > > > > >   Google
> > > > > > > > > > >   GitHub
> > > > > > > > > > >   Facebook
> > > > > > > > > > >   Twitter
> > > > > > > > > > > 
> > > > > > > > > > > Let's drop social on/off and instead have a
> > > > > > > > > > > enable/disable
> > > > > > > > > > > button
> > > > > > > > > > > on
> > > > > > > > > > > each
> > > > > > > > > > > provider.
> > > > > > > > > > 
> > > > > > > > > > Sure.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Also, would be nice if users could set a name or alias
> > > > > > > > > > > for
> > > > > > > > > > > a
> > > > > > > > > > > provider
> > > > > > > > > > > instance. This would make the callback url easier to use
> > > > > > > > > > > (instead
> > > > > > > > > > > of
> > > > > > > > > > > callback/<UUID> it's callback/<alias>). The user
> > > > > > > > > > > federation
> > > > > > > > > > > providers
> > > > > > > > > > > have
> > > > > > > > > > > this.
> > > > > > > > > > 
> > > > > > > > > > One of my first tries was using an alias, just like that.
> > > > > > > > > > But
> > > > > > > > > > I
> > > > > > > > > > preferred
> > > > > > > > > > using the UUID and make the configuration more easier.
> > > > > > > > > > Beside
> > > > > > > > > > that,
> > > > > > > > > > the
> > > > > > > > > > callback url is just a copy and paste, so I think an alias
> > > > > > > > > > would
> > > > > > > > > > not
> > > > > > > > > > bring
> > > > > > > > > > so much usability, but add one more step when configuring
> > > > > > > > > > providers.
> > > > > > > > > > 
> > > > > > > > > > However, if this is an usability requirement for KC I can
> > > > > > > > > > change
> > > > > > > > > > that.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > In one of our last discussions, you suggested to leave
> > > > > > > > > > > > Social
> > > > > > > > > > > > as
> > > > > > > > > > > > it
> > > > > > > > > > > > is.
> > > > > > > > > > > > Although IMO I think we can have a single place to
> > > > > > > > > > > > manage
> > > > > > > > > > > > both
> > > > > > > > > > > > social
> > > > > > > > > > > > and
> > > > > > > > > > > > user-defined identity providers. Social ones are just
> > > > > > > > > > > > OOTB
> > > > > > > > > > > > and
> > > > > > > > > > > > pre-configured identity providers now.
> > > > > > > > > > > > 
> > > > > > > > > > > > That said, today I'm using separated tabs for social
> > > > > > > > > > > > and
> > > > > > > > > > > > user-defined.
> > > > > > > > > > > > Please, take a look at [1] for more details on how the
> > > > > > > > > > > > UI
> > > > > > > > > > > > looks
> > > > > > > > > > > > like.
> > > > > > > > > > > > 
> > > > > > > > > > > > I've changed social UI a bit in order to provide a
> > > > > > > > > > > > specific
> > > > > > > > > > > > page
> > > > > > > > > > > > for
> > > > > > > > > > > > create/update. I've also added a "Show Secret" link to
> > > > > > > > > > > > display
> > > > > > > > > > > > the
> > > > > > > > > > > > client_secret in clear text if user wants to.
> > > > > > > > > > > > 
> > > > > > > > > > > > Beside the enable/disable button, I think another good
> > > > > > > > > > > > thing
> > > > > > > > > > > > to
> > > > > > > > > > > > do
> > > > > > > > > > > > is
> > > > > > > > > > > > specify
> > > > > > > > > > > > a default role(s) for each provider. That can be useful
> > > > > > > > > > > > if
> > > > > > > > > > > > applications
> > > > > > > > > > > > want
> > > > > > > > > > > > to perform any kind of authorization based on the
> > > > > > > > > > > > identity
> > > > > > > > > > > > provider
> > > > > > > > > > > > or
> > > > > > > > > > > > authentication method used to authenticate an user
> > > > > > > > > > > > (eg.:
> > > > > > > > > > > > useful
> > > > > > > > > > > > for
> > > > > > > > > > > > adaptative or multi-level access control). We can also
> > > > > > > > > > > > use
> > > > > > > > > > > > the
> > > > > > > > > > > > "amr"
> > > > > > > > > > > > claim
> > > > > > > > > > > > in the ID Token, which seems KC is not considering at
> > > > > > > > > > > > all.
> > > > > > > > > > > > The
> > > > > > > > > > > > latter
> > > > > > > > > > > > is
> > > > > > > > > > > > an
> > > > > > > > > > > > important thing to think of, regardless this broker
> > > > > > > > > > > > work
> > > > > > > > > > > > I'm
> > > > > > > > > > > > doing.
> > > > > > > > > > > > 
> > > > > > > > > > > > [1]
> > > > > > > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > Having a separate enable/disable for each provider
> > > > > > > > > > > > would
> > > > > > > > > > > > be
> > > > > > > > > > > > good.
> > > > > > > > > > > > If
> > > > > > > > > > > > you're
> > > > > > > > > > > > leaving the social tab as is and adding a separate tab
> > > > > > > > > > > > for
> > > > > > > > > > > > configuring
> > > > > > > > > > > > brokered idp's then we should leave the social
> > > > > > > > > > > > enable/disable
> > > > > > > > > > > > button,
> > > > > > > > > > > > otherwise it depends how it'll look like in the end.
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    Social has a button to enable/disable it. I'm
> > > > > > > > > > > > >    wondering
> > > > > > > > > > > > >    what
> > > > > > > > > > > > >    to
> > > > > > > > > > > > >    do
> > > > > > > > > > > > >    with
> > > > > > > > > > > > >    the brokered identity providers. Shall we add a
> > > > > > > > > > > > >    similar
> > > > > > > > > > > > >    flag
> > > > > > > > > > > > >    for
> > > > > > > > > > > > >    that
> > > > > > > > > > > > >    ?
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    I was also wondering if the best would be a flag
> > > > > > > > > > > > >    in
> > > > > > > > > > > > >    a
> > > > > > > > > > > > >    per
> > > > > > > > > > > > >    provider
> > > > > > > > > > > > >    basis.
> > > > > > > > > > > > >    So we can disable/enable a specific provider
> > > > > > > > > > > > >    (social
> > > > > > > > > > > > >    or
> > > > > > > > > > > > >    brokered),
> > > > > > > > > > > > >    instead of doing that for all.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I'll go for it then. Will remove the icon url
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > model
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > leave
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > for users if they want to provide icons for their
> > > > > > > > > > > > > > > identity
> > > > > > > > > > > > > > > providers.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > My point is that icons can be usually served by
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > same
> > > > > > > > > > > > > > > server/application
> > > > > > > > > > > > > > > or proxy, so download images are not such a big
> > > > > > > > > > > > > > > deal.
> > > > > > > > > > > > > > > Also,
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > icon
> > > > > > > > > > > > > > > url
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > part of the freemarker model and people can do
> > > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > ever
> > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > want
> > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > it.
> > > > > > > > > > > > > > > What I think will also help in your future plans.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I'm not following. Are you saying that if a named
> > > > > > > > > > > > > > image
> > > > > > > > > > > > > > 'my-provider.png'
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > loaded from a theme, then you can override it in
> > > > > > > > > > > > > > another
> > > > > > > > > > > > > > theme?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > If so, that's basically the same as having a css
> > > > > > > > > > > > > > class
> > > > > > > > > > > > > > 'my-provider'
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > theme. With the exception that with an image you
> > > > > > > > > > > > > > end
> > > > > > > > > > > > > > up
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > having
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > require a image per provider per theme per
> > > > > > > > > > > > > > language,
> > > > > > > > > > > > > > which
> > > > > > > > > > > > > > could
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > lot
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > images for a single provider. Also, buttons for
> > > > > > > > > > > > > > accessibility
> > > > > > > > > > > > > > should
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > defined with text and css, not images that can't be
> > > > > > > > > > > > > > interpreted.
> > > > > > > > > > > > > > You
> > > > > > > > > > > > > > also
> > > > > > > > > > > > > > still need to modify the theme, so I don't see any
> > > > > > > > > > > > > > benefits.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > You are right. Having a icon url per provider does
> > > > > > > > > > > > > not
> > > > > > > > > > > > > makes
> > > > > > > > > > > > > sense
> > > > > > > > > > > > > if
> > > > > > > > > > > > > there
> > > > > > > > > > > > > are requirements to change images accordingly to a
> > > > > > > > > > > > > theme
> > > > > > > > > > > > > or
> > > > > > > > > > > > > language.
> > > > > > > > > > > > > CSS
> > > > > > > > > > > > > makes life easier.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Will remove that property from the model.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Users can now specify a Icon Url to be rendered
> > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > login
> > > > > > > > > > > > > > > > page
> > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > social
> > > > > > > > > > > > > > > > or any other identity provider is configured.
> > > > > > > > > > > > > > > > So
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > just
> > > > > > > > > > > > > > > > load
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > image
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > url entered by the user.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Are you saying that users should change the
> > > > > > > > > > > > > > > > theme
> > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > customize
> > > > > > > > > > > > > > > > css
> > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > only want to change an icon for a provider ?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Yes, there's many issues with having a icon url:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > * Won't work for internationalization - we don't
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > now,
> > > > > > > > > > > > > > > but
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > * Image is not a good button - CSS is much better
> > > > > > > > > > > > > > > * Doesn't support themes - we allow users to
> > > > > > > > > > > > > > > switch
> > > > > > > > > > > > > > > l&f
> > > > > > > > > > > > > > > by
> > > > > > > > > > > > > > > switching
> > > > > > > > > > > > > > > themes,
> > > > > > > > > > > > > > > but that won't work for a icon url. In the future
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > may
> > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > multiple themes per-realm, for example to
> > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > devices
> > > > > > > > > > > > > > > (one
> > > > > > > > > > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > > > > > > > > > * Requires the URL to be hosted somewhere - why
> > > > > > > > > > > > > > > require
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > separate
> > > > > > > > > > > > > > > call
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > download an image (to a separate server maybe) if
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > can
> > > > > > > > > > > > > > > simply
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > defined
> > > > > > > > > > > > > > > in a single CSS file?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Rather than add additional places to define look
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > feel
> > > > > > > > > > > > > > > components
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > should in the future make it easier to
> > > > > > > > > > > > > > > add/customize
> > > > > > > > > > > > > > > themes.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > All look and feel related things including
> > > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > stylesheets
> > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > part of themes. This is to allow customizing
> > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > theme.
> > > > > > > > > > > > > > > > Also,
> > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > image is not the correct way to render a
> > > > > > > > > > > > > > > > button,
> > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > defined
> > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > CSS.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > You shouldn't have icon images for social
> > > > > > > > > > > > > > > > > providers.
> > > > > > > > > > > > > > > > > They
> > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > specified
> > > > > > > > > > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > > From: "Pedro Igor Silva"
> > > > > > > > > > > > > > > > > > <psilva at redhat.com>
> > > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM
> > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >     Anyone know where I can get the icons
> > > > > > > > > > > > > > > > > >     images
> > > > > > > > > > > > > > > > > >     for
> > > > > > > > > > > > > > > > > >     social
> > > > > > > > > > > > > > > > > >     providers
> > > > > > > > > > > > > > > > > >     ?
> > > > > > > > > > > > > > > > > >     It
> > > > > > > > > > > > > > > > > >     seems zocial defines them encoded in
> > > > > > > > > > > > > > > > > >     some
> > > > > > > > > > > > > > > > > >     way
> > > > > > > > > > > > > > > > > >     in
> > > > > > > > > > > > > > > > > >     CSS.
> > > > > > > > > > > > > > > > > >     I
> > > > > > > > > > > > > > > > > >     need
> > > > > > > > > > > > > > > > > >     that
> > > > > > > > > > > > > > > > > >     to
> > > > > > > > > > > > > > > > > >     provide default images if user does not
> > > > > > > > > > > > > > > > > >     specify
> > > > > > > > > > > > > > > > > >     their
> > > > > > > > > > > > > > > > > >     own.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >     Or is still possible to use zocial ones
> > > > > > > > > > > > > > > > > >     ?
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > > From: "Pedro Igor Silva"
> > > > > > > > > > > > > > > > > > <psilva at redhat.com>
> > > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38
> > > > > > > > > > > > > > > > > > PM
> > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >    I've done some initial work covering
> > > > > > > > > > > > > > > > > >    both
> > > > > > > > > > > > > > > > > >    persistence
> > > > > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > > > > >    brokering.
> > > > > > > > > > > > > > > > > >    No
> > > > > > > > > > > > > > > > > >    UI, yet. I'm focused on the model, rest
> > > > > > > > > > > > > > > > > >    api
> > > > > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > > > > >    brokering
> > > > > > > > > > > > > > > > > >    functionality
> > > > > > > > > > > > > > > > > >    for now.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >    What I have is enough to decide if we
> > > > > > > > > > > > > > > > > >    are
> > > > > > > > > > > > > > > > > >    aligned
> > > > > > > > > > > > > > > > > >    about
> > > > > > > > > > > > > > > > > >    this
> > > > > > > > > > > > > > > > > >    functionality. So you can understand how
> > > > > > > > > > > > > > > > > >    the
> > > > > > > > > > > > > > > > > >    model
> > > > > > > > > > > > > > > > > >    (and
> > > > > > > > > > > > > > > > > >    persistence),
> > > > > > > > > > > > > > > > > >    rest api and brokering functionality
> > > > > > > > > > > > > > > > > >    looks
> > > > > > > > > > > > > > > > > >    like.
> > > > > > > > > > > > > > > > > >    Can
> > > > > > > > > > > > > > > > > >    we
> > > > > > > > > > > > > > > > > >    schedule
> > > > > > > > > > > > > > > > > >    a
> > > > > > > > > > > > > > > > > >    meeting ?
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49
> > > > > > > > > > > > > > > > > > PM
> > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Currently adapters can only make authz
> > > > > > > > > > > > > > > > > > decisions
> > > > > > > > > > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > on either realm roles or the roles of one
> > > > > > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > > > > > application.
> > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > related to 1) too.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw Dawidowicz
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > 1) Sounds like something definitely worth
> > > > > > > > > > > > > > > > > > > aiming
> > > > > > > > > > > > > > > > > > > for.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >> I just wanted to quickly list the
> > > > > > > > > > > > > > > > > > >> additional
> > > > > > > > > > > > > > > > > > >> work
> > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > >> discussed
> > > > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > > > >> everyone
> > > > > > > > > > > > > > > > > > >> can think about it (in no particular
> > > > > > > > > > > > > > > > > > >> order):
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal
> > > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > >> a KC token? For example an external
> > > > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > > >> attribute
> > > > > > > > > > > > > > > > > > >> 'group'
> > > > > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > > > > >> contains 'sales' and 'manager' could be
> > > > > > > > > > > > > > > > > > >> mapped
> > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > >> 'manager'
> > > > > > > > > > > > > > > > > > >> role
> > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > >> 'sales app in a KC token. Could we use
> > > > > > > > > > > > > > > > > > >> Drools?
> > > > > > > > > > > > > > > > > > >> This
> > > > > > > > > > > > > > > > > > >> could
> > > > > > > > > > > > > > > > > > >> also
> > > > > > > > > > > > > > > > > > >> be
> > > > > > > > > > > > > > > > > > >> used
> > > > > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > > > > >> user federation to allow more complex
> > > > > > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > > > >> roles/groups
> > > > > > > > > > > > > > > > > > >> than
> > > > > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > > > > >> simple 1-1
> > > > > > > > > > > > > > > > > > >> 2) Retrieving tokens - if an application
> > > > > > > > > > > > > > > > > > >> wants
> > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > >> retrieve
> > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > > >> token (for example to view Facebook
> > > > > > > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > > > > > > >> if
> > > > > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > > > > >> logged
> > > > > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > > >> Facebook)
> > > > > > > > > > > > > > > > > > >> 3) Configure scope - currently for
> > > > > > > > > > > > > > > > > > >> social
> > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > >> only
> > > > > > > > > > > > > > > > > > >> request
> > > > > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > > > > >> very
> > > > > > > > > > > > > > > > > > >> limited
> > > > > > > > > > > > > > > > > > >> scope (basic profile and email), to for
> > > > > > > > > > > > > > > > > > >> example
> > > > > > > > > > > > > > > > > > >> view
> > > > > > > > > > > > > > > > > > >> Facebook
> > > > > > > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > > > > > > > > > >> 4) Selecting provider - currently in
> > > > > > > > > > > > > > > > > > >> social
> > > > > > > > > > > > > > > > > > >> (and
> > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > >> first
> > > > > > > > > > > > > > > > > > >> pass
> > > > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > > > >> brokering) we have an icon user has to
> > > > > > > > > > > > > > > > > > >> select,
> > > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > > >> can
> > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > >> provider in a different way (for example
> > > > > > > > > > > > > > > > > > >> ask
> > > > > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > >> email,
> > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > > > > >> based on email domain)
> > > > > > > > > > > > > > > > > > >> 5) Gateway - don't create a KC token,
> > > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > > >> just
> > > > > > > > > > > > > > > > > > >> forward
> > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >> IMO 1) is a killer feature, as it would
> > > > > > > > > > > > > > > > > > >> allow
> > > > > > > > > > > > > > > > > > >> companies
> > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > >> add
> > > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > > >> users without having to modify their
> > > > > > > > > > > > > > > > > > >> applications.
> > > > > > > > > > > > > > > > > > >> Issue
> > > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > > >> 5)
> > > > > > > > > > > > > > > > > > >> is
> > > > > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > > > > >> applications need to understand more
> > > > > > > > > > > > > > > > > > >> than
> > > > > > > > > > > > > > > > > > >> one
> > > > > > > > > > > > > > > > > > >> token,
> > > > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > > > >> would
> > > > > > > > > > > > > > > > > > >> require
> > > > > > > > > > > > > > > > > > >> rewriting applications.
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >> This work is also somewhat related to
> > > > > > > > > > > > > > > > > > >> other
> > > > > > > > > > > > > > > > > > >> authentication
> > > > > > > > > > > > > > > > > > >> mechanisms
> > > > > > > > > > > > > > > > > > >> (for
> > > > > > > > > > > > > > > > > > >> example Kerberos ticket, LDAP and
> > > > > > > > > > > > > > > > > > >> passwordless).
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > > > > > > > > > >>> From: "Pedro Igor Silva"
> > > > > > > > > > > > > > > > > > >>> <psilva at redhat.com>
> > > > > > > > > > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014
> > > > > > > > > > > > > > > > > > >>> 8:27:58
> > > > > > > > > > > > > > > > > > >>> PM
> > > > > > > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > >>> Identity
> > > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > > >>> Authentication
> > > > > > > > > > > > > > > > > > >>> Broker
> > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > > > > > > > > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014
> > > > > > > > > > > > > > > > > > >>>> 4:39:52
> > > > > > > > > > > > > > > > > > >>>> PM
> > > > > > > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > >>>> Identity
> > > > > > > > > > > > > > > > > > >>>> and
> > > > > > > > > > > > > > > > > > >>>> Authentication
> > > > > > > > > > > > > > > > > > >>>> Broker
> > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor
> > > > > > > > > > > > > > > > > > >>>> Silva
> > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > >>>>> Hi,
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        Would like to start a
> > > > > > > > > > > > > > > > > > >>>>>        discussion
> > > > > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        enable
> > > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > >>>>>        Authentication Broker in order
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > > > > > >>>>>        Chained
> > > > > > > > > > > > > > > > > > >>>>>        Federation
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        also Identity Federation.
> > > > > > > > > > > > > > > > > > >>>>>        First
> > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > >>>>>        all,
> > > > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > > > >>>>>        background
> > > > > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > > > > >>>>>        what
> > > > > > > > > > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        Currently KeyCloak provides
> > > > > > > > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > > > > >>>>>        types
> > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > > >>>>>        (correct
> > > > > > > > > > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>            1) Local authentication
> > > > > > > > > > > > > > > > > > >>>>>            (based
> > > > > > > > > > > > > > > > > > >>>>>            on
> > > > > > > > > > > > > > > > > > >>>>>            some
> > > > > > > > > > > > > > > > > > >>>>>            credential
> > > > > > > > > > > > > > > > > > >>>>>            type
> > > > > > > > > > > > > > > > > > >>>>>            enabled
> > > > > > > > > > > > > > > > > > >>>>>            to
> > > > > > > > > > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        Local authentication is about
> > > > > > > > > > > > > > > > > > >>>>>        authenticating
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > > > >>>>>        locally
> > > > > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > > > > >>>>>        KC's own identity store.
> > > > > > > > > > > > > > > > > > >>>>>        Nothing
> > > > > > > > > > > > > > > > > > >>>>>        special
> > > > > > > > > > > > > > > > > > >>>>>        here.
> > > > > > > > > > > > > > > > > > >>>>>        And
> > > > > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > > > > >>>>>        Authentication which allows
> > > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        choose
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > > > > > > > >>>>>        to authenticate with. In this
> > > > > > > > > > > > > > > > > > >>>>>        case,
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > >>>>>        always
> > > > > > > > > > > > > > > > > > >>>>>        one
> > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        built-in social providers
> > > > > > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > > > > > > > > > >>>>>        Google,
> > > > > > > > > > > > > > > > > > >>>>>        Twitter, Github and so forth.
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        When doing social, the user is
> > > > > > > > > > > > > > > > > > >>>>>        automatically
> > > > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > > >>>>>        identity store after a
> > > > > > > > > > > > > > > > > > >>>>>        successful
> > > > > > > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > > > >>>>>        does
> > > > > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > > > > >>>>>        need to fill a registration
> > > > > > > > > > > > > > > > > > >>>>>        form
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > >>>>>        very
> > > > > > > > > > > > > > > > > > >>>>>        quickly. During the
> > > > > > > > > > > > > > > > > > >>>>>        provisioning
> > > > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > > > > > > > > > >>>>>        from the social provider such
> > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > >>>>>        email,
> > > > > > > > > > > > > > > > > > >>>>>        firstname
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > > > > >>>>>        These
> > > > > > > > > > > > > > > > > > >>>>>        are very basic information,
> > > > > > > > > > > > > > > > > > >>>>>        any
> > > > > > > > > > > > > > > > > > >>>>>        other
> > > > > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > > > > >>>>>        related with authorization
> > > > > > > > > > > > > > > > > > >>>>>        policies
> > > > > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > > > > >>>>>        eg.:
> > > > > > > > > > > > > > > > > > >>>>>        roles
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        groups
> > > > > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > >>>>>        defined later via KC's admin
> > > > > > > > > > > > > > > > > > >>>>>        console.
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        Another important
> > > > > > > > > > > > > > > > > > >>>>>        characteristic
> > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        application receives a KC
> > > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > > > > >>>>>        issued by
> > > > > > > > > > > > > > > > > > >>>>>        the social IdP during the
> > > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > > >>>>>        process.
> > > > > > > > > > > > > > > > > > >>>>>        If
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > >>>>>        wants to consume resources
> > > > > > > > > > > > > > > > > > >>>>>        from
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        resource
> > > > > > > > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > > > > > > > >>>>>        he
> > > > > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > > > > >>>>>        authenticated it must obtain
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > > > > >>>>>        itself
> > > > > > > > > > > > > > > > > > >>>>>        prior
> > > > > > > > > > > > > > > > > > >>>>>        to invoke the resource
> > > > > > > > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > > > > > > > >>>>>        API.
> > > > > > > > > > > > > > > > > > >>>>>        Assuming
> > > > > > > > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > > >>>>>        providers are based on oAuth
> > > > > > > > > > > > > > > > > > >>>>>        1.0
> > > > > > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > > > > > >>>>>        2.0.
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        That said, the Authentication
> > > > > > > > > > > > > > > > > > >>>>>        Broker
> > > > > > > > > > > > > > > > > > >>>>>        functionality
> > > > > > > > > > > > > > > > > > >>>>>        aims
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        cover
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        same use cases but with a lot
> > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > >>>>>        more
> > > > > > > > > > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > > > > > > > > > >>>>>        on
> > > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > > > > > > >>>>>        setup
> > > > > > > > > > > > > > > > > > >>>>>        identity providers(not only
> > > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > > >>>>>        ones)
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > > > > > >>>>>        protocols they may support
> > > > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > >>>>>        SAML,
> > > > > > > > > > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > > > > >>>>>        This is useful when an
> > > > > > > > > > > > > > > > > > >>>>>        enterprise
> > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > >>>>>        providing
> > > > > > > > > > > > > > > > > > >>>>>        services
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > > > >>>>>        customers(IdP) and does not
> > > > > > > > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        manage
> > > > > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > > > > >>>>>        relationships. When using a
> > > > > > > > > > > > > > > > > > >>>>>        broker,
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > > >>>>>        steps
> > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > >>>>>        pretty much the same when you
> > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > > > > > > > > > >>>>>        with
> > > > > > > > > > > > > > > > > > >>>>>        important differences on how
> > > > > > > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > > > > > > >>>>>        support
> > > > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > > > > > > > > >>>>>        providers, different
> > > > > > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > > > > > >>>>>        protocols,
> > > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > > > >>>>>        and how claims and attributes
> > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > >>>>>        resolved.
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        The brokering functionality
> > > > > > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > >>>>>        done
> > > > > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > > > > > > > >>>>>        ways
> > > > > > > > > > > > > > > > > > >>>>>        depending
> > > > > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        broker service is acting as a
> > > > > > > > > > > > > > > > > > >>>>>        gateway
> > > > > > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > > > > > >>>>>        not.
> > > > > > > > > > > > > > > > > > >>>>>        When
> > > > > > > > > > > > > > > > > > >>>>>        acting
> > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > > >>>>>        gateway, the broker will
> > > > > > > > > > > > > > > > > > >>>>>        respond
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        same
> > > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > > >>>>>        issued by the trusted identity
> > > > > > > > > > > > > > > > > > >>>>>        provider.
> > > > > > > > > > > > > > > > > > >>>>>        For
> > > > > > > > > > > > > > > > > > >>>>>        instance,
> > > > > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > > > >>>>>        selects a SAML IdP to
> > > > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > > > >>>>>        with,
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > > > > >>>>>        a SAML Response. In this case,
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > >>>>>        prepared
> > > > > > > > > > > > > > > > > > >>>>>        to handle a specific
> > > > > > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > > > > > >>>>>        protocol.
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        However, the broker service
> > > > > > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        completely
> > > > > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > > > > >>>>>        from the application the
> > > > > > > > > > > > > > > > > > >>>>>        protocol
> > > > > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > >>>>>        user.
> > > > > > > > > > > > > > > > > > >>>>>        In
> > > > > > > > > > > > > > > > > > >>>>>        this case, the application
> > > > > > > > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > > > > > > > >>>>>        just
> > > > > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > > >>>>>        after a successful
> > > > > > > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        In both cases, the broker acts
> > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > > > > > > > > > >>>>>        where
> > > > > > > > > > > > > > > > > > >>>>>        specific
> > > > > > > > > > > > > > > > > > >>>>>        security policies can be
> > > > > > > > > > > > > > > > > > >>>>>        applied
> > > > > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > > >>>>>        try
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > > > >>>>>        themselves against a 3rd party
> > > > > > > > > > > > > > > > > > >>>>>        IdP.
> > > > > > > > > > > > > > > > > > >>>>>        That
> > > > > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > >>>>>        value
> > > > > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > > > > >>>>>        you think about auditing,
> > > > > > > > > > > > > > > > > > >>>>>        authorization
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > > > >>>>>        when federation of identities
> > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > >>>>>        needed.
> > > > > > > > > > > > > > > > > > >>>>>        This
> > > > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > > > >>>>>        allows
> > > > > > > > > > > > > > > > > > >>>>>        existing
> > > > > > > > > > > > > > > > > > >>>>>        security infrastructures (eg.:
> > > > > > > > > > > > > > > > > > >>>>>        SAML-based
> > > > > > > > > > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        benefit
> > > > > > > > > > > > > > > > > > >>>>>        from KC's support for cloud,
> > > > > > > > > > > > > > > > > > >>>>>        rest
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        mobile
> > > > > > > > > > > > > > > > > > >>>>>        use
> > > > > > > > > > > > > > > > > > >>>>>        cases.
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>>        I think this is enough to
> > > > > > > > > > > > > > > > > > >>>>>        start
> > > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > > >>>>>        discussion.
> > > > > > > > > > > > > > > > > > >>>>>        I've
> > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > >>>>>        initial
> > > > > > > > > > > > > > > > > > >>>>>        discussion with Stian about
> > > > > > > > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        we
> > > > > > > > > > > > > > > > > > >>>>>        agreed
> > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > >>>>>        protocol from applications
> > > > > > > > > > > > > > > > > > >>>>>        should
> > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > > > > >>>>>        main
> > > > > > > > > > > > > > > > > > >>>>>        reason is
> > > > > > > > > > > > > > > > > > >>>>>        that it makes life easier for
> > > > > > > > > > > > > > > > > > >>>>>        applications
> > > > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > > > > >>>>>        only
> > > > > > > > > > > > > > > > > > >>>>>        need
> > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > >>>>>        know
> > > > > > > > > > > > > > > > > > >>>>>        about KC tokens and nothing
> > > > > > > > > > > > > > > > > > >>>>>        else.
> > > > > > > > > > > > > > > > > > >>>>>        However
> > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > > > >>>>>        new
> > > > > > > > > > > > > > > > > > >>>>>        requirements around user
> > > > > > > > > > > > > > > > > > >>>>>        provisioning
> > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > > > > > > > > > >>>>>        resolution
> > > > > > > > > > > > > > > > > > >>>>>        or mapping. But that would be
> > > > > > > > > > > > > > > > > > >>>>>        another
> > > > > > > > > > > > > > > > > > >>>>>        thread.
> > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > >>>> Can you elaborate on "abstract the
> > > > > > > > > > > > > > > > > > >>>> protocol
> > > > > > > > > > > > > > > > > > >>>> from
> > > > > > > > > > > > > > > > > > >>>> applications"?
> > > > > > > > > > > > > > > > > > >>>> Not
> > > > > > > > > > > > > > > > > > >>>> sure what you mean by that.  IDP
> > > > > > > > > > > > > > > > > > >>>> federation
> > > > > > > > > > > > > > > > > > >>>> should
> > > > > > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > > > > > >>>> configured
> > > > > > > > > > > > > > > > > > >>>> at
> > > > > > > > > > > > > > > > > > >>>> the
> > > > > > > > > > > > > > > > > > >>>> realm level and really has nothing to
> > > > > > > > > > > > > > > > > > >>>> do
> > > > > > > > > > > > > > > > > > >>>> with
> > > > > > > > > > > > > > > > > > >>>> applications.
> > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > >>>> I'm really happy that somebody is
> > > > > > > > > > > > > > > > > > >>>> doing
> > > > > > > > > > > > > > > > > > >>>> this.
> > > > > > > > > > > > > > > > > > >>>> We're
> > > > > > > > > > > > > > > > > > >>>> getting
> > > > > > > > > > > > > > > > > > >>>> a
> > > > > > > > > > > > > > > > > > >>>> real
> > > > > > > > > > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > >>> Sure. What I meant was that the
> > > > > > > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > > > > > > >>> only
> > > > > > > > > > > > > > > > > > >>> knows
> > > > > > > > > > > > > > > > > > >>> about
> > > > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > > > >>> tokens
> > > > > > > > > > > > > > > > > > >>> nothing else. It will always receive a
> > > > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > > > >>> regardless
> > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > >>> protocol
> > > > > > > > > > > > > > > > > > >>> used
> > > > > > > > > > > > > > > > > > >>> to authenticate the user against a 3rd
> > > > > > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > > > > >>> (saml,
> > > > > > > > > > > > > > > > > > >>> oidc,
> > > > > > > > > > > > > > > > > > >>> whatever).
> > > > > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > > > > >>> example I gave was about an user trying
> > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > >>> authenticate
> > > > > > > > > > > > > > > > > > >>> against
> > > > > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > > > > >>> SAML
> > > > > > > > > > > > > > > > > > >>> IdP.
> > > > > > > > > > > > > > > > > > >>> In this case, after a successful
> > > > > > > > > > > > > > > > > > >>> authentication
> > > > > > > > > > > > > > > > > > >>> on
> > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > >>> IdP,
> > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > > > >>> issue a token to KC. Then KC will
> > > > > > > > > > > > > > > > > > >>> validate
> > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > >>> token,
> > > > > > > > > > > > > > > > > > >>> perform
> > > > > > > > > > > > > > > > > > >>> trust
> > > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > > >>> security checks, do user provisioning
> > > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > > >>> attribute/claim
> > > > > > > > > > > > > > > > > > >>> resolution
> > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > >>> finally issue a KC token and redirect
> > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > >>> user
> > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > >>> application.
> > > > > > > > > > > > > > > > > > >>> If
> > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > >>> app is configured to use openid in KC
> > > > > > > > > > > > > > > > > > >>> then
> > > > > > > > > > > > > > > > > > >>> it
> > > > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > > > >>> receive
> > > > > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > > > > >>> openid
> > > > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > >>> The other scenario is pretty much the
> > > > > > > > > > > > > > > > > > >>> same.
> > > > > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > > > > >>> difference
> > > > > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > > > > >>> that
> > > > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > > > >>> not issue its own token but just replay
> > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > > > >>> issued
> > > > > > > > > > > > > > > > > > >>> by
> > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > >>> 3rd
> > > > > > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > >>> I agree that this config goes at the
> > > > > > > > > > > > > > > > > > >>> realm
> > > > > > > > > > > > > > > > > > >>> level.
> > > > > > > > > > > > > > > > > > >>> For
> > > > > > > > > > > > > > > > > > >>> instance,
> > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > >>> create
> > > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > > >>> enable providers for being used.
> > > > > > > > > > > > > > > > > > >>> However,
> > > > > > > > > > > > > > > > > > >>> I
> > > > > > > > > > > > > > > > > > >>> think
> > > > > > > > > > > > > > > > > > >>> we
> > > > > > > > > > > > > > > > > > >>> would
> > > > > > > > > > > > > > > > > > >>> need
> > > > > > > > > > > > > > > > > > >>> some
> > > > > > > > > > > > > > > > > > >>> specific configuration for applications
> > > > > > > > > > > > > > > > > > >>> as
> > > > > > > > > > > > > > > > > > >>> well.
> > > > > > > > > > > > > > > > > > >>> Specially
> > > > > > > > > > > > > > > > > > >>> when
> > > > > > > > > > > > > > > > > > >>> defining
> > > > > > > > > > > > > > > > > > >>> default roles, mapping attributes.
> > > > > > > > > > > > > > > > > > >>> Another
> > > > > > > > > > > > > > > > > > >>> example
> > > > > > > > > > > > > > > > > > >>> of
> > > > > > > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > > > > > > >>> config
> > > > > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may
> > > > > > > > > > > > > > > > > > >>> want
> > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > >>> define
> > > > > > > > > > > > > > > > > > >>> scopes
> > > > > > > > > > > > > > > > > > >>> per-application.
> > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > >>>> --
> > > > > > > > > > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > > > > > > > > >>> 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
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From stian at redhat.com  Fri Dec  5 09:43:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 09:43:44 -0500 (EST)
Subject: [keycloak-dev] vision vs. infinite configurability
In-Reply-To: <5481B9BB.9080403@redhat.com>
References: <5481B9BB.9080403@redhat.com>
Message-ID: <758730704.11430388.1417790624943.JavaMail.zimbra@redhat.com>

+1000

We shouldn't just blindly throw in new features, now matter how small they are. Most mature projects out there probably have more undocumented and unused features than they have documented and used.

Having a rule that all features should be documented and tested goes some way to prevent this. If you can't be asked to document and test something, chances are we don't need it!

Besides that, I'm a strong believer in "the team knows best" so most things, no matter how small they are, should be mentioned on the mailing list IMO.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 2:57:15 PM
> Subject: [keycloak-dev] vision vs. infinite configurability
> 
> Users want Keycloak to work like their existing solutions.  Users have
> peculiar use cases they need to solve.  As engineers, we want to satisfy
> our customer's needs so we add option after option.
> 
> This worries me...
> 
> We have to constantly think about the Keycloak "vision".  We need to
> continually think about how users *should* use Keycloak rather than how
> they want to use it.  Every time we add a new configuration option to
> keycloak we add complexity.  We make keycloak harder to understand and
> use.  We need to keep this in mind as we go forward over the next few
> months.   When customers ask for a new feature we need to ask them or think:
> 
> * Is there an existing way to do this?
> * Should we allow this option?
> * Is there a better way to solve the customer's need?
> 
> A big one is: Can we enforce specify policies to make Keycloak easier to
> configure?  For example, as a SAML IDP, we can say, sorry, but any SP
> needs to be able to handle signed saml documets.  we don't need to
> provide the config switch to not sign a document.  Get what I mean?
> 
> BTW, this is why I get so pissy whenever you guys want to add another
> SPI or config switch.  I know how these types of things snowball as a
> project ages.  You can collapse under the weight of them.  Having a
> "vision" helps tremendously as you tell users how they should be doing
> security rather than just doing whatever they want.
> 
> --
> 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 Dec  5 09:46:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 09:46:52 -0500 (EST)
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <1028521915.25390433.1417790509554.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>
	<1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>
	<4760322.11384589.1417788457523.JavaMail.zimbra@redhat.com>
	<711831466.25373681.1417788942317.JavaMail.zimbra@redhat.com>
	<48451523.11412244.1417789433189.JavaMail.zimbra@redhat.com>
	<1535438172.25382344.1417789748360.JavaMail.zimbra@redhat.com>
	<1841207631.11425021.1417790213219.JavaMail.zimbra@redhat.com>
	<1028521915.25390433.1417790509554.JavaMail.zimbra@redhat.com>
Message-ID: <316170421.11431796.1417790812403.JavaMail.zimbra@redhat.com>

With regards to mobile we have AeroGear guys working on it and I do believe they're using webviews.

I'd like to at some point schedule a meeting with them so we can discuss what the best integration angle is. There seems to be quite a lot of people not wanting to do webviews, with a good reason as they have a certain clumsy element. Besides they often end up with having a separate cookie per-app so SSO doesn't work in either case.

Let's put the idea of passing a access token to the direct grant api on the back-burner for now, until we have a clear vision on how mobile adapters should work.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 3:41:49 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, December 5, 2014 12:36:53 PM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 5 December, 2014 3:29:08 PM
> > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> > > 
> > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, December 5, 2014 12:23:53 PM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, 5 December, 2014 3:15:42 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > Broker
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, December 5, 2014 12:07:37 PM
> > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > Broker
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > Sent: Friday, 5 December, 2014 2:57:46 PM
> > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > > > > Broker
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > Sent: Friday, December 5, 2014 11:43:32 AM
> > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > Authentication
> > > > > > > > Broker
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > Sent: Friday, 5 December, 2014 2:36:14 PM
> > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > Authentication
> > > > > > > > > Broker
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > Sent: Friday, December 5, 2014 10:59:08 AM
> > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > Authentication
> > > > > > > > > > Broker
> > > > > > > > > > 
> > > > > > > > > > Another related thing. We've had a few people ask to be
> > > > > > > > > > able
> > > > > > > > > > to
> > > > > > > > > > login
> > > > > > > > > > to
> > > > > > > > > > Keycloak on mobiles using the native social login
> > > > > > > > > > mechanism.
> > > > > > > > > > 
> > > > > > > > > > I think the best way to do that is to use the direct grant
> > > > > > > > > > api
> > > > > > > > > > and
> > > > > > > > > > make
> > > > > > > > > > it
> > > > > > > > > > possible to call that endpoint passing a IdP id and a token
> > > > > > > > > > instead
> > > > > > > > > > of
> > > > > > > > > > username and password.
> > > > > > > > > > 
> > > > > > > > > > WDYT?
> > > > > > > > > 
> > > > > > > > > The broker endpoint expects the idp id in order to start the
> > > > > > > > > authentication
> > > > > > > > > process. Today, the endpoint also expects KCs authorization
> > > > > > > > > code
> > > > > > > > > in
> > > > > > > > > order
> > > > > > > > > to
> > > > > > > > > validate requests from clients and use it as a state to
> > > > > > > > > validate
> > > > > > > > > responses
> > > > > > > > > from the trusted idps.
> > > > > > > > > 
> > > > > > > > > This authorization code is a blocker for this use case, given
> > > > > > > > > that
> > > > > > > > > mobile
> > > > > > > > > don't have this code and just want to start the
> > > > > > > > > authentication.
> > > > > > > > > 
> > > > > > > > > A possible solution would be to change the broker to also
> > > > > > > > > accept
> > > > > > > > > a
> > > > > > > > > client_id
> > > > > > > > > to reference the mobile app and perform some validations
> > > > > > > > > based
> > > > > > > > > on
> > > > > > > > > that.
> > > > > > > > > Something like that:
> > > > > > > > > 
> > > > > > > > > 1) Mobile displays a Facebook button
> > > > > > > > > 2) User clicks the button and mobile sends a request to KC
> > > > > > > > > Broker
> > > > > > > > > with
> > > > > > > > > the
> > > > > > > > > idp id and his client_id.
> > > > > > > > > 3) KC Broker checks if the client_id is valid and creates a
> > > > > > > > > temporary
> > > > > > > > > authorization code.
> > > > > > > > > 4) KC Broker redirect mobile to the chosen IdP to perform
> > > > > > > > > authentication.
> > > > > > > > > 5) KC Broker receives a response from the IdP, generate its
> > > > > > > > > own
> > > > > > > > > token
> > > > > > > > > and
> > > > > > > > > send it back to mobile
> > > > > > > > > 
> > > > > > > > > Makes sense ?
> > > > > > > > 
> > > > > > > > No that's not the flow I had in mind. Basically the mobile app
> > > > > > > > authenticates
> > > > > > > > with Facebook through the native mechanisms. The app then has
> > > > > > > > an
> > > > > > > > access
> > > > > > > > token, which it would send to Keycloak on the direct grant api
> > > > > > > > to
> > > > > > > > obtain
> > > > > > > > a
> > > > > > > > Keycloak token.
> > > > > > > 
> > > > > > > Ahh, now I get what you mean :)
> > > > > > > 
> > > > > > > Yes, what you said is enough. Then we just need to validate the
> > > > > > > access
> > > > > > > token
> > > > > > > (eg.: using a tokeninfo endpoint).
> > > > > > > 
> > > > > > > But I think we can also consider that use case I mentioned. You
> > > > > > > may
> > > > > > > want
> > > > > > > to
> > > > > > > login without forcing the user to redirect to KC login page.
> > > > > > 
> > > > > > We could just add a query param to the login url that lets you pick
> > > > > > the
> > > > > > IdP
> > > > > > to use by alias?
> > > > > > 
> > > > > >   For example auth/.../login?client_id=...&auth_method=google
> > > > > 
> > > > > Yes, just like my previously example, we need the client_id. The idp
> > > > > id/alias
> > > > > is already there.
> > > > 
> > > > Sure, was just saying it should be the same URL as the regular login
> > > > page,
> > > > but with one extra param to specify the IdP.
> > > > 
> > > > > 
> > > > > Btw, regarding SAML. SAML does not provide a "validation" endpoint
> > > > > like
> > > > > oAuth2/OpenID providers usually provide. AFAIK, there is nothing on
> > > > > the
> > > > > specs for that. What can be done here is validate SAML assertions
> > > > > against
> > > > > a
> > > > > WS-Trust STS. Or just trust the assertion based on the signature and
> > > > > others
> > > > > standards info along it.
> > > > > 
> > > > > We can also take a closer look at the oAuth2 SAML bearer token
> > > > > profile
> > > > > and
> > > > > see if it helps.
> > > > 
> > > > If we could have it for social and OpenID Connect providers for now
> > > > that'd
> > > > be
> > > > good.
> > > 
> > > Deal. I'll do that.
> > > 
> > > What about that use case I mentioned ? The one about mobile asking to
> > > broker
> > > (not previously issued access_token) an identity provider ?
> > 
> > Sounds like a nice feature, but I'm not sure if anyone would use it. It
> > also
> > has a bit of an issue related to adapters, as they would have to have some
> > support for it. For example we added a while back the login_hint query
> > param
> > from OpenID Connect, which is really only usable from the JS adapter
> > currently.
> 
> How does mobile authenticate with KC today ? Users are redirect to KC login
> page in a web view ?
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > Same for other identity providers, the assumption is the app
> > > > > > > > has
> > > > > > > > an
> > > > > > > > out
> > > > > > > > of
> > > > > > > > bounds mechanism to obtain an access token, which is then sent
> > > > > > > > to
> > > > > > > > Keycloak
> > > > > > > > over the direct grant api.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > Sent: Friday, 5 December, 2014 1:45:24 PM
> > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > Authentication
> > > > > > > > > > > Broker
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > Sent: Friday, December 5, 2014 10:22:10 AM
> > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > Authentication
> > > > > > > > > > > > Broker
> > > > > > > > > > > > 
> > > > > > > > > > > > Looks good. I reckon we can combine the two pages. What
> > > > > > > > > > > > about
> > > > > > > > > > > > if
> > > > > > > > > > > > the
> > > > > > > > > > > > 'Add
> > > > > > > > > > > > provider' drop-down is:
> > > > > > > > > > > > 
> > > > > > > > > > > >   OpenID
> > > > > > > > > > > >   SAML
> > > > > > > > > > > >   ------
> > > > > > > > > > > >   Google
> > > > > > > > > > > >   GitHub
> > > > > > > > > > > >   Facebook
> > > > > > > > > > > >   Twitter
> > > > > > > > > > > > 
> > > > > > > > > > > > Let's drop social on/off and instead have a
> > > > > > > > > > > > enable/disable
> > > > > > > > > > > > button
> > > > > > > > > > > > on
> > > > > > > > > > > > each
> > > > > > > > > > > > provider.
> > > > > > > > > > > 
> > > > > > > > > > > Sure.
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Also, would be nice if users could set a name or alias
> > > > > > > > > > > > for
> > > > > > > > > > > > a
> > > > > > > > > > > > provider
> > > > > > > > > > > > instance. This would make the callback url easier to
> > > > > > > > > > > > use
> > > > > > > > > > > > (instead
> > > > > > > > > > > > of
> > > > > > > > > > > > callback/<UUID> it's callback/<alias>). The user
> > > > > > > > > > > > federation
> > > > > > > > > > > > providers
> > > > > > > > > > > > have
> > > > > > > > > > > > this.
> > > > > > > > > > > 
> > > > > > > > > > > One of my first tries was using an alias, just like that.
> > > > > > > > > > > But
> > > > > > > > > > > I
> > > > > > > > > > > preferred
> > > > > > > > > > > using the UUID and make the configuration more easier.
> > > > > > > > > > > Beside
> > > > > > > > > > > that,
> > > > > > > > > > > the
> > > > > > > > > > > callback url is just a copy and paste, so I think an
> > > > > > > > > > > alias
> > > > > > > > > > > would
> > > > > > > > > > > not
> > > > > > > > > > > bring
> > > > > > > > > > > so much usability, but add one more step when configuring
> > > > > > > > > > > providers.
> > > > > > > > > > > 
> > > > > > > > > > > However, if this is an usability requirement for KC I can
> > > > > > > > > > > change
> > > > > > > > > > > that.
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > In one of our last discussions, you suggested to
> > > > > > > > > > > > > leave
> > > > > > > > > > > > > Social
> > > > > > > > > > > > > as
> > > > > > > > > > > > > it
> > > > > > > > > > > > > is.
> > > > > > > > > > > > > Although IMO I think we can have a single place to
> > > > > > > > > > > > > manage
> > > > > > > > > > > > > both
> > > > > > > > > > > > > social
> > > > > > > > > > > > > and
> > > > > > > > > > > > > user-defined identity providers. Social ones are just
> > > > > > > > > > > > > OOTB
> > > > > > > > > > > > > and
> > > > > > > > > > > > > pre-configured identity providers now.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > That said, today I'm using separated tabs for social
> > > > > > > > > > > > > and
> > > > > > > > > > > > > user-defined.
> > > > > > > > > > > > > Please, take a look at [1] for more details on how
> > > > > > > > > > > > > the
> > > > > > > > > > > > > UI
> > > > > > > > > > > > > looks
> > > > > > > > > > > > > like.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I've changed social UI a bit in order to provide a
> > > > > > > > > > > > > specific
> > > > > > > > > > > > > page
> > > > > > > > > > > > > for
> > > > > > > > > > > > > create/update. I've also added a "Show Secret" link
> > > > > > > > > > > > > to
> > > > > > > > > > > > > display
> > > > > > > > > > > > > the
> > > > > > > > > > > > > client_secret in clear text if user wants to.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Beside the enable/disable button, I think another
> > > > > > > > > > > > > good
> > > > > > > > > > > > > thing
> > > > > > > > > > > > > to
> > > > > > > > > > > > > do
> > > > > > > > > > > > > is
> > > > > > > > > > > > > specify
> > > > > > > > > > > > > a default role(s) for each provider. That can be
> > > > > > > > > > > > > useful
> > > > > > > > > > > > > if
> > > > > > > > > > > > > applications
> > > > > > > > > > > > > want
> > > > > > > > > > > > > to perform any kind of authorization based on the
> > > > > > > > > > > > > identity
> > > > > > > > > > > > > provider
> > > > > > > > > > > > > or
> > > > > > > > > > > > > authentication method used to authenticate an user
> > > > > > > > > > > > > (eg.:
> > > > > > > > > > > > > useful
> > > > > > > > > > > > > for
> > > > > > > > > > > > > adaptative or multi-level access control). We can
> > > > > > > > > > > > > also
> > > > > > > > > > > > > use
> > > > > > > > > > > > > the
> > > > > > > > > > > > > "amr"
> > > > > > > > > > > > > claim
> > > > > > > > > > > > > in the ID Token, which seems KC is not considering at
> > > > > > > > > > > > > all.
> > > > > > > > > > > > > The
> > > > > > > > > > > > > latter
> > > > > > > > > > > > > is
> > > > > > > > > > > > > an
> > > > > > > > > > > > > important thing to think of, regardless this broker
> > > > > > > > > > > > > work
> > > > > > > > > > > > > I'm
> > > > > > > > > > > > > doing.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > [1]
> > > > > > > > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sharing
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM
> > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > Broker
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Having a separate enable/disable for each provider
> > > > > > > > > > > > > would
> > > > > > > > > > > > > be
> > > > > > > > > > > > > good.
> > > > > > > > > > > > > If
> > > > > > > > > > > > > you're
> > > > > > > > > > > > > leaving the social tab as is and adding a separate
> > > > > > > > > > > > > tab
> > > > > > > > > > > > > for
> > > > > > > > > > > > > configuring
> > > > > > > > > > > > > brokered idp's then we should leave the social
> > > > > > > > > > > > > enable/disable
> > > > > > > > > > > > > button,
> > > > > > > > > > > > > otherwise it depends how it'll look like in the end.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    Social has a button to enable/disable it. I'm
> > > > > > > > > > > > > >    wondering
> > > > > > > > > > > > > >    what
> > > > > > > > > > > > > >    to
> > > > > > > > > > > > > >    do
> > > > > > > > > > > > > >    with
> > > > > > > > > > > > > >    the brokered identity providers. Shall we add a
> > > > > > > > > > > > > >    similar
> > > > > > > > > > > > > >    flag
> > > > > > > > > > > > > >    for
> > > > > > > > > > > > > >    that
> > > > > > > > > > > > > >    ?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    I was also wondering if the best would be a flag
> > > > > > > > > > > > > >    in
> > > > > > > > > > > > > >    a
> > > > > > > > > > > > > >    per
> > > > > > > > > > > > > >    provider
> > > > > > > > > > > > > >    basis.
> > > > > > > > > > > > > >    So we can disable/enable a specific provider
> > > > > > > > > > > > > >    (social
> > > > > > > > > > > > > >    or
> > > > > > > > > > > > > >    brokered),
> > > > > > > > > > > > > >    instead of doing that for all.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM
> > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and
> > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM
> > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM
> > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I'll go for it then. Will remove the icon url
> > > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > model
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > leave
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > for users if they want to provide icons for
> > > > > > > > > > > > > > > > their
> > > > > > > > > > > > > > > > identity
> > > > > > > > > > > > > > > > providers.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > My point is that icons can be usually served by
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > same
> > > > > > > > > > > > > > > > server/application
> > > > > > > > > > > > > > > > or proxy, so download images are not such a big
> > > > > > > > > > > > > > > > deal.
> > > > > > > > > > > > > > > > Also,
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > icon
> > > > > > > > > > > > > > > > url
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > part of the freemarker model and people can do
> > > > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > > ever
> > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > want
> > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > it.
> > > > > > > > > > > > > > > > What I think will also help in your future
> > > > > > > > > > > > > > > > plans.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I'm not following. Are you saying that if a named
> > > > > > > > > > > > > > > image
> > > > > > > > > > > > > > > 'my-provider.png'
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > loaded from a theme, then you can override it in
> > > > > > > > > > > > > > > another
> > > > > > > > > > > > > > > theme?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > If so, that's basically the same as having a css
> > > > > > > > > > > > > > > class
> > > > > > > > > > > > > > > 'my-provider'
> > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > theme. With the exception that with an image you
> > > > > > > > > > > > > > > end
> > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > having
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > require a image per provider per theme per
> > > > > > > > > > > > > > > language,
> > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > lot
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > images for a single provider. Also, buttons for
> > > > > > > > > > > > > > > accessibility
> > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > defined with text and css, not images that can't
> > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > interpreted.
> > > > > > > > > > > > > > > You
> > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > still need to modify the theme, so I don't see
> > > > > > > > > > > > > > > any
> > > > > > > > > > > > > > > benefits.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > You are right. Having a icon url per provider does
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > makes
> > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > if
> > > > > > > > > > > > > > there
> > > > > > > > > > > > > > are requirements to change images accordingly to a
> > > > > > > > > > > > > > theme
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > language.
> > > > > > > > > > > > > > CSS
> > > > > > > > > > > > > > makes life easier.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Will remove that property from the model.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM
> > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM
> > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Users can now specify a Icon Url to be
> > > > > > > > > > > > > > > > > rendered
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > login
> > > > > > > > > > > > > > > > > page
> > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > social
> > > > > > > > > > > > > > > > > or any other identity provider is configured.
> > > > > > > > > > > > > > > > > So
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > just
> > > > > > > > > > > > > > > > > load
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > image
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > url entered by the user.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Are you saying that users should change the
> > > > > > > > > > > > > > > > > theme
> > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > customize
> > > > > > > > > > > > > > > > > css
> > > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > only want to change an icon for a provider ?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Yes, there's many issues with having a icon
> > > > > > > > > > > > > > > > url:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > * Won't work for internationalization - we
> > > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > now,
> > > > > > > > > > > > > > > > but
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > * Image is not a good button - CSS is much
> > > > > > > > > > > > > > > > better
> > > > > > > > > > > > > > > > * Doesn't support themes - we allow users to
> > > > > > > > > > > > > > > > switch
> > > > > > > > > > > > > > > > l&f
> > > > > > > > > > > > > > > > by
> > > > > > > > > > > > > > > > switching
> > > > > > > > > > > > > > > > themes,
> > > > > > > > > > > > > > > > but that won't work for a icon url. In the
> > > > > > > > > > > > > > > > future
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > may
> > > > > > > > > > > > > > > > also
> > > > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > multiple themes per-realm, for example to
> > > > > > > > > > > > > > > > depending
> > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > devices
> > > > > > > > > > > > > > > > (one
> > > > > > > > > > > > > > > > theme for mobiles, one for desktops, etc)
> > > > > > > > > > > > > > > > * Requires the URL to be hosted somewhere - why
> > > > > > > > > > > > > > > > require
> > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > separate
> > > > > > > > > > > > > > > > call
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > download an image (to a separate server maybe)
> > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > can
> > > > > > > > > > > > > > > > simply
> > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > defined
> > > > > > > > > > > > > > > > in a single CSS file?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Rather than add additional places to define
> > > > > > > > > > > > > > > > look
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > feel
> > > > > > > > > > > > > > > > components
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > should in the future make it easier to
> > > > > > > > > > > > > > > > add/customize
> > > > > > > > > > > > > > > > themes.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM
> > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > All look and feel related things including
> > > > > > > > > > > > > > > > > images
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > stylesheets
> > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > part of themes. This is to allow customizing
> > > > > > > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > theme.
> > > > > > > > > > > > > > > > > Also,
> > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > image is not the correct way to render a
> > > > > > > > > > > > > > > > > button,
> > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > defined
> > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > CSS.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM
> > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > You shouldn't have icon images for social
> > > > > > > > > > > > > > > > > > providers.
> > > > > > > > > > > > > > > > > > They
> > > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > specified
> > > > > > > > > > > > > > > > > > as part of the theme in CSS as is now.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > > > From: "Pedro Igor Silva"
> > > > > > > > > > > > > > > > > > > <psilva at redhat.com>
> > > > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21
> > > > > > > > > > > > > > > > > > > PM
> > > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >     Anyone know where I can get the icons
> > > > > > > > > > > > > > > > > > >     images
> > > > > > > > > > > > > > > > > > >     for
> > > > > > > > > > > > > > > > > > >     social
> > > > > > > > > > > > > > > > > > >     providers
> > > > > > > > > > > > > > > > > > >     ?
> > > > > > > > > > > > > > > > > > >     It
> > > > > > > > > > > > > > > > > > >     seems zocial defines them encoded in
> > > > > > > > > > > > > > > > > > >     some
> > > > > > > > > > > > > > > > > > >     way
> > > > > > > > > > > > > > > > > > >     in
> > > > > > > > > > > > > > > > > > >     CSS.
> > > > > > > > > > > > > > > > > > >     I
> > > > > > > > > > > > > > > > > > >     need
> > > > > > > > > > > > > > > > > > >     that
> > > > > > > > > > > > > > > > > > >     to
> > > > > > > > > > > > > > > > > > >     provide default images if user does
> > > > > > > > > > > > > > > > > > >     not
> > > > > > > > > > > > > > > > > > >     specify
> > > > > > > > > > > > > > > > > > >     their
> > > > > > > > > > > > > > > > > > >     own.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >     Or is still possible to use zocial
> > > > > > > > > > > > > > > > > > >     ones
> > > > > > > > > > > > > > > > > > >     ?
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > > > From: "Pedro Igor Silva"
> > > > > > > > > > > > > > > > > > > <psilva at redhat.com>
> > > > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38
> > > > > > > > > > > > > > > > > > > PM
> > > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >    I've done some initial work covering
> > > > > > > > > > > > > > > > > > >    both
> > > > > > > > > > > > > > > > > > >    persistence
> > > > > > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > > > > > >    brokering.
> > > > > > > > > > > > > > > > > > >    No
> > > > > > > > > > > > > > > > > > >    UI, yet. I'm focused on the model,
> > > > > > > > > > > > > > > > > > >    rest
> > > > > > > > > > > > > > > > > > >    api
> > > > > > > > > > > > > > > > > > >    and
> > > > > > > > > > > > > > > > > > >    brokering
> > > > > > > > > > > > > > > > > > >    functionality
> > > > > > > > > > > > > > > > > > >    for now.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >    What I have is enough to decide if we
> > > > > > > > > > > > > > > > > > >    are
> > > > > > > > > > > > > > > > > > >    aligned
> > > > > > > > > > > > > > > > > > >    about
> > > > > > > > > > > > > > > > > > >    this
> > > > > > > > > > > > > > > > > > >    functionality. So you can understand
> > > > > > > > > > > > > > > > > > >    how
> > > > > > > > > > > > > > > > > > >    the
> > > > > > > > > > > > > > > > > > >    model
> > > > > > > > > > > > > > > > > > >    (and
> > > > > > > > > > > > > > > > > > >    persistence),
> > > > > > > > > > > > > > > > > > >    rest api and brokering functionality
> > > > > > > > > > > > > > > > > > >    looks
> > > > > > > > > > > > > > > > > > >    like.
> > > > > > > > > > > > > > > > > > >    Can
> > > > > > > > > > > > > > > > > > >    we
> > > > > > > > > > > > > > > > > > >    schedule
> > > > > > > > > > > > > > > > > > >    a
> > > > > > > > > > > > > > > > > > >    meeting ?
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >    Btw, my branch is here [1].
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Regards.
> > > > > > > > > > > > > > > > > > > Pedro Igor
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > > > > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > > To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49
> > > > > > > > > > > > > > > > > > > PM
> > > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > > Identity
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > Authentication
> > > > > > > > > > > > > > > > > > > Broker
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Currently adapters can only make authz
> > > > > > > > > > > > > > > > > > > decisions
> > > > > > > > > > > > > > > > > > > (@RolesAllowed)
> > > > > > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > on either realm roles or the roles of one
> > > > > > > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > > > > > > application.
> > > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > related to 1) too.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Boles?aw
> > > > > > > > > > > > > > > > > > > Dawidowicz
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > 1) Sounds like something definitely
> > > > > > > > > > > > > > > > > > > > worth
> > > > > > > > > > > > > > > > > > > > aiming
> > > > > > > > > > > > > > > > > > > > for.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian
> > > > > > > > > > > > > > > > > > > > Thorgersen
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >> I just wanted to quickly list the
> > > > > > > > > > > > > > > > > > > >> additional
> > > > > > > > > > > > > > > > > > > >> work
> > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > >> discussed
> > > > > > > > > > > > > > > > > > > >> so
> > > > > > > > > > > > > > > > > > > >> everyone
> > > > > > > > > > > > > > > > > > > >> can think about it (in no particular
> > > > > > > > > > > > > > > > > > > >> order):
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal
> > > > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > > > > >> an
> > > > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > > >> a KC token? For example an external
> > > > > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > > > >> attribute
> > > > > > > > > > > > > > > > > > > >> 'group'
> > > > > > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > > > > > >> contains 'sales' and 'manager' could
> > > > > > > > > > > > > > > > > > > >> be
> > > > > > > > > > > > > > > > > > > >> mapped
> > > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > > >> 'manager'
> > > > > > > > > > > > > > > > > > > >> role
> > > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > > >> 'sales app in a KC token. Could we use
> > > > > > > > > > > > > > > > > > > >> Drools?
> > > > > > > > > > > > > > > > > > > >> This
> > > > > > > > > > > > > > > > > > > >> could
> > > > > > > > > > > > > > > > > > > >> also
> > > > > > > > > > > > > > > > > > > >> be
> > > > > > > > > > > > > > > > > > > >> used
> > > > > > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > > > > > >> user federation to allow more complex
> > > > > > > > > > > > > > > > > > > >> mapping
> > > > > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > > > > >> roles/groups
> > > > > > > > > > > > > > > > > > > >> than
> > > > > > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > > > > > >> simple 1-1
> > > > > > > > > > > > > > > > > > > >> 2) Retrieving tokens - if an
> > > > > > > > > > > > > > > > > > > >> application
> > > > > > > > > > > > > > > > > > > >> wants
> > > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > > >> retrieve
> > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > > > >> token (for example to view Facebook
> > > > > > > > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > > > > > > > >> if
> > > > > > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > > > > > >> logged
> > > > > > > > > > > > > > > > > > > >> in
> > > > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > > > >> Facebook)
> > > > > > > > > > > > > > > > > > > >> 3) Configure scope - currently for
> > > > > > > > > > > > > > > > > > > >> social
> > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > >> only
> > > > > > > > > > > > > > > > > > > >> request
> > > > > > > > > > > > > > > > > > > >> a
> > > > > > > > > > > > > > > > > > > >> very
> > > > > > > > > > > > > > > > > > > >> limited
> > > > > > > > > > > > > > > > > > > >> scope (basic profile and email), to
> > > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > > >> example
> > > > > > > > > > > > > > > > > > > >> view
> > > > > > > > > > > > > > > > > > > >> Facebook
> > > > > > > > > > > > > > > > > > > >> friends
> > > > > > > > > > > > > > > > > > > >> we'd need to ask for that as well
> > > > > > > > > > > > > > > > > > > >> 4) Selecting provider - currently in
> > > > > > > > > > > > > > > > > > > >> social
> > > > > > > > > > > > > > > > > > > >> (and
> > > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > > >> first
> > > > > > > > > > > > > > > > > > > >> pass
> > > > > > > > > > > > > > > > > > > >> of
> > > > > > > > > > > > > > > > > > > >> brokering) we have an icon user has to
> > > > > > > > > > > > > > > > > > > >> select,
> > > > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > > > >> can
> > > > > > > > > > > > > > > > > > > >> we
> > > > > > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > >> provider in a different way (for
> > > > > > > > > > > > > > > > > > > >> example
> > > > > > > > > > > > > > > > > > > >> ask
> > > > > > > > > > > > > > > > > > > >> user
> > > > > > > > > > > > > > > > > > > >> for
> > > > > > > > > > > > > > > > > > > >> email,
> > > > > > > > > > > > > > > > > > > >> and
> > > > > > > > > > > > > > > > > > > >> select
> > > > > > > > > > > > > > > > > > > >> based on email domain)
> > > > > > > > > > > > > > > > > > > >> 5) Gateway - don't create a KC token,
> > > > > > > > > > > > > > > > > > > >> but
> > > > > > > > > > > > > > > > > > > >> just
> > > > > > > > > > > > > > > > > > > >> forward
> > > > > > > > > > > > > > > > > > > >> the
> > > > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > > > >> token
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >> IMO 1) is a killer feature, as it
> > > > > > > > > > > > > > > > > > > >> would
> > > > > > > > > > > > > > > > > > > >> allow
> > > > > > > > > > > > > > > > > > > >> companies
> > > > > > > > > > > > > > > > > > > >> to
> > > > > > > > > > > > > > > > > > > >> add
> > > > > > > > > > > > > > > > > > > >> external
> > > > > > > > > > > > > > > > > > > >> users without having to modify their
> > > > > > > > > > > > > > > > > > > >> applications.
> > > > > > > > > > > > > > > > > > > >> Issue
> > > > > > > > > > > > > > > > > > > >> with
> > > > > > > > > > > > > > > > > > > >> 5)
> > > > > > > > > > > > > > > > > > > >> is
> > > > > > > > > > > > > > > > > > > >> that
> > > > > > > > > > > > > > > > > > > >> applications need to understand more
> > > > > > > > > > > > > > > > > > > >> than
> > > > > > > > > > > > > > > > > > > >> one
> > > > > > > > > > > > > > > > > > > >> token,
> > > > > > > > > > > > > > > > > > > >> which
> > > > > > > > > > > > > > > > > > > >> would
> > > > > > > > > > > > > > > > > > > >> require
> > > > > > > > > > > > > > > > > > > >> rewriting applications.
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >> This work is also somewhat related to
> > > > > > > > > > > > > > > > > > > >> other
> > > > > > > > > > > > > > > > > > > >> authentication
> > > > > > > > > > > > > > > > > > > >> mechanisms
> > > > > > > > > > > > > > > > > > > >> (for
> > > > > > > > > > > > > > > > > > > >> example Kerberos ticket, LDAP and
> > > > > > > > > > > > > > > > > > > >> passwordless).
> > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >> ----- Original Message -----
> > > > > > > > > > > > > > > > > > > >>> From: "Pedro Igor Silva"
> > > > > > > > > > > > > > > > > > > >>> <psilva at redhat.com>
> > > > > > > > > > > > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > > >>> Cc: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014
> > > > > > > > > > > > > > > > > > > >>> 8:27:58
> > > > > > > > > > > > > > > > > > > >>> PM
> > > > > > > > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated
> > > > > > > > > > > > > > > > > > > >>> Identity
> > > > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > > > >>> Authentication
> > > > > > > > > > > > > > > > > > > >>> Broker
> > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > >>> ----- Original Message -----
> > > > > > > > > > > > > > > > > > > >>>> From: "Bill Burke"
> > > > > > > > > > > > > > > > > > > >>>> <bburke at redhat.com>
> > > > > > > > > > > > > > > > > > > >>>> To: keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014
> > > > > > > > > > > > > > > > > > > >>>> 4:39:52
> > > > > > > > > > > > > > > > > > > >>>> PM
> > > > > > > > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev]
> > > > > > > > > > > > > > > > > > > >>>> Federated
> > > > > > > > > > > > > > > > > > > >>>> Identity
> > > > > > > > > > > > > > > > > > > >>>> and
> > > > > > > > > > > > > > > > > > > >>>> Authentication
> > > > > > > > > > > > > > > > > > > >>>> Broker
> > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor
> > > > > > > > > > > > > > > > > > > >>>> Silva
> > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > >>>>> Hi,
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        Would like to start a
> > > > > > > > > > > > > > > > > > > >>>>>        discussion
> > > > > > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        enable
> > > > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > > >>>>>        Authentication Broker in
> > > > > > > > > > > > > > > > > > > >>>>>        order
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > > > > > > >>>>>        Chained
> > > > > > > > > > > > > > > > > > > >>>>>        Federation
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        also Identity Federation.
> > > > > > > > > > > > > > > > > > > >>>>>        First
> > > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > > >>>>>        all,
> > > > > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > > > > >>>>>        background
> > > > > > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > > > > > >>>>>        what
> > > > > > > > > > > > > > > > > > > >>>>>        this is all about.
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        Currently KeyCloak provides
> > > > > > > > > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > > > > > >>>>>        types
> > > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > > > >>>>>        (correct
> > > > > > > > > > > > > > > > > > > >>>>>        me if I'm wrong, please):
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>            1) Local authentication
> > > > > > > > > > > > > > > > > > > >>>>>            (based
> > > > > > > > > > > > > > > > > > > >>>>>            on
> > > > > > > > > > > > > > > > > > > >>>>>            some
> > > > > > > > > > > > > > > > > > > >>>>>            credential
> > > > > > > > > > > > > > > > > > > >>>>>            type
> > > > > > > > > > > > > > > > > > > >>>>>            enabled
> > > > > > > > > > > > > > > > > > > >>>>>            to
> > > > > > > > > > > > > > > > > > > >>>>>            a realm)
> > > > > > > > > > > > > > > > > > > >>>>>            2) Social authentication
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        Local authentication is
> > > > > > > > > > > > > > > > > > > >>>>>        about
> > > > > > > > > > > > > > > > > > > >>>>>        authenticating
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > > > > >>>>>        locally
> > > > > > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > > > > > >>>>>        KC's own identity store.
> > > > > > > > > > > > > > > > > > > >>>>>        Nothing
> > > > > > > > > > > > > > > > > > > >>>>>        special
> > > > > > > > > > > > > > > > > > > >>>>>        here.
> > > > > > > > > > > > > > > > > > > >>>>>        And
> > > > > > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > > > > > >>>>>        Authentication which allows
> > > > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        choose
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        Social
> > > > > > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > > > > > > > > >>>>>        to authenticate with. In
> > > > > > > > > > > > > > > > > > > >>>>>        this
> > > > > > > > > > > > > > > > > > > >>>>>        case,
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        IdP
> > > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > > >>>>>        always
> > > > > > > > > > > > > > > > > > > >>>>>        one
> > > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        built-in social providers
> > > > > > > > > > > > > > > > > > > >>>>>        supported
> > > > > > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > > >>>>>        Facebook,
> > > > > > > > > > > > > > > > > > > >>>>>        Google,
> > > > > > > > > > > > > > > > > > > >>>>>        Twitter, Github and so
> > > > > > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        When doing social, the user
> > > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > > >>>>>        automatically
> > > > > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > > > >>>>>        identity store after a
> > > > > > > > > > > > > > > > > > > >>>>>        successful
> > > > > > > > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > > > > >>>>>        does
> > > > > > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > > > > > >>>>>        need to fill a registration
> > > > > > > > > > > > > > > > > > > >>>>>        form
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > > >>>>>        very
> > > > > > > > > > > > > > > > > > > >>>>>        quickly. During the
> > > > > > > > > > > > > > > > > > > >>>>>        provisioning
> > > > > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > > > > >>>>>        basic
> > > > > > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > > >>>>>        retrieved
> > > > > > > > > > > > > > > > > > > >>>>>        from the social provider
> > > > > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > > >>>>>        email,
> > > > > > > > > > > > > > > > > > > >>>>>        firstname
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > > > > > >>>>>        These
> > > > > > > > > > > > > > > > > > > >>>>>        are very basic information,
> > > > > > > > > > > > > > > > > > > >>>>>        any
> > > > > > > > > > > > > > > > > > > >>>>>        other
> > > > > > > > > > > > > > > > > > > >>>>>        information
> > > > > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > > > > > >>>>>        related with authorization
> > > > > > > > > > > > > > > > > > > >>>>>        policies
> > > > > > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > > > > > >>>>>        eg.:
> > > > > > > > > > > > > > > > > > > >>>>>        roles
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        groups
> > > > > > > > > > > > > > > > > > > >>>>>        -
> > > > > > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > > >>>>>        defined later via KC's admin
> > > > > > > > > > > > > > > > > > > >>>>>        console.
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        Another important
> > > > > > > > > > > > > > > > > > > >>>>>        characteristic
> > > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        application receives a KC
> > > > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        not
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > > > > > >>>>>        issued by
> > > > > > > > > > > > > > > > > > > >>>>>        the social IdP during the
> > > > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > > > >>>>>        process.
> > > > > > > > > > > > > > > > > > > >>>>>        If
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > > >>>>>        wants to consume resources
> > > > > > > > > > > > > > > > > > > >>>>>        from
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        resource
> > > > > > > > > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > > > > > > > > >>>>>        he
> > > > > > > > > > > > > > > > > > > >>>>>        was
> > > > > > > > > > > > > > > > > > > >>>>>        authenticated it must obtain
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        access
> > > > > > > > > > > > > > > > > > > >>>>>        token(again)
> > > > > > > > > > > > > > > > > > > >>>>>        by
> > > > > > > > > > > > > > > > > > > >>>>>        itself
> > > > > > > > > > > > > > > > > > > >>>>>        prior
> > > > > > > > > > > > > > > > > > > >>>>>        to invoke the resource
> > > > > > > > > > > > > > > > > > > >>>>>        provider
> > > > > > > > > > > > > > > > > > > >>>>>        API.
> > > > > > > > > > > > > > > > > > > >>>>>        Assuming
> > > > > > > > > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > > > > > > > > >>>>>        those
> > > > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > > > >>>>>        providers are based on oAuth
> > > > > > > > > > > > > > > > > > > >>>>>        1.0
> > > > > > > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > > > > > > >>>>>        2.0.
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        That said, the
> > > > > > > > > > > > > > > > > > > >>>>>        Authentication
> > > > > > > > > > > > > > > > > > > >>>>>        Broker
> > > > > > > > > > > > > > > > > > > >>>>>        functionality
> > > > > > > > > > > > > > > > > > > >>>>>        aims
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        cover
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        same use cases but with a
> > > > > > > > > > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > > >>>>>        more
> > > > > > > > > > > > > > > > > > > >>>>>        flexibility
> > > > > > > > > > > > > > > > > > > >>>>>        on
> > > > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > > > > > > > >>>>>        setup
> > > > > > > > > > > > > > > > > > > >>>>>        identity providers(not only
> > > > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > > > >>>>>        ones)
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > > > > > > >>>>>        protocols they may support
> > > > > > > > > > > > > > > > > > > >>>>>        such
> > > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > > >>>>>        SAML,
> > > > > > > > > > > > > > > > > > > >>>>>        OpenID,
> > > > > > > > > > > > > > > > > > > >>>>>        oAuth
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > > > > >>>>>        forth.
> > > > > > > > > > > > > > > > > > > >>>>>        This is useful when an
> > > > > > > > > > > > > > > > > > > >>>>>        enterprise
> > > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > > >>>>>        providing
> > > > > > > > > > > > > > > > > > > >>>>>        services
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > > > > >>>>>        customers(IdP) and does not
> > > > > > > > > > > > > > > > > > > >>>>>        want
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        manage
> > > > > > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        many
> > > > > > > > > > > > > > > > > > > >>>>>        relationships. When using a
> > > > > > > > > > > > > > > > > > > >>>>>        broker,
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        authentication
> > > > > > > > > > > > > > > > > > > >>>>>        steps
> > > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > > >>>>>        pretty much the same when
> > > > > > > > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > > >>>>>        using
> > > > > > > > > > > > > > > > > > > >>>>>        social
> > > > > > > > > > > > > > > > > > > >>>>>        authentication,
> > > > > > > > > > > > > > > > > > > >>>>>        with
> > > > > > > > > > > > > > > > > > > >>>>>        important differences on how
> > > > > > > > > > > > > > > > > > > >>>>>        you
> > > > > > > > > > > > > > > > > > > >>>>>        support
> > > > > > > > > > > > > > > > > > > >>>>>        different
> > > > > > > > > > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > > > > > > > > > >>>>>        providers, different
> > > > > > > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > > > > > > >>>>>        protocols,
> > > > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > > > > >>>>>        and how claims and
> > > > > > > > > > > > > > > > > > > >>>>>        attributes
> > > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > > >>>>>        resolved.
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        The brokering functionality
> > > > > > > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > > >>>>>        done
> > > > > > > > > > > > > > > > > > > >>>>>        in
> > > > > > > > > > > > > > > > > > > >>>>>        two
> > > > > > > > > > > > > > > > > > > >>>>>        ways
> > > > > > > > > > > > > > > > > > > >>>>>        depending
> > > > > > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        broker service is acting as
> > > > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > > > >>>>>        gateway
> > > > > > > > > > > > > > > > > > > >>>>>        or
> > > > > > > > > > > > > > > > > > > >>>>>        not.
> > > > > > > > > > > > > > > > > > > >>>>>        When
> > > > > > > > > > > > > > > > > > > >>>>>        acting
> > > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > > > >>>>>        gateway, the broker will
> > > > > > > > > > > > > > > > > > > >>>>>        respond
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        same
> > > > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > > > >>>>>        issued by the trusted
> > > > > > > > > > > > > > > > > > > >>>>>        identity
> > > > > > > > > > > > > > > > > > > >>>>>        provider.
> > > > > > > > > > > > > > > > > > > >>>>>        For
> > > > > > > > > > > > > > > > > > > >>>>>        instance,
> > > > > > > > > > > > > > > > > > > >>>>>        if
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        user
> > > > > > > > > > > > > > > > > > > >>>>>        selects a SAML IdP to
> > > > > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > > > > >>>>>        with,
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > > > > > >>>>>        a SAML Response. In this
> > > > > > > > > > > > > > > > > > > >>>>>        case,
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        application
> > > > > > > > > > > > > > > > > > > >>>>>        must
> > > > > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > > >>>>>        prepared
> > > > > > > > > > > > > > > > > > > >>>>>        to handle a specific
> > > > > > > > > > > > > > > > > > > >>>>>        federation
> > > > > > > > > > > > > > > > > > > >>>>>        protocol.
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        However, the broker service
> > > > > > > > > > > > > > > > > > > >>>>>        can
> > > > > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        completely
> > > > > > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > > > > > >>>>>        from the application the
> > > > > > > > > > > > > > > > > > > >>>>>        protocol
> > > > > > > > > > > > > > > > > > > >>>>>        used
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > > >>>>>        user.
> > > > > > > > > > > > > > > > > > > >>>>>        In
> > > > > > > > > > > > > > > > > > > >>>>>        this case, the application
> > > > > > > > > > > > > > > > > > > >>>>>        will
> > > > > > > > > > > > > > > > > > > >>>>>        just
> > > > > > > > > > > > > > > > > > > >>>>>        receive
> > > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > > >>>>>        ordinary
> > > > > > > > > > > > > > > > > > > >>>>>        KC
> > > > > > > > > > > > > > > > > > > >>>>>        token
> > > > > > > > > > > > > > > > > > > >>>>>        after a successful
> > > > > > > > > > > > > > > > > > > >>>>>        authentication.
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        In both cases, the broker
> > > > > > > > > > > > > > > > > > > >>>>>        acts
> > > > > > > > > > > > > > > > > > > >>>>>        as
> > > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > > >>>>>        intermediary
> > > > > > > > > > > > > > > > > > > >>>>>        where
> > > > > > > > > > > > > > > > > > > >>>>>        specific
> > > > > > > > > > > > > > > > > > > >>>>>        security policies can be
> > > > > > > > > > > > > > > > > > > >>>>>        applied
> > > > > > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > > > >>>>>        try
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        authenticate
> > > > > > > > > > > > > > > > > > > >>>>>        themselves against a 3rd
> > > > > > > > > > > > > > > > > > > >>>>>        party
> > > > > > > > > > > > > > > > > > > >>>>>        IdP.
> > > > > > > > > > > > > > > > > > > >>>>>        That
> > > > > > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > > > >>>>>        lot
> > > > > > > > > > > > > > > > > > > >>>>>        of
> > > > > > > > > > > > > > > > > > > >>>>>        value
> > > > > > > > > > > > > > > > > > > >>>>>        when
> > > > > > > > > > > > > > > > > > > >>>>>        you think about auditing,
> > > > > > > > > > > > > > > > > > > >>>>>        authorization
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        how
> > > > > > > > > > > > > > > > > > > >>>>>        users
> > > > > > > > > > > > > > > > > > > >>>>>        are
> > > > > > > > > > > > > > > > > > > >>>>>        provisioned
> > > > > > > > > > > > > > > > > > > >>>>>        when federation of
> > > > > > > > > > > > > > > > > > > >>>>>        identities
> > > > > > > > > > > > > > > > > > > >>>>>        is
> > > > > > > > > > > > > > > > > > > >>>>>        needed.
> > > > > > > > > > > > > > > > > > > >>>>>        This
> > > > > > > > > > > > > > > > > > > >>>>>        also
> > > > > > > > > > > > > > > > > > > >>>>>        allows
> > > > > > > > > > > > > > > > > > > >>>>>        existing
> > > > > > > > > > > > > > > > > > > >>>>>        security infrastructures
> > > > > > > > > > > > > > > > > > > >>>>>        (eg.:
> > > > > > > > > > > > > > > > > > > >>>>>        SAML-based
> > > > > > > > > > > > > > > > > > > >>>>>        infrastructures)
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        benefit
> > > > > > > > > > > > > > > > > > > >>>>>        from KC's support for cloud,
> > > > > > > > > > > > > > > > > > > >>>>>        rest
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        mobile
> > > > > > > > > > > > > > > > > > > >>>>>        use
> > > > > > > > > > > > > > > > > > > >>>>>        cases.
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>>        I think this is enough to
> > > > > > > > > > > > > > > > > > > >>>>>        start
> > > > > > > > > > > > > > > > > > > >>>>>        a
> > > > > > > > > > > > > > > > > > > >>>>>        discussion.
> > > > > > > > > > > > > > > > > > > >>>>>        I've
> > > > > > > > > > > > > > > > > > > >>>>>        an
> > > > > > > > > > > > > > > > > > > >>>>>        initial
> > > > > > > > > > > > > > > > > > > >>>>>        discussion with Stian about
> > > > > > > > > > > > > > > > > > > >>>>>        all
> > > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        we
> > > > > > > > > > > > > > > > > > > >>>>>        agreed
> > > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > > >>>>>        abstract
> > > > > > > > > > > > > > > > > > > >>>>>        the
> > > > > > > > > > > > > > > > > > > >>>>>        protocol from applications
> > > > > > > > > > > > > > > > > > > >>>>>        should
> > > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > > >>>>>        prioritized.
> > > > > > > > > > > > > > > > > > > >>>>>        The
> > > > > > > > > > > > > > > > > > > >>>>>        main
> > > > > > > > > > > > > > > > > > > >>>>>        reason is
> > > > > > > > > > > > > > > > > > > >>>>>        that it makes life easier
> > > > > > > > > > > > > > > > > > > >>>>>        for
> > > > > > > > > > > > > > > > > > > >>>>>        applications
> > > > > > > > > > > > > > > > > > > >>>>>        so
> > > > > > > > > > > > > > > > > > > >>>>>        they
> > > > > > > > > > > > > > > > > > > >>>>>        only
> > > > > > > > > > > > > > > > > > > >>>>>        need
> > > > > > > > > > > > > > > > > > > >>>>>        to
> > > > > > > > > > > > > > > > > > > >>>>>        know
> > > > > > > > > > > > > > > > > > > >>>>>        about KC tokens and nothing
> > > > > > > > > > > > > > > > > > > >>>>>        else.
> > > > > > > > > > > > > > > > > > > >>>>>        However
> > > > > > > > > > > > > > > > > > > >>>>>        that
> > > > > > > > > > > > > > > > > > > >>>>>        brings
> > > > > > > > > > > > > > > > > > > >>>>>        some
> > > > > > > > > > > > > > > > > > > >>>>>        new
> > > > > > > > > > > > > > > > > > > >>>>>        requirements around user
> > > > > > > > > > > > > > > > > > > >>>>>        provisioning
> > > > > > > > > > > > > > > > > > > >>>>>        and
> > > > > > > > > > > > > > > > > > > >>>>>        claim/attribute
> > > > > > > > > > > > > > > > > > > >>>>>        resolution
> > > > > > > > > > > > > > > > > > > >>>>>        or mapping. But that would
> > > > > > > > > > > > > > > > > > > >>>>>        be
> > > > > > > > > > > > > > > > > > > >>>>>        another
> > > > > > > > > > > > > > > > > > > >>>>>        thread.
> > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > >>>> Can you elaborate on "abstract the
> > > > > > > > > > > > > > > > > > > >>>> protocol
> > > > > > > > > > > > > > > > > > > >>>> from
> > > > > > > > > > > > > > > > > > > >>>> applications"?
> > > > > > > > > > > > > > > > > > > >>>> Not
> > > > > > > > > > > > > > > > > > > >>>> sure what you mean by that.  IDP
> > > > > > > > > > > > > > > > > > > >>>> federation
> > > > > > > > > > > > > > > > > > > >>>> should
> > > > > > > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > > > > > > >>>> configured
> > > > > > > > > > > > > > > > > > > >>>> at
> > > > > > > > > > > > > > > > > > > >>>> the
> > > > > > > > > > > > > > > > > > > >>>> realm level and really has nothing
> > > > > > > > > > > > > > > > > > > >>>> to
> > > > > > > > > > > > > > > > > > > >>>> do
> > > > > > > > > > > > > > > > > > > >>>> with
> > > > > > > > > > > > > > > > > > > >>>> applications.
> > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > >>>> I'm really happy that somebody is
> > > > > > > > > > > > > > > > > > > >>>> doing
> > > > > > > > > > > > > > > > > > > >>>> this.
> > > > > > > > > > > > > > > > > > > >>>> We're
> > > > > > > > > > > > > > > > > > > >>>> getting
> > > > > > > > > > > > > > > > > > > >>>> a
> > > > > > > > > > > > > > > > > > > >>>> real
> > > > > > > > > > > > > > > > > > > >>>> impressive feature set!
> > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > >>> Sure. What I meant was that the
> > > > > > > > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > > > > > > > >>> only
> > > > > > > > > > > > > > > > > > > >>> knows
> > > > > > > > > > > > > > > > > > > >>> about
> > > > > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > > > > >>> tokens
> > > > > > > > > > > > > > > > > > > >>> nothing else. It will always receive
> > > > > > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > > > > >>> regardless
> > > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > > >>> protocol
> > > > > > > > > > > > > > > > > > > >>> used
> > > > > > > > > > > > > > > > > > > >>> to authenticate the user against a
> > > > > > > > > > > > > > > > > > > >>> 3rd
> > > > > > > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > > > > > >>> (saml,
> > > > > > > > > > > > > > > > > > > >>> oidc,
> > > > > > > > > > > > > > > > > > > >>> whatever).
> > > > > > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > > > > > >>> example I gave was about an user
> > > > > > > > > > > > > > > > > > > >>> trying
> > > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > > >>> authenticate
> > > > > > > > > > > > > > > > > > > >>> against
> > > > > > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > > > > > >>> SAML
> > > > > > > > > > > > > > > > > > > >>> IdP.
> > > > > > > > > > > > > > > > > > > >>> In this case, after a successful
> > > > > > > > > > > > > > > > > > > >>> authentication
> > > > > > > > > > > > > > > > > > > >>> on
> > > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > > >>> IdP,
> > > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > > >>> IdP
> > > > > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > > > > >>> issue a token to KC. Then KC will
> > > > > > > > > > > > > > > > > > > >>> validate
> > > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > > >>> token,
> > > > > > > > > > > > > > > > > > > >>> perform
> > > > > > > > > > > > > > > > > > > >>> trust
> > > > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > > > >>> security checks, do user provisioning
> > > > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > > > >>> attribute/claim
> > > > > > > > > > > > > > > > > > > >>> resolution
> > > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > > >>> finally issue a KC token and redirect
> > > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > > >>> user
> > > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > > >>> application.
> > > > > > > > > > > > > > > > > > > >>> If
> > > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > > >>> app is configured to use openid in KC
> > > > > > > > > > > > > > > > > > > >>> then
> > > > > > > > > > > > > > > > > > > >>> it
> > > > > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > > > > >>> receive
> > > > > > > > > > > > > > > > > > > >>> a
> > > > > > > > > > > > > > > > > > > >>> openid
> > > > > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > > > > >>> from KC, not saml ...
> > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > >>> The other scenario is pretty much the
> > > > > > > > > > > > > > > > > > > >>> same.
> > > > > > > > > > > > > > > > > > > >>> The
> > > > > > > > > > > > > > > > > > > >>> difference
> > > > > > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > > > > > >>> that
> > > > > > > > > > > > > > > > > > > >>> KC
> > > > > > > > > > > > > > > > > > > >>> will
> > > > > > > > > > > > > > > > > > > >>> not issue its own token but just
> > > > > > > > > > > > > > > > > > > >>> replay
> > > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > > >>> token
> > > > > > > > > > > > > > > > > > > >>> issued
> > > > > > > > > > > > > > > > > > > >>> by
> > > > > > > > > > > > > > > > > > > >>> the
> > > > > > > > > > > > > > > > > > > >>> 3rd
> > > > > > > > > > > > > > > > > > > >>> party
> > > > > > > > > > > > > > > > > > > >>> IdP to the service provider.
> > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > >>> I agree that this config goes at the
> > > > > > > > > > > > > > > > > > > >>> realm
> > > > > > > > > > > > > > > > > > > >>> level.
> > > > > > > > > > > > > > > > > > > >>> For
> > > > > > > > > > > > > > > > > > > >>> instance,
> > > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > > >>> create
> > > > > > > > > > > > > > > > > > > >>> and
> > > > > > > > > > > > > > > > > > > >>> enable providers for being used.
> > > > > > > > > > > > > > > > > > > >>> However,
> > > > > > > > > > > > > > > > > > > >>> I
> > > > > > > > > > > > > > > > > > > >>> think
> > > > > > > > > > > > > > > > > > > >>> we
> > > > > > > > > > > > > > > > > > > >>> would
> > > > > > > > > > > > > > > > > > > >>> need
> > > > > > > > > > > > > > > > > > > >>> some
> > > > > > > > > > > > > > > > > > > >>> specific configuration for
> > > > > > > > > > > > > > > > > > > >>> applications
> > > > > > > > > > > > > > > > > > > >>> as
> > > > > > > > > > > > > > > > > > > >>> well.
> > > > > > > > > > > > > > > > > > > >>> Specially
> > > > > > > > > > > > > > > > > > > >>> when
> > > > > > > > > > > > > > > > > > > >>> defining
> > > > > > > > > > > > > > > > > > > >>> default roles, mapping attributes.
> > > > > > > > > > > > > > > > > > > >>> Another
> > > > > > > > > > > > > > > > > > > >>> example
> > > > > > > > > > > > > > > > > > > >>> of
> > > > > > > > > > > > > > > > > > > >>> application
> > > > > > > > > > > > > > > > > > > >>> config
> > > > > > > > > > > > > > > > > > > >>> is
> > > > > > > > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may
> > > > > > > > > > > > > > > > > > > >>> want
> > > > > > > > > > > > > > > > > > > >>> to
> > > > > > > > > > > > > > > > > > > >>> define
> > > > > > > > > > > > > > > > > > > >>> scopes
> > > > > > > > > > > > > > > > > > > >>> per-application.
> > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > >>>> --
> > > > > > > > > > > > > > > > > > > >>>> Bill Burke
> > > > > > > > > > > > > > > > > > > >>>> JBoss, a division of Red Hat
> > > > > > > > > > > > > > > > > > > >>>> http://bill.burkecentral.com
> > > > > > > > > > > > > > > > > > > >>>> _______________________________________________
> > > > > > > > > > > > > > > > > > > >>>> keycloak-dev mailing list
> > > > > > > > > > > > > > > > > > > >>>> keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > > > > > > > > > >>> 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
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From bburke at redhat.com  Fri Dec  5 21:08:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 21:08:53 -0500
Subject: [keycloak-dev] Keycloak 1.1.0.Beta2 released
Message-ID: <54826535.3000802@redhat.com>

A lot of new features this release.

     Tomcat 6, 7, and 8 adapters
     Jetty 8.1, 9.1, and 9.2 adapters
     HTTP Security Proxy for platforms that don?t have an adapter based 
on Undertow.
     Wildfly subsystem for auth server.  Allows you to run keycloak in 
domain mode to make it easier to run in a cluster.

Hope to do 1.1.0.Final sometime end of January.  See http://keycloak.org 
for more details

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

From bburke at redhat.com  Sat Dec  6 09:17:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 06 Dec 2014 09:17:32 -0500
Subject: [keycloak-dev] Federated Identity and Authentication Broker
In-Reply-To: <711831466.25373681.1417788942317.JavaMail.zimbra@redhat.com>
References: <364608495.16533527.1416421350553.JavaMail.zimbra@redhat.com>	<2002466225.11250182.1417782130983.JavaMail.zimbra@redhat.com>	<498316011.25296936.1417783524067.JavaMail.zimbra@redhat.com>	<1408711037.11277750.1417784348855.JavaMail.zimbra@redhat.com>	<691652847.25353671.1417786574063.JavaMail.zimbra@redhat.com>	<34814473.11306512.1417787012213.JavaMail.zimbra@redhat.com>	<1510361140.25364644.1417787866789.JavaMail.zimbra@redhat.com>	<4760322.11384589.1417788457523.JavaMail.zimbra@redhat.com>
	<711831466.25373681.1417788942317.JavaMail.zimbra@redhat.com>
Message-ID: <54830FFC.4050408@redhat.com>



On 12/5/2014 9:15 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, December 5, 2014 12:07:37 PM
>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>
>>
>>
>> ----- Original Message -----
>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 5 December, 2014 2:57:46 PM
>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, December 5, 2014 11:43:32 AM
>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, 5 December, 2014 2:36:14 PM
>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>> Broker
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Friday, December 5, 2014 10:59:08 AM
>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>>> Broker
>>>>>>
>>>>>> Another related thing. We've had a few people ask to be able to login
>>>>>> to
>>>>>> Keycloak on mobiles using the native social login mechanism.
>>>>>>
>>>>>> I think the best way to do that is to use the direct grant api and
>>>>>> make
>>>>>> it
>>>>>> possible to call that endpoint passing a IdP id and a token instead
>>>>>> of
>>>>>> username and password.
>>>>>>
>>>>>> WDYT?
>>>>>
>>>>> The broker endpoint expects the idp id in order to start the
>>>>> authentication
>>>>> process. Today, the endpoint also expects KCs authorization code in
>>>>> order
>>>>> to
>>>>> validate requests from clients and use it as a state to validate
>>>>> responses
>>>>> from the trusted idps.
>>>>>
>>>>> This authorization code is a blocker for this use case, given that
>>>>> mobile
>>>>> don't have this code and just want to start the authentication.
>>>>>
>>>>> A possible solution would be to change the broker to also accept a
>>>>> client_id
>>>>> to reference the mobile app and perform some validations based on that.
>>>>> Something like that:
>>>>>
>>>>> 1) Mobile displays a Facebook button
>>>>> 2) User clicks the button and mobile sends a request to KC Broker with
>>>>> the
>>>>> idp id and his client_id.
>>>>> 3) KC Broker checks if the client_id is valid and creates a temporary
>>>>> authorization code.
>>>>> 4) KC Broker redirect mobile to the chosen IdP to perform
>>>>> authentication.
>>>>> 5) KC Broker receives a response from the IdP, generate its own token
>>>>> and
>>>>> send it back to mobile
>>>>>
>>>>> Makes sense ?
>>>>
>>>> No that's not the flow I had in mind. Basically the mobile app
>>>> authenticates
>>>> with Facebook through the native mechanisms. The app then has an access
>>>> token, which it would send to Keycloak on the direct grant api to obtain
>>>> a
>>>> Keycloak token.
>>>
>>> Ahh, now I get what you mean :)
>>>
>>> Yes, what you said is enough. Then we just need to validate the access
>>> token
>>> (eg.: using a tokeninfo endpoint).
>>>
>>> But I think we can also consider that use case I mentioned. You may want to
>>> login without forcing the user to redirect to KC login page.
>>
>> We could just add a query param to the login url that lets you pick the IdP
>> to use by alias?
>>
>>    For example auth/.../login?client_id=...&auth_method=google
>
> Yes, just like my previously example, we need the client_id. The idp id/alias is already there.
>
> Btw, regarding SAML. SAML does not provide a "validation" endpoint like oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the specs for that. What can be done here is validate SAML assertions against a WS-Trust STS. Or just trust the assertion based on the signature and others standards info along it.
>
> We can also take a closer look at the oAuth2 SAML bearer token profile and see if it helps.
>

We can discuss this next week, but I've said before SAML should be 
delegated to an "interoperability/portability" protocol and used only 
with clients that can't install an adapter and don't want to use our 
HTTP security proxy.  We should focus on extensions to OIDC only.  It 
makes no sense to add our own extensions to both SAML and OIDC.

Same goes with bearer token formats.  We put our extensions into JWT.


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

From bburke at redhat.com  Sat Dec  6 09:20:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 06 Dec 2014 09:20:02 -0500
Subject: [keycloak-dev] [keycloak-user] Keycloak 1.1.0.Beta2 released
In-Reply-To: <CAKhWDPR1hpWrM7rmqeBVNrMgrRLcGnVokiSt5VHwGGachoE4Xw@mail.gmail.com>
References: <54826535.3000802@redhat.com>
	<CAKhWDPR1hpWrM7rmqeBVNrMgrRLcGnVokiSt5VHwGGachoE4Xw@mail.gmail.com>
Message-ID: <54831092.50609@redhat.com>

Fixed download page to point back to sf.net

On 12/5/2014 10:59 PM, lanabe wrote:
> Congratulations!
>
> Recently I started to apply Kyecloak to my personally simple blog
> application(using WildFly 8.2.0.FInal, JSF, JAX-RS,...).
> Keycloak is very easy to use!
>
> BTW,  the download page(http://keycloak.jboss.org/downloads) remains
> 1.1.0.Beta1.
> # I got the new binary at
> http://sourceforge.net/projects/keycloak/files/1.1.0.Beta2 .
>
> Thanks.
>
> Yoshimasa Tanabe
>
> On Sat, Dec 6, 2014 at 11:08 AM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     A lot of new features this release.
>
>           Tomcat 6, 7, and 8 adapters
>           Jetty 8.1, 9.1, and 9.2 adapters
>           HTTP Security Proxy for platforms that don?t have an adapter based
>     on Undertow.
>           Wildfly subsystem for auth server.  Allows you to run keycloak in
>     domain mode to make it easier to run in a cluster.
>
>     Hope to do 1.1.0.Final sometime end of January.  See http://keycloak.org
>     for more details
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

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

From bburke at redhat.com  Sat Dec  6 10:56:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 06 Dec 2014 10:56:26 -0500
Subject: [keycloak-dev] blog topics
Message-ID: <5483272A.5090805@redhat.com>

There's a bunch of different blogs/articles we could write over the next 
few months to discuss/promote Keycloak and web security.  Here's some ideas:

Keycloak approach to federation:
* discuss our import and sync approach
* discuss IDP federation (when Pedro gets it in).

Validating CORS requests with Keycloak:
* Discuss what CORS is and why it exists
* Discuss how Keycloak helps to manage CORS requests

Preventing CSRF:
* Discuss what CSRF is and how HTTP SEssion/cookie based security is 
vulnerable
* Discuss how to mitigate with bearer tokens, CORS, and other techniques 
we use for old-school web apps.

Preventing Clickjacking
* What is clickjacking.
* discuss HTTP headers that apps can pass back to prevent this.

How to brand/embed Keycloak to make it look like your product.

There's other ones we can write down the line when we get more features 
in:  for mobile, keycloak and the enterprise, etc...

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

From bburke at redhat.com  Sun Dec  7 10:06:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Sun, 07 Dec 2014 10:06:19 -0500
Subject: [keycloak-dev] Fwd: [OAUTH-WG] I-D Action:
	draft-ietf-oauth-dyn-reg-management-06.txt
In-Reply-To: <20141207043855.11221.58305.idtracker@ietfa.amsl.com>
References: <20141207043855.11221.58305.idtracker@ietfa.amsl.com>
Message-ID: <54846CEB.1070608@redhat.com>




-------- Original Message --------
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-06.txt
Date: Sat, 06 Dec 2014 20:38:55 -0800
From: internet-drafts at ietf.org
To: i-d-announce at ietf.org
CC: oauth at ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
  This draft is a work item of the Web Authorization Protocol Working 
Group of the IETF.

         Title           : OAuth 2.0 Dynamic Client Registration 
Management Protocol
         Authors         : Justin Richer
                           Michael B. Jones
                           John Bradley
                           Maciej Machulak
	Filename        : draft-ietf-oauth-dyn-reg-management-06.txt
	Pages           : 17
	Date            : 2014-12-06

Abstract:
    This specification defines methods for management of dynamic OAuth
    2.0 client registrations for use cases in which the properties of a
    registered client may need to be changed during the lifetime of the
    client.  Not all authorization servers supporting dynamic client
    registration will support these management methods.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth at ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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



From mposolda at redhat.com  Mon Dec  8 06:20:33 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 08 Dec 2014 12:20:33 +0100
Subject: [keycloak-dev] [keycloak-user] Keycloak 1.1.0.Beta2 released
In-Reply-To: <54826535.3000802@redhat.com>
References: <54826535.3000802@redhat.com>
Message-ID: <54858981.7060407@redhat.com>

It seems there is missing version update in bower.json in 
keycloak-js-bower . Sent PR for this, but can't merge it. Also it would 
be needed to push 1.1.0.Beta2 tag to keycloak-js-bower repo.

Marek

On 6.12.2014 03:08, Bill Burke wrote:
> A lot of new features this release.
>
>       Tomcat 6, 7, and 8 adapters
>       Jetty 8.1, 9.1, and 9.2 adapters
>       HTTP Security Proxy for platforms that don?t have an adapter based
> on Undertow.
>       Wildfly subsystem for auth server.  Allows you to run keycloak in
> domain mode to make it easier to run in a cluster.
>
> Hope to do 1.1.0.Final sometime end of January.  See http://keycloak.org
> for more details
>


From matzew at apache.org  Thu Dec 11 10:50:39 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 11 Dec 2014 16:50:39 +0100
Subject: [keycloak-dev] Database script for manual migration?
Message-ID: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>

Hi,

I am wondering do you guys have a .sql script for going from '1.0-beta-4'
to '1.0.4.Final' ?

My motivation is updating the an instance of UPS 1.0.0.Final (was using
Keycloak-1.0-beta-4) to latest stable release candidate (1.0.3-SNAPSHOT,
which is using Keycloak-1.0.4.Final)

Deploying the new auth-server (that we build ourselfs), is giving me this
(with Postgres and MySQL)




13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-15)
MSC000001: Failed to start service
jboss.undertow.deployment.default-server.default-host./auth:
org.jboss.msc.service.StartException in service
jboss.undertow.deployment.default-server.default-host./auth: Failed to
start service
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_65]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
Caused by: java.lang.RuntimeException: Failed to construct public
org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
at
org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
at
org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
at
org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
at
org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
at
io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at
org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
at
io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at
io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
at
io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
at
io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
... 3 more
Caused by: org.keycloak.models.ModelException:
javax.persistence.PersistenceException:
org.hibernate.PropertyAccessException: Null value was assigned to a
property of primitive type setter of
org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
at com.sun.proxy.$Proxy128.find(Unknown Source)
at
org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
at
org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
at
org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
at
org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
at
org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
at
org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
at
org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
at
org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[rt.jar:1.7.0_65]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
[rt.jar:1.7.0_65]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[rt.jar:1.7.0_65]
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
[rt.jar:1.7.0_65]
at
org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
... 18 more
Caused by: javax.persistence.PersistenceException:
org.hibernate.PropertyAccessException: Null value was assigned to a
property of primitive type setter of
org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.7.0_65]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[rt.jar:1.7.0_65]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_65]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
... 32 more
Caused by: org.hibernate.PropertyAccessException: Null value was assigned
to a property of primitive type setter of
org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
at
org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
at
org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
at
org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
at
org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
at
org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
at
org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
at
org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
at
org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
at
org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
at
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
at
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
at
org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
at
org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
at
org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
at
org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
at
org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
at
org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
at
org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
at
org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
... 38 more
Caused by: java.lang.IllegalArgumentException: Can not set boolean field
org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null value
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
[rt.jar:1.7.0_65]
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
[rt.jar:1.7.0_65]
at
sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
[rt.jar:1.7.0_65]
at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
at
org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
... 60 more

13:32:29,205 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address:
([("deployment" => "auth-server.war")]) - failure description:
{"JBAS014671: Failed services" =>
{"jboss.undertow.deployment.default-server.default-host./auth" =>
"org.jboss.msc.service.StartException in service
jboss.undertow.deployment.default-server.default-host./auth: Failed to
start service
    Caused by: java.lang.RuntimeException: Failed to construct public
org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
    Caused by: org.keycloak.models.ModelException:
javax.persistence.PersistenceException:
org.hibernate.PropertyAccessException: Null value was assigned to a
property of primitive type setter of
org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
    Caused by: javax.persistence.PersistenceException:
org.hibernate.PropertyAccessException: Null value was assigned to a
property of primitive type setter of
org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
    Caused by: org.hibernate.PropertyAccessException: Null value was
assigned to a property of primitive type setter of
org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
    Caused by: java.lang.IllegalArgumentException: Can not set boolean
field org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null
value"}}


Thanks,
Matthias

-- 
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/20141211/7978096e/attachment-0001.html 

From mposolda at redhat.com  Fri Dec 12 04:32:36 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Dec 2014 10:32:36 +0100
Subject: [keycloak-dev] Database script for manual migration?
In-Reply-To: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>
References: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>
Message-ID: <548AB634.2020805@redhat.com>

Unfortunately I don't think that we have this. We have automatic 
migration available with liquibase, but this is from 1.0.0.Final (or 
newer) to 1.1.0.X .

Marek

On 11.12.2014 16:50, Matthias Wessendorf wrote:
> Hi,
>
> I am wondering do you guys have a .sql script for going from 
> '1.0-beta-4' to '1.0.4.Final' ?
>
> My motivation is updating the an instance of UPS 1.0.0.Final (was 
> using Keycloak-1.0-beta-4) to latest stable release candidate 
> (1.0.3-SNAPSHOT, which is using Keycloak-1.0.4.Final)
>
> Deploying the new auth-server (that we build ourselfs), is giving me 
> this (with Postgres and MySQL)
>
>
>
>
> 13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service thread 
> 1-15) MSC000001: Failed to start service 
> jboss.undertow.deployment.default-server.default-host./auth: 
> org.jboss.msc.service.StartException in service 
> jboss.undertow.deployment.default-server.default-host./auth: Failed to 
> start service
> at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) 
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
> [rt.jar:1.7.0_65]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
> [rt.jar:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: java.lang.RuntimeException: Failed to construct public 
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
> at 
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
> at 
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
> at 
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
> at 
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
> at 
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
> at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at 
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at 
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
> at 
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at 
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
> at 
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
> at 
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
> at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
> at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
> at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) 
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) 
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> Caused by: org.keycloak.models.ModelException: 
> javax.persistence.PersistenceException: 
> org.hibernate.PropertyAccessException: Null value was assigned to a 
> property of primitive type setter of 
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> at 
> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
> at 
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
> at com.sun.proxy.$Proxy128.find(Unknown Source)
> at 
> org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
> at 
> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
> at 
> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
> at 
> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
> at 
> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
> at 
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
> at 
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
> at 
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method) [rt.jar:1.7.0_65]
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) 
> [rt.jar:1.7.0_65]
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 
> [rt.jar:1.7.0_65]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) 
> [rt.jar:1.7.0_65]
> at 
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
> ... 18 more
> Caused by: javax.persistence.PersistenceException: 
> org.hibernate.PropertyAccessException: Null value was assigned to a 
> property of primitive type setter of 
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694)
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> [rt.jar:1.7.0_65]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> [rt.jar:1.7.0_65]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
> [rt.jar:1.7.0_65]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> at 
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
> ... 32 more
> Caused by: org.hibernate.PropertyAccessException: Null value was 
> assigned to a property of primitive type setter of 
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> at 
> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
> at 
> org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
> at 
> org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
> at 
> org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
> at 
> org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
> at 
> org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
> at 
> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
> at 
> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
> at 
> org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
> at 
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
> at 
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
> at 
> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
> at 
> org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
> at 
> org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
> at 
> org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
> at 
> org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
> at 
> org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
> at 
> org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
> at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
> at 
> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
> at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
> ... 38 more
> Caused by: java.lang.IllegalArgumentException: Can not set boolean 
> field org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to 
> null value
> at 
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) 
> [rt.jar:1.7.0_65]
> at 
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) 
> [rt.jar:1.7.0_65]
> at 
> sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) 
> [rt.jar:1.7.0_65]
> at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
> at 
> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
> ... 60 more
>
> 13:32:29,205 ERROR [org.jboss.as.controller.management-operation] 
> (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - 
> address: ([("deployment" => "auth-server.war")]) - failure 
> description: {"JBAS014671: Failed services" => 
> {"jboss.undertow.deployment.default-server.default-host./auth" => 
> "org.jboss.msc.service.StartException in service 
> jboss.undertow.deployment.default-server.default-host./auth: Failed to 
> start service
>     Caused by: java.lang.RuntimeException: Failed to construct public 
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>     Caused by: org.keycloak.models.ModelException: 
> javax.persistence.PersistenceException: 
> org.hibernate.PropertyAccessException: Null value was assigned to a 
> property of primitive type setter of 
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>     Caused by: javax.persistence.PersistenceException: 
> org.hibernate.PropertyAccessException: Null value was assigned to a 
> property of primitive type setter of 
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>     Caused by: org.hibernate.PropertyAccessException: Null value was 
> assigned to a property of primitive type setter of 
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>     Caused by: java.lang.IllegalArgumentException: Can not set boolean 
> field org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to 
> null value"}}
>
>
> Thanks,
> Matthias
>
> -- 
> 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

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

From matzew at apache.org  Fri Dec 12 05:50:49 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 12 Dec 2014 11:50:49 +0100
Subject: [keycloak-dev] Database script for manual migration?
In-Reply-To: <548AB634.2020805@redhat.com>
References: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>
	<548AB634.2020805@redhat.com>
Message-ID: <CAAg5f2S=JyUWnAzC-FtOja8LCSy+6dpERKSL1wNeDe88Srrnzg@mail.gmail.com>

Hi Marek,

any chance to get a script to get that kinda migration done manually? I
think this is now blocking us from upgrading to 1.0.4.Final (from 1.0-beta-4,
which we used in our 1.0.0.Final)

thanks,
Matthias

On Fri, Dec 12, 2014 at 10:32 AM, Marek Posolda <mposolda at redhat.com> wrote:
>
>  Unfortunately I don't think that we have this. We have automatic
> migration available with liquibase, but this is from 1.0.0.Final (or newer)
> to 1.1.0.X .
>
> Marek
>
>
> On 11.12.2014 16:50, Matthias Wessendorf wrote:
>
>  Hi,
>
>  I am wondering do you guys have a .sql script for going from
> '1.0-beta-4' to '1.0.4.Final' ?
>
>  My motivation is updating the an instance of UPS 1.0.0.Final (was using
> Keycloak-1.0-beta-4) to latest stable release candidate (1.0.3-SNAPSHOT,
> which is using Keycloak-1.0.4.Final)
>
>  Deploying the new auth-server (that we build ourselfs), is giving me
> this (with Postgres and MySQL)
>
>
>
>
>  13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service thread
> 1-15) MSC000001: Failed to start service
> jboss.undertow.deployment.default-server.default-host./auth:
> org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./auth: Failed to
> start service
>  at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [rt.jar:1.7.0_65]
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [rt.jar:1.7.0_65]
>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: java.lang.RuntimeException: Failed to construct public
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>  at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
>  at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
>  at
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
>  at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
>  at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
>  at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>  at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>  at
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
>  at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>  at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
>  at
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
>  at
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
>  at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
>  at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>  at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>  at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>  ... 3 more
> Caused by: org.keycloak.models.ModelException:
> javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: Null value was assigned to a
> property of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>  at
> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
>  at
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
>  at com.sun.proxy.$Proxy128.find(Unknown Source)
>  at
> org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
>  at
> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
>  at
> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
>  at
> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
>  at
> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
>  at
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
>  at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
>  at
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> [rt.jar:1.7.0_65]
>  at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> [rt.jar:1.7.0_65]
>  at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [rt.jar:1.7.0_65]
>  at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> [rt.jar:1.7.0_65]
>  at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
>  ... 18 more
> Caused by: javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: Null value was assigned to a
> property of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>  at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
>  at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:
> 1694)
>  at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
>  at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_65]
>  at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_65]
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_65]
>  at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
>  at
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
>  ... 32 more
> Caused by: org.hibernate.PropertyAccessException: Null value was assigned
> to a property of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>  at
> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
>  at
> org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
>  at
> org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
>  at
> org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
>  at
> org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
>  at
> org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
>  at
> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
>  at
> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
>  at
> org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
>  at
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
>  at
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
>  at
> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
>  at
> org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
>  at
> org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
>  at
> org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
>  at
> org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
>  at
> org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
>  at
> org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
>  at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
>  at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
>  at
> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
>  at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
>  at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
>  ... 38 more
> Caused by: java.lang.IllegalArgumentException: Can not set boolean field
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null value
>  at
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
> [rt.jar:1.7.0_65]
>  at
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
> [rt.jar:1.7.0_65]
>  at
> sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
> [rt.jar:1.7.0_65]
>  at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
>  at
> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
>  ... 60 more
>
>  13:32:29,205 ERROR [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address:
> ([("deployment" => "auth-server.war")]) - failure description:
> {"JBAS014671: Failed services" =>
> {"jboss.undertow.deployment.default-server.default-host./auth" =>
> "org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./auth: Failed to
> start service
>     Caused by: java.lang.RuntimeException: Failed to construct public
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>     Caused by: org.keycloak.models.ModelException:
> javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: Null value was assigned to a
> property of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>     Caused by: javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: Null value was assigned to a
> property of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>     Caused by: org.hibernate.PropertyAccessException: Null value was
> assigned to a property of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>     Caused by: java.lang.IllegalArgumentException: Can not set boolean
> field org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null
> value"}}
>
>
>  Thanks,
> Matthias
>
>  --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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/20141212/61306da5/attachment-0001.html 

From matzew at apache.org  Fri Dec 12 06:27:11 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 12 Dec 2014 12:27:11 +0100
Subject: [keycloak-dev] Database script for manual migration?
In-Reply-To: <CAAg5f2S=JyUWnAzC-FtOja8LCSy+6dpERKSL1wNeDe88Srrnzg@mail.gmail.com>
References: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>
	<548AB634.2020805@redhat.com>
	<CAAg5f2S=JyUWnAzC-FtOja8LCSy+6dpERKSL1wNeDe88Srrnzg@mail.gmail.com>
Message-ID: <CAAg5f2Qc=fJZrxNVCTExq5Si_Mk+s3tXxZmS2KjPkSff+jpcTw@mail.gmail.com>

I *think* I tracked it down to this commit:

https://github.com/keycloak/keycloak/commit/3bfe3d256ed0c292fbb040fa2276c737c3798864

the 'org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled' field is
present in KC 1.0.Final, but not in the 1.0-beta-4.




On Fri, Dec 12, 2014 at 11:50 AM, Matthias Wessendorf <matzew at apache.org>
wrote:
>
> Hi Marek,
>
> any chance to get a script to get that kinda migration done manually? I
> think this is now blocking us from upgrading to 1.0.4.Final (from 1.0-beta-4,
> which we used in our 1.0.0.Final)
>
> thanks,
> Matthias
>
> On Fri, Dec 12, 2014 at 10:32 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
>>
>>  Unfortunately I don't think that we have this. We have automatic
>> migration available with liquibase, but this is from 1.0.0.Final (or newer)
>> to 1.1.0.X .
>>
>> Marek
>>
>>
>> On 11.12.2014 16:50, Matthias Wessendorf wrote:
>>
>>  Hi,
>>
>>  I am wondering do you guys have a .sql script for going from
>> '1.0-beta-4' to '1.0.4.Final' ?
>>
>>  My motivation is updating the an instance of UPS 1.0.0.Final (was using
>> Keycloak-1.0-beta-4) to latest stable release candidate (1.0.3-SNAPSHOT,
>> which is using Keycloak-1.0.4.Final)
>>
>>  Deploying the new auth-server (that we build ourselfs), is giving me
>> this (with Postgres and MySQL)
>>
>>
>>
>>
>>  13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service thread
>> 1-15) MSC000001: Failed to start service
>> jboss.undertow.deployment.default-server.default-host./auth:
>> org.jboss.msc.service.StartException in service
>> jboss.undertow.deployment.default-server.default-host./auth: Failed to
>> start service
>>  at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>  at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> [rt.jar:1.7.0_65]
>>  at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> [rt.jar:1.7.0_65]
>>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
>> Caused by: java.lang.RuntimeException: Failed to construct public
>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>  at
>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
>>  at
>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
>>  at
>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
>>  at
>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
>>  at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
>>  at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>>  at
>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>>  at
>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
>>  at
>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>>  at
>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
>>  at
>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
>>  at
>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
>>  at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
>>  at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>>  at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>  at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>  ... 3 more
>> Caused by: org.keycloak.models.ModelException:
>> javax.persistence.PersistenceException:
>> org.hibernate.PropertyAccessException: Null value was assigned to a
>> property of primitive type setter of
>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>  at
>> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
>>  at
>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
>>  at com.sun.proxy.$Proxy128.find(Unknown Source)
>>  at
>> org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
>>  at
>> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
>>  at
>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
>>  at
>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
>>  at
>> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
>>  at
>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
>>  at
>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
>>  at
>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
>>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method) [rt.jar:1.7.0_65]
>>  at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>> [rt.jar:1.7.0_65]
>>  at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> [rt.jar:1.7.0_65]
>>  at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>> [rt.jar:1.7.0_65]
>>  at
>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
>>  ... 18 more
>> Caused by: javax.persistence.PersistenceException:
>> org.hibernate.PropertyAccessException: Null value was assigned to a
>> property of primitive type setter of
>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>  at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
>>  at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:
>> 1694)
>>  at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
>>  at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [rt.jar:1.7.0_65]
>>  at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> [rt.jar:1.7.0_65]
>>  at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.7.0_65]
>>  at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
>>  at
>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
>>  ... 32 more
>> Caused by: org.hibernate.PropertyAccessException: Null value was assigned
>> to a property of primitive type setter of
>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>  at
>> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
>>  at
>> org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
>>  at
>> org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
>>  at
>> org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
>>  at
>> org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
>>  at
>> org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
>>  at
>> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
>>  at
>> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
>>  at
>> org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
>>  at
>> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
>>  at
>> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
>>  at
>> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
>>  at
>> org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
>>  at
>> org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
>>  at
>> org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
>>  at
>> org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
>>  at
>> org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
>>  at
>> org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
>>  at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
>>  at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
>>  at
>> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
>>  at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
>>  at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
>>  ... 38 more
>> Caused by: java.lang.IllegalArgumentException: Can not set boolean field
>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null value
>>  at
>> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
>> [rt.jar:1.7.0_65]
>>  at
>> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
>> [rt.jar:1.7.0_65]
>>  at
>> sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
>> [rt.jar:1.7.0_65]
>>  at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
>>  at
>> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
>>  ... 60 more
>>
>>  13:32:29,205 ERROR [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address:
>> ([("deployment" => "auth-server.war")]) - failure description:
>> {"JBAS014671: Failed services" =>
>> {"jboss.undertow.deployment.default-server.default-host./auth" =>
>> "org.jboss.msc.service.StartException in service
>> jboss.undertow.deployment.default-server.default-host./auth: Failed to
>> start service
>>     Caused by: java.lang.RuntimeException: Failed to construct public
>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>     Caused by: org.keycloak.models.ModelException:
>> javax.persistence.PersistenceException:
>> org.hibernate.PropertyAccessException: Null value was assigned to a
>> property of primitive type setter of
>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>     Caused by: javax.persistence.PersistenceException:
>> org.hibernate.PropertyAccessException: Null value was assigned to a
>> property of primitive type setter of
>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>     Caused by: org.hibernate.PropertyAccessException: Null value was
>> assigned to a property of primitive type setter of
>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>     Caused by: java.lang.IllegalArgumentException: Can not set boolean
>> field org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null
>> value"}}
>>
>>
>>  Thanks,
>> Matthias
>>
>>  --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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
>


-- 
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/20141212/86c2a31b/attachment-0001.html 

From mposolda at redhat.com  Fri Dec 12 08:22:33 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Dec 2014 14:22:33 +0100
Subject: [keycloak-dev] Database script for manual migration?
In-Reply-To: <CAAg5f2Qc=fJZrxNVCTExq5Si_Mk+s3tXxZmS2KjPkSff+jpcTw@mail.gmail.com>
References: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>	<548AB634.2020805@redhat.com>	<CAAg5f2S=JyUWnAzC-FtOja8LCSy+6dpERKSL1wNeDe88Srrnzg@mail.gmail.com>
	<CAAg5f2Qc=fJZrxNVCTExq5Si_Mk+s3tXxZmS2KjPkSff+jpcTw@mail.gmail.com>
Message-ID: <548AEC19.2010002@redhat.com>

This is related to renaming of 'audit' to 'events', which was done after 
1.0-beta-4 and affect db schema.

I've checked that there are no more major changes to db schema and these 
3 commands helped to migrate my MySQL 5 from beta-4 to 1.0.4.Final:

rename table REALM_AUDIT_LISTENERS to REALM_EVENTS_LISTENERS;
alter table REALM change AUDIT_ENABLED EVENTS_ENABLED bit(1);
alter table REALM change AUDIT_EXPIRATION EVENTS_EXPIRATION bigint(20);

However not sure if same commands work for other databases.

Marek

On 12.12.2014 12:27, Matthias Wessendorf wrote:
> I *think* I tracked it down to this commit:
>
> https://github.com/keycloak/keycloak/commit/3bfe3d256ed0c292fbb040fa2276c737c3798864
>
> the 'org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled' field 
> is present in KC 1.0.Final, but not in the 1.0-beta-4.
>
>
>
>
> On Fri, Dec 12, 2014 at 11:50 AM, Matthias Wessendorf 
> <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>
>     Hi Marek,
>
>     any chance to get a script to get that kinda migration done
>     manually? I think this is now blocking us from upgrading to
>     1.0.4.Final (from 1.0-beta-4, which we used in our 1.0.0.Final)
>
>     thanks,
>     Matthias
>
>     On Fri, Dec 12, 2014 at 10:32 AM, Marek Posolda
>     <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>
>         Unfortunately I don't think that we have this. We have
>         automatic migration available with liquibase, but this is from
>         1.0.0.Final (or newer) to 1.1.0.X .
>
>         Marek
>
>
>         On 11.12.2014 16:50, Matthias Wessendorf wrote:
>>         Hi,
>>
>>         I am wondering do you guys have a .sql script for going from
>>         '1.0-beta-4' to '1.0.4.Final' ?
>>
>>         My motivation is updating the an instance of UPS 1.0.0.Final
>>         (was using Keycloak-1.0-beta-4) to latest stable release
>>         candidate (1.0.3-SNAPSHOT, which is using Keycloak-1.0.4.Final)
>>
>>         Deploying the new auth-server (that we build ourselfs), is
>>         giving me this (with Postgres and MySQL)
>>
>>
>>
>>
>>         13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service
>>         thread 1-15) MSC000001: Failed to start service
>>         jboss.undertow.deployment.default-server.default-host./auth:
>>         org.jboss.msc.service.StartException in service
>>         jboss.undertow.deployment.default-server.default-host./auth:
>>         Failed to start service
>>         at
>>         org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>>         [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>         at
>>         java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>         [rt.jar:1.7.0_65]
>>         at
>>         java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>         [rt.jar:1.7.0_65]
>>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
>>         Caused by: java.lang.RuntimeException: Failed to construct
>>         public
>>         org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>         at
>>         org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
>>         at
>>         org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
>>         at
>>         org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
>>         at
>>         org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
>>         at
>>         org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
>>         at
>>         org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>>         at
>>         io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>>         at
>>         org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
>>         at
>>         io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>>         at
>>         io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
>>         at
>>         io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
>>         at
>>         io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
>>         at
>>         org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
>>         at
>>         org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>>         at
>>         org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>>         [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>         at
>>         org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>>         [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>         ... 3 more
>>         Caused by: org.keycloak.models.ModelException:
>>         javax.persistence.PersistenceException:
>>         org.hibernate.PropertyAccessException: Null value was
>>         assigned to a property of primitive type setter of
>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>         at
>>         org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
>>         at
>>         org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
>>         at com.sun.proxy.$Proxy128.find(Unknown Source)
>>         at
>>         org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
>>         at
>>         org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
>>         at
>>         org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
>>         at
>>         org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
>>         at
>>         org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
>>         at
>>         org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
>>         at
>>         org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
>>         at
>>         org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
>>         at
>>         sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>         Method) [rt.jar:1.7.0_65]
>>         at
>>         sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>>         [rt.jar:1.7.0_65]
>>         at
>>         sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>         [rt.jar:1.7.0_65]
>>         at
>>         java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>>         [rt.jar:1.7.0_65]
>>         at
>>         org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
>>         ... 18 more
>>         Caused by: javax.persistence.PersistenceException:
>>         org.hibernate.PropertyAccessException: Null value was
>>         assigned to a property of primitive type setter of
>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>         at
>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
>>         at
>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694
>>         <tel:1694>)
>>         at
>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
>>         at
>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>         Method) [rt.jar:1.7.0_65]
>>         at
>>         sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>         [rt.jar:1.7.0_65]
>>         at
>>         sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>         [rt.jar:1.7.0_65]
>>         at java.lang.reflect.Method.invoke(Method.java:606)
>>         [rt.jar:1.7.0_65]
>>         at
>>         org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
>>         ... 32 more
>>         Caused by: org.hibernate.PropertyAccessException: Null value
>>         was assigned to a property of primitive type setter of
>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>         at
>>         org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
>>         at
>>         org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
>>         at
>>         org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
>>         at
>>         org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
>>         at
>>         org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
>>         at
>>         org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
>>         at
>>         org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
>>         at
>>         org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
>>         at
>>         org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
>>         at
>>         org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
>>         at
>>         org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
>>         at
>>         org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
>>         at
>>         org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
>>         at
>>         org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
>>         at
>>         org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
>>         at
>>         org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
>>         at
>>         org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
>>         at
>>         org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
>>         at
>>         org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
>>         at
>>         org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
>>         at
>>         org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
>>         at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
>>         at
>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
>>         ... 38 more
>>         Caused by: java.lang.IllegalArgumentException: Can not set
>>         boolean field
>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to
>>         null value
>>         at
>>         sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
>>         [rt.jar:1.7.0_65]
>>         at
>>         sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
>>         [rt.jar:1.7.0_65]
>>         at
>>         sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
>>         [rt.jar:1.7.0_65]
>>         at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
>>         at
>>         org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
>>         ... 60 more
>>
>>         13:32:29,205 ERROR
>>         [org.jboss.as.controller.management-operation] (Controller
>>         Boot Thread) JBAS014613: Operation ("deploy") failed -
>>         address: ([("deployment" => "auth-server.war")]) - failure
>>         description: {"JBAS014671: Failed services" =>
>>         {"jboss.undertow.deployment.default-server.default-host./auth" =>
>>         "org.jboss.msc.service.StartException in service
>>         jboss.undertow.deployment.default-server.default-host./auth:
>>         Failed to start service
>>             Caused by: java.lang.RuntimeException: Failed to
>>         construct public
>>         org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>             Caused by: org.keycloak.models.ModelException:
>>         javax.persistence.PersistenceException:
>>         org.hibernate.PropertyAccessException: Null value was
>>         assigned to a property of primitive type setter of
>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>             Caused by: javax.persistence.PersistenceException:
>>         org.hibernate.PropertyAccessException: Null value was
>>         assigned to a property of primitive type setter of
>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>             Caused by: org.hibernate.PropertyAccessException: Null
>>         value was assigned to a property of primitive type setter of
>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>             Caused by: java.lang.IllegalArgumentException: Can not
>>         set boolean field
>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to
>>         null value"}}
>>
>>
>>         Thanks,
>>         Matthias
>>
>>         -- 
>>         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  <mailto: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
>
>
>
> -- 
> 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/20141212/2f612d77/attachment-0001.html 

From bburke at redhat.com  Sat Dec 13 09:19:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 13 Dec 2014 09:19:02 -0500
Subject: [keycloak-dev] sorry, we were away
Message-ID: <548C4AD6.2000009@redhat.com>

Hey Keycloak community,

Sorry if we were unresponsive last week...We were in Brno for a face to 
face meeting of entire team.  One of us will blog about it next week 
sometime.


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

From stian at redhat.com  Mon Dec 15 04:39:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 15 Dec 2014 04:39:44 -0500 (EST)
Subject: [keycloak-dev] Database script for manual migration?
In-Reply-To: <CAAg5f2Qc=fJZrxNVCTExq5Si_Mk+s3tXxZmS2KjPkSff+jpcTw@mail.gmail.com>
References: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>
	<548AB634.2020805@redhat.com>
	<CAAg5f2S=JyUWnAzC-FtOja8LCSy+6dpERKSL1wNeDe88Srrnzg@mail.gmail.com>
	<CAAg5f2Qc=fJZrxNVCTExq5Si_Mk+s3tXxZmS2KjPkSff+jpcTw@mail.gmail.com>
Message-ID: <1453586995.17721144.1418636384955.JavaMail.zimbra@redhat.com>

We can sort out something for you guys. When do you need it?

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at apache.org>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 12 December, 2014 12:27:11 PM
> Subject: Re: [keycloak-dev] Database script for manual migration?
> 
> I *think* I tracked it down to this commit:
> 
> https://github.com/keycloak/keycloak/commit/3bfe3d256ed0c292fbb040fa2276c737c3798864
> 
> the ' org.keycloak.models.jpa. entities.RealmEntity. eventsEnabled' field is
> present in KC 1.0.Final, but not in the 1.0-beta-4.
> 
> 
> 
> 
> On Fri, Dec 12, 2014 at 11:50 AM, Matthias Wessendorf < matzew at apache.org >
> wrote:
> 
> 
> Hi Marek,
> 
> any chance to get a script to get that kinda migration done manually? I think
> this is now blocking us from upgrading to 1.0.4.Final (from 1.0-beta-4,
> which we used in our 1.0.0.Final)
> 
> thanks,
> Matthias
> 
> On Fri, Dec 12, 2014 at 10:32 AM, Marek Posolda < mposolda at redhat.com >
> wrote:
> 
> 
> Unfortunately I don't think that we have this. We have automatic migration
> available with liquibase, but this is from 1.0.0.Final (or newer) to 1.1.0.X
> .
> 
> Marek
> 
> 
> On 11.12.2014 16:50, Matthias Wessendorf wrote:
> 
> 
> 
> Hi,
> 
> I am wondering do you guys have a .sql script for going from '1.0-beta-4' to
> '1.0.4.Final' ?
> 
> My motivation is updating the an instance of UPS 1.0.0.Final (was using
> Keycloak-1.0-beta-4) to latest stable release candidate (1.0.3-SNAPSHOT,
> which is using Keycloak-1.0.4.Final)
> 
> Deploying the new auth-server (that we build ourselfs), is giving me this
> (with Postgres and MySQL)
> 
> 
> 
> 
> 13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-15)
> MSC000001: Failed to start service
> jboss.undertow.deployment.default-server.default-host./auth:
> org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./auth: Failed to start
> service
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [rt.jar:1.7.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [rt.jar:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: java.lang.RuntimeException: Failed to construct public
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
> at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
> at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
> at
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
> at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
> at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
> at
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
> at
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
> at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
> at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> Caused by: org.keycloak.models.ModelException:
> javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: Null value was assigned to a property
> of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> at
> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
> at
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
> at com.sun.proxy.$Proxy128.find(Unknown Source)
> at
> org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
> at
> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
> at
> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
> at
> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
> at
> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
> at
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
> at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
> at
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> [rt.jar:1.7.0_65]
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> [rt.jar:1.7.0_65]
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [rt.jar:1.7.0_65]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> [rt.jar:1.7.0_65]
> at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
> ... 18 more
> Caused by: javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: Null value was assigned to a property
> of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:
> 1694 )
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_65]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_65]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_65]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> at
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
> ... 32 more
> Caused by: org.hibernate.PropertyAccessException: Null value was assigned to
> a property of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> at
> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
> at
> org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
> at
> org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
> at
> org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
> at
> org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
> at
> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
> at
> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
> at
> org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
> at
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
> at
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
> at
> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
> at
> org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
> at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
> at
> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
> at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
> ... 38 more
> Caused by: java.lang.IllegalArgumentException: Can not set boolean field
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null value
> at
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
> [rt.jar:1.7.0_65]
> at
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
> [rt.jar:1.7.0_65]
> at
> sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
> [rt.jar:1.7.0_65]
> at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
> at
> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
> ... 60 more
> 
> 13:32:29,205 ERROR [org.jboss.as.controller.management-operation] (Controller
> Boot Thread) JBAS014613: Operation ("deploy") failed - address:
> ([("deployment" => "auth-server.war")]) - failure description: {"JBAS014671:
> Failed services" =>
> {"jboss.undertow.deployment.default-server.default-host./auth" =>
> "org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./auth: Failed to start
> service
> Caused by: java.lang.RuntimeException: Failed to construct public
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
> Caused by: org.keycloak.models.ModelException:
> javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: Null value was assigned to a property
> of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> Caused by: javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: Null value was assigned to a property
> of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> Caused by: org.hibernate.PropertyAccessException: Null value was assigned to
> a property of primitive type setter of
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> Caused by: java.lang.IllegalArgumentException: Can not set boolean field
> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null value"}}
> 
> 
> Thanks,
> Matthias
> 
> --
> 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
> 
> 
> --
> 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

From matzew at apache.org  Mon Dec 15 09:24:54 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 15 Dec 2014 15:24:54 +0100
Subject: [keycloak-dev] Database script for manual migration?
In-Reply-To: <1453586995.17721144.1418636384955.JavaMail.zimbra@redhat.com>
References: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>
	<548AB634.2020805@redhat.com>
	<CAAg5f2S=JyUWnAzC-FtOja8LCSy+6dpERKSL1wNeDe88Srrnzg@mail.gmail.com>
	<CAAg5f2Qc=fJZrxNVCTExq5Si_Mk+s3tXxZmS2KjPkSff+jpcTw@mail.gmail.com>
	<1453586995.17721144.1418636384955.JavaMail.zimbra@redhat.com>
Message-ID: <CAAg5f2T7FdSt0fX0ty2XgG-bwUkcHNVvWeBwg3eckTWSEgFG5w@mail.gmail.com>

Marek helped me already - PR against UPS is pending :)

On Mon, Dec 15, 2014 at 10:39 AM, Stian Thorgersen <stian at redhat.com> wrote:
>
> We can sort out something for you guys. When do you need it?
>
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at apache.org>
> > To: "Marek Posolda" <mposolda at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 12 December, 2014 12:27:11 PM
> > Subject: Re: [keycloak-dev] Database script for manual migration?
> >
> > I *think* I tracked it down to this commit:
> >
> >
> https://github.com/keycloak/keycloak/commit/3bfe3d256ed0c292fbb040fa2276c737c3798864
> >
> > the ' org.keycloak.models.jpa. entities.RealmEntity. eventsEnabled'
> field is
> > present in KC 1.0.Final, but not in the 1.0-beta-4.
> >
> >
> >
> >
> > On Fri, Dec 12, 2014 at 11:50 AM, Matthias Wessendorf <
> matzew at apache.org >
> > wrote:
> >
> >
> > Hi Marek,
> >
> > any chance to get a script to get that kinda migration done manually? I
> think
> > this is now blocking us from upgrading to 1.0.4.Final (from 1.0-beta-4,
> > which we used in our 1.0.0.Final)
> >
> > thanks,
> > Matthias
> >
> > On Fri, Dec 12, 2014 at 10:32 AM, Marek Posolda < mposolda at redhat.com >
> > wrote:
> >
> >
> > Unfortunately I don't think that we have this. We have automatic
> migration
> > available with liquibase, but this is from 1.0.0.Final (or newer) to
> 1.1.0.X
> > .
> >
> > Marek
> >
> >
> > On 11.12.2014 16:50, Matthias Wessendorf wrote:
> >
> >
> >
> > Hi,
> >
> > I am wondering do you guys have a .sql script for going from
> '1.0-beta-4' to
> > '1.0.4.Final' ?
> >
> > My motivation is updating the an instance of UPS 1.0.0.Final (was using
> > Keycloak-1.0-beta-4) to latest stable release candidate (1.0.3-SNAPSHOT,
> > which is using Keycloak-1.0.4.Final)
> >
> > Deploying the new auth-server (that we build ourselfs), is giving me this
> > (with Postgres and MySQL)
> >
> >
> >
> >
> > 13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-15)
> > MSC000001: Failed to start service
> > jboss.undertow.deployment.default-server.default-host./auth:
> > org.jboss.msc.service.StartException in service
> > jboss.undertow.deployment.default-server.default-host./auth: Failed to
> start
> > service
> > at
> >
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> > [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > [rt.jar:1.7.0_65]
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > [rt.jar:1.7.0_65]
> > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> > Caused by: java.lang.RuntimeException: Failed to construct public
> >
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
> > at
> >
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
> > at
> >
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
> > at
> >
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
> > at
> >
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
> > at
> >
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
> > at
> >
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> > at
> >
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> > at
> >
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
> > at
> >
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> > at
> >
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
> > at
> >
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
> > at
> >
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
> > at
> >
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
> > at
> >
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
> > at
> >
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> > [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> > at
> >
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> > [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> > ... 3 more
> > Caused by: org.keycloak.models.ModelException:
> > javax.persistence.PersistenceException:
> > org.hibernate.PropertyAccessException: Null value was assigned to a
> property
> > of primitive type setter of
> > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > at
> >
> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
> > at
> >
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
> > at com.sun.proxy.$Proxy128.find(Unknown Source)
> > at
> >
> org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
> > at
> >
> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
> > at
> >
> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
> > at
> >
> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
> > at
> >
> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
> > at
> >
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
> > at
> >
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
> > at
> >
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> > [rt.jar:1.7.0_65]
> > at
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> > [rt.jar:1.7.0_65]
> > at
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > [rt.jar:1.7.0_65]
> > at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> > [rt.jar:1.7.0_65]
> > at
> >
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
> > ... 18 more
> > Caused by: javax.persistence.PersistenceException:
> > org.hibernate.PropertyAccessException: Null value was assigned to a
> property
> > of primitive type setter of
> > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > at
> >
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
> > at
> >
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:
> > 1694 )
> > at
> >
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
> > at
> >
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > [rt.jar:1.7.0_65]
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > [rt.jar:1.7.0_65]
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > [rt.jar:1.7.0_65]
> > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> > at
> >
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
> > ... 32 more
> > Caused by: org.hibernate.PropertyAccessException: Null value was
> assigned to
> > a property of primitive type setter of
> > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > at
> >
> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
> > at
> >
> org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
> > at
> >
> org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
> > at
> >
> org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
> > at
> >
> org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
> > at
> >
> org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
> > at
> >
> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
> > at
> >
> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
> > at
> >
> org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
> > at
> >
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
> > at
> >
> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
> > at
> >
> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
> > at
> >
> org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
> > at
> >
> org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
> > at
> >
> org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
> > at
> >
> org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
> > at
> >
> org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
> > at
> >
> org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
> > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
> > at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
> > at
> >
> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
> > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
> > at
> >
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
> > ... 38 more
> > Caused by: java.lang.IllegalArgumentException: Can not set boolean field
> > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null value
> > at
> >
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
> > [rt.jar:1.7.0_65]
> > at
> >
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
> > [rt.jar:1.7.0_65]
> > at
> >
> sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
> > [rt.jar:1.7.0_65]
> > at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
> > at
> >
> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
> > ... 60 more
> >
> > 13:32:29,205 ERROR [org.jboss.as.controller.management-operation]
> (Controller
> > Boot Thread) JBAS014613: Operation ("deploy") failed - address:
> > ([("deployment" => "auth-server.war")]) - failure description:
> {"JBAS014671:
> > Failed services" =>
> > {"jboss.undertow.deployment.default-server.default-host./auth" =>
> > "org.jboss.msc.service.StartException in service
> > jboss.undertow.deployment.default-server.default-host./auth: Failed to
> start
> > service
> > Caused by: java.lang.RuntimeException: Failed to construct public
> >
> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
> > Caused by: org.keycloak.models.ModelException:
> > javax.persistence.PersistenceException:
> > org.hibernate.PropertyAccessException: Null value was assigned to a
> property
> > of primitive type setter of
> > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > Caused by: javax.persistence.PersistenceException:
> > org.hibernate.PropertyAccessException: Null value was assigned to a
> property
> > of primitive type setter of
> > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > Caused by: org.hibernate.PropertyAccessException: Null value was
> assigned to
> > a property of primitive type setter of
> > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > Caused by: java.lang.IllegalArgumentException: Can not set boolean field
> > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null
> value"}}
> >
> >
> > Thanks,
> > Matthias
> >
> > --
> > 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
> >
> >
> > --
> > 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/20141215/966cb365/attachment-0001.html 

From gerbermichi at me.com  Mon Dec 15 09:52:55 2014
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 15 Dec 2014 14:52:55 +0000 (GMT)
Subject: [keycloak-dev] ${...} enclosure in standalone.xml
Message-ID: <a7340daf-4b39-4669-8cf1-07b6fe4d2f9a@me.com>

Hi all,

I want to use?${...} enclosure in standalone.xml like the following example:

<subsystem xmlns="urn:jboss:domain:keycloak:1.0">
? ? <secure-deployment name="app.war">
? ? ? ? <realm>xxx</realm>
? ? ? ? <resource>xxx</resource>
? ? ? ? <realm-public-key>MIGfMA0GCSqGS</realm-public-key>
? ? ? ? <auth-server-url>https://localhost:8443/auth</auth-server-url>
? ? ? ? <truststore>${jboss.server.config.dir}../../certs/cert.jks</truststore>
? ? ? ? <truststore-password>password</truststore-password>
? ? ? ? <ssl-required>ALL</ssl-required>
? ? ? ? <credential name="secret">6e12d2db</credential>
? ? </secure-deployment>
</subsystem>

But I've got the following error:
Caused by: java.lang.RuntimeException: org.codehaus.jackson.map.JsonMappingException: Can not deserialize instance of java.lang.String out of START_OBJECT token
?at [Source: java.io.ByteArrayInputStream at 27312e38; line: 1, column: 344] (through reference chain: org.keycloak.representations.adapters.config.AdapterConfig["truststore"])
	at org.keycloak.adapters.KeycloakDeploymentBuilder.loadAdapterConfig(KeycloakDeploymentBuilder.java:102)
	at org.keycloak.adapters.KeycloakDeploymentBuilder.build(KeycloakDeploymentBuilder.java:91)
	at org.keycloak.adapters.undertow.KeycloakServletExtension.handleDeployment(KeycloakServletExtension.java:135)

Does anyone know how to fix this?

Thank you for your help!
Michael

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

From ssilvert at redhat.com  Mon Dec 15 10:02:16 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 15 Dec 2014 10:02:16 -0500
Subject: [keycloak-dev] ${...} enclosure in standalone.xml
In-Reply-To: <a7340daf-4b39-4669-8cf1-07b6fe4d2f9a@me.com>
References: <a7340daf-4b39-4669-8cf1-07b6fe4d2f9a@me.com>
Message-ID: <548EF7F8.5030800@redhat.com>

Hi Michael,

Please open a Jira and assign to me.

Stan

On 12/15/2014 9:52 AM, Michael Gerber wrote:
> Hi all,
>
> I want to use ${...} enclosure in standalone.xml like the following 
> example:
>
> <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
>     <secure-deployment name="app.war">
>         <realm>xxx</realm>
>         <resource>xxx</resource>
> <realm-public-key>MIGfMA0GCSqGS</realm-public-key>
> <auth-server-url>https://localhost:8443/auth</auth-server-url>
> <truststore>${jboss.server.config.dir}../../certs/cert.jks</truststore>
> <truststore-password>password</truststore-password>
>         <ssl-required>ALL</ssl-required>
>         <credential name="secret">6e12d2db</credential>
>     </secure-deployment>
> </subsystem>
>
> But I've got the following error:
> Caused by: java.lang.RuntimeException: 
> org.codehaus.jackson.map.JsonMappingException: Can not deserialize 
> instance of java.lang.String out of START_OBJECT token
>  at [Source: java.io.ByteArrayInputStream at 27312e38; line: 1, column: 
> 344] (through reference chain: 
> org.keycloak.representations.adapters.config.AdapterConfig["truststore"])
> at 
> org.keycloak.adapters.KeycloakDeploymentBuilder.loadAdapterConfig(KeycloakDeploymentBuilder.java:102)
> at 
> org.keycloak.adapters.KeycloakDeploymentBuilder.build(KeycloakDeploymentBuilder.java:91)
> at 
> org.keycloak.adapters.undertow.KeycloakServletExtension.handleDeployment(KeycloakServletExtension.java:135)
>
> Does anyone know how to fix this?
>
> Thank you for your help!
> Michael
>
>
>
> _______________________________________________
> 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/20141215/d21f46e2/attachment.html 

From stian at redhat.com  Mon Dec 15 10:39:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 15 Dec 2014 10:39:03 -0500 (EST)
Subject: [keycloak-dev] Database script for manual migration?
In-Reply-To: <CAAg5f2T7FdSt0fX0ty2XgG-bwUkcHNVvWeBwg3eckTWSEgFG5w@mail.gmail.com>
References: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>
	<548AB634.2020805@redhat.com>
	<CAAg5f2S=JyUWnAzC-FtOja8LCSy+6dpERKSL1wNeDe88Srrnzg@mail.gmail.com>
	<CAAg5f2Qc=fJZrxNVCTExq5Si_Mk+s3tXxZmS2KjPkSff+jpcTw@mail.gmail.com>
	<1453586995.17721144.1418636384955.JavaMail.zimbra@redhat.com>
	<CAAg5f2T7FdSt0fX0ty2XgG-bwUkcHNVvWeBwg3eckTWSEgFG5w@mail.gmail.com>
Message-ID: <497730507.17994092.1418657943722.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Matthias Wessendorf" <matzew at apache.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, 15 December, 2014 3:24:54 PM
> Subject: Re: [keycloak-dev] Database script for manual migration?
> 
> Marek helped me already - PR against UPS is pending :)

Great :)

> 
> On Mon, Dec 15, 2014 at 10:39 AM, Stian Thorgersen <stian at redhat.com> wrote:
> >
> > We can sort out something for you guys. When do you need it?
> >
> > ----- Original Message -----
> > > From: "Matthias Wessendorf" <matzew at apache.org>
> > > To: "Marek Posolda" <mposolda at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 12 December, 2014 12:27:11 PM
> > > Subject: Re: [keycloak-dev] Database script for manual migration?
> > >
> > > I *think* I tracked it down to this commit:
> > >
> > >
> > https://github.com/keycloak/keycloak/commit/3bfe3d256ed0c292fbb040fa2276c737c3798864
> > >
> > > the ' org.keycloak.models.jpa. entities.RealmEntity. eventsEnabled'
> > field is
> > > present in KC 1.0.Final, but not in the 1.0-beta-4.
> > >
> > >
> > >
> > >
> > > On Fri, Dec 12, 2014 at 11:50 AM, Matthias Wessendorf <
> > matzew at apache.org >
> > > wrote:
> > >
> > >
> > > Hi Marek,
> > >
> > > any chance to get a script to get that kinda migration done manually? I
> > think
> > > this is now blocking us from upgrading to 1.0.4.Final (from 1.0-beta-4,
> > > which we used in our 1.0.0.Final)
> > >
> > > thanks,
> > > Matthias
> > >
> > > On Fri, Dec 12, 2014 at 10:32 AM, Marek Posolda < mposolda at redhat.com >
> > > wrote:
> > >
> > >
> > > Unfortunately I don't think that we have this. We have automatic
> > migration
> > > available with liquibase, but this is from 1.0.0.Final (or newer) to
> > 1.1.0.X
> > > .
> > >
> > > Marek
> > >
> > >
> > > On 11.12.2014 16:50, Matthias Wessendorf wrote:
> > >
> > >
> > >
> > > Hi,
> > >
> > > I am wondering do you guys have a .sql script for going from
> > '1.0-beta-4' to
> > > '1.0.4.Final' ?
> > >
> > > My motivation is updating the an instance of UPS 1.0.0.Final (was using
> > > Keycloak-1.0-beta-4) to latest stable release candidate (1.0.3-SNAPSHOT,
> > > which is using Keycloak-1.0.4.Final)
> > >
> > > Deploying the new auth-server (that we build ourselfs), is giving me this
> > > (with Postgres and MySQL)
> > >
> > >
> > >
> > >
> > > 13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-15)
> > > MSC000001: Failed to start service
> > > jboss.undertow.deployment.default-server.default-host./auth:
> > > org.jboss.msc.service.StartException in service
> > > jboss.undertow.deployment.default-server.default-host./auth: Failed to
> > start
> > > service
> > > at
> > >
> > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> > > at
> > >
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > > [rt.jar:1.7.0_65]
> > > at
> > >
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > > [rt.jar:1.7.0_65]
> > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> > > Caused by: java.lang.RuntimeException: Failed to construct public
> > >
> > org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
> > > at
> > >
> > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
> > > at
> > >
> > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
> > > at
> > >
> > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
> > > at
> > >
> > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
> > > at
> > >
> > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
> > > at
> > >
> > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> > > at
> > >
> > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> > > at
> > >
> > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
> > > at
> > >
> > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> > > at
> > >
> > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
> > > at
> > >
> > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
> > > at
> > >
> > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
> > > at
> > >
> > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
> > > at
> > >
> > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
> > > at
> > >
> > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> > > at
> > >
> > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> > > ... 3 more
> > > Caused by: org.keycloak.models.ModelException:
> > > javax.persistence.PersistenceException:
> > > org.hibernate.PropertyAccessException: Null value was assigned to a
> > property
> > > of primitive type setter of
> > > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > > at
> > >
> > org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
> > > at
> > >
> > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
> > > at com.sun.proxy.$Proxy128.find(Unknown Source)
> > > at
> > >
> > org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
> > > at
> > >
> > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
> > > at
> > >
> > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
> > > at
> > >
> > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
> > > at
> > >
> > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
> > > at
> > >
> > org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
> > > at
> > >
> > org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
> > > at
> > >
> > org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
> > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> > > [rt.jar:1.7.0_65]
> > > at
> > >
> > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> > > [rt.jar:1.7.0_65]
> > > at
> > >
> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > > [rt.jar:1.7.0_65]
> > > at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> > > [rt.jar:1.7.0_65]
> > > at
> > >
> > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
> > > ... 18 more
> > > Caused by: javax.persistence.PersistenceException:
> > > org.hibernate.PropertyAccessException: Null value was assigned to a
> > property
> > > of primitive type setter of
> > > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > > at
> > >
> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
> > > at
> > >
> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:
> > > 1694 )
> > > at
> > >
> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
> > > at
> > >
> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > [rt.jar:1.7.0_65]
> > > at
> > >
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > > [rt.jar:1.7.0_65]
> > > at
> > >
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > [rt.jar:1.7.0_65]
> > > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> > > at
> > >
> > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
> > > ... 32 more
> > > Caused by: org.hibernate.PropertyAccessException: Null value was
> > assigned to
> > > a property of primitive type setter of
> > > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > > at
> > >
> > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
> > > at
> > >
> > org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
> > > at
> > >
> > org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
> > > at
> > >
> > org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
> > > at
> > >
> > org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
> > > at
> > >
> > org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
> > > at
> > >
> > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
> > > at
> > >
> > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
> > > at
> > >
> > org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
> > > at
> > >
> > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
> > > at
> > >
> > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
> > > at
> > >
> > org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
> > > at
> > >
> > org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
> > > at
> > >
> > org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
> > > at
> > >
> > org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
> > > at
> > >
> > org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
> > > at
> > >
> > org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
> > > at
> > >
> > org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
> > > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
> > > at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
> > > at
> > >
> > org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
> > > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
> > > at
> > >
> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
> > > ... 38 more
> > > Caused by: java.lang.IllegalArgumentException: Can not set boolean field
> > > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null value
> > > at
> > >
> > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
> > > [rt.jar:1.7.0_65]
> > > at
> > >
> > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
> > > [rt.jar:1.7.0_65]
> > > at
> > >
> > sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
> > > [rt.jar:1.7.0_65]
> > > at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
> > > at
> > >
> > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
> > > ... 60 more
> > >
> > > 13:32:29,205 ERROR [org.jboss.as.controller.management-operation]
> > (Controller
> > > Boot Thread) JBAS014613: Operation ("deploy") failed - address:
> > > ([("deployment" => "auth-server.war")]) - failure description:
> > {"JBAS014671:
> > > Failed services" =>
> > > {"jboss.undertow.deployment.default-server.default-host./auth" =>
> > > "org.jboss.msc.service.StartException in service
> > > jboss.undertow.deployment.default-server.default-host./auth: Failed to
> > start
> > > service
> > > Caused by: java.lang.RuntimeException: Failed to construct public
> > >
> > org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
> > > Caused by: org.keycloak.models.ModelException:
> > > javax.persistence.PersistenceException:
> > > org.hibernate.PropertyAccessException: Null value was assigned to a
> > property
> > > of primitive type setter of
> > > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > > Caused by: javax.persistence.PersistenceException:
> > > org.hibernate.PropertyAccessException: Null value was assigned to a
> > property
> > > of primitive type setter of
> > > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > > Caused by: org.hibernate.PropertyAccessException: Null value was
> > assigned to
> > > a property of primitive type setter of
> > > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
> > > Caused by: java.lang.IllegalArgumentException: Can not set boolean field
> > > org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null
> > value"}}
> > >
> > >
> > > Thanks,
> > > Matthias
> > >
> > > --
> > > 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
> > >
> > >
> > > --
> > > 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
> 

From stian at redhat.com  Tue Dec 16 06:13:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 06:13:44 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <614543319.18464432.1418719945329.JavaMail.zimbra@redhat.com>
Message-ID: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>

Before we start any new features we should release 1.1.0.Final. Are there any outstanding tasks not listed in JIRA:

  https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final

There's quite a lot of bugs associated with the release. I'd like us to try to get rid of as many as possible before releasing, so would be great if everyone can do some bug fixing before starting on features for 1.2.

Let's aim for a release shortly after we all return in the New Year.

----

Features for 1.2 includes:

* SAML redirect logout (KEYCLOAK-771, Bill)
* Custom user profiles (KEYCLOAK-311, Bill)
* Kerberos brokering (KEYCLOAK-828, Marek)
* LDAP enhancement (KEYCLOAK-886, Marek)
* OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
* OpenID Connect Discovery (KEYCLOAK-571, Pedro)
* OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
* OpenID Connect Session Management - review and finish missing parts (KEYCLOAK-451, Pedro)
* Fabric8 integration (Stian)

----

I've started creating JIRA's for tasks we defined at the F2F and I'll also create agile boards (or use labels) to make it easy to identify categories of tasks. Main plan is to make it easy for us to pull out for example all tasks related to EAP, IDM, etc.

I've also dropped the 1.x version. All tasks should now be scheduled for current version, the next version or not have a version associated with it.

From stian at redhat.com  Tue Dec 16 06:38:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 06:38:14 -0500 (EST)
Subject: [keycloak-dev] Merry Christmas from the Keycloak team
In-Reply-To: <1674960151.18619710.1418729886484.JavaMail.zimbra@redhat.com>
Message-ID: <1852578705.18619737.1418729894635.JavaMail.zimbra@redhat.com>

2014 was the year of Keycloak! At least that was the case for us on the Keycloak team. In January we released the very first alpha of the project. The first stable release wasn?t out until September, but in return we added a lot more features as well as reaching a very high level of stability for a 1.0.

Since then we?ve delivered a number of security and bug fixes for 1.0, while continuing to bake in new exiting features for 1.1. We?re planning to do a stable release of 1.1 early in the New Year, which will bring SAML 2, much improved clustering and a number of new application adapters.

Not only have we managed to provide a feature rich and easy to use open source security solution, but we?ve also managed to build an awesome community around the project. We?ve had over 5000 downloads, over 2500 commits from 32 contributors and our developer and user mailing lists are very active. Keycloak is already in use in production on a number of projects, in fact some has even used it in production since our first alpha release!

Our road-map for 2015 is not written in stone, but expect at least some of the following features to be delivered in 2015:

  * Custom user profiles ? this will let you configure the attributes for a user profile, which should be visible on the registration screen and account management, as well as specify validation
  * Identity Brokering ? we?re adding support to authenticate with external Identity Providers via OpenID Connect, SAML 2.0 and Kerberos
  * Two-Factor Authentication ? currently we only support Google Authenticator or FreeOTP applications for two-factor authentication, but we plan to make it possible to add your own and provide some more out of the box
  * Client Accounts ? these will be special user accounts directly linked to a client, allowing a client to access services as itself not just on-behalf of users
  * Client Certificates ? support authentication of clients with certificates
  * Client Types ? at the moment we have applications and oauth clients, the main difference being oauth clients require users to grant permissions to roles. To simplify the admin console we plan to introduce a single unified view for clients and also introduce new types such as devices
  * Internationalization ? internationalization support for login and account management pages
  * SMS ? enable SMS to recover passwords, as a 2nd factor authentication mechanism and to be notified about events like login failures
  * OpenID Connect Dynamic Registration ?  allows clients to dynamically register with Keycloak. We?ll also look at passing the OpenID Connect Interop testing
  * Mapping of users and tokens ? custom mapping of user profiles from external identity stores and tokens from external Identity Providers

We also have ideas for some bigger features, but we?ll leave those as a surprise for 2015!

Finally, I?d like to wish everyone a Merry Christmas and a Happy New Year.


From psilva at redhat.com  Tue Dec 16 06:38:35 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 16 Dec 2014 06:38:35 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
Message-ID: <423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>

Stian,

   Regarding my tasks, I will be more dedicated to KC once I decrease my PL backlog a bit. This week is becoming very productive and will help me to plan my work load with more focus on my KC tasks.

   Release date for 1.1.0.Final is 09/Feb/15, right ?

Regards.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Tuesday, December 16, 2014 9:13:44 AM
Subject: [keycloak-dev] Remaining work for 1.1.0.Final

Before we start any new features we should release 1.1.0.Final. Are there any outstanding tasks not listed in JIRA:

  https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final

There's quite a lot of bugs associated with the release. I'd like us to try to get rid of as many as possible before releasing, so would be great if everyone can do some bug fixing before starting on features for 1.2.

Let's aim for a release shortly after we all return in the New Year.

----

Features for 1.2 includes:

* SAML redirect logout (KEYCLOAK-771, Bill)
* Custom user profiles (KEYCLOAK-311, Bill)
* Kerberos brokering (KEYCLOAK-828, Marek)
* LDAP enhancement (KEYCLOAK-886, Marek)
* OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
* OpenID Connect Discovery (KEYCLOAK-571, Pedro)
* OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
* OpenID Connect Session Management - review and finish missing parts (KEYCLOAK-451, Pedro)
* Fabric8 integration (Stian)

----

I've started creating JIRA's for tasks we defined at the F2F and I'll also create agile boards (or use labels) to make it easy to identify categories of tasks. Main plan is to make it easy for us to pull out for example all tasks related to EAP, IDM, etc.

I've also dropped the 1.x version. All tasks should now be scheduled for current version, the next version or not have a version associated with it.
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From christian.beikov at gmail.com  Tue Dec 16 06:42:26 2014
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 16 Dec 2014 12:42:26 +0100
Subject: [keycloak-dev] Login with Access Token
In-Reply-To: <65581544.9522973.1417606302820.JavaMail.zimbra@redhat.com>
References: <547DFDD2.4080500@gmail.com>
	<1533062182.9350512.1417592923589.JavaMail.zimbra@redhat.com>
	<CANMUGsVhNOvdCKu6ZkuNQc-t-i_xh3DDXBuv+m=wCxXGNX+HZg@mail.gmail.com>
	<758632778.9393795.1417594963102.JavaMail.zimbra@redhat.com>
	<CANMUGsU=H1BNbjwOoPXdQccLLoSz1n-v76Sni47VpQ5HNC3j7Q@mail.gmail.com>
	<1778226955.9401093.1417596190241.JavaMail.zimbra@redhat.com>
	<CANMUGsUoF+L4dxZ8GAW3mt12wM6mqpKyrXq3c+CUtK823ktNtw@mail.gmail.com>
	<1961314962.9522155.1417606203740.JavaMail.zimbra@redhat.com>
	<65581544.9522973.1417606302820.JavaMail.zimbra@redhat.com>
Message-ID: <54901AA2.3010509@gmail.com>

Is there a JIRA issue for that feature? I would like to help with this 
regard since I really would like to see support for that in an upcoming 
release.

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 03.12.2014 um 12:31 schrieb Stian Thorgersen:
> Just thought of a reason why it won't work. The link to login with Facebook is to the Keycloak server, which then sets the required state before redirecting to Facebook.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Christian Beikov" <christian.beikov at gmail.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 3 December, 2014 12:30:03 PM
>> Subject: Re: [keycloak-dev] Login with Access Token
>>
>> The callback to Keycloak expects a code, not a token, so I don't think it
>> would work unless you modify Keycloak's Facebook provider. I can't think of
>> any other reasons why it wouldn't work.
>>
>> ----- Original Message -----
>>> From: "Christian Beikov" <christian.beikov at gmail.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 3 December, 2014 11:04:05 AM
>>> Subject: Re: [keycloak-dev] Login with Access Token
>>>
>>> I was thinking of something like the following as a workaround
>>>
>>> 1. Create a hidden iframe in a webview that navigates to the login page of
>>> the keycloak server.
>>> 2. Extract the state from the link of the Facebook login
>>> 3. Start the login with the native SDK
>>> 4. On success navigate in the iframe to the social callback
>>> 5. Use some keycloak token to act as the logged in user
>>>
>>> Regarding 4. I am not sure what URL I should invoke exactly. I guess I have
>>> to append the state parameter to it, but I couldn't find out exactly and I
>>> haven't debugged that far yet.
>>> Regarding 5. I don't know how to retrieve that keycloak token from the
>>> iframe, but I hope there is a way.
>>>
>>> For this to work I will probably have to add some CORS http headers that
>>> will allow localhost so that the app can access the iframe. Although this
>>> makes it vulnerable, since every localhost app could then "steal" the
>>> keycloak token, it would do the job for now.
>>>
>>> What do you think? Could that work?
>>>
>>> 2014-12-03 9:43 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
>>>
>>>> Keycloak generates a special state parameter. It consists of two parts, a
>>>> signature and an id. The id is used to lookup a session in Keycloak,
>>>> while
>>>> the signature is then used to verify that specific request is valid (a
>>>> session can only be used for one thing at a time, for example a social
>>>> login). By design there's no way you can generate this yourself unless
>>>> you
>>>> have access to the Keycloak database.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
>>>>> Sent: Wednesday, 3 December, 2014 9:33:20 AM
>>>>> Subject: Re: [keycloak-dev] Login with Access Token
>>>>>
>>>>> I am wondering how you do that. I know that there is a state parameter
>>>> that
>>>>> is added to the facebook login url, but I could just make an initial
>>>>> request to keycloak to copy that, or did I understand something wrong?
>>>>>
>>>>> 2014-12-03 9:22 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
>>>>>
>>>>>> It's code that is currently changing as we're working on adding
>>>> enterprise
>>>>>> IdP's as well as social IdP's we have at the moment.
>>>>>>
>>>>>> I think the correct approach would be to use the direct grant api,
>>>> which
>>>>>> currently lets you exchange a username + password for a Keycloak
>>>> token, we
>>>>>> could add an option here to pass in a token from an external IdP to
>>>>>> exchange for a internal Keycloak token. If you're interested in
>>>> looking at
>>>>>> the code look at OpenIDConnectService.grantAccessToken.
>>>>>>
>>>>>> There's no work-around that you can do due to security restrictions
>>>>>> in
>>>>>> Keycloak. Keycloak makes sure that the callback can only be called if
>>>> it
>>>>>> indeed made the original request.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Sent: Wednesday, 3 December, 2014 9:11:55 AM
>>>>>>> Subject: Re: [keycloak-dev] Login with Access Token
>>>>>>>
>>>>>>> Thanks for the quick answer. Could you maybe give me a hint on how
>>>>>>> I
>>>>>> could
>>>>>>> implement that in a quick-and-dirty way? Could I maybe do some
>>>>>>> iframe
>>>>>> magic
>>>>>>> in a hidden webview to do the login? I am not quite sure how the
>>>> social
>>>>>>> login works exactly. Facebook will redirect me back to the social
>>>>>> callback
>>>>>>> address after a login, but how does keycloak actually retrieve that
>>>>>> access
>>>>>>> token? If I knew that, I could maybe create a workaround for now
>>>>>>> and
>>>>>> maybe
>>>>>>> also contribute something? :)
>>>>>>>
>>>>>>> 2014-12-03 8:48 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Tuesday, 2 December, 2014 6:58:42 PM
>>>>>>>>> Subject: [keycloak-dev] Login with Access Token
>>>>>>>>>
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> I am new to OAuth so sorry if my question is dumb.
>>>>>>>>> I have an App which wants to provide a custom and Facebook
>>>>>>>>> login.
>>>>>> Since
>>>>>>>> many
>>>>>>>>> people already have the Facebook App installed, I thought it
>>>> might be
>>>>>>>> better
>>>>>>>>> to give them the native experience and use the Facebook SDK to
>>>>>> implement
>>>>>>>> the
>>>>>>>>> login.
>>>>>>>>> The problem now is, that I have the Access Token from the
>>>> successful
>>>>>>>> Facebook
>>>>>>>>> login, but don't know how to properly login at the Keycloak
>>>> server
>>>>>> with
>>>>>>>>> that.
>>>>>>>>>
>>>>>>>>> Any ideas on how to do that? Or is that even stupid and is
>>>>>>>>> there
>>>> a
>>>>>> better
>>>>>>>>> way?
>>>>>>>> Not at all a dumb question and we actually had someone else ask
>>>>>>>> the
>>>>>> same
>>>>>>>> last week.
>>>>>>>>
>>>>>>>> Currently, Keycloak does not support this flow, but it something
>>>> we may
>>>>>>>> consider adding.
>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Mit freundlichen Gr??en,
>>>>>>>>>
>>>>>>>>> Christian Beikov
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Mit freundlichen Gr??en,
>>>>>>>
>>>>>>>
>>>>>>> *Christian Beikov*Blazebit Design & Developing
>>>>>>> http://www.blazebit.com
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Mit freundlichen Gr??en,
>>>>>
>>>>>
>>>>> *Christian Beikov*Blazebit Design & Developing
>>>>> http://www.blazebit.com
>>>>>
>>>
>>>
>>> --
>>>
>>> Mit freundlichen Gr??en,
>>>
>>>
>>> *Christian Beikov*Blazebit Design & Developing
>>> http://www.blazebit.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/20141216/c8ba2bc0/attachment-0001.html 

From stian at redhat.com  Tue Dec 16 06:46:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 06:46:04 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
Message-ID: <512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 16 December, 2014 12:38:35 PM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> Stian,
> 
>    Regarding my tasks, I will be more dedicated to KC once I decrease my PL
>    backlog a bit. This week is becoming very productive and will help me to
>    plan my work load with more focus on my KC tasks.
> 

Great, I was hoping that'd be the case :)

>    Release date for 1.1.0.Final is 09/Feb/15, right ?

No, hopefully around 09/Jan/15. With regards to identity brokering do you think you'll be able to wrap-it up by then or would you need longer?

For the other OpenID Connect tasks (1.2) we'll just do them in priority order. If you get stuck on PL issues we can push them out, or someone else can help you.

> 
> Regards.
> 
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, December 16, 2014 9:13:44 AM
> Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> Before we start any new features we should release 1.1.0.Final. Are there any
> outstanding tasks not listed in JIRA:
> 
>   https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> 
> There's quite a lot of bugs associated with the release. I'd like us to try
> to get rid of as many as possible before releasing, so would be great if
> everyone can do some bug fixing before starting on features for 1.2.
> 
> Let's aim for a release shortly after we all return in the New Year.
> 
> ----
> 
> Features for 1.2 includes:
> 
> * SAML redirect logout (KEYCLOAK-771, Bill)
> * Custom user profiles (KEYCLOAK-311, Bill)
> * Kerberos brokering (KEYCLOAK-828, Marek)
> * LDAP enhancement (KEYCLOAK-886, Marek)
> * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> * OpenID Connect Session Management - review and finish missing parts
> (KEYCLOAK-451, Pedro)
> * Fabric8 integration (Stian)
> 
> ----
> 
> I've started creating JIRA's for tasks we defined at the F2F and I'll also
> create agile boards (or use labels) to make it easy to identify categories
> of tasks. Main plan is to make it easy for us to pull out for example all
> tasks related to EAP, IDM, etc.
> 
> I've also dropped the 1.x version. All tasks should now be scheduled for
> current version, the next version or not have a version associated with it.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Dec 16 06:57:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 06:57:46 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
Message-ID: <1020896282.18636257.1418731066354.JavaMail.zimbra@redhat.com>

Let's aim for releasing 1.1.0.Final 12-16th January. That'll give everyone a week after the holidays to finish off tasks and do some bug fixes.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 16 December, 2014 12:46:04 PM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, 16 December, 2014 12:38:35 PM
> > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > Stian,
> > 
> >    Regarding my tasks, I will be more dedicated to KC once I decrease my PL
> >    backlog a bit. This week is becoming very productive and will help me to
> >    plan my work load with more focus on my KC tasks.
> > 
> 
> Great, I was hoping that'd be the case :)
> 
> >    Release date for 1.1.0.Final is 09/Feb/15, right ?
> 
> No, hopefully around 09/Jan/15. With regards to identity brokering do you
> think you'll be able to wrap-it up by then or would you need longer?
> 
> For the other OpenID Connect tasks (1.2) we'll just do them in priority
> order. If you get stuck on PL issues we can push them out, or someone else
> can help you.
> 
> > 
> > Regards.
> > 
> > ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, December 16, 2014 9:13:44 AM
> > Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > Before we start any new features we should release 1.1.0.Final. Are there
> > any
> > outstanding tasks not listed in JIRA:
> > 
> >   https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> > 
> > There's quite a lot of bugs associated with the release. I'd like us to try
> > to get rid of as many as possible before releasing, so would be great if
> > everyone can do some bug fixing before starting on features for 1.2.
> > 
> > Let's aim for a release shortly after we all return in the New Year.
> > 
> > ----
> > 
> > Features for 1.2 includes:
> > 
> > * SAML redirect logout (KEYCLOAK-771, Bill)
> > * Custom user profiles (KEYCLOAK-311, Bill)
> > * Kerberos brokering (KEYCLOAK-828, Marek)
> > * LDAP enhancement (KEYCLOAK-886, Marek)
> > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> > * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> > * OpenID Connect Session Management - review and finish missing parts
> > (KEYCLOAK-451, Pedro)
> > * Fabric8 integration (Stian)
> > 
> > ----
> > 
> > I've started creating JIRA's for tasks we defined at the F2F and I'll also
> > create agile boards (or use labels) to make it easy to identify categories
> > of tasks. Main plan is to make it easy for us to pull out for example all
> > tasks related to EAP, IDM, etc.
> > 
> > I've also dropped the 1.x version. All tasks should now be scheduled for
> > current version, the next version or not have a version associated with it.
> > _______________________________________________
> > 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 psilva at redhat.com  Tue Dec 16 07:15:40 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 16 Dec 2014 07:15:40 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
Message-ID: <503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, December 16, 2014 9:46:04 AM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, 16 December, 2014 12:38:35 PM
> > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > Stian,
> > 
> >    Regarding my tasks, I will be more dedicated to KC once I decrease my PL
> >    backlog a bit. This week is becoming very productive and will help me to
> >    plan my work load with more focus on my KC tasks.
> > 
> 
> Great, I was hoping that'd be the case :)
> 
> >    Release date for 1.1.0.Final is 09/Feb/15, right ?
> 
> No, hopefully around 09/Jan/15. With regards to identity brokering do you
> think you'll be able to wrap-it up by then or would you need longer?

In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...

Regarding the brokering stuff, the missing bits are:

- Remove old social references from code.
- Review Account page.
- Add more config options to SAML brokering
  - Upload IdP metadata
  - Signature and Encryption support
  - Http Binding Configuration for AuthnRequests
  - NameID Format configuration for AuthnRequests
- Automatic redirection when no credential is supported and a single IdP is configured/enabled.
- Test KC brokering.
  - Requires a better OIDC support in KC. We already have some JIRAs for that.

There is also the attribute mapping stuff. Which will allow users to resolve claims/attributes from trusted IdPs. But to support that, I think we first need the custom claim/profiles in place. However, this is not a blocker for a first release IMO.

The broker is already doing the job. UI, model, REST endpoints, persistence and SPI are fine. We have everything we need to focus only on the functional bits.

> 
> For the other OpenID Connect tasks (1.2) we'll just do them in priority
> order. If you get stuck on PL issues we can push them out, or someone else
> can help you.
> 
> > 
> > Regards.
> > 
> > ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, December 16, 2014 9:13:44 AM
> > Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > Before we start any new features we should release 1.1.0.Final. Are there
> > any
> > outstanding tasks not listed in JIRA:
> > 
> >   https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> > 
> > There's quite a lot of bugs associated with the release. I'd like us to try
> > to get rid of as many as possible before releasing, so would be great if
> > everyone can do some bug fixing before starting on features for 1.2.
> > 
> > Let's aim for a release shortly after we all return in the New Year.
> > 
> > ----
> > 
> > Features for 1.2 includes:
> > 
> > * SAML redirect logout (KEYCLOAK-771, Bill)
> > * Custom user profiles (KEYCLOAK-311, Bill)
> > * Kerberos brokering (KEYCLOAK-828, Marek)
> > * LDAP enhancement (KEYCLOAK-886, Marek)
> > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> > * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> > * OpenID Connect Session Management - review and finish missing parts
> > (KEYCLOAK-451, Pedro)
> > * Fabric8 integration (Stian)
> > 
> > ----
> > 
> > I've started creating JIRA's for tasks we defined at the F2F and I'll also
> > create agile boards (or use labels) to make it easy to identify categories
> > of tasks. Main plan is to make it easy for us to pull out for example all
> > tasks related to EAP, IDM, etc.
> > 
> > I've also dropped the 1.x version. All tasks should now be scheduled for
> > current version, the next version or not have a version associated with it.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From psilva at redhat.com  Tue Dec 16 07:25:50 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 16 Dec 2014 07:25:50 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
Message-ID: <1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>

Btw, regarding SAML brokering. I'm trying to focus on KC integration with a PL SAML IdP. I think that will help people (customers and community) already using PL to adopt KC without forcing them to drop existing infrastructure and investments. And that will also help them to think about a migration plan.

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Stian Thorgersen" <stian at redhat.com>
Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Tuesday, December 16, 2014 10:15:40 AM
Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, December 16, 2014 9:46:04 AM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, 16 December, 2014 12:38:35 PM
> > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > Stian,
> > 
> >    Regarding my tasks, I will be more dedicated to KC once I decrease my PL
> >    backlog a bit. This week is becoming very productive and will help me to
> >    plan my work load with more focus on my KC tasks.
> > 
> 
> Great, I was hoping that'd be the case :)
> 
> >    Release date for 1.1.0.Final is 09/Feb/15, right ?
> 
> No, hopefully around 09/Jan/15. With regards to identity brokering do you
> think you'll be able to wrap-it up by then or would you need longer?

In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...

Regarding the brokering stuff, the missing bits are:

- Remove old social references from code.
- Review Account page.
- Add more config options to SAML brokering
  - Upload IdP metadata
  - Signature and Encryption support
  - Http Binding Configuration for AuthnRequests
  - NameID Format configuration for AuthnRequests
- Automatic redirection when no credential is supported and a single IdP is configured/enabled.
- Test KC brokering.
  - Requires a better OIDC support in KC. We already have some JIRAs for that.

There is also the attribute mapping stuff. Which will allow users to resolve claims/attributes from trusted IdPs. But to support that, I think we first need the custom claim/profiles in place. However, this is not a blocker for a first release IMO.

The broker is already doing the job. UI, model, REST endpoints, persistence and SPI are fine. We have everything we need to focus only on the functional bits.

> 
> For the other OpenID Connect tasks (1.2) we'll just do them in priority
> order. If you get stuck on PL issues we can push them out, or someone else
> can help you.
> 
> > 
> > Regards.
> > 
> > ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, December 16, 2014 9:13:44 AM
> > Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > Before we start any new features we should release 1.1.0.Final. Are there
> > any
> > outstanding tasks not listed in JIRA:
> > 
> >   https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> > 
> > There's quite a lot of bugs associated with the release. I'd like us to try
> > to get rid of as many as possible before releasing, so would be great if
> > everyone can do some bug fixing before starting on features for 1.2.
> > 
> > Let's aim for a release shortly after we all return in the New Year.
> > 
> > ----
> > 
> > Features for 1.2 includes:
> > 
> > * SAML redirect logout (KEYCLOAK-771, Bill)
> > * Custom user profiles (KEYCLOAK-311, Bill)
> > * Kerberos brokering (KEYCLOAK-828, Marek)
> > * LDAP enhancement (KEYCLOAK-886, Marek)
> > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> > * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> > * OpenID Connect Session Management - review and finish missing parts
> > (KEYCLOAK-451, Pedro)
> > * Fabric8 integration (Stian)
> > 
> > ----
> > 
> > I've started creating JIRA's for tasks we defined at the F2F and I'll also
> > create agile boards (or use labels) to make it easy to identify categories
> > of tasks. Main plan is to make it easy for us to pull out for example all
> > tasks related to EAP, IDM, etc.
> > 
> > I've also dropped the 1.x version. All tasks should now be scheduled for
> > current version, the next version or not have a version associated with it.
> > _______________________________________________
> > 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 Dec 16 07:33:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 07:33:05 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
Message-ID: <1103555435.18756696.1418733185809.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 16 December, 2014 1:15:40 PM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, December 16, 2014 9:46:04 AM
> > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Tuesday, 16 December, 2014 12:38:35 PM
> > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > > 
> > > Stian,
> > > 
> > >    Regarding my tasks, I will be more dedicated to KC once I decrease my
> > >    PL
> > >    backlog a bit. This week is becoming very productive and will help me
> > >    to
> > >    plan my work load with more focus on my KC tasks.
> > > 
> > 
> > Great, I was hoping that'd be the case :)
> > 
> > >    Release date for 1.1.0.Final is 09/Feb/15, right ?
> > 
> > No, hopefully around 09/Jan/15. With regards to identity brokering do you
> > think you'll be able to wrap-it up by then or would you need longer?
> 
> In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...

Not any more ;)

> 
> Regarding the brokering stuff, the missing bits are:
> 
> - Remove old social references from code.
> - Review Account page.
> - Add more config options to SAML brokering
>   - Upload IdP metadata
>   - Signature and Encryption support
>   - Http Binding Configuration for AuthnRequests
>   - NameID Format configuration for AuthnRequests
> - Automatic redirection when no credential is supported and a single IdP is
> configured/enabled.
> - Test KC brokering.
>   - Requires a better OIDC support in KC. We already have some JIRAs for
>   that.
> 
> There is also the attribute mapping stuff. Which will allow users to resolve
> claims/attributes from trusted IdPs. But to support that, I think we first
> need the custom claim/profiles in place. However, this is not a blocker for
> a first release IMO.

Yes, mapping can (and probably has to) wait. There's still a fair amount of work you've listed there though. Let's revisit in Jan before we do a release. 

We can always push it to 1.2.0.Beta1, which would be in Feb/March. May be better to introduce this in a beta than a final in either case.

> 
> The broker is already doing the job. UI, model, REST endpoints, persistence
> and SPI are fine. We have everything we need to focus only on the functional
> bits.
> 
> > 
> > For the other OpenID Connect tasks (1.2) we'll just do them in priority
> > order. If you get stuck on PL issues we can push them out, or someone else
> > can help you.
> > 
> > > 
> > > Regards.
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Tuesday, December 16, 2014 9:13:44 AM
> > > Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> > > 
> > > Before we start any new features we should release 1.1.0.Final. Are there
> > > any
> > > outstanding tasks not listed in JIRA:
> > > 
> > >   https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> > > 
> > > There's quite a lot of bugs associated with the release. I'd like us to
> > > try
> > > to get rid of as many as possible before releasing, so would be great if
> > > everyone can do some bug fixing before starting on features for 1.2.
> > > 
> > > Let's aim for a release shortly after we all return in the New Year.
> > > 
> > > ----
> > > 
> > > Features for 1.2 includes:
> > > 
> > > * SAML redirect logout (KEYCLOAK-771, Bill)
> > > * Custom user profiles (KEYCLOAK-311, Bill)
> > > * Kerberos brokering (KEYCLOAK-828, Marek)
> > > * LDAP enhancement (KEYCLOAK-886, Marek)
> > > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> > > * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> > > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> > > * OpenID Connect Session Management - review and finish missing parts
> > > (KEYCLOAK-451, Pedro)
> > > * Fabric8 integration (Stian)
> > > 
> > > ----
> > > 
> > > I've started creating JIRA's for tasks we defined at the F2F and I'll
> > > also
> > > create agile boards (or use labels) to make it easy to identify
> > > categories
> > > of tasks. Main plan is to make it easy for us to pull out for example all
> > > tasks related to EAP, IDM, etc.
> > > 
> > > I've also dropped the 1.x version. All tasks should now be scheduled for
> > > current version, the next version or not have a version associated with
> > > it.
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 

From stian at redhat.com  Tue Dec 16 07:37:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 07:37:11 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
Message-ID: <558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 16 December, 2014 1:25:50 PM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> Btw, regarding SAML brokering. I'm trying to focus on KC integration with a
> PL SAML IdP. I think that will help people (customers and community) already
> using PL to adopt KC without forcing them to drop existing infrastructure
> and investments. And that will also help them to think about a migration
> plan.

Makes sense. We should also provide a migration path for the stored users. If we moved to PL IDM that'd be easy, but not sure that'll happen straight away. Maybe we could provide a PL IDM user federation provider?

> 
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, December 16, 2014 10:15:40 AM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, December 16, 2014 9:46:04 AM
> > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Tuesday, 16 December, 2014 12:38:35 PM
> > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > > 
> > > Stian,
> > > 
> > >    Regarding my tasks, I will be more dedicated to KC once I decrease my
> > >    PL
> > >    backlog a bit. This week is becoming very productive and will help me
> > >    to
> > >    plan my work load with more focus on my KC tasks.
> > > 
> > 
> > Great, I was hoping that'd be the case :)
> > 
> > >    Release date for 1.1.0.Final is 09/Feb/15, right ?
> > 
> > No, hopefully around 09/Jan/15. With regards to identity brokering do you
> > think you'll be able to wrap-it up by then or would you need longer?
> 
> In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...
> 
> Regarding the brokering stuff, the missing bits are:
> 
> - Remove old social references from code.
> - Review Account page.
> - Add more config options to SAML brokering
>   - Upload IdP metadata
>   - Signature and Encryption support
>   - Http Binding Configuration for AuthnRequests
>   - NameID Format configuration for AuthnRequests
> - Automatic redirection when no credential is supported and a single IdP is
> configured/enabled.
> - Test KC brokering.
>   - Requires a better OIDC support in KC. We already have some JIRAs for
>   that.
> 
> There is also the attribute mapping stuff. Which will allow users to resolve
> claims/attributes from trusted IdPs. But to support that, I think we first
> need the custom claim/profiles in place. However, this is not a blocker for
> a first release IMO.
> 
> The broker is already doing the job. UI, model, REST endpoints, persistence
> and SPI are fine. We have everything we need to focus only on the functional
> bits.
> 
> > 
> > For the other OpenID Connect tasks (1.2) we'll just do them in priority
> > order. If you get stuck on PL issues we can push them out, or someone else
> > can help you.
> > 
> > > 
> > > Regards.
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Tuesday, December 16, 2014 9:13:44 AM
> > > Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> > > 
> > > Before we start any new features we should release 1.1.0.Final. Are there
> > > any
> > > outstanding tasks not listed in JIRA:
> > > 
> > >   https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> > > 
> > > There's quite a lot of bugs associated with the release. I'd like us to
> > > try
> > > to get rid of as many as possible before releasing, so would be great if
> > > everyone can do some bug fixing before starting on features for 1.2.
> > > 
> > > Let's aim for a release shortly after we all return in the New Year.
> > > 
> > > ----
> > > 
> > > Features for 1.2 includes:
> > > 
> > > * SAML redirect logout (KEYCLOAK-771, Bill)
> > > * Custom user profiles (KEYCLOAK-311, Bill)
> > > * Kerberos brokering (KEYCLOAK-828, Marek)
> > > * LDAP enhancement (KEYCLOAK-886, Marek)
> > > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> > > * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> > > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> > > * OpenID Connect Session Management - review and finish missing parts
> > > (KEYCLOAK-451, Pedro)
> > > * Fabric8 integration (Stian)
> > > 
> > > ----
> > > 
> > > I've started creating JIRA's for tasks we defined at the F2F and I'll
> > > also
> > > create agile boards (or use labels) to make it easy to identify
> > > categories
> > > of tasks. Main plan is to make it easy for us to pull out for example all
> > > tasks related to EAP, IDM, etc.
> > > 
> > > I've also dropped the 1.x version. All tasks should now be scheduled for
> > > current version, the next version or not have a version associated with
> > > it.
> > > _______________________________________________
> > > 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 psilva at redhat.com  Tue Dec 16 07:47:24 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 16 Dec 2014 07:47:24 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
Message-ID: <765200019.31582344.1418734044534.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, December 16, 2014 10:37:11 AM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, 16 December, 2014 1:25:50 PM
> > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > Btw, regarding SAML brokering. I'm trying to focus on KC integration with a
> > PL SAML IdP. I think that will help people (customers and community)
> > already
> > using PL to adopt KC without forcing them to drop existing infrastructure
> > and investments. And that will also help them to think about a migration
> > plan.
> 
> Makes sense. We should also provide a migration path for the stored users. If
> we moved to PL IDM that'd be easy, but not sure that'll happen straight
> away. Maybe we could provide a PL IDM user federation provider?

Today, people are not using PL IDM and SAML stuff together. Instead of IDM, they are just using JAAS LoginModules to load data from their identity stores. We had some people asking for a PL IDM JAAS LoginModule, but that was not in our plans.

Not sure about the PL IDM provider ... Probably not ... If they want to use PL IDM with the existing SPI it should be fine. But in the future, we can add a lot more configuration options for data federation once IDM is fully integrated with KC. During our F2F we discussed some very nice features for that ...

> 
> > 
> > ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, December 16, 2014 10:15:40 AM
> > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Tuesday, December 16, 2014 9:46:04 AM
> > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > Sent: Tuesday, 16 December, 2014 12:38:35 PM
> > > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > > > 
> > > > Stian,
> > > > 
> > > >    Regarding my tasks, I will be more dedicated to KC once I decrease
> > > >    my
> > > >    PL
> > > >    backlog a bit. This week is becoming very productive and will help
> > > >    me
> > > >    to
> > > >    plan my work load with more focus on my KC tasks.
> > > > 
> > > 
> > > Great, I was hoping that'd be the case :)
> > > 
> > > >    Release date for 1.1.0.Final is 09/Feb/15, right ?
> > > 
> > > No, hopefully around 09/Jan/15. With regards to identity brokering do you
> > > think you'll be able to wrap-it up by then or would you need longer?
> > 
> > In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...
> > 
> > Regarding the brokering stuff, the missing bits are:
> > 
> > - Remove old social references from code.
> > - Review Account page.
> > - Add more config options to SAML brokering
> >   - Upload IdP metadata
> >   - Signature and Encryption support
> >   - Http Binding Configuration for AuthnRequests
> >   - NameID Format configuration for AuthnRequests
> > - Automatic redirection when no credential is supported and a single IdP is
> > configured/enabled.
> > - Test KC brokering.
> >   - Requires a better OIDC support in KC. We already have some JIRAs for
> >   that.
> > 
> > There is also the attribute mapping stuff. Which will allow users to
> > resolve
> > claims/attributes from trusted IdPs. But to support that, I think we first
> > need the custom claim/profiles in place. However, this is not a blocker for
> > a first release IMO.
> > 
> > The broker is already doing the job. UI, model, REST endpoints, persistence
> > and SPI are fine. We have everything we need to focus only on the
> > functional
> > bits.
> > 
> > > 
> > > For the other OpenID Connect tasks (1.2) we'll just do them in priority
> > > order. If you get stuck on PL issues we can push them out, or someone
> > > else
> > > can help you.
> > > 
> > > > 
> > > > Regards.
> > > > 
> > > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > Sent: Tuesday, December 16, 2014 9:13:44 AM
> > > > Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> > > > 
> > > > Before we start any new features we should release 1.1.0.Final. Are
> > > > there
> > > > any
> > > > outstanding tasks not listed in JIRA:
> > > > 
> > > >   https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> > > > 
> > > > There's quite a lot of bugs associated with the release. I'd like us to
> > > > try
> > > > to get rid of as many as possible before releasing, so would be great
> > > > if
> > > > everyone can do some bug fixing before starting on features for 1.2.
> > > > 
> > > > Let's aim for a release shortly after we all return in the New Year.
> > > > 
> > > > ----
> > > > 
> > > > Features for 1.2 includes:
> > > > 
> > > > * SAML redirect logout (KEYCLOAK-771, Bill)
> > > > * Custom user profiles (KEYCLOAK-311, Bill)
> > > > * Kerberos brokering (KEYCLOAK-828, Marek)
> > > > * LDAP enhancement (KEYCLOAK-886, Marek)
> > > > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> > > > * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> > > > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> > > > * OpenID Connect Session Management - review and finish missing parts
> > > > (KEYCLOAK-451, Pedro)
> > > > * Fabric8 integration (Stian)
> > > > 
> > > > ----
> > > > 
> > > > I've started creating JIRA's for tasks we defined at the F2F and I'll
> > > > also
> > > > create agile boards (or use labels) to make it easy to identify
> > > > categories
> > > > of tasks. Main plan is to make it easy for us to pull out for example
> > > > all
> > > > tasks related to EAP, IDM, etc.
> > > > 
> > > > I've also dropped the 1.x version. All tasks should now be scheduled
> > > > for
> > > > current version, the next version or not have a version associated with
> > > > it.
> > > > _______________________________________________
> > > > 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 psilva at redhat.com  Tue Dec 16 07:48:38 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 16 Dec 2014 07:48:38 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <1103555435.18756696.1418733185809.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
	<1103555435.18756696.1418733185809.JavaMail.zimbra@redhat.com>
Message-ID: <1426201824.31582500.1418734118218.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, December 16, 2014 10:33:05 AM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, 16 December, 2014 1:15:40 PM
> > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Tuesday, December 16, 2014 9:46:04 AM
> > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > Sent: Tuesday, 16 December, 2014 12:38:35 PM
> > > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> > > > 
> > > > Stian,
> > > > 
> > > >    Regarding my tasks, I will be more dedicated to KC once I decrease
> > > >    my
> > > >    PL
> > > >    backlog a bit. This week is becoming very productive and will help
> > > >    me
> > > >    to
> > > >    plan my work load with more focus on my KC tasks.
> > > > 
> > > 
> > > Great, I was hoping that'd be the case :)
> > > 
> > > >    Release date for 1.1.0.Final is 09/Feb/15, right ?
> > > 
> > > No, hopefully around 09/Jan/15. With regards to identity brokering do you
> > > think you'll be able to wrap-it up by then or would you need longer?
> > 
> > In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...
> 
> Not any more ;)
> 
> > 
> > Regarding the brokering stuff, the missing bits are:
> > 
> > - Remove old social references from code.
> > - Review Account page.
> > - Add more config options to SAML brokering
> >   - Upload IdP metadata
> >   - Signature and Encryption support
> >   - Http Binding Configuration for AuthnRequests
> >   - NameID Format configuration for AuthnRequests
> > - Automatic redirection when no credential is supported and a single IdP is
> > configured/enabled.
> > - Test KC brokering.
> >   - Requires a better OIDC support in KC. We already have some JIRAs for
> >   that.
> > 
> > There is also the attribute mapping stuff. Which will allow users to
> > resolve
> > claims/attributes from trusted IdPs. But to support that, I think we first
> > need the custom claim/profiles in place. However, this is not a blocker for
> > a first release IMO.
> 
> Yes, mapping can (and probably has to) wait. There's still a fair amount of
> work you've listed there though. Let's revisit in Jan before we do a
> release.
> 
> We can always push it to 1.2.0.Beta1, which would be in Feb/March. May be
> better to introduce this in a beta than a final in either case.

+1. Makes sense.

> 
> > 
> > The broker is already doing the job. UI, model, REST endpoints, persistence
> > and SPI are fine. We have everything we need to focus only on the
> > functional
> > bits.
> > 
> > > 
> > > For the other OpenID Connect tasks (1.2) we'll just do them in priority
> > > order. If you get stuck on PL issues we can push them out, or someone
> > > else
> > > can help you.
> > > 
> > > > 
> > > > Regards.
> > > > 
> > > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > Sent: Tuesday, December 16, 2014 9:13:44 AM
> > > > Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> > > > 
> > > > Before we start any new features we should release 1.1.0.Final. Are
> > > > there
> > > > any
> > > > outstanding tasks not listed in JIRA:
> > > > 
> > > >   https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> > > > 
> > > > There's quite a lot of bugs associated with the release. I'd like us to
> > > > try
> > > > to get rid of as many as possible before releasing, so would be great
> > > > if
> > > > everyone can do some bug fixing before starting on features for 1.2.
> > > > 
> > > > Let's aim for a release shortly after we all return in the New Year.
> > > > 
> > > > ----
> > > > 
> > > > Features for 1.2 includes:
> > > > 
> > > > * SAML redirect logout (KEYCLOAK-771, Bill)
> > > > * Custom user profiles (KEYCLOAK-311, Bill)
> > > > * Kerberos brokering (KEYCLOAK-828, Marek)
> > > > * LDAP enhancement (KEYCLOAK-886, Marek)
> > > > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> > > > * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> > > > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> > > > * OpenID Connect Session Management - review and finish missing parts
> > > > (KEYCLOAK-451, Pedro)
> > > > * Fabric8 integration (Stian)
> > > > 
> > > > ----
> > > > 
> > > > I've started creating JIRA's for tasks we defined at the F2F and I'll
> > > > also
> > > > create agile boards (or use labels) to make it easy to identify
> > > > categories
> > > > of tasks. Main plan is to make it easy for us to pull out for example
> > > > all
> > > > tasks related to EAP, IDM, etc.
> > > > 
> > > > I've also dropped the 1.x version. All tasks should now be scheduled
> > > > for
> > > > current version, the next version or not have a version associated with
> > > > it.
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > 
> > > 
> > 
> 

From bburke at redhat.com  Tue Dec 16 08:35:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Dec 2014 08:35:08 -0500
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
Message-ID: <5490350C.7010904@redhat.com>

Is Pedro's work already included?  Don't forget SAML/OIDC brokering.

On 12/16/2014 6:13 AM, Stian Thorgersen wrote:
> Before we start any new features we should release 1.1.0.Final. Are there any outstanding tasks not listed in JIRA:
>
>    https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
>
> There's quite a lot of bugs associated with the release. I'd like us to try to get rid of as many as possible before releasing, so would be great if everyone can do some bug fixing before starting on features for 1.2.
>
> Let's aim for a release shortly after we all return in the New Year.
>
> ----
>
> Features for 1.2 includes:
>
> * SAML redirect logout (KEYCLOAK-771, Bill)
> * Custom user profiles (KEYCLOAK-311, Bill)
> * Kerberos brokering (KEYCLOAK-828, Marek)
> * LDAP enhancement (KEYCLOAK-886, Marek)
> * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> * OpenID Connect Session Management - review and finish missing parts (KEYCLOAK-451, Pedro)
> * Fabric8 integration (Stian)
>
> ----
>
> I've started creating JIRA's for tasks we defined at the F2F and I'll also create agile boards (or use labels) to make it easy to identify categories of tasks. Main plan is to make it easy for us to pull out for example all tasks related to EAP, IDM, etc.
>
> I've also dropped the 1.x version. All tasks should now be scheduled for current version, the next version or not have a version associated with it.
> _______________________________________________
> 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 Dec 16 08:38:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Dec 2014 08:38:19 -0500
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <5490350C.7010904@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<5490350C.7010904@redhat.com>
Message-ID: <549035CB.8090603@redhat.com>

NVM!  I finally got through the emails.

On 12/16/2014 8:35 AM, Bill Burke wrote:
> Is Pedro's work already included?  Don't forget SAML/OIDC brokering.
>
> On 12/16/2014 6:13 AM, Stian Thorgersen wrote:
>> Before we start any new features we should release 1.1.0.Final. Are there any outstanding tasks not listed in JIRA:
>>
>>     https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
>>
>> There's quite a lot of bugs associated with the release. I'd like us to try to get rid of as many as possible before releasing, so would be great if everyone can do some bug fixing before starting on features for 1.2.
>>
>> Let's aim for a release shortly after we all return in the New Year.
>>
>> ----
>>
>> Features for 1.2 includes:
>>
>> * SAML redirect logout (KEYCLOAK-771, Bill)
>> * Custom user profiles (KEYCLOAK-311, Bill)
>> * Kerberos brokering (KEYCLOAK-828, Marek)
>> * LDAP enhancement (KEYCLOAK-886, Marek)
>> * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
>> * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
>> * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
>> * OpenID Connect Session Management - review and finish missing parts (KEYCLOAK-451, Pedro)
>> * Fabric8 integration (Stian)
>>
>> ----
>>
>> I've started creating JIRA's for tasks we defined at the F2F and I'll also create agile boards (or use labels) to make it easy to identify categories of tasks. Main plan is to make it easy for us to pull out for example all tasks related to EAP, IDM, etc.
>>
>> I've also dropped the 1.x version. All tasks should now be scheduled for current version, the next version or not have a version associated with it.
>> _______________________________________________
>> 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  Tue Dec 16 08:42:44 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Dec 2014 14:42:44 +0100
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
Message-ID: <549036D4.8050702@redhat.com>

On 16.12.2014 13:37, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, 16 December, 2014 1:25:50 PM
>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>
>> Btw, regarding SAML brokering. I'm trying to focus on KC integration with a
>> PL SAML IdP. I think that will help people (customers and community) already
>> using PL to adopt KC without forcing them to drop existing infrastructure
>> and investments. And that will also help them to think about a migration
>> plan.
> Makes sense. We should also provide a migration path for the stored users. If we moved to PL IDM that'd be easy, but not sure that'll happen straight away. Maybe we could provide a PL IDM user federation provider?
Well, we defacto already have it :) Our LDAPFederationProvider is using 
Picketlink IDM API to bridge between keycloak model and 
org.picketlink.idm.model.basic.User . There is no direct interaction 
with LDAP, but everything goes through PL IDM API.

In early stage when we discussed ldap integration and using PL IDM API 
for it, we also discussed that it could be nice if people could provide 
different source of PL IDM store. So there is PartitionManagerProvider 
interface, which provides access to pl idm PartitionManager. Right now 
we have just one implementation LDAPPartitionManagerProvider, which 
returns picketlink PartitionManager configured to use LDAP store based 
on ldap configuration provided by keycloak admin console.

So theoretically only thing, which people need to do is to provide their 
own PartitionManagerProvider when they can configure PL IDM stores 
according to their environment. And this PartitionManagerProvider would 
need to be configured in keycloak-server.json, so it has precedence over 
the default LDAP based impl. Only condition is that their users should 
be retrievable with usage of org.picketlink.idm.model.basic.User from PL 
IDM Basic model.

Marek
>
>> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, December 16, 2014 10:15:40 AM
>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>
>> ----- Original Message -----
>>> From: "Stian Thorgersen" <stian at redhat.com>
>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Tuesday, December 16, 2014 9:46:04 AM
>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, 16 December, 2014 12:38:35 PM
>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>>>
>>>> Stian,
>>>>
>>>>     Regarding my tasks, I will be more dedicated to KC once I decrease my
>>>>     PL
>>>>     backlog a bit. This week is becoming very productive and will help me
>>>>     to
>>>>     plan my work load with more focus on my KC tasks.
>>>>
>>> Great, I was hoping that'd be the case :)
>>>
>>>>     Release date for 1.1.0.Final is 09/Feb/15, right ?
>>> No, hopefully around 09/Jan/15. With regards to identity brokering do you
>>> think you'll be able to wrap-it up by then or would you need longer?
>> In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...
>>
>> Regarding the brokering stuff, the missing bits are:
>>
>> - Remove old social references from code.
>> - Review Account page.
>> - Add more config options to SAML brokering
>>    - Upload IdP metadata
>>    - Signature and Encryption support
>>    - Http Binding Configuration for AuthnRequests
>>    - NameID Format configuration for AuthnRequests
>> - Automatic redirection when no credential is supported and a single IdP is
>> configured/enabled.
>> - Test KC brokering.
>>    - Requires a better OIDC support in KC. We already have some JIRAs for
>>    that.
>>
>> There is also the attribute mapping stuff. Which will allow users to resolve
>> claims/attributes from trusted IdPs. But to support that, I think we first
>> need the custom claim/profiles in place. However, this is not a blocker for
>> a first release IMO.
>>
>> The broker is already doing the job. UI, model, REST endpoints, persistence
>> and SPI are fine. We have everything we need to focus only on the functional
>> bits.
>>
>>> For the other OpenID Connect tasks (1.2) we'll just do them in priority
>>> order. If you get stuck on PL issues we can push them out, or someone else
>>> can help you.
>>>
>>>> Regards.
>>>>
>>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, December 16, 2014 9:13:44 AM
>>>> Subject: [keycloak-dev] Remaining work for 1.1.0.Final
>>>>
>>>> Before we start any new features we should release 1.1.0.Final. Are there
>>>> any
>>>> outstanding tasks not listed in JIRA:
>>>>
>>>>    https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
>>>>
>>>> There's quite a lot of bugs associated with the release. I'd like us to
>>>> try
>>>> to get rid of as many as possible before releasing, so would be great if
>>>> everyone can do some bug fixing before starting on features for 1.2.
>>>>
>>>> Let's aim for a release shortly after we all return in the New Year.
>>>>
>>>> ----
>>>>
>>>> Features for 1.2 includes:
>>>>
>>>> * SAML redirect logout (KEYCLOAK-771, Bill)
>>>> * Custom user profiles (KEYCLOAK-311, Bill)
>>>> * Kerberos brokering (KEYCLOAK-828, Marek)
>>>> * LDAP enhancement (KEYCLOAK-886, Marek)
>>>> * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
>>>> * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
>>>> * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
>>>> * OpenID Connect Session Management - review and finish missing parts
>>>> (KEYCLOAK-451, Pedro)
>>>> * Fabric8 integration (Stian)
>>>>
>>>> ----
>>>>
>>>> I've started creating JIRA's for tasks we defined at the F2F and I'll
>>>> also
>>>> create agile boards (or use labels) to make it easy to identify
>>>> categories
>>>> of tasks. Main plan is to make it easy for us to pull out for example all
>>>> tasks related to EAP, IDM, etc.
>>>>
>>>> I've also dropped the 1.x version. All tasks should now be scheduled for
>>>> current version, the next version or not have a version associated with
>>>> it.
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Tue Dec 16 08:55:00 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 16 Dec 2014 08:55:00 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <549036D4.8050702@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
	<549036D4.8050702@redhat.com>
Message-ID: <200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, December 16, 2014 11:42:44 AM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> On 16.12.2014 13:37, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Tuesday, 16 December, 2014 1:25:50 PM
> >> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>
> >> Btw, regarding SAML brokering. I'm trying to focus on KC integration with
> >> a
> >> PL SAML IdP. I think that will help people (customers and community)
> >> already
> >> using PL to adopt KC without forcing them to drop existing infrastructure
> >> and investments. And that will also help them to think about a migration
> >> plan.
> > Makes sense. We should also provide a migration path for the stored users.
> > If we moved to PL IDM that'd be easy, but not sure that'll happen straight
> > away. Maybe we could provide a PL IDM user federation provider?
> Well, we defacto already have it :) Our LDAPFederationProvider is using
> Picketlink IDM API to bridge between keycloak model and
> org.picketlink.idm.model.basic.User . There is no direct interaction
> with LDAP, but everything goes through PL IDM API.
> 
> In early stage when we discussed ldap integration and using PL IDM API
> for it, we also discussed that it could be nice if people could provide
> different source of PL IDM store. So there is PartitionManagerProvider
> interface, which provides access to pl idm PartitionManager. Right now
> we have just one implementation LDAPPartitionManagerProvider, which
> returns picketlink PartitionManager configured to use LDAP store based
> on ldap configuration provided by keycloak admin console.
> 
> So theoretically only thing, which people need to do is to provide their
> own PartitionManagerProvider when they can configure PL IDM stores
> according to their environment. And this PartitionManagerProvider would
> need to be configured in keycloak-server.json, so it has precedence over
> the default LDAP based impl. Only condition is that their users should
> be retrievable with usage of org.picketlink.idm.model.basic.User from PL
> IDM Basic model.

Or they can just provide a JNDI url where the PartitionManager is located, when using the subsystem. Also, PL IDM has the concept of stereotypes [1]. What means, in theory, that you can deal with any identity model definition (eg.: not only the basic identity model). 

[1] http://docs.jboss.org/picketlink/2/latest/reference/html-single/#sect-Stereotypes

> 
> Marek
> >
> >> ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Tuesday, December 16, 2014 10:15:40 AM
> >> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>
> >> ----- Original Message -----
> >>> From: "Stian Thorgersen" <stian at redhat.com>
> >>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>> Sent: Tuesday, December 16, 2014 9:46:04 AM
> >>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Tuesday, 16 December, 2014 12:38:35 PM
> >>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>>>
> >>>> Stian,
> >>>>
> >>>>     Regarding my tasks, I will be more dedicated to KC once I decrease
> >>>>     my
> >>>>     PL
> >>>>     backlog a bit. This week is becoming very productive and will help
> >>>>     me
> >>>>     to
> >>>>     plan my work load with more focus on my KC tasks.
> >>>>
> >>> Great, I was hoping that'd be the case :)
> >>>
> >>>>     Release date for 1.1.0.Final is 09/Feb/15, right ?
> >>> No, hopefully around 09/Jan/15. With regards to identity brokering do you
> >>> think you'll be able to wrap-it up by then or would you need longer?
> >> In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...
> >>
> >> Regarding the brokering stuff, the missing bits are:
> >>
> >> - Remove old social references from code.
> >> - Review Account page.
> >> - Add more config options to SAML brokering
> >>    - Upload IdP metadata
> >>    - Signature and Encryption support
> >>    - Http Binding Configuration for AuthnRequests
> >>    - NameID Format configuration for AuthnRequests
> >> - Automatic redirection when no credential is supported and a single IdP
> >> is
> >> configured/enabled.
> >> - Test KC brokering.
> >>    - Requires a better OIDC support in KC. We already have some JIRAs for
> >>    that.
> >>
> >> There is also the attribute mapping stuff. Which will allow users to
> >> resolve
> >> claims/attributes from trusted IdPs. But to support that, I think we first
> >> need the custom claim/profiles in place. However, this is not a blocker
> >> for
> >> a first release IMO.
> >>
> >> The broker is already doing the job. UI, model, REST endpoints,
> >> persistence
> >> and SPI are fine. We have everything we need to focus only on the
> >> functional
> >> bits.
> >>
> >>> For the other OpenID Connect tasks (1.2) we'll just do them in priority
> >>> order. If you get stuck on PL issues we can push them out, or someone
> >>> else
> >>> can help you.
> >>>
> >>>> Regards.
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Tuesday, December 16, 2014 9:13:44 AM
> >>>> Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> >>>>
> >>>> Before we start any new features we should release 1.1.0.Final. Are
> >>>> there
> >>>> any
> >>>> outstanding tasks not listed in JIRA:
> >>>>
> >>>>    https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> >>>>
> >>>> There's quite a lot of bugs associated with the release. I'd like us to
> >>>> try
> >>>> to get rid of as many as possible before releasing, so would be great if
> >>>> everyone can do some bug fixing before starting on features for 1.2.
> >>>>
> >>>> Let's aim for a release shortly after we all return in the New Year.
> >>>>
> >>>> ----
> >>>>
> >>>> Features for 1.2 includes:
> >>>>
> >>>> * SAML redirect logout (KEYCLOAK-771, Bill)
> >>>> * Custom user profiles (KEYCLOAK-311, Bill)
> >>>> * Kerberos brokering (KEYCLOAK-828, Marek)
> >>>> * LDAP enhancement (KEYCLOAK-886, Marek)
> >>>> * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> >>>> * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> >>>> * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> >>>> * OpenID Connect Session Management - review and finish missing parts
> >>>> (KEYCLOAK-451, Pedro)
> >>>> * Fabric8 integration (Stian)
> >>>>
> >>>> ----
> >>>>
> >>>> I've started creating JIRA's for tasks we defined at the F2F and I'll
> >>>> also
> >>>> create agile boards (or use labels) to make it easy to identify
> >>>> categories
> >>>> of tasks. Main plan is to make it easy for us to pull out for example
> >>>> all
> >>>> tasks related to EAP, IDM, etc.
> >>>>
> >>>> I've also dropped the 1.x version. All tasks should now be scheduled for
> >>>> current version, the next version or not have a version associated with
> >>>> it.
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From stian at redhat.com  Tue Dec 16 09:17:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 09:17:38 -0500 (EST)
Subject: [keycloak-dev] Login with Access Token
In-Reply-To: <54901AA2.3010509@gmail.com>
References: <547DFDD2.4080500@gmail.com>
	<758632778.9393795.1417594963102.JavaMail.zimbra@redhat.com>
	<CANMUGsU=H1BNbjwOoPXdQccLLoSz1n-v76Sni47VpQ5HNC3j7Q@mail.gmail.com>
	<1778226955.9401093.1417596190241.JavaMail.zimbra@redhat.com>
	<CANMUGsUoF+L4dxZ8GAW3mt12wM6mqpKyrXq3c+CUtK823ktNtw@mail.gmail.com>
	<1961314962.9522155.1417606203740.JavaMail.zimbra@redhat.com>
	<65581544.9522973.1417606302820.JavaMail.zimbra@redhat.com>
	<54901AA2.3010509@gmail.com>
Message-ID: <952996042.18876098.1418739458980.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Christian Beikov" <christian.beikov at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 16 December, 2014 12:42:26 PM
> Subject: Re: [keycloak-dev] Login with Access Token
> 
> Is there a JIRA issue for that feature? I would like to help with this
> regard since I really would like to see support for that in an upcoming
> release.

I've just created https://issues.jboss.org/browse/KEYCLOAK-890. If you'd like to look at it that'd be great as we have loads of work atm, so not sure we'd have time ourselves. One thing to note is that we'd have to start with a POC and review it first. I can't guarantee that it's something we'd actually add either.

> 
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 03.12.2014 um 12:31 schrieb Stian Thorgersen:
> > Just thought of a reason why it won't work. The link to login with Facebook
> > is to the Keycloak server, which then sets the required state before
> > redirecting to Facebook.
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Christian Beikov" <christian.beikov at gmail.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 3 December, 2014 12:30:03 PM
> >> Subject: Re: [keycloak-dev] Login with Access Token
> >>
> >> The callback to Keycloak expects a code, not a token, so I don't think it
> >> would work unless you modify Keycloak's Facebook provider. I can't think
> >> of
> >> any other reasons why it wouldn't work.
> >>
> >> ----- Original Message -----
> >>> From: "Christian Beikov" <christian.beikov at gmail.com>
> >>> To: "Stian Thorgersen" <stian at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, 3 December, 2014 11:04:05 AM
> >>> Subject: Re: [keycloak-dev] Login with Access Token
> >>>
> >>> I was thinking of something like the following as a workaround
> >>>
> >>> 1. Create a hidden iframe in a webview that navigates to the login page
> >>> of
> >>> the keycloak server.
> >>> 2. Extract the state from the link of the Facebook login
> >>> 3. Start the login with the native SDK
> >>> 4. On success navigate in the iframe to the social callback
> >>> 5. Use some keycloak token to act as the logged in user
> >>>
> >>> Regarding 4. I am not sure what URL I should invoke exactly. I guess I
> >>> have
> >>> to append the state parameter to it, but I couldn't find out exactly and
> >>> I
> >>> haven't debugged that far yet.
> >>> Regarding 5. I don't know how to retrieve that keycloak token from the
> >>> iframe, but I hope there is a way.
> >>>
> >>> For this to work I will probably have to add some CORS http headers that
> >>> will allow localhost so that the app can access the iframe. Although this
> >>> makes it vulnerable, since every localhost app could then "steal" the
> >>> keycloak token, it would do the job for now.
> >>>
> >>> What do you think? Could that work?
> >>>
> >>> 2014-12-03 9:43 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> >>>
> >>>> Keycloak generates a special state parameter. It consists of two parts,
> >>>> a
> >>>> signature and an id. The id is used to lookup a session in Keycloak,
> >>>> while
> >>>> the signature is then used to verify that specific request is valid (a
> >>>> session can only be used for one thing at a time, for example a social
> >>>> login). By design there's no way you can generate this yourself unless
> >>>> you
> >>>> have access to the Keycloak database.
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
> >>>>> To: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> >>>>> Sent: Wednesday, 3 December, 2014 9:33:20 AM
> >>>>> Subject: Re: [keycloak-dev] Login with Access Token
> >>>>>
> >>>>> I am wondering how you do that. I know that there is a state parameter
> >>>> that
> >>>>> is added to the facebook login url, but I could just make an initial
> >>>>> request to keycloak to copy that, or did I understand something wrong?
> >>>>>
> >>>>> 2014-12-03 9:22 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> >>>>>
> >>>>>> It's code that is currently changing as we're working on adding
> >>>> enterprise
> >>>>>> IdP's as well as social IdP's we have at the moment.
> >>>>>>
> >>>>>> I think the correct approach would be to use the direct grant api,
> >>>> which
> >>>>>> currently lets you exchange a username + password for a Keycloak
> >>>> token, we
> >>>>>> could add an option here to pass in a token from an external IdP to
> >>>>>> exchange for a internal Keycloak token. If you're interested in
> >>>> looking at
> >>>>>> the code look at OpenIDConnectService.grantAccessToken.
> >>>>>>
> >>>>>> There's no work-around that you can do due to security restrictions
> >>>>>> in
> >>>>>> Keycloak. Keycloak makes sure that the callback can only be called if
> >>>> it
> >>>>>> indeed made the original request.
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
> >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>> Sent: Wednesday, 3 December, 2014 9:11:55 AM
> >>>>>>> Subject: Re: [keycloak-dev] Login with Access Token
> >>>>>>>
> >>>>>>> Thanks for the quick answer. Could you maybe give me a hint on how
> >>>>>>> I
> >>>>>> could
> >>>>>>> implement that in a quick-and-dirty way? Could I maybe do some
> >>>>>>> iframe
> >>>>>> magic
> >>>>>>> in a hidden webview to do the login? I am not quite sure how the
> >>>> social
> >>>>>>> login works exactly. Facebook will redirect me back to the social
> >>>>>> callback
> >>>>>>> address after a login, but how does keycloak actually retrieve that
> >>>>>> access
> >>>>>>> token? If I knew that, I could maybe create a workaround for now
> >>>>>>> and
> >>>>>> maybe
> >>>>>>> also contribute something? :)
> >>>>>>>
> >>>>>>> 2014-12-03 8:48 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
> >>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>> Sent: Tuesday, 2 December, 2014 6:58:42 PM
> >>>>>>>>> Subject: [keycloak-dev] Login with Access Token
> >>>>>>>>>
> >>>>>>>>> Hello!
> >>>>>>>>>
> >>>>>>>>> I am new to OAuth so sorry if my question is dumb.
> >>>>>>>>> I have an App which wants to provide a custom and Facebook
> >>>>>>>>> login.
> >>>>>> Since
> >>>>>>>> many
> >>>>>>>>> people already have the Facebook App installed, I thought it
> >>>> might be
> >>>>>>>> better
> >>>>>>>>> to give them the native experience and use the Facebook SDK to
> >>>>>> implement
> >>>>>>>> the
> >>>>>>>>> login.
> >>>>>>>>> The problem now is, that I have the Access Token from the
> >>>> successful
> >>>>>>>> Facebook
> >>>>>>>>> login, but don't know how to properly login at the Keycloak
> >>>> server
> >>>>>> with
> >>>>>>>>> that.
> >>>>>>>>>
> >>>>>>>>> Any ideas on how to do that? Or is that even stupid and is
> >>>>>>>>> there
> >>>> a
> >>>>>> better
> >>>>>>>>> way?
> >>>>>>>> Not at all a dumb question and we actually had someone else ask
> >>>>>>>> the
> >>>>>> same
> >>>>>>>> last week.
> >>>>>>>>
> >>>>>>>> Currently, Keycloak does not support this flow, but it something
> >>>> we may
> >>>>>>>> consider adding.
> >>>>>>>>
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>> Mit freundlichen Gr??en,
> >>>>>>>>>
> >>>>>>>>> Christian Beikov
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> keycloak-dev mailing list
> >>>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Mit freundlichen Gr??en,
> >>>>>>>
> >>>>>>>
> >>>>>>> *Christian Beikov*Blazebit Design & Developing
> >>>>>>> http://www.blazebit.com
> >>>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Mit freundlichen Gr??en,
> >>>>>
> >>>>>
> >>>>> *Christian Beikov*Blazebit Design & Developing
> >>>>> http://www.blazebit.com
> >>>>>
> >>>
> >>>
> >>> --
> >>>
> >>> Mit freundlichen Gr??en,
> >>>
> >>>
> >>> *Christian Beikov*Blazebit Design & Developing
> >>> http://www.blazebit.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 Dec 16 09:25:27 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Dec 2014 15:25:27 +0100
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
	<549036D4.8050702@redhat.com>
	<200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>
Message-ID: <549040D7.6020202@redhat.com>

On 16.12.2014 14:55, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, December 16, 2014 11:42:44 AM
>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>
>> On 16.12.2014 13:37, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, 16 December, 2014 1:25:50 PM
>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>>>
>>>> Btw, regarding SAML brokering. I'm trying to focus on KC integration with
>>>> a
>>>> PL SAML IdP. I think that will help people (customers and community)
>>>> already
>>>> using PL to adopt KC without forcing them to drop existing infrastructure
>>>> and investments. And that will also help them to think about a migration
>>>> plan.
>>> Makes sense. We should also provide a migration path for the stored users.
>>> If we moved to PL IDM that'd be easy, but not sure that'll happen straight
>>> away. Maybe we could provide a PL IDM user federation provider?
>> Well, we defacto already have it :) Our LDAPFederationProvider is using
>> Picketlink IDM API to bridge between keycloak model and
>> org.picketlink.idm.model.basic.User . There is no direct interaction
>> with LDAP, but everything goes through PL IDM API.
>>
>> In early stage when we discussed ldap integration and using PL IDM API
>> for it, we also discussed that it could be nice if people could provide
>> different source of PL IDM store. So there is PartitionManagerProvider
>> interface, which provides access to pl idm PartitionManager. Right now
>> we have just one implementation LDAPPartitionManagerProvider, which
>> returns picketlink PartitionManager configured to use LDAP store based
>> on ldap configuration provided by keycloak admin console.
>>
>> So theoretically only thing, which people need to do is to provide their
>> own PartitionManagerProvider when they can configure PL IDM stores
>> according to their environment. And this PartitionManagerProvider would
>> need to be configured in keycloak-server.json, so it has precedence over
>> the default LDAP based impl. Only condition is that their users should
>> be retrievable with usage of org.picketlink.idm.model.basic.User from PL
>> IDM Basic model.
> Or they can just provide a JNDI url where the PartitionManager is located, when using the subsystem. Also, PL IDM has the concept of stereotypes [1]. What means, in theory, that you can deal with any identity model definition (eg.: not only the basic identity model).
yeah, so we can do something like "SubsystemPartitionManagerProvider", 
which will allow people to retrieve PartitionManager from JNDI URL and 
they won't need to code anything by themselves. Only provide JDNI URL in 
configuration.
>
> [1] http://docs.jboss.org/picketlink/2/latest/reference/html-single/#sect-Stereotypes
>
>> Marek
>>>> ----- Original Message -----
>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, December 16, 2014 10:15:40 AM
>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>>>
>>>> ----- Original Message -----
>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>> Sent: Tuesday, December 16, 2014 9:46:04 AM
>>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Tuesday, 16 December, 2014 12:38:35 PM
>>>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>>>>>
>>>>>> Stian,
>>>>>>
>>>>>>      Regarding my tasks, I will be more dedicated to KC once I decrease
>>>>>>      my
>>>>>>      PL
>>>>>>      backlog a bit. This week is becoming very productive and will help
>>>>>>      me
>>>>>>      to
>>>>>>      plan my work load with more focus on my KC tasks.
>>>>>>
>>>>> Great, I was hoping that'd be the case :)
>>>>>
>>>>>>      Release date for 1.1.0.Final is 09/Feb/15, right ?
>>>>> No, hopefully around 09/Jan/15. With regards to identity brokering do you
>>>>> think you'll be able to wrap-it up by then or would you need longer?
>>>> In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...
>>>>
>>>> Regarding the brokering stuff, the missing bits are:
>>>>
>>>> - Remove old social references from code.
>>>> - Review Account page.
>>>> - Add more config options to SAML brokering
>>>>     - Upload IdP metadata
>>>>     - Signature and Encryption support
>>>>     - Http Binding Configuration for AuthnRequests
>>>>     - NameID Format configuration for AuthnRequests
>>>> - Automatic redirection when no credential is supported and a single IdP
>>>> is
>>>> configured/enabled.
>>>> - Test KC brokering.
>>>>     - Requires a better OIDC support in KC. We already have some JIRAs for
>>>>     that.
>>>>
>>>> There is also the attribute mapping stuff. Which will allow users to
>>>> resolve
>>>> claims/attributes from trusted IdPs. But to support that, I think we first
>>>> need the custom claim/profiles in place. However, this is not a blocker
>>>> for
>>>> a first release IMO.
>>>>
>>>> The broker is already doing the job. UI, model, REST endpoints,
>>>> persistence
>>>> and SPI are fine. We have everything we need to focus only on the
>>>> functional
>>>> bits.
>>>>
>>>>> For the other OpenID Connect tasks (1.2) we'll just do them in priority
>>>>> order. If you get stuck on PL issues we can push them out, or someone
>>>>> else
>>>>> can help you.
>>>>>
>>>>>> Regards.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Tuesday, December 16, 2014 9:13:44 AM
>>>>>> Subject: [keycloak-dev] Remaining work for 1.1.0.Final
>>>>>>
>>>>>> Before we start any new features we should release 1.1.0.Final. Are
>>>>>> there
>>>>>> any
>>>>>> outstanding tasks not listed in JIRA:
>>>>>>
>>>>>>     https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
>>>>>>
>>>>>> There's quite a lot of bugs associated with the release. I'd like us to
>>>>>> try
>>>>>> to get rid of as many as possible before releasing, so would be great if
>>>>>> everyone can do some bug fixing before starting on features for 1.2.
>>>>>>
>>>>>> Let's aim for a release shortly after we all return in the New Year.
>>>>>>
>>>>>> ----
>>>>>>
>>>>>> Features for 1.2 includes:
>>>>>>
>>>>>> * SAML redirect logout (KEYCLOAK-771, Bill)
>>>>>> * Custom user profiles (KEYCLOAK-311, Bill)
>>>>>> * Kerberos brokering (KEYCLOAK-828, Marek)
>>>>>> * LDAP enhancement (KEYCLOAK-886, Marek)
>>>>>> * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
>>>>>> * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
>>>>>> * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
>>>>>> * OpenID Connect Session Management - review and finish missing parts
>>>>>> (KEYCLOAK-451, Pedro)
>>>>>> * Fabric8 integration (Stian)
>>>>>>
>>>>>> ----
>>>>>>
>>>>>> I've started creating JIRA's for tasks we defined at the F2F and I'll
>>>>>> also
>>>>>> create agile boards (or use labels) to make it easy to identify
>>>>>> categories
>>>>>> of tasks. Main plan is to make it easy for us to pull out for example
>>>>>> all
>>>>>> tasks related to EAP, IDM, etc.
>>>>>>
>>>>>> I've also dropped the 1.x version. All tasks should now be scheduled for
>>>>>> current version, the next version or not have a version associated with
>>>>>> it.
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Tue Dec 16 09:27:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 09:27:12 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <549040D7.6020202@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
	<549036D4.8050702@redhat.com>
	<200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>
	<549040D7.6020202@redhat.com>
Message-ID: <615190419.18885645.1418740032904.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 16 December, 2014 3:25:27 PM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> On 16.12.2014 14:55, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva"
> >> <psilva at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Tuesday, December 16, 2014 11:42:44 AM
> >> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>
> >> On 16.12.2014 13:37, Stian Thorgersen wrote:
> >>> ----- Original Message -----
> >>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Tuesday, 16 December, 2014 1:25:50 PM
> >>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>>>
> >>>> Btw, regarding SAML brokering. I'm trying to focus on KC integration
> >>>> with
> >>>> a
> >>>> PL SAML IdP. I think that will help people (customers and community)
> >>>> already
> >>>> using PL to adopt KC without forcing them to drop existing
> >>>> infrastructure
> >>>> and investments. And that will also help them to think about a migration
> >>>> plan.
> >>> Makes sense. We should also provide a migration path for the stored
> >>> users.
> >>> If we moved to PL IDM that'd be easy, but not sure that'll happen
> >>> straight
> >>> away. Maybe we could provide a PL IDM user federation provider?
> >> Well, we defacto already have it :) Our LDAPFederationProvider is using
> >> Picketlink IDM API to bridge between keycloak model and
> >> org.picketlink.idm.model.basic.User . There is no direct interaction
> >> with LDAP, but everything goes through PL IDM API.
> >>
> >> In early stage when we discussed ldap integration and using PL IDM API
> >> for it, we also discussed that it could be nice if people could provide
> >> different source of PL IDM store. So there is PartitionManagerProvider
> >> interface, which provides access to pl idm PartitionManager. Right now
> >> we have just one implementation LDAPPartitionManagerProvider, which
> >> returns picketlink PartitionManager configured to use LDAP store based
> >> on ldap configuration provided by keycloak admin console.
> >>
> >> So theoretically only thing, which people need to do is to provide their
> >> own PartitionManagerProvider when they can configure PL IDM stores
> >> according to their environment. And this PartitionManagerProvider would
> >> need to be configured in keycloak-server.json, so it has precedence over
> >> the default LDAP based impl. Only condition is that their users should
> >> be retrievable with usage of org.picketlink.idm.model.basic.User from PL
> >> IDM Basic model.
> > Or they can just provide a JNDI url where the PartitionManager is located,
> > when using the subsystem. Also, PL IDM has the concept of stereotypes [1].
> > What means, in theory, that you can deal with any identity model
> > definition (eg.: not only the basic identity model).
> yeah, so we can do something like "SubsystemPartitionManagerProvider",
> which will allow people to retrieve PartitionManager from JNDI URL and
> they won't need to code anything by themselves. Only provide JDNI URL in
> configuration.

What about following the same pattern as we use for JPA and Infinispan. The default provider can either be configured to create on on it's own or you can set the data-source / jndi-name?

> >
> > [1]
> > http://docs.jboss.org/picketlink/2/latest/reference/html-single/#sect-Stereotypes
> >
> >> Marek
> >>>> ----- Original Message -----
> >>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Tuesday, December 16, 2014 10:15:40 AM
> >>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>> Sent: Tuesday, December 16, 2014 9:46:04 AM
> >>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>>> Sent: Tuesday, 16 December, 2014 12:38:35 PM
> >>>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>>>>>
> >>>>>> Stian,
> >>>>>>
> >>>>>>      Regarding my tasks, I will be more dedicated to KC once I
> >>>>>>      decrease
> >>>>>>      my
> >>>>>>      PL
> >>>>>>      backlog a bit. This week is becoming very productive and will
> >>>>>>      help
> >>>>>>      me
> >>>>>>      to
> >>>>>>      plan my work load with more focus on my KC tasks.
> >>>>>>
> >>>>> Great, I was hoping that'd be the case :)
> >>>>>
> >>>>>>      Release date for 1.1.0.Final is 09/Feb/15, right ?
> >>>>> No, hopefully around 09/Jan/15. With regards to identity brokering do
> >>>>> you
> >>>>> think you'll be able to wrap-it up by then or would you need longer?
> >>>> In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ...
> >>>>
> >>>> Regarding the brokering stuff, the missing bits are:
> >>>>
> >>>> - Remove old social references from code.
> >>>> - Review Account page.
> >>>> - Add more config options to SAML brokering
> >>>>     - Upload IdP metadata
> >>>>     - Signature and Encryption support
> >>>>     - Http Binding Configuration for AuthnRequests
> >>>>     - NameID Format configuration for AuthnRequests
> >>>> - Automatic redirection when no credential is supported and a single IdP
> >>>> is
> >>>> configured/enabled.
> >>>> - Test KC brokering.
> >>>>     - Requires a better OIDC support in KC. We already have some JIRAs
> >>>>     for
> >>>>     that.
> >>>>
> >>>> There is also the attribute mapping stuff. Which will allow users to
> >>>> resolve
> >>>> claims/attributes from trusted IdPs. But to support that, I think we
> >>>> first
> >>>> need the custom claim/profiles in place. However, this is not a blocker
> >>>> for
> >>>> a first release IMO.
> >>>>
> >>>> The broker is already doing the job. UI, model, REST endpoints,
> >>>> persistence
> >>>> and SPI are fine. We have everything we need to focus only on the
> >>>> functional
> >>>> bits.
> >>>>
> >>>>> For the other OpenID Connect tasks (1.2) we'll just do them in priority
> >>>>> order. If you get stuck on PL issues we can push them out, or someone
> >>>>> else
> >>>>> can help you.
> >>>>>
> >>>>>> Regards.
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>>> Sent: Tuesday, December 16, 2014 9:13:44 AM
> >>>>>> Subject: [keycloak-dev] Remaining work for 1.1.0.Final
> >>>>>>
> >>>>>> Before we start any new features we should release 1.1.0.Final. Are
> >>>>>> there
> >>>>>> any
> >>>>>> outstanding tasks not listed in JIRA:
> >>>>>>
> >>>>>>     https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1.0.Final
> >>>>>>
> >>>>>> There's quite a lot of bugs associated with the release. I'd like us
> >>>>>> to
> >>>>>> try
> >>>>>> to get rid of as many as possible before releasing, so would be great
> >>>>>> if
> >>>>>> everyone can do some bug fixing before starting on features for 1.2.
> >>>>>>
> >>>>>> Let's aim for a release shortly after we all return in the New Year.
> >>>>>>
> >>>>>> ----
> >>>>>>
> >>>>>> Features for 1.2 includes:
> >>>>>>
> >>>>>> * SAML redirect logout (KEYCLOAK-771, Bill)
> >>>>>> * Custom user profiles (KEYCLOAK-311, Bill)
> >>>>>> * Kerberos brokering (KEYCLOAK-828, Marek)
> >>>>>> * LDAP enhancement (KEYCLOAK-886, Marek)
> >>>>>> * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro)
> >>>>>> * OpenID Connect Discovery (KEYCLOAK-571, Pedro)
> >>>>>> * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro)
> >>>>>> * OpenID Connect Session Management - review and finish missing parts
> >>>>>> (KEYCLOAK-451, Pedro)
> >>>>>> * Fabric8 integration (Stian)
> >>>>>>
> >>>>>> ----
> >>>>>>
> >>>>>> I've started creating JIRA's for tasks we defined at the F2F and I'll
> >>>>>> also
> >>>>>> create agile boards (or use labels) to make it easy to identify
> >>>>>> categories
> >>>>>> of tasks. Main plan is to make it easy for us to pull out for example
> >>>>>> all
> >>>>>> tasks related to EAP, IDM, etc.
> >>>>>>
> >>>>>> I've also dropped the 1.x version. All tasks should now be scheduled
> >>>>>> for
> >>>>>> current version, the next version or not have a version associated
> >>>>>> with
> >>>>>> it.
> >>>>>> _______________________________________________
> >>>>>> keycloak-dev mailing list
> >>>>>> keycloak-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From stian at redhat.com  Tue Dec 16 09:51:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 09:51:04 -0500 (EST)
Subject: [keycloak-dev] Free SSL Certificates
In-Reply-To: <1129082686.18923216.1418741448497.JavaMail.zimbra@redhat.com>
Message-ID: <2119204088.18923363.1418741464092.JavaMail.zimbra@redhat.com>

http://thehackernews.com/2014/11/lets-encrypt-certificate-authority-to.html

From bburke at redhat.com  Tue Dec 16 09:55:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Dec 2014 09:55:26 -0500
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>	<423121058.31555336.1418729914994.JavaMail.zimbra@redhat.com>	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>	<549036D4.8050702@redhat.com>
	<200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>
Message-ID: <549047DE.6020103@redhat.com>



On 12/16/2014 8:55 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, December 16, 2014 11:42:44 AM
>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>
>> On 16.12.2014 13:37, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, 16 December, 2014 1:25:50 PM
>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>>>
>>>> Btw, regarding SAML brokering. I'm trying to focus on KC integration with
>>>> a
>>>> PL SAML IdP. I think that will help people (customers and community)
>>>> already
>>>> using PL to adopt KC without forcing them to drop existing infrastructure
>>>> and investments. And that will also help them to think about a migration
>>>> plan.
>>> Makes sense. We should also provide a migration path for the stored users.
>>> If we moved to PL IDM that'd be easy, but not sure that'll happen straight
>>> away. Maybe we could provide a PL IDM user federation provider?
>> Well, we defacto already have it :) Our LDAPFederationProvider is using
>> Picketlink IDM API to bridge between keycloak model and
>> org.picketlink.idm.model.basic.User . There is no direct interaction
>> with LDAP, but everything goes through PL IDM API.
>>
>> In early stage when we discussed ldap integration and using PL IDM API
>> for it, we also discussed that it could be nice if people could provide
>> different source of PL IDM store. So there is PartitionManagerProvider
>> interface, which provides access to pl idm PartitionManager. Right now
>> we have just one implementation LDAPPartitionManagerProvider, which
>> returns picketlink PartitionManager configured to use LDAP store based
>> on ldap configuration provided by keycloak admin console.
>>
>> So theoretically only thing, which people need to do is to provide their
>> own PartitionManagerProvider when they can configure PL IDM stores
>> according to their environment. And this PartitionManagerProvider would
>> need to be configured in keycloak-server.json, so it has precedence over
>> the default LDAP based impl. Only condition is that their users should
>> be retrievable with usage of org.picketlink.idm.model.basic.User from PL
>> IDM Basic model.
>
> Or they can just provide a JNDI url where the PartitionManager is located, when using the subsystem. Also, PL IDM has the concept of stereotypes [1]. What means, in theory, that you can deal with any identity model definition (eg.: not only the basic identity model).
>
> [1] http://docs.jboss.org/picketlink/2/latest/reference/html-single/#sect-Stereotypes
>

There would still need to be code to map from the user's "stereotype" to 
the Keycloak metamodel.

Bill

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

From stian at redhat.com  Tue Dec 16 10:16:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 10:16:47 -0500 (EST)
Subject: [keycloak-dev] Free SSL Certificates
In-Reply-To: <2119204088.18923363.1418741464092.JavaMail.zimbra@redhat.com>
References: <2119204088.18923363.1418741464092.JavaMail.zimbra@redhat.com>
Message-ID: <1757241698.18954811.1418743007855.JavaMail.zimbra@redhat.com>

This is actually pretty cool as you can generate a certificate automatically. Enabling SSL is as simple as:

$ sudo apt-get install lets-encrypt
$ lets-encrypt example.com

Would be cool to have the same integration with WildFly/Keycloak to automatically create a valid certificate.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 16 December, 2014 3:51:04 PM
> Subject: [keycloak-dev] Free SSL Certificates
> 
> http://thehackernews.com/2014/11/lets-encrypt-certificate-authority-to.html
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Tue Dec 16 10:20:46 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Dec 2014 16:20:46 +0100
Subject: [keycloak-dev] Database script for manual migration?
In-Reply-To: <548AEC19.2010002@redhat.com>
References: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>	<548AB634.2020805@redhat.com>	<CAAg5f2S=JyUWnAzC-FtOja8LCSy+6dpERKSL1wNeDe88Srrnzg@mail.gmail.com>	<CAAg5f2Qc=fJZrxNVCTExq5Si_Mk+s3tXxZmS2KjPkSff+jpcTw@mail.gmail.com>
	<548AEC19.2010002@redhat.com>
Message-ID: <54904DCE.6030800@redhat.com>

For Postgresql I have those SQL commands:

alter table REALM_AUDIT_LISTENERS rename to REALM_EVENTS_LISTENERS;
alter table REALM rename column AUDIT_ENABLED to EVENTS_ENABLED;
alter table REALM rename column AUDIT_EXPIRATION to EVENTS_EXPIRATION;

Tested with PostgreSQL 9.1. Unfortunately same commands doesn't work for 
MySQL :/

Marek

On 12.12.2014 14:22, Marek Posolda wrote:
> This is related to renaming of 'audit' to 'events', which was done 
> after 1.0-beta-4 and affect db schema.
>
> I've checked that there are no more major changes to db schema and 
> these 3 commands helped to migrate my MySQL 5 from beta-4 to 1.0.4.Final:
>
> rename table REALM_AUDIT_LISTENERS to REALM_EVENTS_LISTENERS;
> alter table REALM change AUDIT_ENABLED EVENTS_ENABLED bit(1);
> alter table REALM change AUDIT_EXPIRATION EVENTS_EXPIRATION bigint(20);
>
> However not sure if same commands work for other databases.
>
> Marek
>
> On 12.12.2014 12:27, Matthias Wessendorf wrote:
>> I *think* I tracked it down to this commit:
>>
>> https://github.com/keycloak/keycloak/commit/3bfe3d256ed0c292fbb040fa2276c737c3798864
>>
>> the 'org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled' 
>> field is present in KC 1.0.Final, but not in the 1.0-beta-4.
>>
>>
>>
>>
>> On Fri, Dec 12, 2014 at 11:50 AM, Matthias Wessendorf 
>> <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>>
>>     Hi Marek,
>>
>>     any chance to get a script to get that kinda migration done
>>     manually? I think this is now blocking us from upgrading to
>>     1.0.4.Final (from 1.0-beta-4, which we used in our 1.0.0.Final)
>>
>>     thanks,
>>     Matthias
>>
>>     On Fri, Dec 12, 2014 at 10:32 AM, Marek Posolda
>>     <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>
>>         Unfortunately I don't think that we have this. We have
>>         automatic migration available with liquibase, but this is
>>         from 1.0.0.Final (or newer) to 1.1.0.X .
>>
>>         Marek
>>
>>
>>         On 11.12.2014 16:50, Matthias Wessendorf wrote:
>>>         Hi,
>>>
>>>         I am wondering do you guys have a .sql script for going from
>>>         '1.0-beta-4' to '1.0.4.Final' ?
>>>
>>>         My motivation is updating the an instance of UPS 1.0.0.Final
>>>         (was using Keycloak-1.0-beta-4) to latest stable release
>>>         candidate (1.0.3-SNAPSHOT, which is using Keycloak-1.0.4.Final)
>>>
>>>         Deploying the new auth-server (that we build ourselfs), is
>>>         giving me this (with Postgres and MySQL)
>>>
>>>
>>>
>>>
>>>         13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service
>>>         thread 1-15) MSC000001: Failed to start service
>>>         jboss.undertow.deployment.default-server.default-host./auth:
>>>         org.jboss.msc.service.StartException in service
>>>         jboss.undertow.deployment.default-server.default-host./auth:
>>>         Failed to start service
>>>         at
>>>         org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>>>         [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>>         at
>>>         java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>         [rt.jar:1.7.0_65]
>>>         at
>>>         java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>         [rt.jar:1.7.0_65]
>>>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
>>>         Caused by: java.lang.RuntimeException: Failed to construct
>>>         public
>>>         org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>>         at
>>>         org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
>>>         at
>>>         org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
>>>         at
>>>         org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
>>>         at
>>>         org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
>>>         at
>>>         org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
>>>         at
>>>         org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>>>         at
>>>         io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>>>         at
>>>         org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
>>>         at
>>>         io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>>>         at
>>>         io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
>>>         at
>>>         io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
>>>         at
>>>         io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
>>>         at
>>>         org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
>>>         at
>>>         org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>>>         at
>>>         org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>>>         [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>>         at
>>>         org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>>>         [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>>         ... 3 more
>>>         Caused by: org.keycloak.models.ModelException:
>>>         javax.persistence.PersistenceException:
>>>         org.hibernate.PropertyAccessException: Null value was
>>>         assigned to a property of primitive type setter of
>>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>         at
>>>         org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
>>>         at
>>>         org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
>>>         at com.sun.proxy.$Proxy128.find(Unknown Source)
>>>         at
>>>         org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
>>>         at
>>>         org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
>>>         at
>>>         org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
>>>         at
>>>         org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
>>>         at
>>>         org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
>>>         at
>>>         org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
>>>         at
>>>         org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
>>>         at
>>>         org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
>>>         at
>>>         sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>>         [rt.jar:1.7.0_65]
>>>         at
>>>         sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>>>         [rt.jar:1.7.0_65]
>>>         at
>>>         sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>         [rt.jar:1.7.0_65]
>>>         at
>>>         java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>>>         [rt.jar:1.7.0_65]
>>>         at
>>>         org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
>>>         ... 18 more
>>>         Caused by: javax.persistence.PersistenceException:
>>>         org.hibernate.PropertyAccessException: Null value was
>>>         assigned to a property of primitive type setter of
>>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>         at
>>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
>>>         at
>>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694
>>>         <tel:1694>)
>>>         at
>>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
>>>         at
>>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>         Method) [rt.jar:1.7.0_65]
>>>         at
>>>         sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>         [rt.jar:1.7.0_65]
>>>         at
>>>         sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>         [rt.jar:1.7.0_65]
>>>         at java.lang.reflect.Method.invoke(Method.java:606)
>>>         [rt.jar:1.7.0_65]
>>>         at
>>>         org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
>>>         ... 32 more
>>>         Caused by: org.hibernate.PropertyAccessException: Null value
>>>         was assigned to a property of primitive type setter of
>>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>         at
>>>         org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
>>>         at
>>>         org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
>>>         at
>>>         org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
>>>         at
>>>         org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
>>>         at
>>>         org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
>>>         at
>>>         org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
>>>         at
>>>         org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
>>>         at
>>>         org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
>>>         at
>>>         org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
>>>         at
>>>         org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
>>>         at
>>>         org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
>>>         at
>>>         org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
>>>         at
>>>         org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
>>>         at
>>>         org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
>>>         at
>>>         org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
>>>         at
>>>         org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
>>>         at
>>>         org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
>>>         at
>>>         org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
>>>         at
>>>         org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
>>>         at
>>>         org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
>>>         at
>>>         org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
>>>         at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
>>>         at
>>>         org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
>>>         ... 38 more
>>>         Caused by: java.lang.IllegalArgumentException: Can not set
>>>         boolean field
>>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>         to null value
>>>         at
>>>         sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
>>>         [rt.jar:1.7.0_65]
>>>         at
>>>         sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
>>>         [rt.jar:1.7.0_65]
>>>         at
>>>         sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
>>>         [rt.jar:1.7.0_65]
>>>         at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
>>>         at
>>>         org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
>>>         ... 60 more
>>>
>>>         13:32:29,205 ERROR
>>>         [org.jboss.as.controller.management-operation] (Controller
>>>         Boot Thread) JBAS014613: Operation ("deploy") failed -
>>>         address: ([("deployment" => "auth-server.war")]) - failure
>>>         description: {"JBAS014671: Failed services" =>
>>>         {"jboss.undertow.deployment.default-server.default-host./auth"
>>>         => "org.jboss.msc.service.StartException in service
>>>         jboss.undertow.deployment.default-server.default-host./auth:
>>>         Failed to start service
>>>             Caused by: java.lang.RuntimeException: Failed to
>>>         construct public
>>>         org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>>             Caused by: org.keycloak.models.ModelException:
>>>         javax.persistence.PersistenceException:
>>>         org.hibernate.PropertyAccessException: Null value was
>>>         assigned to a property of primitive type setter of
>>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>             Caused by: javax.persistence.PersistenceException:
>>>         org.hibernate.PropertyAccessException: Null value was
>>>         assigned to a property of primitive type setter of
>>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>             Caused by: org.hibernate.PropertyAccessException: Null
>>>         value was assigned to a property of primitive type setter of
>>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>             Caused by: java.lang.IllegalArgumentException: Can not
>>>         set boolean field
>>>         org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>         to null value"}}
>>>
>>>
>>>         Thanks,
>>>         Matthias
>>>
>>>         -- 
>>>         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  <mailto: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
>>
>>
>>
>> -- 
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141216/87cc36a0/attachment-0001.html 

From bruno at abstractj.org  Tue Dec 16 10:55:13 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 16 Dec 2014 13:55:13 -0200
Subject: [keycloak-dev] Free SSL Certificates
In-Reply-To: <1757241698.18954811.1418743007855.JavaMail.zimbra@redhat.com>
References: <2119204088.18923363.1418741464092.JavaMail.zimbra@redhat.com>
	<1757241698.18954811.1418743007855.JavaMail.zimbra@redhat.com>
Message-ID: <20141216155513.GA57415@abstractj.org>

I think that might be a good fit for the docker image. Currently we
generate self signed certificates for UPS[1]. The same can be done for
Keycloak.

[1] -
https://github.com/aerogear/dockerfiles/blob/master/wildfly/Dockerfile#L33

On 2014-12-16, Stian Thorgersen wrote:
> This is actually pretty cool as you can generate a certificate automatically. Enabling SSL is as simple as:
>
> $ sudo apt-get install lets-encrypt
> $ lets-encrypt example.com
>
> Would be cool to have the same integration with WildFly/Keycloak to automatically create a valid certificate.
>
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, 16 December, 2014 3:51:04 PM
> > Subject: [keycloak-dev] Free SSL Certificates
> >
> > http://thehackernews.com/2014/11/lets-encrypt-certificate-authority-to.html
> > _______________________________________________
> > 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

--

abstractj
PGP: 0x84DC9914

From psilva at redhat.com  Tue Dec 16 11:12:06 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 16 Dec 2014 11:12:06 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <549047DE.6020103@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
	<549036D4.8050702@redhat.com>
	<200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>
	<549047DE.6020103@redhat.com>
Message-ID: <1140422926.31967513.1418746326784.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, December 16, 2014 12:55:26 PM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> 
> 
> On 12/16/2014 8:55 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva"
> >> <psilva at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Tuesday, December 16, 2014 11:42:44 AM
> >> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>
> >> On 16.12.2014 13:37, Stian Thorgersen wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Tuesday, 16 December, 2014 1:25:50 PM
> >>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> >>>>
> >>>> Btw, regarding SAML brokering. I'm trying to focus on KC integration
> >>>> with
> >>>> a
> >>>> PL SAML IdP. I think that will help people (customers and community)
> >>>> already
> >>>> using PL to adopt KC without forcing them to drop existing
> >>>> infrastructure
> >>>> and investments. And that will also help them to think about a migration
> >>>> plan.
> >>> Makes sense. We should also provide a migration path for the stored
> >>> users.
> >>> If we moved to PL IDM that'd be easy, but not sure that'll happen
> >>> straight
> >>> away. Maybe we could provide a PL IDM user federation provider?
> >> Well, we defacto already have it :) Our LDAPFederationProvider is using
> >> Picketlink IDM API to bridge between keycloak model and
> >> org.picketlink.idm.model.basic.User . There is no direct interaction
> >> with LDAP, but everything goes through PL IDM API.
> >>
> >> In early stage when we discussed ldap integration and using PL IDM API
> >> for it, we also discussed that it could be nice if people could provide
> >> different source of PL IDM store. So there is PartitionManagerProvider
> >> interface, which provides access to pl idm PartitionManager. Right now
> >> we have just one implementation LDAPPartitionManagerProvider, which
> >> returns picketlink PartitionManager configured to use LDAP store based
> >> on ldap configuration provided by keycloak admin console.
> >>
> >> So theoretically only thing, which people need to do is to provide their
> >> own PartitionManagerProvider when they can configure PL IDM stores
> >> according to their environment. And this PartitionManagerProvider would
> >> need to be configured in keycloak-server.json, so it has precedence over
> >> the default LDAP based impl. Only condition is that their users should
> >> be retrievable with usage of org.picketlink.idm.model.basic.User from PL
> >> IDM Basic model.
> >
> > Or they can just provide a JNDI url where the PartitionManager is located,
> > when using the subsystem. Also, PL IDM has the concept of stereotypes [1].
> > What means, in theory, that you can deal with any identity model
> > definition (eg.: not only the basic identity model).
> >
> > [1]
> > http://docs.jboss.org/picketlink/2/latest/reference/html-single/#sect-Stereotypes
> >
> 
> There would still need to be code to map from the user's "stereotype" to
> the Keycloak metamodel.

Yeah, true. The idea behind those stereotypes is that PL provides some built-in features that require some very specific info to integrate any identity model with them. For instance, authorization based on RBAC and GBAC. So you can just plug your identity model and get things working without having to deal with SPIs.

> 
> Bill
> 
> --
> 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 Dec 16 11:57:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 11:57:11 -0500 (EST)
Subject: [keycloak-dev] Free SSL Certificates
In-Reply-To: <20141216155513.GA57415@abstractj.org>
References: <2119204088.18923363.1418741464092.JavaMail.zimbra@redhat.com>
	<1757241698.18954811.1418743007855.JavaMail.zimbra@redhat.com>
	<20141216155513.GA57415@abstractj.org>
Message-ID: <361192879.19126545.1418749031326.JavaMail.zimbra@redhat.com>

I was thinking if we did a basic certificate server that could generate internal certificates and provided the same api as lets-encrypt then users could have certificates for internal ips/domains and external domains done automatically.

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 16 December, 2014 4:55:13 PM
> Subject: Re: [keycloak-dev] Free SSL Certificates
> 
> I think that might be a good fit for the docker image. Currently we
> generate self signed certificates for UPS[1]. The same can be done for
> Keycloak.
> 
> [1] -
> https://github.com/aerogear/dockerfiles/blob/master/wildfly/Dockerfile#L33
> 
> On 2014-12-16, Stian Thorgersen wrote:
> > This is actually pretty cool as you can generate a certificate
> > automatically. Enabling SSL is as simple as:
> >
> > $ sudo apt-get install lets-encrypt
> > $ lets-encrypt example.com
> >
> > Would be cool to have the same integration with WildFly/Keycloak to
> > automatically create a valid certificate.
> >
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Tuesday, 16 December, 2014 3:51:04 PM
> > > Subject: [keycloak-dev] Free SSL Certificates
> > >
> > > http://thehackernews.com/2014/11/lets-encrypt-certificate-authority-to.html
> > > _______________________________________________
> > > 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
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> 

From mposolda at redhat.com  Tue Dec 16 12:15:30 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Dec 2014 18:15:30 +0100
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <615190419.18885645.1418740032904.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<512968874.18622703.1418730364885.JavaMail.zimbra@redhat.com>
	<503211452.31565132.1418732140419.JavaMail.zimbra@redhat.com>
	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
	<549036D4.8050702@redhat.com>
	<200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>
	<549040D7.6020202@redhat.com>
	<615190419.18885645.1418740032904.JavaMail.zimbra@redhat.com>
Message-ID: <549068B2.80803@redhat.com>

On 16.12.2014 15:27, Stian Thorgersen wrote:
>>>>> Makes sense. We should also provide a migration path for the stored
>>>>> > >>>users.
>>>>> > >>>If we moved to PL IDM that'd be easy, but not sure that'll happen
>>>>> > >>>straight
>>>>> > >>>away. Maybe we could provide a PL IDM user federation provider?
>>>> > >>Well, we defacto already have it:)  Our LDAPFederationProvider is using
>>>> > >>Picketlink IDM API to bridge between keycloak model and
>>>> > >>org.picketlink.idm.model.basic.User . There is no direct interaction
>>>> > >>with LDAP, but everything goes through PL IDM API.
>>>> > >>
>>>> > >>In early stage when we discussed ldap integration and using PL IDM API
>>>> > >>for it, we also discussed that it could be nice if people could provide
>>>> > >>different source of PL IDM store. So there is PartitionManagerProvider
>>>> > >>interface, which provides access to pl idm PartitionManager. Right now
>>>> > >>we have just one implementation LDAPPartitionManagerProvider, which
>>>> > >>returns picketlink PartitionManager configured to use LDAP store based
>>>> > >>on ldap configuration provided by keycloak admin console.
>>>> > >>
>>>> > >>So theoretically only thing, which people need to do is to provide their
>>>> > >>own PartitionManagerProvider when they can configure PL IDM stores
>>>> > >>according to their environment. And this PartitionManagerProvider would
>>>> > >>need to be configured in keycloak-server.json, so it has precedence over
>>>> > >>the default LDAP based impl. Only condition is that their users should
>>>> > >>be retrievable with usage of org.picketlink.idm.model.basic.User from PL
>>>> > >>IDM Basic model.
>>> > >Or they can just provide a JNDI url where the PartitionManager is located,
>>> > >when using the subsystem. Also, PL IDM has the concept of stereotypes [1].
>>> > >What means, in theory, that you can deal with any identity model
>>> > >definition (eg.: not only the basic identity model).
>> >yeah, so we can do something like "SubsystemPartitionManagerProvider",
>> >which will allow people to retrieve PartitionManager from JNDI URL and
>> >they won't need to code anything by themselves. Only provide JDNI URL in
>> >configuration.
> What about following the same pattern as we use for JPA and Infinispan. The default provider can either be configured to create on on it's own or you can set the data-source / jndi-name?
>
Yeah, that should work well. Tricky thing is how to configure it in 
admin console? Right now we have 'ldap' federation provider, which 
allows to configure ldap settings and this is the provider, which 
delegates to picketlink. So possible solution is:

1) Add another provider in admin console. So they will be both 'ldap' 
and 'picketlink' providers available. In the screen for 'ldap' provider, 
people can configure LDAP like it's now. In the screen for 'picketlink' 
provider, people can configure just JNDI URL from where they can 
retrieve PartitionManager from picketlink subsystem. Implementation 
wise, we can have 2 implementations of UserFederationProviderFactory, 
which will differ just in the detail on how to retrieve PartitionManager 
- 
https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main/java/org/keycloak/federation/ldap/LDAPFederationProviderFactory.java#L46 
.
The 'ldap' impl can call: 
session.getProvider(PartitionManagerProvider.class, 'ldap') to retrieve 
LDAPPartitionManagerProvider.
The 'picketlink' impl can call: 
session.getProvider(PartitionManagerProvider.class, 'picketlink') to 
retrieve SubsystemPartitionManagerProvider (or 
PicketlinkPartitionManagerProvider ?), which will retrieve 
PartitionManager from configured JNDI URL.

2) Have single impl of UserFederationProvider and in admin console, 
there may be checkbox. If checked, people can configure JNDI URL. If not 
checked, people can configure LDAP like it's now.

I like (1) more. Solution (2) make it a bit harder to enable LDAP 
integration. Better ideas?

Marek

From matzew at apache.org  Tue Dec 16 13:45:05 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 16 Dec 2014 19:45:05 +0100
Subject: [keycloak-dev] Database script for manual migration?
In-Reply-To: <54904DCE.6030800@redhat.com>
References: <CAAg5f2SWzJY1paNHtYi76J4pNTSOqiL4LdnWDPeQ02hvt5KRtw@mail.gmail.com>
	<548AB634.2020805@redhat.com>
	<CAAg5f2S=JyUWnAzC-FtOja8LCSy+6dpERKSL1wNeDe88Srrnzg@mail.gmail.com>
	<CAAg5f2Qc=fJZrxNVCTExq5Si_Mk+s3tXxZmS2KjPkSff+jpcTw@mail.gmail.com>
	<548AEC19.2010002@redhat.com> <54904DCE.6030800@redhat.com>
Message-ID: <CAAg5f2TsGX7fpKQHWVUrOa+DuvCZssbQcK=W5RU1mSaAc+EVSw@mail.gmail.com>

Thanks, Marek!

that worked fine!

On Tue, Dec 16, 2014 at 4:20 PM, Marek Posolda <mposolda at redhat.com> wrote:
>
>  For Postgresql I have those SQL commands:
>
> alter table REALM_AUDIT_LISTENERS rename to REALM_EVENTS_LISTENERS;
> alter table REALM rename column AUDIT_ENABLED to EVENTS_ENABLED;
> alter table REALM rename column AUDIT_EXPIRATION to EVENTS_EXPIRATION;
>
> Tested with PostgreSQL 9.1. Unfortunately same commands doesn't work for
> MySQL :/
>
> Marek
>
>
> On 12.12.2014 14:22, Marek Posolda wrote:
>
> This is related to renaming of 'audit' to 'events', which was done after
> 1.0-beta-4 and affect db schema.
>
> I've checked that there are no more major changes to db schema and these 3
> commands helped to migrate my MySQL 5 from beta-4 to 1.0.4.Final:
>
> rename table REALM_AUDIT_LISTENERS to REALM_EVENTS_LISTENERS;
> alter table REALM change AUDIT_ENABLED EVENTS_ENABLED bit(1);
> alter table REALM change AUDIT_EXPIRATION EVENTS_EXPIRATION bigint(20);
>
> However not sure if same commands work for other databases.
>
> Marek
>
> On 12.12.2014 12:27, Matthias Wessendorf wrote:
>
>  I *think* I tracked it down to this commit:
>
>
> https://github.com/keycloak/keycloak/commit/3bfe3d256ed0c292fbb040fa2276c737c3798864
>
>  the 'org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled' field
> is present in KC 1.0.Final, but not in the 1.0-beta-4.
>
>
>
>
> On Fri, Dec 12, 2014 at 11:50 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>>
>> Hi Marek,
>>
>>  any chance to get a script to get that kinda migration done manually? I
>> think this is now blocking us from upgrading to 1.0.4.Final (from 1.0-beta-4,
>> which we used in our 1.0.0.Final)
>>
>>  thanks,
>> Matthias
>>
>> On Fri, Dec 12, 2014 at 10:32 AM, Marek Posolda <mposolda at redhat.com>
>> wrote:
>>>
>>>  Unfortunately I don't think that we have this. We have automatic
>>> migration available with liquibase, but this is from 1.0.0.Final (or newer)
>>> to 1.1.0.X .
>>>
>>> Marek
>>>
>>>
>>> On 11.12.2014 16:50, Matthias Wessendorf wrote:
>>>
>>>   Hi,
>>>
>>>  I am wondering do you guys have a .sql script for going from
>>> '1.0-beta-4' to '1.0.4.Final' ?
>>>
>>>  My motivation is updating the an instance of UPS 1.0.0.Final (was
>>> using Keycloak-1.0-beta-4) to latest stable release candidate
>>> (1.0.3-SNAPSHOT, which is using Keycloak-1.0.4.Final)
>>>
>>>  Deploying the new auth-server (that we build ourselfs), is giving me
>>> this (with Postgres and MySQL)
>>>
>>>
>>>
>>>
>>>  13:32:29,191 ERROR [org.jboss.msc.service.fail] (MSC service thread
>>> 1-15) MSC000001: Failed to start service
>>> jboss.undertow.deployment.default-server.default-host./auth:
>>> org.jboss.msc.service.StartException in service
>>> jboss.undertow.deployment.default-server.default-host./auth: Failed to
>>> start service
>>>  at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>>  at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>> [rt.jar:1.7.0_65]
>>>  at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>> [rt.jar:1.7.0_65]
>>>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
>>> Caused by: java.lang.RuntimeException: Failed to construct public
>>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>>  at
>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
>>>  at
>>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
>>>  at
>>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
>>>  at
>>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
>>>  at
>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
>>>  at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>>>  at
>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>>>  at
>>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79)
>>>  at
>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>>>  at
>>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
>>>  at
>>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
>>>  at
>>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
>>>  at
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
>>>  at
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>>>  at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>>  at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>>  ... 3 more
>>> Caused by: org.keycloak.models.ModelException:
>>> javax.persistence.PersistenceException:
>>> org.hibernate.PropertyAccessException: Null value was assigned to a
>>> property of primitive type setter of
>>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>  at
>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
>>>  at
>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
>>>  at com.sun.proxy.$Proxy128.find(Unknown Source)
>>>  at
>>> org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:51)
>>>  at
>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:173)
>>>  at
>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:42)
>>>  at
>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33)
>>>  at
>>> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137)
>>>  at
>>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40)
>>>  at
>>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:86)
>>>  at
>>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.<init>(UpsKeycloakApplication.java:35)
>>>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>> Method) [rt.jar:1.7.0_65]
>>>  at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>>> [rt.jar:1.7.0_65]
>>>  at
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>> [rt.jar:1.7.0_65]
>>>  at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>>> [rt.jar:1.7.0_65]
>>>  at
>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
>>>  ... 18 more
>>> Caused by: javax.persistence.PersistenceException:
>>> org.hibernate.PropertyAccessException: Null value was assigned to a
>>> property of primitive type setter of
>>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>  at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
>>>  at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:
>>> 1694)
>>>  at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
>>>  at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
>>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> [rt.jar:1.7.0_65]
>>>  at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> [rt.jar:1.7.0_65]
>>>  at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> [rt.jar:1.7.0_65]
>>>  at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
>>>  at
>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
>>>  ... 32 more
>>> Caused by: org.hibernate.PropertyAccessException: Null value was
>>> assigned to a property of primitive type setter of
>>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>  at
>>> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126)
>>>  at
>>> org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713)
>>>  at
>>> org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362)
>>>  at
>>> org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718)
>>>  at
>>> org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188)
>>>  at
>>> org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144)
>>>  at
>>> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244)
>>>  at
>>> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215)
>>>  at
>>> org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140)
>>>  at
>>> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
>>>  at
>>> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
>>>  at
>>> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
>>>  at
>>> org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
>>>  at
>>> org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
>>>  at
>>> org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
>>>  at
>>> org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
>>>  at
>>> org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
>>>  at
>>> org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
>>>  at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070)
>>>  at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
>>>  at
>>> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551)
>>>  at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955)
>>>  at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
>>>  ... 38 more
>>> Caused by: java.lang.IllegalArgumentException: Can not set boolean field
>>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null value
>>>  at
>>> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
>>> [rt.jar:1.7.0_65]
>>>  at
>>> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
>>> [rt.jar:1.7.0_65]
>>>  at
>>> sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80)
>>> [rt.jar:1.7.0_65]
>>>  at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65]
>>>  at
>>> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122)
>>>  ... 60 more
>>>
>>>  13:32:29,205 ERROR [org.jboss.as.controller.management-operation]
>>> (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address:
>>> ([("deployment" => "auth-server.war")]) - failure description:
>>> {"JBAS014671: Failed services" =>
>>> {"jboss.undertow.deployment.default-server.default-host./auth" =>
>>> "org.jboss.msc.service.StartException in service
>>> jboss.undertow.deployment.default-server.default-host./auth: Failed to
>>> start service
>>>     Caused by: java.lang.RuntimeException: Failed to construct public
>>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>>     Caused by: org.keycloak.models.ModelException:
>>> javax.persistence.PersistenceException:
>>> org.hibernate.PropertyAccessException: Null value was assigned to a
>>> property of primitive type setter of
>>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>     Caused by: javax.persistence.PersistenceException:
>>> org.hibernate.PropertyAccessException: Null value was assigned to a
>>> property of primitive type setter of
>>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>     Caused by: org.hibernate.PropertyAccessException: Null value was
>>> assigned to a property of primitive type setter of
>>> org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled
>>>     Caused by: java.lang.IllegalArgumentException: Can not set boolean
>>> field org.keycloak.models.jpa.entities.RealmEntity.eventsEnabled to null
>>> value"}}
>>>
>>>
>>>  Thanks,
>>> Matthias
>>>
>>>  --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>>
>>>  _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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
>>
>
>
>  --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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/20141216/987df958/attachment-0001.html 

From stian at redhat.com  Wed Dec 17 03:11:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Dec 2014 03:11:21 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <549068B2.80803@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>
	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>
	<549036D4.8050702@redhat.com>
	<200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>
	<549040D7.6020202@redhat.com>
	<615190419.18885645.1418740032904.JavaMail.zimbra@redhat.com>
	<549068B2.80803@redhat.com>
Message-ID: <1820579121.19576735.1418803881524.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 16 December, 2014 6:15:30 PM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> On 16.12.2014 15:27, Stian Thorgersen wrote:
> >>>>> Makes sense. We should also provide a migration path for the stored
> >>>>> > >>>users.
> >>>>> > >>>If we moved to PL IDM that'd be easy, but not sure that'll happen
> >>>>> > >>>straight
> >>>>> > >>>away. Maybe we could provide a PL IDM user federation provider?
> >>>> > >>Well, we defacto already have it:)  Our LDAPFederationProvider is
> >>>> > >>using
> >>>> > >>Picketlink IDM API to bridge between keycloak model and
> >>>> > >>org.picketlink.idm.model.basic.User . There is no direct interaction
> >>>> > >>with LDAP, but everything goes through PL IDM API.
> >>>> > >>
> >>>> > >>In early stage when we discussed ldap integration and using PL IDM
> >>>> > >>API
> >>>> > >>for it, we also discussed that it could be nice if people could
> >>>> > >>provide
> >>>> > >>different source of PL IDM store. So there is
> >>>> > >>PartitionManagerProvider
> >>>> > >>interface, which provides access to pl idm PartitionManager. Right
> >>>> > >>now
> >>>> > >>we have just one implementation LDAPPartitionManagerProvider, which
> >>>> > >>returns picketlink PartitionManager configured to use LDAP store
> >>>> > >>based
> >>>> > >>on ldap configuration provided by keycloak admin console.
> >>>> > >>
> >>>> > >>So theoretically only thing, which people need to do is to provide
> >>>> > >>their
> >>>> > >>own PartitionManagerProvider when they can configure PL IDM stores
> >>>> > >>according to their environment. And this PartitionManagerProvider
> >>>> > >>would
> >>>> > >>need to be configured in keycloak-server.json, so it has precedence
> >>>> > >>over
> >>>> > >>the default LDAP based impl. Only condition is that their users
> >>>> > >>should
> >>>> > >>be retrievable with usage of org.picketlink.idm.model.basic.User
> >>>> > >>from PL
> >>>> > >>IDM Basic model.
> >>> > >Or they can just provide a JNDI url where the PartitionManager is
> >>> > >located,
> >>> > >when using the subsystem. Also, PL IDM has the concept of stereotypes
> >>> > >[1].
> >>> > >What means, in theory, that you can deal with any identity model
> >>> > >definition (eg.: not only the basic identity model).
> >> >yeah, so we can do something like "SubsystemPartitionManagerProvider",
> >> >which will allow people to retrieve PartitionManager from JNDI URL and
> >> >they won't need to code anything by themselves. Only provide JDNI URL in
> >> >configuration.
> > What about following the same pattern as we use for JPA and Infinispan. The
> > default provider can either be configured to create on on it's own or you
> > can set the data-source / jndi-name?
> >
> Yeah, that should work well. Tricky thing is how to configure it in
> admin console? Right now we have 'ldap' federation provider, which
> allows to configure ldap settings and this is the provider, which
> delegates to picketlink. So possible solution is:
> 
> 1) Add another provider in admin console. So they will be both 'ldap'
> and 'picketlink' providers available. In the screen for 'ldap' provider,
> people can configure LDAP like it's now. In the screen for 'picketlink'
> provider, people can configure just JNDI URL from where they can
> retrieve PartitionManager from picketlink subsystem. Implementation
> wise, we can have 2 implementations of UserFederationProviderFactory,
> which will differ just in the detail on how to retrieve PartitionManager
> -
> https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main/java/org/keycloak/federation/ldap/LDAPFederationProviderFactory.java#L46
> .
> The 'ldap' impl can call:
> session.getProvider(PartitionManagerProvider.class, 'ldap') to retrieve
> LDAPPartitionManagerProvider.
> The 'picketlink' impl can call:
> session.getProvider(PartitionManagerProvider.class, 'picketlink') to
> retrieve SubsystemPartitionManagerProvider (or
> PicketlinkPartitionManagerProvider ?), which will retrieve
> PartitionManager from configured JNDI URL.
> 
> 2) Have single impl of UserFederationProvider and in admin console,
> there may be checkbox. If checked, people can configure JNDI URL. If not
> checked, people can configure LDAP like it's now.
> 
> I like (1) more. Solution (2) make it a bit harder to enable LDAP
> integration. Better ideas?

Hm.... I don't like either of those, but don't have any better ideas :/

> 
> Marek
> 

From bburke at redhat.com  Wed Dec 17 08:01:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Dec 2014 08:01:20 -0500
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <1820579121.19576735.1418803881524.JavaMail.zimbra@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>	<1233278806.31568086.1418732750947.JavaMail.zimbra@redhat.com>	<558816271.18776480.1418733431525.JavaMail.zimbra@redhat.com>	<549036D4.8050702@redhat.com>	<200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>	<549040D7.6020202@redhat.com>	<615190419.18885645.1418740032904.JavaMail.zimbra@redhat.com>	<549068B2.80803@redhat.com>
	<1820579121.19576735.1418803881524.JavaMail.zimbra@redhat.com>
Message-ID: <54917EA0.8030507@redhat.com>



On 12/17/2014 3:11 AM, Stian Thorgersen wrote:
>> Yeah, that should work well. Tricky thing is how to configure it in
>> admin console? Right now we have 'ldap' federation provider, which
>> allows to configure ldap settings and this is the provider, which
>> delegates to picketlink. So possible solution is:
>>
>> 1) Add another provider in admin console. So they will be both 'ldap'
>> and 'picketlink' providers available. In the screen for 'ldap' provider,
>> people can configure LDAP like it's now. In the screen for 'picketlink'
>> provider, people can configure just JNDI URL from where they can
>> retrieve PartitionManager from picketlink subsystem. Implementation
>> wise, we can have 2 implementations of UserFederationProviderFactory,
>> which will differ just in the detail on how to retrieve PartitionManager
>> -
>> https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main/java/org/keycloak/federation/ldap/LDAPFederationProviderFactory.java#L46
>> .
>> The 'ldap' impl can call:
>> session.getProvider(PartitionManagerProvider.class, 'ldap') to retrieve
>> LDAPPartitionManagerProvider.
>> The 'picketlink' impl can call:
>> session.getProvider(PartitionManagerProvider.class, 'picketlink') to
>> retrieve SubsystemPartitionManagerProvider (or
>> PicketlinkPartitionManagerProvider ?), which will retrieve
>> PartitionManager from configured JNDI URL.
>>
>> 2) Have single impl of UserFederationProvider and in admin console,
>> there may be checkbox. If checked, people can configure JNDI URL. If not
>> checked, people can configure LDAP like it's now.
>>
>> I like (1) more. Solution (2) make it a bit harder to enable LDAP
>> integration. Better ideas?
>
> Hm.... I don't like either of those, but don't have any better ideas :/
>

If the PL IDM API user is using the default PL IDM API security model, 
then we can write something generic and plug it in via a JNDI reference 
(1).  I don't understand why you are against this Stian.  Its just PL 
IDM API integration.

I don't like #2 at all.  Users should have no knowledge of PL IDM API 
when using our default LDAP provider.  My hope is that our LDAP provider 
becomes sophisticated enough that the user never needs to see any code 
even for the most complex LDAP deployments.


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

From stian at redhat.com  Wed Dec 17 08:13:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Dec 2014 08:13:08 -0500 (EST)
Subject: [keycloak-dev] Remaining work for 1.1.0.Final
In-Reply-To: <54917EA0.8030507@redhat.com>
References: <1062302546.18604521.1418728424233.JavaMail.zimbra@redhat.com>
	<549036D4.8050702@redhat.com>
	<200938548.31632123.1418738100554.JavaMail.zimbra@redhat.com>
	<549040D7.6020202@redhat.com>
	<615190419.18885645.1418740032904.JavaMail.zimbra@redhat.com>
	<549068B2.80803@redhat.com>
	<1820579121.19576735.1418803881524.JavaMail.zimbra@redhat.com>
	<54917EA0.8030507@redhat.com>
Message-ID: <1224596721.19907044.1418821988340.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 December, 2014 2:01:20 PM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> 
> 
> On 12/17/2014 3:11 AM, Stian Thorgersen wrote:
> >> Yeah, that should work well. Tricky thing is how to configure it in
> >> admin console? Right now we have 'ldap' federation provider, which
> >> allows to configure ldap settings and this is the provider, which
> >> delegates to picketlink. So possible solution is:
> >>
> >> 1) Add another provider in admin console. So they will be both 'ldap'
> >> and 'picketlink' providers available. In the screen for 'ldap' provider,
> >> people can configure LDAP like it's now. In the screen for 'picketlink'
> >> provider, people can configure just JNDI URL from where they can
> >> retrieve PartitionManager from picketlink subsystem. Implementation
> >> wise, we can have 2 implementations of UserFederationProviderFactory,
> >> which will differ just in the detail on how to retrieve PartitionManager
> >> -
> >> https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main/java/org/keycloak/federation/ldap/LDAPFederationProviderFactory.java#L46
> >> .
> >> The 'ldap' impl can call:
> >> session.getProvider(PartitionManagerProvider.class, 'ldap') to retrieve
> >> LDAPPartitionManagerProvider.
> >> The 'picketlink' impl can call:
> >> session.getProvider(PartitionManagerProvider.class, 'picketlink') to
> >> retrieve SubsystemPartitionManagerProvider (or
> >> PicketlinkPartitionManagerProvider ?), which will retrieve
> >> PartitionManager from configured JNDI URL.
> >>
> >> 2) Have single impl of UserFederationProvider and in admin console,
> >> there may be checkbox. If checked, people can configure JNDI URL. If not
> >> checked, people can configure LDAP like it's now.
> >>
> >> I like (1) more. Solution (2) make it a bit harder to enable LDAP
> >> integration. Better ideas?
> >
> > Hm.... I don't like either of those, but don't have any better ideas :/
> >
> 
> If the PL IDM API user is using the default PL IDM API security model,
> then we can write something generic and plug it in via a JNDI reference
> (1).  I don't understand why you are against this Stian.  Its just PL
> IDM API integration.

I don't like the idea of having a 'picketlink' provider. Problem is what happens when we merge the two projects? Also, what happens if we drop PicketLink IDM as a separate project?

Maybe we could call it 'picketlink2-idm' or something like that and not have it available by default. We could then document it as part of a migration from PicketLink to Keycloak documentation.

If we're going to use PicketLink IDM internally that changes it quite a lot, but that also depends on how we end up using it.

I'd say lets leave it for now, then have a discussion in January about how we plan to use PicketLink IDM in the future, and also what migration paths we should provide for existing PicketLink users.

> 
> I don't like #2 at all.  Users should have no knowledge of PL IDM API
> when using our default LDAP provider.  My hope is that our LDAP provider
> becomes sophisticated enough that the user never needs to see any code
> even for the most complex LDAP deployments.
> 
> 
> --
> 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 Dec 17 23:12:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Dec 2014 23:12:31 -0500
Subject: [keycloak-dev] JIRA emails
Message-ID: <5492542F.4070808@redhat.com>

Anybody else *NOT* getting JIRA emails?

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

From ssilvert at redhat.com  Thu Dec 18 07:33:00 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 Dec 2014 07:33:00 -0500
Subject: [keycloak-dev] JIRA emails
In-Reply-To: <5492542F.4070808@redhat.com>
References: <5492542F.4070808@redhat.com>
Message-ID: <5492C97C.1090201@redhat.com>

On 12/17/2014 11:12 PM, Bill Burke wrote:
> Anybody else *NOT* getting JIRA emails?
>
I'm not getting them either.

From gerbermichi at me.com  Thu Dec 18 08:13:24 2014
From: gerbermichi at me.com (Michael Gerber)
Date: Thu, 18 Dec 2014 13:13:24 +0000 (GMT)
Subject: [keycloak-dev] logged in user not in application session listed
Message-ID: <db38dfca-0fd9-4be8-9dd7-025337dd02fa@me.com>

Hi,

I use the REST WebService?realms/{realm}/protocol/openid-connect/grants/access to grant access to resources protected by keycloak.

But these logged in users are not listed in the Application Sessions.

Is there any way to get all active sessions for a given application or realm?

kind regards
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141218/7b6488c5/attachment.html 

From ssilvert at redhat.com  Thu Dec 18 08:39:52 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 Dec 2014 08:39:52 -0500
Subject: [keycloak-dev] Hacking on Keycloak
Message-ID: <5492D928.1040205@redhat.com>

I've created a Wiki to show it's not tricky,
To start working with our fine code.
It's short and it's sweet, and it's not quite complete,
But for now it is all that I showed.

https://github.com/keycloak/keycloak/wiki/Hacking-on-Keycloak

Feel free to add your own tips to this page.  Just refrain from poor 
verse like above.



From psilva at redhat.com  Thu Dec 18 08:58:00 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 18 Dec 2014 08:58:00 -0500 (EST)
Subject: [keycloak-dev] Hacking on Keycloak
In-Reply-To: <5492D928.1040205@redhat.com>
References: <5492D928.1040205@redhat.com>
Message-ID: <456429045.441251.1418911080121.JavaMail.zimbra@redhat.com>

One important tip that I got from Stian is the org.keycloak.testutils.KeycloakServer. It saves a lot of time when doing changes to code and UI.

----- Original Message -----
From: "Stan Silvert" <ssilvert at redhat.com>
To: keycloak-dev at lists.jboss.org, keycloak-user at lists.jboss.org
Sent: Thursday, December 18, 2014 11:39:52 AM
Subject: [keycloak-dev] Hacking on Keycloak

I've created a Wiki to show it's not tricky,
To start working with our fine code.
It's short and it's sweet, and it's not quite complete,
But for now it is all that I showed.

https://github.com/keycloak/keycloak/wiki/Hacking-on-Keycloak

Feel free to add your own tips to this page.  Just refrain from poor 
verse like above.


_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From ssilvert at redhat.com  Thu Dec 18 12:15:50 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 Dec 2014 12:15:50 -0500
Subject: [keycloak-dev] Hacking on Keycloak
In-Reply-To: <456429045.441251.1418911080121.JavaMail.zimbra@redhat.com>
References: <5492D928.1040205@redhat.com>
	<456429045.441251.1418911080121.JavaMail.zimbra@redhat.com>
Message-ID: <54930BC6.8060001@redhat.com>

Sounds good.  Will you add it to the wiki?

On 12/18/2014 8:58 AM, Pedro Igor Silva wrote:
> One important tip that I got from Stian is the org.keycloak.testutils.KeycloakServer. It saves a lot of time when doing changes to code and UI.
>
> ----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org, keycloak-user at lists.jboss.org
> Sent: Thursday, December 18, 2014 11:39:52 AM
> Subject: [keycloak-dev] Hacking on Keycloak
>
> I've created a Wiki to show it's not tricky,
> To start working with our fine code.
> It's short and it's sweet, and it's not quite complete,
> But for now it is all that I showed.
>
> https://github.com/keycloak/keycloak/wiki/Hacking-on-Keycloak
>
> Feel free to add your own tips to this page.  Just refrain from poor
> verse like above.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Thu Dec 18 13:03:21 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 18 Dec 2014 13:03:21 -0500 (EST)
Subject: [keycloak-dev] Hacking on Keycloak
In-Reply-To: <54930BC6.8060001@redhat.com>
References: <5492D928.1040205@redhat.com>
	<456429045.441251.1418911080121.JavaMail.zimbra@redhat.com>
	<54930BC6.8060001@redhat.com>
Message-ID: <979084213.689511.1418925801953.JavaMail.zimbra@redhat.com>

Added ...

----- Original Message -----
From: "Stan Silvert" <ssilvert at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Thursday, December 18, 2014 3:15:50 PM
Subject: Re: [keycloak-dev] Hacking on Keycloak

Sounds good.  Will you add it to the wiki?

On 12/18/2014 8:58 AM, Pedro Igor Silva wrote:
> One important tip that I got from Stian is the org.keycloak.testutils.KeycloakServer. It saves a lot of time when doing changes to code and UI.
>
> ----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org, keycloak-user at lists.jboss.org
> Sent: Thursday, December 18, 2014 11:39:52 AM
> Subject: [keycloak-dev] Hacking on Keycloak
>
> I've created a Wiki to show it's not tricky,
> To start working with our fine code.
> It's short and it's sweet, and it's not quite complete,
> But for now it is all that I showed.
>
> https://github.com/keycloak/keycloak/wiki/Hacking-on-Keycloak
>
> Feel free to add your own tips to this page.  Just refrain from poor
> verse like above.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From gerbermichi at me.com  Fri Dec 19 11:03:10 2014
From: gerbermichi at me.com (Michael Gerber)
Date: Fri, 19 Dec 2014 16:03:10 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_resource_excludes_in_web=2Exml_not_work?=
 =?utf-8?q?ing_in_latest_master_build?=
Message-ID: <89aaf5ee-7b83-473b-ad00-b3b1012cc123@me.com>

Hi all,

I created today a build from the latest master branch and struggled with the following problem.
I've got some REST services which are excluded from keycloak, so I can access them without a logged in user. (see detail from web.xml)
The request body in these post rest services were always empty. I found out that my wildfly tried to authenticate all requests.
The?tokenStore.saveRequest() method in the OAuthRequestAuthenticator class read the inputStream and so it was empty later on.

I dont understand why all my requests are authenticated, even when they are excluded through the web.xml file.
So, I added the following lines in the ServletKeycloakAuthMech class in the authenticate method: (see?https://github.com/gerbermichi/keycloak/commit/1eaafcd3d9ad4082429ab500a4512c87d47ed75c)
if (!deployment.isConfigured() || !securityContext.isAuthenticationRequired()) {
? ? ? ? ? ? return AuthenticationMechanismOutcome.NOT_ATTEMPTED;
}

This hack solved all my problems. Is this a bug and should i create a pull request? Or are there some problems in my project configuration?

Detail from my web.xml file:
? <security-constraint>
? ? ? ? <web-resource-collection>
? ? ? ? ? ? <web-resource-name>Client WS</web-resource-name>
? ? ? ? ? ? <url-pattern>/clientws/*</url-pattern>
? ? ? ? </web-resource-collection>
? ? ? ? <web-resource-collection>
? ? ? ? ? ? <web-resource-name>Client Exchange WS</web-resource-name>
? ? ? ? ? ? <url-pattern>/services/exchange/*</url-pattern>
? ? ? ? </web-resource-collection>
? ? ? ? <user-data-constraint>
? ? ? ? ? ? <transport-guarantee>CONFIDENTIAL</transport-guarantee>
? ? ? ? </user-data-constraint>
? ? </security-constraint>

? ? <security-constraint>
? ? ? ? <web-resource-collection>
? ? ? ? ? ? <web-resource-name>All</web-resource-name>
? ? ? ? ? ? <url-pattern>/*</url-pattern>
? ? ? ? </web-resource-collection>
? ? ? ? <auth-constraint>
? ? ? ? ? ? <role-name>myRole</role-name>
? ? ? ? </auth-constraint>
? ? ? ? <user-data-constraint>
? ? ? ? ? ? <transport-guarantee>CONFIDENTIAL</transport-guarantee>
? ? ? ? </user-data-constraint>
? ? </security-constraint>

? ? <login-config>
? ? ? ? <auth-method>KEYCLOAK</auth-method>
? ? ? ? <realm-name>myRealm</realm-name>
? ? </login-config>

? ? <security-role>
? ? ? ? <role-name>myRole</role-name>
? ? </security-role>



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

From gerbermichi at me.com  Sat Dec 20 08:34:29 2014
From: gerbermichi at me.com (Michael Gerber)
Date: Sat, 20 Dec 2014 14:34:29 +0100
Subject: [keycloak-dev] resource excludes in web.xml not working in
 latest master build
In-Reply-To: <89aaf5ee-7b83-473b-ad00-b3b1012cc123@me.com>
References: <89aaf5ee-7b83-473b-ad00-b3b1012cc123@me.com>
Message-ID: <6A86D6E4-C580-44AA-AD34-0FD0102279D2@me.com>

I created a small demo app to show you what I meant:
https://github.com/gerbermichi/keycloak/tree/master/examples/demo-template/rest-resources <https://github.com/gerbermichi/keycloak/tree/master/examples/demo-template/rest-resources>

As you can see, keycloak consumes the post data during the authentication step, which is wrong, because the resource should be public (without any authentication)

	curl -X POST -H ?Content-Type: text/plain" http://localhost:8080/rest-resources/public -d 'hello world'
	You said:

My previous bug fix for this problem was wrong, but I think my latests changes in the RequestAuthenticator class would solve this problem.
You can find all my changes here: https://github.com/gerbermichi/keycloak/commit/512a68c5fa405567fe56968b5fdd9bb51eeb3316

	curl -X POST -H ?Content-Type: text/plain" http://localhost:8080/rest-resources/public -d 'hello world'
	You said: hello world

The only question is, how to implement the 
protected abstract boolean isAuthenticationRequired();
method correctly in the JettyRequestAuthenticator and CatalinaRequestAuthenticator class.



> Am 19.12.2014 um 17:03 schrieb Michael Gerber <gerbermichi at me.com>:
> 
> Hi all,
> 
> I created today a build from the latest master branch and struggled with the following problem.
> I've got some REST services which are excluded from keycloak, so I can access them without a logged in user. (see detail from web.xml)
> The request body in these post rest services were always empty. I found out that my wildfly tried to authenticate all requests.
> The tokenStore.saveRequest() method in the OAuthRequestAuthenticator class read the inputStream and so it was empty later on.
> 
> I dont understand why all my requests are authenticated, even when they are excluded through the web.xml file.
> So, I added the following lines in the ServletKeycloakAuthMech class in the authenticate method: (see https://github.com/gerbermichi/keycloak/commit/1eaafcd3d9ad4082429ab500a4512c87d47ed75c <https://github.com/gerbermichi/keycloak/commit/1eaafcd3d9ad4082429ab500a4512c87d47ed75c>)
> if (!deployment.isConfigured() || !securityContext.isAuthenticationRequired()) {
>             return AuthenticationMechanismOutcome.NOT_ATTEMPTED;
> }
> 
> This hack solved all my problems. Is this a bug and should i create a pull request? Or are there some problems in my project configuration?
> 
> Detail from my web.xml file:
>   <security-constraint>
>         <web-resource-collection>
>             <web-resource-name>Client WS</web-resource-name>
>             <url-pattern>/clientws/*</url-pattern>
>         </web-resource-collection>
>         <web-resource-collection>
>             <web-resource-name>Client Exchange WS</web-resource-name>
>             <url-pattern>/services/exchange/*</url-pattern>
>         </web-resource-collection>
>         <user-data-constraint>
>             <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>         </user-data-constraint>
>     </security-constraint>
> 
>     <security-constraint>
>         <web-resource-collection>
>             <web-resource-name>All</web-resource-name>
>             <url-pattern>/*</url-pattern>
>         </web-resource-collection>
>         <auth-constraint>
>             <role-name>myRole</role-name>
>         </auth-constraint>
>         <user-data-constraint>
>             <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>         </user-data-constraint>
>     </security-constraint>
> 
>     <login-config>
>         <auth-method>KEYCLOAK</auth-method>
>         <realm-name>myRealm</realm-name>
>     </login-config>
> 
>     <security-role>
>         <role-name>myRole</role-name>
>     </security-role>
> 
> 
> 
> _______________________________________________
> 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/20141220/137bfdce/attachment.html 

From bburke at redhat.com  Mon Dec 22 10:32:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Dec 2014 10:32:20 -0500
Subject: [keycloak-dev] resource excludes in web.xml not working in
 latest master build
In-Reply-To: <89aaf5ee-7b83-473b-ad00-b3b1012cc123@me.com>
References: <89aaf5ee-7b83-473b-ad00-b3b1012cc123@me.com>
Message-ID: <54983984.3020403@redhat.com>

Ok, I set up a JIRA.

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

I need to look at Jetty/Tomcat to see if authenticate() is called.  BTW, 
I'm not sure why Undertow is calling the authentication mechanism for 
unsecure resources.

On 12/19/2014 11:03 AM, Michael Gerber wrote:
> I created today a build from the latest master branch and struggled with
> the following problem.
> I've got some REST services which are excluded from keycloak, so I can
> access them without a logged in user. (see detail from web.xml)
> The request body in these post rest services were always empty. I found
> out that my wildfly tried to authenticate all requests.
> The tokenStore.saveRequest() method in the OAuthRequestAuthenticator
> class read the inputStream and so it was empty later on.
>
> I dont understand why all my requests are authenticated, even when they
> are excluded through the web.xml file.
> So, I added the following lines in the ServletKeycloakAuthMech class in
> the authenticate method: (see
> https://github.com/gerbermichi/keycloak/commit/1eaafcd3d9ad4082429ab500a4512c87d47ed75c)
> if (!deployment.isConfigured() ||
> !securityContext.isAuthenticationRequired()) {
>              return AuthenticationMechanismOutcome.NOT_ATTEMPTED;
> }
>
> This hack solved all my problems. Is this a bug and should i create a
> pull request? Or are there some problems in my project configuration?
>
> Detail from my web.xml file:
>    <security-constraint>
>          <web-resource-collection>
>              <web-resource-name>Client WS</web-resource-name>
>              <url-pattern>/clientws/*</url-pattern>
>          </web-resource-collection>
>          <web-resource-collection>
>              <web-resource-name>Client Exchange WS</web-resource-name>
>              <url-pattern>/services/exchange/*</url-pattern>
>          </web-resource-collection>
>          <user-data-constraint>
>              <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>          </user-data-constraint>
>      </security-constraint>
>
>      <security-constraint>
>          <web-resource-collection>
>              <web-resource-name>All</web-resource-name>
>              <url-pattern>/*</url-pattern>
>          </web-resource-collection>
>          <auth-constraint>
>              <role-name>myRole</role-name>
>          </auth-constraint>
>          <user-data-constraint>
>              <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>          </user-data-constraint>
>      </security-constraint>
>
>      <login-config>
>          <auth-method>KEYCLOAK</auth-method>
>          <realm-name>myRealm</realm-name>
>      </login-config>
>
>      <security-role>
>          <role-name>myRole</role-name>
>      </security-role>

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

From bburke at redhat.com  Mon Dec 22 10:41:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Dec 2014 10:41:45 -0500
Subject: [keycloak-dev] resource excludes in web.xml not working in
 latest master build
In-Reply-To: <54983984.3020403@redhat.com>
References: <89aaf5ee-7b83-473b-ad00-b3b1012cc123@me.com>
	<54983984.3020403@redhat.com>
Message-ID: <54983BB9.905@redhat.com>

I've pinged Undertow list on why auth mechanisms is invoked for 
unsecured resources.

On 12/22/2014 10:32 AM, Bill Burke wrote:
> Ok, I set up a JIRA.
>
> https://issues.jboss.org/browse/KEYCLOAK-901
>
> I need to look at Jetty/Tomcat to see if authenticate() is called.  BTW,
> I'm not sure why Undertow is calling the authentication mechanism for
> unsecure resources.
>
> On 12/19/2014 11:03 AM, Michael Gerber wrote:
>> I created today a build from the latest master branch and struggled with
>> the following problem.
>> I've got some REST services which are excluded from keycloak, so I can
>> access them without a logged in user. (see detail from web.xml)
>> The request body in these post rest services were always empty. I found
>> out that my wildfly tried to authenticate all requests.
>> The tokenStore.saveRequest() method in the OAuthRequestAuthenticator
>> class read the inputStream and so it was empty later on.
>>
>> I dont understand why all my requests are authenticated, even when they
>> are excluded through the web.xml file.
>> So, I added the following lines in the ServletKeycloakAuthMech class in
>> the authenticate method: (see
>> https://github.com/gerbermichi/keycloak/commit/1eaafcd3d9ad4082429ab500a4512c87d47ed75c)
>> if (!deployment.isConfigured() ||
>> !securityContext.isAuthenticationRequired()) {
>>               return AuthenticationMechanismOutcome.NOT_ATTEMPTED;
>> }
>>
>> This hack solved all my problems. Is this a bug and should i create a
>> pull request? Or are there some problems in my project configuration?
>>
>> Detail from my web.xml file:
>>     <security-constraint>
>>           <web-resource-collection>
>>               <web-resource-name>Client WS</web-resource-name>
>>               <url-pattern>/clientws/*</url-pattern>
>>           </web-resource-collection>
>>           <web-resource-collection>
>>               <web-resource-name>Client Exchange WS</web-resource-name>
>>               <url-pattern>/services/exchange/*</url-pattern>
>>           </web-resource-collection>
>>           <user-data-constraint>
>>               <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>           </user-data-constraint>
>>       </security-constraint>
>>
>>       <security-constraint>
>>           <web-resource-collection>
>>               <web-resource-name>All</web-resource-name>
>>               <url-pattern>/*</url-pattern>
>>           </web-resource-collection>
>>           <auth-constraint>
>>               <role-name>myRole</role-name>
>>           </auth-constraint>
>>           <user-data-constraint>
>>               <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>           </user-data-constraint>
>>       </security-constraint>
>>
>>       <login-config>
>>           <auth-method>KEYCLOAK</auth-method>
>>           <realm-name>myRealm</realm-name>
>>       </login-config>
>>
>>       <security-role>
>>           <role-name>myRole</role-name>
>>       </security-role>
>

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

From bburke at redhat.com  Mon Dec 22 15:31:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Dec 2014 15:31:39 -0500
Subject: [keycloak-dev] resource excludes in web.xml not working in
 latest master build
In-Reply-To: <6A86D6E4-C580-44AA-AD34-0FD0102279D2@me.com>
References: <89aaf5ee-7b83-473b-ad00-b3b1012cc123@me.com>
	<6A86D6E4-C580-44AA-AD34-0FD0102279D2@me.com>
Message-ID: <54987FAB.2030908@redhat.com>

You fix one problem but introduce another. 
ServletRequest.authenticate() will fail with your fix because of the way 
Undertow works.  It expects that all auth mechanisms are attempted and 
any challenges queued up just in case ServletRequest.authenticate() is 
invoked.

Your problem is that posts are eaten on unsecured requests?  What I need 
to do is to do the request saving in the challenge callback.

On 12/20/2014 8:34 AM, Michael Gerber wrote:
> I created a small demo app to show you what I meant:
> https://github.com/gerbermichi/keycloak/tree/master/examples/demo-template/rest-resources
>
> As you can see, keycloak consumes the post data during the
> authentication step, which is wrong, because the resource should be
> public (without any authentication)
>
> curl -X POST -H ?Content-Type: text/plain"
> http://localhost:8080/rest-resources/public -d 'hello world'
> You said:
>
> My previous bug fix for this problem was wrong, but I think my latests
> changes in the RequestAuthenticator class would solve this problem.
> You can find all my changes here:
> https://github.com/gerbermichi/keycloak/commit/512a68c5fa405567fe56968b5fdd9bb51eeb3316
>
> curl -X POST -H ?Content-Type: text/plain"
> http://localhost:8080/rest-resources/public -d 'hello world'
> You said: hello world
>
> The only question is, how to implement the
> protected abstract boolean isAuthenticationRequired();
> method correctly in the JettyRequestAuthenticator
> and CatalinaRequestAuthenticator class.
>
>
>
>> Am 19.12.2014 um 17:03 schrieb Michael Gerber <gerbermichi at me.com
>> <mailto:gerbermichi at me.com>>:
>>
>> Hi all,
>>
>> I created today a build from the latest master branch and struggled
>> with the following problem.
>> I've got some REST services which are excluded from keycloak, so I can
>> access them without a logged in user. (see detail from web.xml)
>> The request body in these post rest services were always empty. I
>> found out that my wildfly tried to authenticate all requests.
>> The tokenStore.saveRequest() method in the OAuthRequestAuthenticator
>> class read the inputStream and so it was empty later on.
>>
>> I dont understand why all my requests are authenticated, even when
>> they are excluded through the web.xml file.
>> So, I added the following lines in the ServletKeycloakAuthMech class
>> in the authenticate method: (see
>> https://github.com/gerbermichi/keycloak/commit/1eaafcd3d9ad4082429ab500a4512c87d47ed75c)
>> if (!deployment.isConfigured() ||
>> !securityContext.isAuthenticationRequired()) {
>>             return AuthenticationMechanismOutcome.NOT_ATTEMPTED;
>> }
>>
>> This hack solved all my problems. Is this a bug and should i create a
>> pull request? Or are there some problems in my project configuration?
>>
>> Detail from my web.xml file:
>>   <security-constraint>
>>         <web-resource-collection>
>>             <web-resource-name>Client WS</web-resource-name>
>>             <url-pattern>/clientws/*</url-pattern>
>>         </web-resource-collection>
>>         <web-resource-collection>
>>             <web-resource-name>Client Exchange WS</web-resource-name>
>>             <url-pattern>/services/exchange/*</url-pattern>
>>         </web-resource-collection>
>>         <user-data-constraint>
>>             <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>         </user-data-constraint>
>>     </security-constraint>
>>
>>     <security-constraint>
>>         <web-resource-collection>
>>             <web-resource-name>All</web-resource-name>
>>             <url-pattern>/*</url-pattern>
>>         </web-resource-collection>
>>         <auth-constraint>
>>             <role-name>myRole</role-name>
>>         </auth-constraint>
>>         <user-data-constraint>
>>             <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>         </user-data-constraint>
>>     </security-constraint>
>>
>>     <login-config>
>>         <auth-method>KEYCLOAK</auth-method>
>>         <realm-name>myRealm</realm-name>
>>     </login-config>
>>
>>     <security-role>
>>         <role-name>myRole</role-name>
>>     </security-role>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto: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 christian.beikov at gmail.com  Sun Dec 28 05:01:54 2014
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sun, 28 Dec 2014 11:01:54 +0100
Subject: [keycloak-dev] Access original session
Message-ID: <549FD512.9020705@gmail.com>

Hello there!"

I have an application that has protected resources on the pattern 
"/protected/*" and I receive a session cookie for the path "/protected", 
which makes sense. Now my problem is, that I want the path of the cookie 
to be "/" so I can access the user information even outside of the 
protected resources.
Since I think this might introduce some problems, the only other way to 
realize that I could think of is, to get access to the underlying 
servlet session. Not only would that session have to be created 
properly, which I am not sure is happening when browsing in the 
protected resources, I would also need to access it on the server, so 
that I can save the currently logged in user into it.

Is there a possibility to access the servlet session within the Keycloak 
context? If so, could you please share some code or point me to an API?
-- 

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141228/d1dd756c/attachment.html 

From stian at redhat.com  Mon Dec 29 02:13:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Dec 2014 02:13:59 -0500 (EST)
Subject: [keycloak-dev] [keycloak-user] Merry Christmas from the
	Keycloak team
In-Reply-To: <847608453.972436.1419078758134.JavaMail.yahoo@jws10029.mail.ne1.yahoo.com>
References: <CACQJ6LQjFesqxdieFFjZyQgHBTD5+dW4ZxnpHEBixz=2oW4hvw@mail.gmail.com>
	<847608453.972436.1419078758134.JavaMail.yahoo@jws10029.mail.ne1.yahoo.com>
Message-ID: <2043314637.1933851.1419837239753.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "prab rrrr" <prabhalar at yahoo.com>
> To: "Travis De Silva" <traviskds at gmail.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>, "keycloack-users" <keycloak-user at lists.jboss.org>
> Sent: Saturday, 20 December, 2014 1:32:38 PM
> Subject: Re: [keycloak-user] Merry Christmas from the Keycloak team
> 
> Hi Stian - Thanks for sharing your roadmap for 2015. Really looking forward
> to see identity brokering and? Openid Dynamic registration.?Do you have any
> plans to?support 1) FIDO specifications (UAT and U2F)?2) Any other NoSQL
> databases like Cassandra?

Most likely yes to FIDO, but most likely no to Cassandra or other DBs unless there's a lot of demand for it.

> Congratulations on a great product key cloak team and Happy holidays to all
> of you.
> Raghu
> ?      From: Travis De Silva <traviskds at gmail.com>
>  To: Stian Thorgersen <stian at redhat.com>
> Cc: keycloak dev <keycloak-dev at lists.jboss.org>; keycloack-users
> <keycloak-user at lists.jboss.org>
>  Sent: Tuesday, December 16, 2014 6:40 AM
>  Subject: Re: [keycloak-user] Merry Christmas from the Keycloak team
>    
> Congratulations and thank you to the entire KeyCloak team. This is a great
> project and wishing it gets better and better over the course of next year.
> Merry Christmas and Happy New Year to everyone.
> 
> 
> On Tue, Dec 16, 2014 at 10:38 PM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> 2014 was the year of Keycloak! At least that was the case for us on the
> Keycloak team. In January we released the very first alpha of the project.
> The first stable release wasn?t out until September, but in return we added
> a lot more features as well as reaching a very high level of stability for a
> 1.0.
> 
> Since then we?ve delivered a number of security and bug fixes for 1.0, while
> continuing to bake in new exiting features for 1.1. We?re planning to do a
> stable release of 1.1 early in the New Year, which will bring SAML 2, much
> improved clustering and a number of new application adapters.
> 
> Not only have we managed to provide a feature rich and easy to use open
> source security solution, but we?ve also managed to build an awesome
> community around the project. We?ve had over 5000 downloads, over 2500
> commits from 32 contributors and our developer and user mailing lists are
> very active. Keycloak is already in use in production on a number of
> projects, in fact some has even used it in production since our first alpha
> release!
> 
> Our road-map for 2015 is not written in stone, but expect at least some of
> the following features to be delivered in 2015:
> 
> ? * Custom user profiles ? this will let you configure the attributes for a
> ? user profile, which should be visible on the registration screen and
> ? account management, as well as specify validation
> ? * Identity Brokering ? we?re adding support to authenticate with external
> ? Identity Providers via OpenID Connect, SAML 2.0 and Kerberos
> ? * Two-Factor Authentication ? currently we only support Google
> ? Authenticator or FreeOTP applications for two-factor authentication, but
> ? we plan to make it possible to add your own and provide some more out of
> ? the box
> ? * Client Accounts ? these will be special user accounts directly linked to
> ? a client, allowing a client to access services as itself not just
> ? on-behalf of users
> ? * Client Certificates ? support authentication of clients with certificates
> ? * Client Types ? at the moment we have applications and oauth clients, the
> ? main difference being oauth clients require users to grant permissions to
> ? roles. To simplify the admin console we plan to introduce a single unified
> ? view for clients and also introduce new types such as devices
> ? * Internationalization ? internationalization support for login and account
> ? management pages
> ? * SMS ? enable SMS to recover passwords, as a 2nd factor authentication
> ? mechanism and to be notified about events like login failures
> ? * OpenID Connect Dynamic Registration ?? allows clients to dynamically
> ? register with Keycloak. We?ll also look at passing the OpenID Connect
> ? Interop testing
> ? * Mapping of users and tokens ? custom mapping of user profiles from
> ? external identity stores and tokens from external Identity Providers
> 
> We also have ideas for some bigger features, but we?ll leave those as a
> surprise for 2015!
> 
> Finally, I?d like to wish everyone a Merry Christmas and a Happy New Year.
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> 


From stian at redhat.com  Mon Dec 29 03:12:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Dec 2014 03:12:14 -0500 (EST)
Subject: [keycloak-dev] JIRA emails
In-Reply-To: <5492C97C.1090201@redhat.com>
References: <5492542F.4070808@redhat.com> <5492C97C.1090201@redhat.com>
Message-ID: <1775597303.1949617.1419840734590.JavaMail.zimbra@redhat.com>

Me neither

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 18 December, 2014 1:33:00 PM
> Subject: Re: [keycloak-dev] JIRA emails
> 
> On 12/17/2014 11:12 PM, Bill Burke wrote:
> > Anybody else *NOT* getting JIRA emails?
> >
> I'm not getting them either.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Dec 30 04:57:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 30 Dec 2014 04:57:20 -0500 (EST)
Subject: [keycloak-dev] logged in user not in application session listed
In-Reply-To: <db38dfca-0fd9-4be8-9dd7-025337dd02fa@me.com>
References: <db38dfca-0fd9-4be8-9dd7-025337dd02fa@me.com>
Message-ID: <1195728502.2182253.1419933440420.JavaMail.zimbra@redhat.com>

Hi,

Sorry for the late response, we've been busy with meetings and Christmas. I can confirm that this is indeed a bug and I've created https://issues.jboss.org/browse/KEYCLOAK-903.

Regards,
Stian Thorgersen

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 18 December, 2014 2:13:24 PM
> Subject: [keycloak-dev] logged in user not in application session listed
> 
> Hi,
> 
> I use the REST WebService
> ?realms/{realm}/protocol/openid-connect/grants/access to grant access to
> resources protected by keycloak.
> 
> But these logged in users are not listed in the Application Sessions.
> 
> Is there any way to get all active sessions for a given application or realm?
> 
> kind regards
> Michael
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Tue Dec 30 07:38:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 30 Dec 2014 07:38:21 -0500 (EST)
Subject: [keycloak-dev] Access original session
In-Reply-To: <549FD512.9020705@gmail.com>
References: <549FD512.9020705@gmail.com>
Message-ID: <349569894.2249184.1419943101421.JavaMail.zimbra@redhat.com>

The session cookie (assuming you're talking about JSESSIONID) should be set to the context-path of your WAR not a specific protected resource. Is your protected resources in the same WAR as the unprotected resources?

----- Original Message -----
> From: "Christian Beikov" <christian.beikov at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, 28 December, 2014 11:01:54 AM
> Subject: [keycloak-dev] Access original session
> 
> Hello there!"
> 
> I have an application that has protected resources on the pattern
> "/protected/*" and I receive a session cookie for the path "/protected",
> which makes sense. Now my problem is, that I want the path of the cookie to
> be "/" so I can access the user information even outside of the protected
> resources.
> Since I think this might introduce some problems, the only other way to
> realize that I could think of is, to get access to the underlying servlet
> session. Not only would that session have to be created properly, which I am
> not sure is happening when browsing in the protected resources, I would also
> need to access it on the server, so that I can save the currently logged in
> user into it.
> 
> Is there a possibility to access the servlet session within the Keycloak
> context? If so, could you please share some code or point me to an API?
> --
> 
> Mit freundlichen Gr??en,
> 
> Christian Beikov
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From christian.beikov at gmail.com  Tue Dec 30 07:45:13 2014
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 30 Dec 2014 13:45:13 +0100
Subject: [keycloak-dev] Access original session
In-Reply-To: <349569894.2249184.1419943101421.JavaMail.zimbra@redhat.com>
References: <549FD512.9020705@gmail.com>
	<349569894.2249184.1419943101421.JavaMail.zimbra@redhat.com>
Message-ID: <54A29E59.7030008@gmail.com>

Seems like my question wasn't clear enough.

I have the following config in my web.xml

     <security-constraint>
         <web-resource-collection>
<web-resource-name>Protected</web-resource-name>
             <url-pattern>/protected/*</url-pattern>
         </web-resource-collection>
         <auth-constraint>
             <role-name>user</role-name>
         </auth-constraint>
     </security-constraint>

     <login-config>
         <auth-method>KEYCLOAK</auth-method>
         <realm-name>portfolio-webapp</realm-name>
     </login-config>

     <security-role>
         <role-name>user</role-name>
     </security-role>

Now when I navigate to e.g. "/protected/index.xhtml" I get redirected to 
the Keycloak login. Unfortunately, the cookie which is set by the 
Keycloak adapters after a succesful login, has the path "/protected" 
set. When I navigate to "/whatever.xhtml" I obviously have no access to 
the cookie since the browser doesn't send it.

How am I supposed to access the logged in user outside of the protected 
area?

The session cookie (assuming you're talking about JSESSIONID) should be set to the context-path of your WAR not a specific protected resource.

Unfortunately I am experiencing that it is set to a different path.

Is your protected resources in the same WAR as the unprotected resources?

Yes, it's all in the same WAR.

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 30.12.2014 um 13:38 schrieb Stian Thorgersen:
> The session cookie (assuming you're talking about JSESSIONID) should be set to the context-path of your WAR not a specific protected resource. Is your protected resources in the same WAR as the unprotected resources?
>
> ----- Original Message -----
>> From: "Christian Beikov" <christian.beikov at gmail.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Sunday, 28 December, 2014 11:01:54 AM
>> Subject: [keycloak-dev] Access original session
>>
>> Hello there!"
>>
>> I have an application that has protected resources on the pattern
>> "/protected/*" and I receive a session cookie for the path "/protected",
>> which makes sense. Now my problem is, that I want the path of the cookie to
>> be "/" so I can access the user information even outside of the protected
>> resources.
>> Since I think this might introduce some problems, the only other way to
>> realize that I could think of is, to get access to the underlying servlet
>> session. Not only would that session have to be created properly, which I am
>> not sure is happening when browsing in the protected resources, I would also
>> need to access it on the server, so that I can save the currently logged in
>> user into it.
>>
>> Is there a possibility to access the servlet session within the Keycloak
>> context? If so, could you please share some code or point me to an API?
>> --
>>
>> Mit freundlichen Gr??en,
>>
>> Christian Beikov
>>
>> _______________________________________________
>> 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/20141230/3d438cf1/attachment.html 

From stian at redhat.com  Tue Dec 30 07:59:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 30 Dec 2014 07:59:44 -0500 (EST)
Subject: [keycloak-dev] Access original session
In-Reply-To: <54A29E59.7030008@gmail.com>
References: <549FD512.9020705@gmail.com>
	<349569894.2249184.1419943101421.JavaMail.zimbra@redhat.com>
	<54A29E59.7030008@gmail.com>
Message-ID: <1057182580.2251047.1419944384069.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Christian Beikov" <christian.beikov at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 30 December, 2014 1:45:13 PM
> Subject: Re: [keycloak-dev] Access original session
> 
> Seems like my question wasn't clear enough.
> 
> I have the following config in my web.xml
> 
>      <security-constraint>
>          <web-resource-collection>
> <web-resource-name>Protected</web-resource-name>
>              <url-pattern>/protected/*</url-pattern>
>          </web-resource-collection>
>          <auth-constraint>
>              <role-name>user</role-name>
>          </auth-constraint>
>      </security-constraint>
> 
>      <login-config>
>          <auth-method>KEYCLOAK</auth-method>
>          <realm-name>portfolio-webapp</realm-name>
>      </login-config>
> 
>      <security-role>
>          <role-name>user</role-name>
>      </security-role>
> 
> Now when I navigate to e.g. "/protected/index.xhtml" I get redirected to
> the Keycloak login. Unfortunately, the cookie which is set by the
> Keycloak adapters after a succesful login, has the path "/protected"
> set. When I navigate to "/whatever.xhtml" I obviously have no access to
> the cookie since the browser doesn't send it.
> 
> How am I supposed to access the logged in user outside of the protected
> area?
> 
> The session cookie (assuming you're talking about JSESSIONID) should be set
> to the context-path of your WAR not a specific protected resource.
> 
> Unfortunately I am experiencing that it is set to a different path.

Strange. I've just tried with our demo, which has a similar security-constraint to yours, and it sets it to the context-path of the WAR as expected.

Keycloak doesn't set this cookie itself, that's sorted by the JEE container. Which Keycloak version and JEE server are you using?

> 
> Is your protected resources in the same WAR as the unprotected resources?
> 
> Yes, it's all in the same WAR.
> 
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 30.12.2014 um 13:38 schrieb Stian Thorgersen:
> > The session cookie (assuming you're talking about JSESSIONID) should be set
> > to the context-path of your WAR not a specific protected resource. Is your
> > protected resources in the same WAR as the unprotected resources?
> >
> > ----- Original Message -----
> >> From: "Christian Beikov" <christian.beikov at gmail.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Sunday, 28 December, 2014 11:01:54 AM
> >> Subject: [keycloak-dev] Access original session
> >>
> >> Hello there!"
> >>
> >> I have an application that has protected resources on the pattern
> >> "/protected/*" and I receive a session cookie for the path "/protected",
> >> which makes sense. Now my problem is, that I want the path of the cookie
> >> to
> >> be "/" so I can access the user information even outside of the protected
> >> resources.
> >> Since I think this might introduce some problems, the only other way to
> >> realize that I could think of is, to get access to the underlying servlet
> >> session. Not only would that session have to be created properly, which I
> >> am
> >> not sure is happening when browsing in the protected resources, I would
> >> also
> >> need to access it on the server, so that I can save the currently logged
> >> in
> >> user into it.
> >>
> >> Is there a possibility to access the servlet session within the Keycloak
> >> context? If so, could you please share some code or point me to an API?
> >> --
> >>
> >> Mit freundlichen Gr??en,
> >>
> >> Christian Beikov
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 


From christian.beikov at gmail.com  Tue Dec 30 09:47:00 2014
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 30 Dec 2014 15:47:00 +0100
Subject: [keycloak-dev] Access original session
In-Reply-To: <1057182580.2251047.1419944384069.JavaMail.zimbra@redhat.com>
References: <549FD512.9020705@gmail.com>
	<349569894.2249184.1419943101421.JavaMail.zimbra@redhat.com>
	<54A29E59.7030008@gmail.com>
	<1057182580.2251047.1419944384069.JavaMail.zimbra@redhat.com>
Message-ID: <54A2BAE4.2050007@gmail.com>

I am using the following versions:

  * Keycloak 1.0.4.Final
  * Wildfly 8.1.0.Final

Also it doesn't respect the cookie settings of the web.xml. I tried to 
configure a different name for the cookie just to test it, but it didn't 
change. When navigating to "/whatever.xhtml" I suddenly get the 
configured cookie set.
It seems as if the Keycloak adapters wrap the HttpServletRequest to 
expose a different session map when working with secured resources. 
Which demo are you talking about? I would love to try it out so that I 
can confirm if it has something to do with my setup or Keycloak.

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 30.12.2014 um 13:59 schrieb Stian Thorgersen:
>
> ----- Original Message -----
>> From: "Christian Beikov" <christian.beikov at gmail.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 30 December, 2014 1:45:13 PM
>> Subject: Re: [keycloak-dev] Access original session
>>
>> Seems like my question wasn't clear enough.
>>
>> I have the following config in my web.xml
>>
>>       <security-constraint>
>>           <web-resource-collection>
>> <web-resource-name>Protected</web-resource-name>
>>               <url-pattern>/protected/*</url-pattern>
>>           </web-resource-collection>
>>           <auth-constraint>
>>               <role-name>user</role-name>
>>           </auth-constraint>
>>       </security-constraint>
>>
>>       <login-config>
>>           <auth-method>KEYCLOAK</auth-method>
>>           <realm-name>portfolio-webapp</realm-name>
>>       </login-config>
>>
>>       <security-role>
>>           <role-name>user</role-name>
>>       </security-role>
>>
>> Now when I navigate to e.g. "/protected/index.xhtml" I get redirected to
>> the Keycloak login. Unfortunately, the cookie which is set by the
>> Keycloak adapters after a succesful login, has the path "/protected"
>> set. When I navigate to "/whatever.xhtml" I obviously have no access to
>> the cookie since the browser doesn't send it.
>>
>> How am I supposed to access the logged in user outside of the protected
>> area?
>>
>> The session cookie (assuming you're talking about JSESSIONID) should be set
>> to the context-path of your WAR not a specific protected resource.
>>
>> Unfortunately I am experiencing that it is set to a different path.
> Strange. I've just tried with our demo, which has a similar security-constraint to yours, and it sets it to the context-path of the WAR as expected.
>
> Keycloak doesn't set this cookie itself, that's sorted by the JEE container. Which Keycloak version and JEE server are you using?
>
>> Is your protected resources in the same WAR as the unprotected resources?
>>
>> Yes, it's all in the same WAR.
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 30.12.2014 um 13:38 schrieb Stian Thorgersen:
>>> The session cookie (assuming you're talking about JSESSIONID) should be set
>>> to the context-path of your WAR not a specific protected resource. Is your
>>> protected resources in the same WAR as the unprotected resources?
>>>
>>> ----- Original Message -----
>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Sunday, 28 December, 2014 11:01:54 AM
>>>> Subject: [keycloak-dev] Access original session
>>>>
>>>> Hello there!"
>>>>
>>>> I have an application that has protected resources on the pattern
>>>> "/protected/*" and I receive a session cookie for the path "/protected",
>>>> which makes sense. Now my problem is, that I want the path of the cookie
>>>> to
>>>> be "/" so I can access the user information even outside of the protected
>>>> resources.
>>>> Since I think this might introduce some problems, the only other way to
>>>> realize that I could think of is, to get access to the underlying servlet
>>>> session. Not only would that session have to be created properly, which I
>>>> am
>>>> not sure is happening when browsing in the protected resources, I would
>>>> also
>>>> need to access it on the server, so that I can save the currently logged
>>>> in
>>>> user into it.
>>>>
>>>> Is there a possibility to access the servlet session within the Keycloak
>>>> context? If so, could you please share some code or point me to an API?
>>>> --
>>>>
>>>> Mit freundlichen Gr??en,
>>>>
>>>> Christian Beikov
>>>>
>>>> _______________________________________________
>>>> 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/20141230/02d97f81/attachment.html