From sthorger at redhat.com  Thu Dec  1 04:09:14 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Dec 2016 10:09:14 +0100
Subject: [keycloak-dev] Private Keys in plain text in database
In-Reply-To: <CACEM6k8DczeTBYdc4euqaEkgX+-FpTWQ1GL1dQ7JnYyM+e9nQQ@mail.gmail.com>
References: <CACEM6k8DczeTBYdc4euqaEkgX+-FpTWQ1GL1dQ7JnYyM+e9nQQ@mail.gmail.com>
Message-ID: <CAJgngAc=fhZb9X0=YRUTwRebjrj=W6+xs8w1bs-P+8Hu2AzJzQ@mail.gmail.com>

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

Until we get around to solving that one you can use a Java keystore for the
keys or implement your own custom key provider.

On 1 December 2016 at 03:42, Muein Muzamil <shmuein+keycloak-dev at gmail.com>
wrote:

> Hi all,
>
> I noticed currently we are storing private keys in plain text in the
> database, our security team has raised some concerns on that, is there any
> way to encrypt these private keys before storing them in database?
>
> Regards,
> Muein
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Dec  1 04:10:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Dec 2016 10:10:25 +0100
Subject: [keycloak-dev] Performance improvements with large number of
	realms
In-Reply-To: <CAKp1Nw7Ln686uVWOC75LMJCHJ9uuq_3MjQGHY4Am1cS9-XKOaA@mail.gmail.com>
References: <CAKp1Nw7=LE2rAt295RY-fVostOdtW=6QY=MMjvHCa+yOqQ4VeA@mail.gmail.com>
	<CAJgngAeBFJLYrwOzcxKmjr21jh6njSZ-HdwyGYu85Kvx21_41A@mail.gmail.com>
	<CAKp1Nw4HYZTU=wozs6k2GoFr31Y__wu5mtkQ92OeWr6qRaaEOA@mail.gmail.com>
	<CAKp1Nw6p2zEdXi9=WQ6ZNQR8A4ttLc0XfWRD4OZp3kntXE6L-w@mail.gmail.com>
	<f380731d-fb6e-eb88-c631-3f22d0e047dd@redhat.com>
	<e1d47082-3fbd-a8d0-9cfc-79000dabf597@redhat.com>
	<CAKp1Nw7f9dFWFbZ_0GKH7zbMRGzOWoxGKXwS5husCrPjfCyAhA@mail.gmail.com>
	<CAKp1Nw7Ln686uVWOC75LMJCHJ9uuq_3MjQGHY4Am1cS9-XKOaA@mail.gmail.com>
Message-ID: <CAJgngAfMPN1hvh0XWjwZ=H=+P8BjRNFmr9yDUtKoAZN-6oJwqA@mail.gmail.com>

Restarted the job

On 30 November 2016 at 17:15, Gabriel Lavoie <glavoie at gmail.com> wrote:

> The two last pull requests were submitted.
>
> Is there a way to re-trigger this build: https://travis-ci.org/
> keycloak/keycloak/builds/179566864 ?
>
> Seems like the failing jobs got stuck in the "mvn install" step for some
> unknown reasons. I've been trying to reproduce this locally without any
> success.
>
> Gabriel
>

From sthorger at redhat.com  Thu Dec  1 05:59:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Dec 2016 11:59:29 +0100
Subject: [keycloak-dev] Proper handling of read only users from user storage
Message-ID: <CAJgngAf1izkRZjhWYqmeET30e08OE3FJp8yy7-tSB1SY7psjtQ@mail.gmail.com>

We should solve the following issues for 2.5.0:

https://issues.jboss.org/browse/KEYCLOAK-3060
https://issues.jboss.org/browse/KEYCLOAK-3613

The current behavior of showing a form and throwing an error is not very
elegant and this should be resolved before as part of user storage SPI work.

From marc.boorshtein at tremolosecurity.com  Thu Dec  1 10:20:29 2016
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Thu, 01 Dec 2016 15:20:29 +0000
Subject: [keycloak-dev] OpenID Connect client_Secret and Kubernetes
Message-ID: <CAH2S7UD2jaTSpo5YgOB=Qg-91VK2327+=ewKfB0EwRsVWAu-rg@mail.gmail.com>

Keycloak team,

A couple of months ago I started a thread on this list about if the
client_secret being shared across developers in kubernetes.  The issue has
come up a few more times and a new ticket has been opened I thought you
would be interested in:

https://github.com/kubernetes/kubernetes/issues/37822
-- 
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
(703) 828-4902
Twitter - @mlbiam / @tremolosecurity

From sblanc at redhat.com  Fri Dec  2 03:24:31 2016
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 2 Dec 2016 09:24:31 +0100
Subject: [keycloak-dev] Suggestion and fix for e-Directory federation
	provider
In-Reply-To: <CAJWapELVVcNKmAepNJChT6ecg8h-1qhQFe=6sDRHJT25Zhw6UQ@mail.gmail.com>
References: <CAJWapELVVcNKmAepNJChT6ecg8h-1qhQFe=6sDRHJT25Zhw6UQ@mail.gmail.com>
Message-ID: <CAMZCGg_SnGnUFLf539TDoJLuVyVFCcEeQbZHM9-XE4EMbnBDDQ@mail.gmail.com>

Hi !

Sure that would be awesome if you can create a pull request and attached it
to the ticket !

Sebi



On Thu, Nov 24, 2016 at 1:38 PM, Tomas Tikovsky <tikovsky.tomas at gmail.com>
wrote:

> Hello everyone,
>
> im using e-directory federation ldap provider and came to this bug
> KEYCLOAK-3099 <https://issues.jboss.org/browse/KEYCLOAK-3099> as i was
> experiencing the same problem.
> e-Directory sends guid attribute as byte[] so it needs to be declared as
> binary the same way as its done for activeDirectory.
> Sending simple diff to fix this issue if you consider this as helpfull.
>
> Novell was acquired by microfocus and their product has been renamed to
> netIQ eDirectory so i incorporated that change as well.
>
> Another thing i noted were 2 incorrect attribute mappings in administration
> console.
>
> "username" -> "uid"
> correct as long as users are enabled for linux (not default) otherwise cn.
> So cn should work for more cases than uid.
>
> "firstname" -> "cn"
> wrong, should be "givenname"
>
> Cheers
>
> Tom
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Fri Dec  2 04:04:42 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 2 Dec 2016 10:04:42 +0100
Subject: [keycloak-dev] Suggestion and fix for e-Directory federation
 provider
In-Reply-To: <CAMZCGg_SnGnUFLf539TDoJLuVyVFCcEeQbZHM9-XE4EMbnBDDQ@mail.gmail.com>
References: <CAJWapELVVcNKmAepNJChT6ecg8h-1qhQFe=6sDRHJT25Zhw6UQ@mail.gmail.com>
	<CAMZCGg_SnGnUFLf539TDoJLuVyVFCcEeQbZHM9-XE4EMbnBDDQ@mail.gmail.com>
Message-ID: <f2f20828-ba16-b878-1a55-3046c22e4d1f@redhat.com>

That's the question... Actually we rejected KEYCLOAK-3099, but it's 
possible that problem described below by Tomas is a little bit different 
then the issue in the ticket. AFAIK the ticket was specific just to 
combination of e-directory LDAP with MSSQL database.

IMO It's always good to support more different LDAP servers. But the 
problem is that:
- Supported vendors should be likely tested, but we don't have capacity 
to test and maintain all the LDAP (and DB) vendors in the world
- There is a chance that community PR for supporting new LDAP vendor 
breaks other vendors etc. There is just always some additional 
complexity with each server supported.
- We don't have possibility to re-test the PR by themselves due to the 
LDAP server not available for us.

We tries to focus especially on the most important servers, so if there 
is enough demand from the community and customers for some LDAP vendor, 
we will add it. But it seems that ATM you're the only one with the 
demand for netIQ e-directory.

So if there is possibility to workaround and have the netIQ e-directory 
working by setup of our existing LDAP StorageProvider configuration 
options and mappers (which AFAIK it is), then it is preferred way 
instead of the PR for adding support for it OOTB.

My 2 cents :)

Marek

On 02/12/16 09:24, Sebastien Blanc wrote:
> Hi !
>
> Sure that would be awesome if you can create a pull request and attached it
> to the ticket !
>
> Sebi
>
>
>
> On Thu, Nov 24, 2016 at 1:38 PM, Tomas Tikovsky <tikovsky.tomas at gmail.com>
> wrote:
>
>> Hello everyone,
>>
>> im using e-directory federation ldap provider and came to this bug
>> KEYCLOAK-3099 <https://issues.jboss.org/browse/KEYCLOAK-3099> as i was
>> experiencing the same problem.
>> e-Directory sends guid attribute as byte[] so it needs to be declared as
>> binary the same way as its done for activeDirectory.
>> Sending simple diff to fix this issue if you consider this as helpfull.
>>
>> Novell was acquired by microfocus and their product has been renamed to
>> netIQ eDirectory so i incorporated that change as well.
>>
>> Another thing i noted were 2 incorrect attribute mappings in administration
>> console.
>>
>> "username" -> "uid"
>> correct as long as users are enabled for linux (not default) otherwise cn.
>> So cn should work for more cases than uid.
>>
>> "firstname" -> "cn"
>> wrong, should be "givenname"
>>
>> Cheers
>>
>> Tom
>>
>> _______________________________________________
>> 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  Fri Dec  2 04:07:37 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 2 Dec 2016 10:07:37 +0100
Subject: [keycloak-dev] Suggestion and fix for e-Directory federation
 provider
In-Reply-To: <f2f20828-ba16-b878-1a55-3046c22e4d1f@redhat.com>
References: <CAJWapELVVcNKmAepNJChT6ecg8h-1qhQFe=6sDRHJT25Zhw6UQ@mail.gmail.com>
	<CAMZCGg_SnGnUFLf539TDoJLuVyVFCcEeQbZHM9-XE4EMbnBDDQ@mail.gmail.com>
	<f2f20828-ba16-b878-1a55-3046c22e4d1f@redhat.com>
Message-ID: <6bf4856a-c955-ada3-15f1-af6015791977@redhat.com>

On 02/12/16 10:04, Marek Posolda wrote:
> That's the question... Actually we rejected KEYCLOAK-3099, but it's
> possible that problem described below by Tomas is a little bit different
> then the issue in the ticket. AFAIK the ticket was specific just to
> combination of e-directory LDAP with MSSQL database.
Sorry, small update. We didn't rejected the ticket, but it should be 
fixed automatically with fixing some other task (work in progress by 
Hynek). So the MSSQL issue KEYCLOAK-3099 should just work fine in new 
version - hopefully :)

Marek
>
> IMO It's always good to support more different LDAP servers. But the
> problem is that:
> - Supported vendors should be likely tested, but we don't have capacity
> to test and maintain all the LDAP (and DB) vendors in the world
> - There is a chance that community PR for supporting new LDAP vendor
> breaks other vendors etc. There is just always some additional
> complexity with each server supported.
> - We don't have possibility to re-test the PR by themselves due to the
> LDAP server not available for us.
>
> We tries to focus especially on the most important servers, so if there
> is enough demand from the community and customers for some LDAP vendor,
> we will add it. But it seems that ATM you're the only one with the
> demand for netIQ e-directory.
>
> So if there is possibility to workaround and have the netIQ e-directory
> working by setup of our existing LDAP StorageProvider configuration
> options and mappers (which AFAIK it is), then it is preferred way
> instead of the PR for adding support for it OOTB.
>
> My 2 cents :)
>
> Marek
>
> On 02/12/16 09:24, Sebastien Blanc wrote:
>> Hi !
>>
>> Sure that would be awesome if you can create a pull request and attached it
>> to the ticket !
>>
>> Sebi
>>
>>
>>
>> On Thu, Nov 24, 2016 at 1:38 PM, Tomas Tikovsky <tikovsky.tomas at gmail.com>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> im using e-directory federation ldap provider and came to this bug
>>> KEYCLOAK-3099 <https://issues.jboss.org/browse/KEYCLOAK-3099> as i was
>>> experiencing the same problem.
>>> e-Directory sends guid attribute as byte[] so it needs to be declared as
>>> binary the same way as its done for activeDirectory.
>>> Sending simple diff to fix this issue if you consider this as helpfull.
>>>
>>> Novell was acquired by microfocus and their product has been renamed to
>>> netIQ eDirectory so i incorporated that change as well.
>>>
>>> Another thing i noted were 2 incorrect attribute mappings in administration
>>> console.
>>>
>>> "username" -> "uid"
>>> correct as long as users are enabled for linux (not default) otherwise cn.
>>> So cn should work for more cases than uid.
>>>
>>> "firstname" -> "cn"
>>> wrong, should be "givenname"
>>>
>>> Cheers
>>>
>>> Tom
>>>
>>> _______________________________________________
>>> 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 bruno at abstractj.org  Fri Dec  2 04:22:12 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 2 Dec 2016 07:22:12 -0200
Subject: [keycloak-dev] Federation Storage: read-only groups
Message-ID: <20161202092212.GA13749@abstractj.org>

Good morning,

Today for SSSD Federation storage everything is read-only. This
is pretty much because we don't have any way to synchronize the changes
made at the admin console back to SSSD.

QE identified this bug[1], that kind of affects LDAP federation provider
in read-only mode too. Correct if I'm wrong, but in theory, if the federation
provider is read-only, people should not be able to edit groups or
roles.

Do we anything in the new API to prevent people from changing roles and
groups when the Federation provider is read-only?


[1] - https://issues.jboss.org/browse/KEYCLOAK-3904

--

abstractj
PGP: 0x84DC9914

From sthorger at redhat.com  Fri Dec  2 05:28:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 2 Dec 2016 11:28:04 +0100
Subject: [keycloak-dev] Considering removing Mongo support
Message-ID: <CAJgngAfSGLq3q=T3rBFypDPmkb68QjEv8c+JVL=ZYC6Pz0HC_w@mail.gmail.com>

All,

We are considering removing Mongo support from Keycloak in 3.x. The reasons
behind it is that there are a fair few issues in the current
implementation, especially around consistency due to lack of transaction
support in Mongo and often we update multiple documents. In many cases we
rely on transactions to rollback to prevent partial updates, but this
obviously doesn't work in Mongo.

With the fact that Mongo is already partially broken and the constant
maintenance involved we're considering removing it and rather focus purely
on the relational database back-end.

Another point to make is that we are not considering supporting Mongo in
the supported version of Keycloak (Red Hat Single Sign-On). So we are never
able to provide the same level of care and attention to it as we can for
relational databases.

If we do decide to remove it we would make sure we provide a seamless and
easy option to migrate from Mongo to a relational database!

I would like to gather some feedback from the community before doing
anything. So please vote on the following Doodle:

http://doodle.com/poll/nnimebpkx774ppus

Also, comments to this thread is more than welcome!

I'll end with a comment - Time spent by core developer on maintaining Mongo
could be better spent on awesome new features, testing and bug fixing!

From tikovsky.tomas at gmail.com  Fri Dec  2 07:35:10 2016
From: tikovsky.tomas at gmail.com (Tomas Tikovsky)
Date: Fri, 2 Dec 2016 13:35:10 +0100
Subject: [keycloak-dev] Suggestion and fix for e-Directory federation
	provider
In-Reply-To: <6bf4856a-c955-ada3-15f1-af6015791977@redhat.com>
References: <CAJWapELVVcNKmAepNJChT6ecg8h-1qhQFe=6sDRHJT25Zhw6UQ@mail.gmail.com>
	<CAMZCGg_SnGnUFLf539TDoJLuVyVFCcEeQbZHM9-XE4EMbnBDDQ@mail.gmail.com>
	<f2f20828-ba16-b878-1a55-3046c22e4d1f@redhat.com>
	<6bf4856a-c955-ada3-15f1-af6015791977@redhat.com>
Message-ID: <CAJWapEKBcFix2Kkgkb1iB76Oz_BybVWdLjgyGj_-7edTVOH1Jw@mail.gmail.com>

I think that the problem mentioned in Keycloak-3099 is not caused by
utf8 as its more related

to this function interpretting UUID attribute as string in case of
anything else than activeDirectory.

eDirectory guid attribute is of byte[] type so reading byte[] as
string results in that garbish found in LDAP_ID field in DB.


/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/store/ldap/LDAPOperationManager.java

public String decodeEntryUUID(final Object entryUUID) {
         String id;

-        if (this.config.isActiveDirectory() && entryUUID instanceof byte[]) {
+        if (entryUUID instanceof byte[]) {
             id = LDAPUtil.decodeObjectGUID((byte[]) entryUUID);
         } else {
            id = entryUUID.toString();
         }

Guid attribute needs to be declared as binary to be correctly returned
from server.

+
+        if (config.isEDirectory()){
+            env.put("java.naming.ldap.attributes.binary",
LDAPConstants.EDIR_GUID);
+        }
+

I posted full diff as attachment in my first post, but didnt realize
it will be discarded. I can make a pull request but i wanted to
consult it first here.

Cheers

Tom


2016-12-02 10:07 GMT+01:00 Marek Posolda <mposolda at redhat.com>:

> On 02/12/16 10:04, Marek Posolda wrote:
>
>> That's the question... Actually we rejected KEYCLOAK-3099, but it's
>> possible that problem described below by Tomas is a little bit different
>> then the issue in the ticket. AFAIK the ticket was specific just to
>> combination of e-directory LDAP with MSSQL database.
>>
> Sorry, small update. We didn't rejected the ticket, but it should be fixed
> automatically with fixing some other task (work in progress by Hynek). So
> the MSSQL issue KEYCLOAK-3099 should just work fine in new version -
> hopefully :)
>
> Marek
>
>
>> IMO It's always good to support more different LDAP servers. But the
>> problem is that:
>> - Supported vendors should be likely tested, but we don't have capacity
>> to test and maintain all the LDAP (and DB) vendors in the world
>> - There is a chance that community PR for supporting new LDAP vendor
>> breaks other vendors etc. There is just always some additional
>> complexity with each server supported.
>> - We don't have possibility to re-test the PR by themselves due to the
>> LDAP server not available for us.
>>
>> We tries to focus especially on the most important servers, so if there
>> is enough demand from the community and customers for some LDAP vendor,
>> we will add it. But it seems that ATM you're the only one with the
>> demand for netIQ e-directory.
>>
>> So if there is possibility to workaround and have the netIQ e-directory
>> working by setup of our existing LDAP StorageProvider configuration
>> options and mappers (which AFAIK it is), then it is preferred way
>> instead of the PR for adding support for it OOTB.
>>
>> My 2 cents :)
>>
>> Marek
>>
>> On 02/12/16 09:24, Sebastien Blanc wrote:
>>
>>> Hi !
>>>
>>> Sure that would be awesome if you can create a pull request and attached
>>> it
>>> to the ticket !
>>>
>>> Sebi
>>>
>>>
>>>
>>> On Thu, Nov 24, 2016 at 1:38 PM, Tomas Tikovsky <
>>> tikovsky.tomas at gmail.com>
>>> wrote:
>>>
>>> Hello everyone,
>>>>
>>>> im using e-directory federation ldap provider and came to this bug
>>>> KEYCLOAK-3099 <https://issues.jboss.org/browse/KEYCLOAK-3099> as i was
>>>> experiencing the same problem.
>>>> e-Directory sends guid attribute as byte[] so it needs to be declared as
>>>> binary the same way as its done for activeDirectory.
>>>> Sending simple diff to fix this issue if you consider this as helpfull.
>>>>
>>>> Novell was acquired by microfocus and their product has been renamed to
>>>> netIQ eDirectory so i incorporated that change as well.
>>>>
>>>> Another thing i noted were 2 incorrect attribute mappings in
>>>> administration
>>>> console.
>>>>
>>>> "username" -> "uid"
>>>> correct as long as users are enabled for linux (not default) otherwise
>>>> cn.
>>>> So cn should work for more cases than uid.
>>>>
>>>> "firstname" -> "cn"
>>>> wrong, should be "givenname"
>>>>
>>>> Cheers
>>>>
>>>> Tom
>>>>
>>>> _______________________________________________
>>>> 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  2 09:15:42 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 2 Dec 2016 09:15:42 -0500
Subject: [keycloak-dev] Proper handling of read only users from user
	storage
In-Reply-To: <CAJgngAf1izkRZjhWYqmeET30e08OE3FJp8yy7-tSB1SY7psjtQ@mail.gmail.com>
References: <CAJgngAf1izkRZjhWYqmeET30e08OE3FJp8yy7-tSB1SY7psjtQ@mail.gmail.com>
Message-ID: <2853701a-820f-6804-4eb4-8fcee799c377@redhat.com>

All we're going to be able to implement is better handling of the 
ReadOnlyException.  I just don't have time to do UI work, it takes too 
long.  As it is, many providers will be hybrid, that will be both 
read-only and writable depending on the attribute, role, credential 
type, or whatever.  LDAP is a perfect example where attributes and 
role/group mappings can be read only or writable in the same 
deployment.  So, anything more elegant will require reworking LDAP as well.


On 12/1/16 5:59 AM, Stian Thorgersen wrote:
> We should solve the following issues for 2.5.0:
>
> https://issues.jboss.org/browse/KEYCLOAK-3060
> https://issues.jboss.org/browse/KEYCLOAK-3613
>
> The current behavior of showing a form and throwing an error is not 
> very elegant and this should be resolved before as part of user 
> storage SPI work.


From bburke at redhat.com  Fri Dec  2 09:26:46 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 2 Dec 2016 09:26:46 -0500
Subject: [keycloak-dev] LDAP read-only was Re: Federation Storage: read-only
 groups
In-Reply-To: <20161202092212.GA13749@abstractj.org>
References: <20161202092212.GA13749@abstractj.org>
Message-ID: <13e0dbd1-7264-07ff-108c-6d729da1cbf0@redhat.com>

Providers are supposed to throw a ReadOnlyException in this scenario.  I 
don't know if the LDAP provider handles this well.  I was a bit confused 
on how it worked, it seems like if a mapper is read-only, it allows you 
to edit the change in the import. Basically unsynced mode.

In looking at your SSSD provider, you only throw ReadOnlyException for 
attributes loaded by SSSD.  For the rest, you allow the local import to 
be updated (unsynced).


On 12/2/16 4:22 AM, Bruno Oliveira wrote:
> Good morning,
>
> Today for SSSD Federation storage everything is read-only. This
> is pretty much because we don't have any way to synchronize the changes
> made at the admin console back to SSSD.
>
> QE identified this bug[1], that kind of affects LDAP federation provider
> in read-only mode too. Correct if I'm wrong, but in theory, if the federation
> provider is read-only, people should not be able to edit groups or
> roles.
>
> Do we anything in the new API to prevent people from changing roles and
> groups when the Federation provider is read-only?
>
>
> [1] - https://issues.jboss.org/browse/KEYCLOAK-3904
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Fri Dec  2 10:30:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 2 Dec 2016 16:30:25 +0100
Subject: [keycloak-dev] Proper handling of read only users from user
	storage
In-Reply-To: <2853701a-820f-6804-4eb4-8fcee799c377@redhat.com>
References: <CAJgngAf1izkRZjhWYqmeET30e08OE3FJp8yy7-tSB1SY7psjtQ@mail.gmail.com>
	<2853701a-820f-6804-4eb4-8fcee799c377@redhat.com>
Message-ID: <CAJgngAdLcZcXdNPbXdUUpJDV+wH1QVS4EeLNjqjWbcLqJXTRjw@mail.gmail.com>

That's far from ideal. Dealing with this through an exception is horrible.
I've said several times that all we need at minimum is a way for a provider
to tell Keycloak if it's read or read/write. A boolean is fine for now.
Once we had that it would take an hour or two to do the UI work.

On 2 December 2016 at 15:15, Bill Burke <bburke at redhat.com> wrote:

> All we're going to be able to implement is better handling of the
> ReadOnlyException.  I just don't have time to do UI work, it takes too
> long.  As it is, many providers will be hybrid, that will be both read-only
> and writable depending on the attribute, role, credential type, or
> whatever.  LDAP is a perfect example where attributes and role/group
> mappings can be read only or writable in the same deployment.  So, anything
> more elegant will require reworking LDAP as well.
>
>
>
> On 12/1/16 5:59 AM, Stian Thorgersen wrote:
>
>> We should solve the following issues for 2.5.0:
>>
>> https://issues.jboss.org/browse/KEYCLOAK-3060
>> https://issues.jboss.org/browse/KEYCLOAK-3613
>>
>> The current behavior of showing a form and throwing an error is not very
>> elegant and this should be resolved before as part of user storage SPI work.
>>
>
>

From sthorger at redhat.com  Fri Dec  2 10:31:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 2 Dec 2016 16:31:20 +0100
Subject: [keycloak-dev] LDAP read-only was Re: Federation Storage:
 read-only groups
In-Reply-To: <13e0dbd1-7264-07ff-108c-6d729da1cbf0@redhat.com>
References: <20161202092212.GA13749@abstractj.org>
	<13e0dbd1-7264-07ff-108c-6d729da1cbf0@redhat.com>
Message-ID: <CAJgngAcObLB+DKTgsuA4Qy3MkrLY3ryvuFhyT22ufhEvoC3W1A@mail.gmail.com>

This is just bad - throwing a ReadOnlyException rather than telling up
front that it can't do it is bad. I'm worried this will require changing
the user storage spi in the future to be able to support it properly.

On 2 December 2016 at 15:26, Bill Burke <bburke at redhat.com> wrote:

> Providers are supposed to throw a ReadOnlyException in this scenario.  I
> don't know if the LDAP provider handles this well.  I was a bit confused
> on how it worked, it seems like if a mapper is read-only, it allows you
> to edit the change in the import. Basically unsynced mode.
>
> In looking at your SSSD provider, you only throw ReadOnlyException for
> attributes loaded by SSSD.  For the rest, you allow the local import to
> be updated (unsynced).
>
>
> On 12/2/16 4:22 AM, Bruno Oliveira wrote:
> > Good morning,
> >
> > Today for SSSD Federation storage everything is read-only. This
> > is pretty much because we don't have any way to synchronize the changes
> > made at the admin console back to SSSD.
> >
> > QE identified this bug[1], that kind of affects LDAP federation provider
> > in read-only mode too. Correct if I'm wrong, but in theory, if the
> federation
> > provider is read-only, people should not be able to edit groups or
> > roles.
> >
> > Do we anything in the new API to prevent people from changing roles and
> > groups when the Federation provider is read-only?
> >
> >
> > [1] - https://issues.jboss.org/browse/KEYCLOAK-3904
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > 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 sthorger at redhat.com  Fri Dec  2 10:36:02 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 2 Dec 2016 16:36:02 +0100
Subject: [keycloak-dev] Proper handling of read only users from user
	storage
In-Reply-To: <CAJgngAdLcZcXdNPbXdUUpJDV+wH1QVS4EeLNjqjWbcLqJXTRjw@mail.gmail.com>
References: <CAJgngAf1izkRZjhWYqmeET30e08OE3FJp8yy7-tSB1SY7psjtQ@mail.gmail.com>
	<2853701a-820f-6804-4eb4-8fcee799c377@redhat.com>
	<CAJgngAdLcZcXdNPbXdUUpJDV+wH1QVS4EeLNjqjWbcLqJXTRjw@mail.gmail.com>
Message-ID: <CAJgngAczba4s2MJmEFBXG+eGhM_rFwzRpaf8EAnee3TcV-6Kbg@mail.gmail.com>

Can we with confidence do this early in 3.x without having to change the
user storage SPI? If so I've got no issue with postponing it to 3.x.

On 2 December 2016 at 16:30, Stian Thorgersen <sthorger at redhat.com> wrote:

> That's far from ideal. Dealing with this through an exception is horrible.
> I've said several times that all we need at minimum is a way for a provider
> to tell Keycloak if it's read or read/write. A boolean is fine for now.
> Once we had that it would take an hour or two to do the UI work.
>
> On 2 December 2016 at 15:15, Bill Burke <bburke at redhat.com> wrote:
>
>> All we're going to be able to implement is better handling of the
>> ReadOnlyException.  I just don't have time to do UI work, it takes too
>> long.  As it is, many providers will be hybrid, that will be both read-only
>> and writable depending on the attribute, role, credential type, or
>> whatever.  LDAP is a perfect example where attributes and role/group
>> mappings can be read only or writable in the same deployment.  So, anything
>> more elegant will require reworking LDAP as well.
>>
>>
>>
>> On 12/1/16 5:59 AM, Stian Thorgersen wrote:
>>
>>> We should solve the following issues for 2.5.0:
>>>
>>> https://issues.jboss.org/browse/KEYCLOAK-3060
>>> https://issues.jboss.org/browse/KEYCLOAK-3613
>>>
>>> The current behavior of showing a form and throwing an error is not very
>>> elegant and this should be resolved before as part of user storage SPI work.
>>>
>>
>>
>

From bruno at abstractj.org  Fri Dec  2 10:53:25 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 2 Dec 2016 13:53:25 -0200
Subject: [keycloak-dev] LDAP read-only was Re: Federation Storage:
 read-only groups
In-Reply-To: <13e0dbd1-7264-07ff-108c-6d729da1cbf0@redhat.com>
References: <20161202092212.GA13749@abstractj.org>
	<13e0dbd1-7264-07ff-108c-6d729da1cbf0@redhat.com>
Message-ID: <20161202155325.GA1582@abstractj.org>

On 2016-12-02, Bill Burke wrote:
> Providers are supposed to throw a ReadOnlyException in this scenario.  I
> don't know if the LDAP provider handles this well.  I was a bit confused
> on how it worked, it seems like if a mapper is read-only, it allows you
> to edit the change in the import. Basically unsynced mode.
>
> In looking at your SSSD provider, you only throw ReadOnlyException for
> attributes loaded by SSSD.  For the rest, you allow the local import to
> be updated (unsynced).

I'm probably missing something here, but I couldn't find anything in
the API how to prevent people from editing groups imported from my
Federation provider.

Where should I look?

>
>
> On 12/2/16 4:22 AM, Bruno Oliveira wrote:
> > Good morning,
> >
> > Today for SSSD Federation storage everything is read-only. This
> > is pretty much because we don't have any way to synchronize the changes
> > made at the admin console back to SSSD.
> >
> > QE identified this bug[1], that kind of affects LDAP federation provider
> > in read-only mode too. Correct if I'm wrong, but in theory, if the federation
> > provider is read-only, people should not be able to edit groups or
> > roles.
> >
> > Do we anything in the new API to prevent people from changing roles and
> > groups when the Federation provider is read-only?
> >
> >
> > [1] - https://issues.jboss.org/browse/KEYCLOAK-3904
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > 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 bburke at redhat.com  Fri Dec  2 11:09:57 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 2 Dec 2016 11:09:57 -0500
Subject: [keycloak-dev] Proper handling of read only users from user
	storage
In-Reply-To: <CAJgngAczba4s2MJmEFBXG+eGhM_rFwzRpaf8EAnee3TcV-6Kbg@mail.gmail.com>
References: <CAJgngAf1izkRZjhWYqmeET30e08OE3FJp8yy7-tSB1SY7psjtQ@mail.gmail.com>
	<2853701a-820f-6804-4eb4-8fcee799c377@redhat.com>
	<CAJgngAdLcZcXdNPbXdUUpJDV+wH1QVS4EeLNjqjWbcLqJXTRjw@mail.gmail.com>
	<CAJgngAczba4s2MJmEFBXG+eGhM_rFwzRpaf8EAnee3TcV-6Kbg@mail.gmail.com>
Message-ID: <7b181015-3e18-2b14-8c7a-a1e81987d8bc@redhat.com>

I know it is far from ideal.  I think it can be added on later. Storage 
providers could implement a UserCapabilitiesProvider interface which 
returns an object that specifies which attributes, mappings, etc. are 
readonly/writeable, etc.


On 12/2/16 10:36 AM, Stian Thorgersen wrote:
> Can we with confidence do this early in 3.x without having to change 
> the user storage SPI? If so I've got no issue with postponing it to 3.x.
>
> On 2 December 2016 at 16:30, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     That's far from ideal. Dealing with this through an exception is
>     horrible. I've said several times that all we need at minimum is a
>     way for a provider to tell Keycloak if it's read or read/write. A
>     boolean is fine for now. Once we had that it would take an hour or
>     two to do the UI work.
>
>     On 2 December 2016 at 15:15, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>
>         All we're going to be able to implement is better handling of
>         the ReadOnlyException.  I just don't have time to do UI work,
>         it takes too long.  As it is, many providers will be hybrid,
>         that will be both read-only and writable depending on the
>         attribute, role, credential type, or whatever. LDAP is a
>         perfect example where attributes and role/group mappings can
>         be read only or writable in the same deployment.  So, anything
>         more elegant will require reworking LDAP as well.
>
>
>
>         On 12/1/16 5:59 AM, Stian Thorgersen wrote:
>
>             We should solve the following issues for 2.5.0:
>
>             https://issues.jboss.org/browse/KEYCLOAK-3060
>             <https://issues.jboss.org/browse/KEYCLOAK-3060>
>             https://issues.jboss.org/browse/KEYCLOAK-3613
>             <https://issues.jboss.org/browse/KEYCLOAK-3613>
>
>             The current behavior of showing a form and throwing an
>             error is not very elegant and this should be resolved
>             before as part of user storage SPI work.
>
>
>
>


From RLaghuvaram at contractor.lb.com  Fri Dec  2 15:34:34 2016
From: RLaghuvaram at contractor.lb.com (Laghuvaram, Raghu)
Date: Fri, 2 Dec 2016 20:34:34 +0000
Subject: [keycloak-dev] Validate Token on IDP
In-Reply-To: <D4674191.3517%rlaghuvaram@contractor.lb.com>
References: <D4674191.3517%rlaghuvaram@contractor.lb.com>
Message-ID: <D46744D9.3528%rlaghuvaram@contractor.lb.com>

I am trying to validate the token(Access Token) using the URL /auth/realms/<realm>/protocol/openid-connect/validate?access_token=<token> but I am getting 404 all the time. I am using 2.3.0 Final, is the token validate URL still valid?


Thanks,
Raghu.


________________________________

Notice: This communication may contain privileged and/or confidential information. If you are not the intended recipient, please notify the sender by email, and immediately delete the message and any attachments without copying or disclosing them. LB may, for any reason, intercept, access, use, and disclose any information that is communicated by or through, or which is stored on, its networks, applications, services, and devices.

From RLaghuvaram at contractor.lb.com  Fri Dec  2 15:36:53 2016
From: RLaghuvaram at contractor.lb.com (Laghuvaram, Raghu)
Date: Fri, 2 Dec 2016 20:36:53 +0000
Subject: [keycloak-dev] Stateless using Java Servlet Filter Adapter
Message-ID: <D4674514.352B%rlaghuvaram@contractor.lb.com>

Currently I am using Java Servlet Filter Adapter to make use of KeyCloak, I gave my secured pages url (/secured/*) for the filter KeycloakOIDCFilter and I am using tokenstore to use cookie so that stateless token store is achieved. But still I am not able to see any KEYCLOAK_ADAPTER_STATE cookie on my application cookies or on the keycloak(http://keycloakhost:keycloakport/auth/realms/{realmname}) cookies? I am using 2.3.0 Final. Is there anything I need to change to make my application use stateless token store?

Thanks,
Raghu

________________________________

Notice: This communication may contain privileged and/or confidential information. If you are not the intended recipient, please notify the sender by email, and immediately delete the message and any attachments without copying or disclosing them. LB may, for any reason, intercept, access, use, and disclose any information that is communicated by or through, or which is stored on, its networks, applications, services, and devices.

From bburke at redhat.com  Fri Dec  2 20:09:48 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 2 Dec 2016 20:09:48 -0500
Subject: [keycloak-dev] User Storage SPI docs
Message-ID: <28559c87-0712-badd-f4fc-f85f82ffa15d@redhat.com>

see here:

https://keycloak.gitbooks.io/server-developer-guide/content/v/master/topics/user-storage.html

1st iteration complete.


From bburke at redhat.com  Sat Dec  3 11:36:48 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 3 Dec 2016 11:36:48 -0500
Subject: [keycloak-dev] local build failing, travis passing
Message-ID: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>

I just noticed that my local build fails while travis passes. The bug is 
really something travis should have picked up, specifically the 
PartialImportsTest was removing an identity provider.  The JPA 
removeIdenittyProviderByAlias method was wrong as it was trying to load 
an IdentityProviderModel after it was removed thus resulting in a 
Hibernate error.  Travis did not pick this up which makes me wonder if 
the test is even running.

FYI, i have a pull request that fixes this that is incoming. The bug, 
not travis.

Bill



From mposolda at redhat.com  Mon Dec  5 02:39:37 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 5 Dec 2016 08:39:37 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
Message-ID: <a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>

Fyi. On Friday afternoon, I've found the issue that travis didn't run 
all the tests from the testsuite. And PartialImportTest was the one, 
which wasn't executed. See https://issues.jboss.org/browse/KEYCLOAK-4021

However with the travis fix, all the tests were passing (including 
PartialImportTest). So it seems this test was just failing randomly (not 
always)?

Now I can see in latest travis build that PartialImportTest passes.

Marek




On 03/12/16 17:36, Bill Burke wrote:
> I just noticed that my local build fails while travis passes. The bug is
> really something travis should have picked up, specifically the
> PartialImportsTest was removing an identity provider.  The JPA
> removeIdenittyProviderByAlias method was wrong as it was trying to load
> an IdentityProviderModel after it was removed thus resulting in a
> Hibernate error.  Travis did not pick this up which makes me wonder if
> the test is even running.
>
> FYI, i have a pull request that fixes this that is incoming. The bug,
> not travis.
>
> Bill
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Mon Dec  5 04:34:00 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 5 Dec 2016 10:34:00 +0100
Subject: [keycloak-dev] Proper handling of read only users from user
 storage
In-Reply-To: <7b181015-3e18-2b14-8c7a-a1e81987d8bc@redhat.com>
References: <CAJgngAf1izkRZjhWYqmeET30e08OE3FJp8yy7-tSB1SY7psjtQ@mail.gmail.com>
	<2853701a-820f-6804-4eb4-8fcee799c377@redhat.com>
	<CAJgngAdLcZcXdNPbXdUUpJDV+wH1QVS4EeLNjqjWbcLqJXTRjw@mail.gmail.com>
	<CAJgngAczba4s2MJmEFBXG+eGhM_rFwzRpaf8EAnee3TcV-6Kbg@mail.gmail.com>
	<7b181015-3e18-2b14-8c7a-a1e81987d8bc@redhat.com>
Message-ID: <9195047f-45a6-4b7e-8688-968a5d694f09@redhat.com>

+1 for UserCapabilitiesProvider.

For LDAP, the implementation of UserCapabilitiesProvider will be able to 
detect the read-only/read-write fields automatically based on the 
configured mode for the provider and configured mappers (eg. if 
particular attribute mapper is writable or read-only etc)

Marek

On 02/12/16 17:09, Bill Burke wrote:
> I know it is far from ideal.  I think it can be added on later. Storage
> providers could implement a UserCapabilitiesProvider interface which
> returns an object that specifies which attributes, mappings, etc. are
> readonly/writeable, etc.
>
>
> On 12/2/16 10:36 AM, Stian Thorgersen wrote:
>> Can we with confidence do this early in 3.x without having to change
>> the user storage SPI? If so I've got no issue with postponing it to 3.x.
>>
>> On 2 December 2016 at 16:30, Stian Thorgersen <sthorger at redhat.com
>> <mailto:sthorger at redhat.com>> wrote:
>>
>>      That's far from ideal. Dealing with this through an exception is
>>      horrible. I've said several times that all we need at minimum is a
>>      way for a provider to tell Keycloak if it's read or read/write. A
>>      boolean is fine for now. Once we had that it would take an hour or
>>      two to do the UI work.
>>
>>      On 2 December 2016 at 15:15, Bill Burke <bburke at redhat.com
>>      <mailto:bburke at redhat.com>> wrote:
>>
>>          All we're going to be able to implement is better handling of
>>          the ReadOnlyException.  I just don't have time to do UI work,
>>          it takes too long.  As it is, many providers will be hybrid,
>>          that will be both read-only and writable depending on the
>>          attribute, role, credential type, or whatever. LDAP is a
>>          perfect example where attributes and role/group mappings can
>>          be read only or writable in the same deployment.  So, anything
>>          more elegant will require reworking LDAP as well.
>>
>>
>>
>>          On 12/1/16 5:59 AM, Stian Thorgersen wrote:
>>
>>              We should solve the following issues for 2.5.0:
>>
>>              https://issues.jboss.org/browse/KEYCLOAK-3060
>>              <https://issues.jboss.org/browse/KEYCLOAK-3060>
>>              https://issues.jboss.org/browse/KEYCLOAK-3613
>>              <https://issues.jboss.org/browse/KEYCLOAK-3613>
>>
>>              The current behavior of showing a form and throwing an
>>              error is not very elegant and this should be resolved
>>              before as part of user storage SPI work.
>>
>>
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Mon Dec  5 05:01:36 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 5 Dec 2016 11:01:36 +0100
Subject: [keycloak-dev] LDAP read-only was Re: Federation Storage:
 read-only groups
In-Reply-To: <13e0dbd1-7264-07ff-108c-6d729da1cbf0@redhat.com>
References: <20161202092212.GA13749@abstractj.org>
	<13e0dbd1-7264-07ff-108c-6d729da1cbf0@redhat.com>
Message-ID: <2603d4a7-5500-6a05-8775-12499a2ea8b7@redhat.com>

On 02/12/16 15:26, Bill Burke wrote:
> Providers are supposed to throw a ReadOnlyException in this scenario.  I
> don't know if the LDAP provider handles this well.  I was a bit confused
> on how it worked, it seems like if a mapper is read-only, it allows you
> to edit the change in the import. Basically unsynced mode.
Yes, the current read-only mode for GroupMapper is defacto "unsynced". 
It allows you to add new group memberships, but those memberships are 
saved in Keycloak DB, not in LDAP itself. So the group membership is the 
merge of memberships from DB and from LDAP. Removing group membership, 
which is saved in LDAP throws an exception.

I am going to add new mode "read-only" and rename the current read-only 
mode to "unsynced" to be better aligned with the modes for userStorage. 
Created https://issues.jboss.org/browse/KEYCLOAK-4025

Marek
>
> In looking at your SSSD provider, you only throw ReadOnlyException for
> attributes loaded by SSSD.  For the rest, you allow the local import to
> be updated (unsynced).
>
>
> On 12/2/16 4:22 AM, Bruno Oliveira wrote:
>> Good morning,
>>
>> Today for SSSD Federation storage everything is read-only. This
>> is pretty much because we don't have any way to synchronize the changes
>> made at the admin console back to SSSD.
>>
>> QE identified this bug[1], that kind of affects LDAP federation provider
>> in read-only mode too. Correct if I'm wrong, but in theory, if the federation
>> provider is read-only, people should not be able to edit groups or
>> roles.
>>
>> Do we anything in the new API to prevent people from changing roles and
>> groups when the Federation provider is read-only?
>>
>>
>> [1] - https://issues.jboss.org/browse/KEYCLOAK-3904
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> 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  Mon Dec  5 05:28:19 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 5 Dec 2016 11:28:19 +0100
Subject: [keycloak-dev] Suggestion and fix for e-Directory federation
 provider
In-Reply-To: <CAJWapEKBcFix2Kkgkb1iB76Oz_BybVWdLjgyGj_-7edTVOH1Jw@mail.gmail.com>
References: <CAJWapELVVcNKmAepNJChT6ecg8h-1qhQFe=6sDRHJT25Zhw6UQ@mail.gmail.com>
	<CAMZCGg_SnGnUFLf539TDoJLuVyVFCcEeQbZHM9-XE4EMbnBDDQ@mail.gmail.com>
	<f2f20828-ba16-b878-1a55-3046c22e4d1f@redhat.com>
	<6bf4856a-c955-ada3-15f1-af6015791977@redhat.com>
	<CAJWapEKBcFix2Kkgkb1iB76Oz_BybVWdLjgyGj_-7edTVOH1Jw@mail.gmail.com>
Message-ID: <34ee21a9-c83b-1451-65f3-18b6823782bc@redhat.com>

Ok, It will be good if you can create another separate JIRA for the 
netIQ eDirectory and send PR and then we can discuss it there too.

Btv. Last Friday it was related community contribution for adding the 
ActiveDirectory LDS support. I guess that once you rebase you will 
probably need to do just the change like this in LDAPConfig class:

     public boolean isObjectGUID() {
-        return 
getUuidLDAPAttributeName().equalsIgnoreCase(LDAPConstants.OBJECT_GUID);
+        return 
getUuidLDAPAttributeName().equalsIgnoreCase(LDAPConstants.OBJECT_GUID) 
|| getUuidLDAPAttributeName().equalsIgnoreCase(LDAPConstants.EDIR_GUID);
     }

Hopefully it will work with just those minimal changes.

We're not going to support another vendor in the "Vendor" list and we 
won't maintain the netIQ eDirectory support by ourselves. But I am 
thinking about creating the section in the docs about various LDAP 
vendors and what are the related needed configuration changes to have 
the vendor working with Keycloak. So if you can create JIRA, send PR 
with the change and then create some steps to have netIQ eDirectory 
working in the JIRA similar to this [1] it will be appreciated.

Thanks,
Marek

[1] 
https://issues.jboss.org/browse/KEYCLOAK-4009?focusedCommentId=13333341&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13333341


On 02/12/16 13:35, Tomas Tikovsky wrote:
> I think that the problem mentioned in Keycloak-3099 is not caused by
> utf8 as its more related
>
> to this function interpretting UUID attribute as string in case of
> anything else than activeDirectory.
>
> eDirectory guid attribute is of byte[] type so reading byte[] as
> string results in that garbish found in LDAP_ID field in DB.
>
>
> /federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/store/ldap/LDAPOperationManager.java
>
> public String decodeEntryUUID(final Object entryUUID) {
>           String id;
>
> -        if (this.config.isActiveDirectory() && entryUUID instanceof byte[]) {
> +        if (entryUUID instanceof byte[]) {
>               id = LDAPUtil.decodeObjectGUID((byte[]) entryUUID);
>           } else {
>              id = entryUUID.toString();
>           }
>
> Guid attribute needs to be declared as binary to be correctly returned
> from server.
>
> +
> +        if (config.isEDirectory()){
> +            env.put("java.naming.ldap.attributes.binary",
> LDAPConstants.EDIR_GUID);
> +        }
> +
>
> I posted full diff as attachment in my first post, but didnt realize
> it will be discarded. I can make a pull request but i wanted to
> consult it first here.
>
> Cheers
>
> Tom
>
>
> 2016-12-02 10:07 GMT+01:00 Marek Posolda <mposolda at redhat.com>:
>
>> On 02/12/16 10:04, Marek Posolda wrote:
>>
>>> That's the question... Actually we rejected KEYCLOAK-3099, but it's
>>> possible that problem described below by Tomas is a little bit different
>>> then the issue in the ticket. AFAIK the ticket was specific just to
>>> combination of e-directory LDAP with MSSQL database.
>>>
>> Sorry, small update. We didn't rejected the ticket, but it should be fixed
>> automatically with fixing some other task (work in progress by Hynek). So
>> the MSSQL issue KEYCLOAK-3099 should just work fine in new version -
>> hopefully :)
>>
>> Marek
>>
>>
>>> IMO It's always good to support more different LDAP servers. But the
>>> problem is that:
>>> - Supported vendors should be likely tested, but we don't have capacity
>>> to test and maintain all the LDAP (and DB) vendors in the world
>>> - There is a chance that community PR for supporting new LDAP vendor
>>> breaks other vendors etc. There is just always some additional
>>> complexity with each server supported.
>>> - We don't have possibility to re-test the PR by themselves due to the
>>> LDAP server not available for us.
>>>
>>> We tries to focus especially on the most important servers, so if there
>>> is enough demand from the community and customers for some LDAP vendor,
>>> we will add it. But it seems that ATM you're the only one with the
>>> demand for netIQ e-directory.
>>>
>>> So if there is possibility to workaround and have the netIQ e-directory
>>> working by setup of our existing LDAP StorageProvider configuration
>>> options and mappers (which AFAIK it is), then it is preferred way
>>> instead of the PR for adding support for it OOTB.
>>>
>>> My 2 cents :)
>>>
>>> Marek
>>>
>>> On 02/12/16 09:24, Sebastien Blanc wrote:
>>>
>>>> Hi !
>>>>
>>>> Sure that would be awesome if you can create a pull request and attached
>>>> it
>>>> to the ticket !
>>>>
>>>> Sebi
>>>>
>>>>
>>>>
>>>> On Thu, Nov 24, 2016 at 1:38 PM, Tomas Tikovsky <
>>>> tikovsky.tomas at gmail.com>
>>>> wrote:
>>>>
>>>> Hello everyone,
>>>>> im using e-directory federation ldap provider and came to this bug
>>>>> KEYCLOAK-3099 <https://issues.jboss.org/browse/KEYCLOAK-3099> as i was
>>>>> experiencing the same problem.
>>>>> e-Directory sends guid attribute as byte[] so it needs to be declared as
>>>>> binary the same way as its done for activeDirectory.
>>>>> Sending simple diff to fix this issue if you consider this as helpfull.
>>>>>
>>>>> Novell was acquired by microfocus and their product has been renamed to
>>>>> netIQ eDirectory so i incorporated that change as well.
>>>>>
>>>>> Another thing i noted were 2 incorrect attribute mappings in
>>>>> administration
>>>>> console.
>>>>>
>>>>> "username" -> "uid"
>>>>> correct as long as users are enabled for linux (not default) otherwise
>>>>> cn.
>>>>> So cn should work for more cases than uid.
>>>>>
>>>>> "firstname" -> "cn"
>>>>> wrong, should be "givenname"
>>>>>
>>>>> Cheers
>>>>>
>>>>> Tom
>>>>>
>>>>> _______________________________________________
>>>>> 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 hmlnarik at redhat.com  Mon Dec  5 06:53:38 2016
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 5 Dec 2016 12:53:38 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
Message-ID: <CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>

Speaking of the tests, we seem not to run any of the adapter test suites. I
believe that running at least adapter tests for wildfly would be
beneficial, preventing e.g. [1]. WDYT?

[1] https://issues.jboss.org/browse/KEYCLOAK-4017

On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda <mposolda at redhat.com> wrote:

> Fyi. On Friday afternoon, I've found the issue that travis didn't run
> all the tests from the testsuite. And PartialImportTest was the one,
> which wasn't executed. See https://issues.jboss.org/browse/KEYCLOAK-4021
>
> However with the travis fix, all the tests were passing (including
> PartialImportTest). So it seems this test was just failing randomly (not
> always)?
>
> Now I can see in latest travis build that PartialImportTest passes.
>
> Marek
>
>
>
>
> On 03/12/16 17:36, Bill Burke wrote:
> > I just noticed that my local build fails while travis passes. The bug is
> > really something travis should have picked up, specifically the
> > PartialImportsTest was removing an identity provider.  The JPA
> > removeIdenittyProviderByAlias method was wrong as it was trying to load
> > an IdentityProviderModel after it was removed thus resulting in a
> > Hibernate error.  Travis did not pick this up which makes me wonder if
> > the test is even running.
> >
> > FYI, i have a pull request that fixes this that is incoming. The bug,
> > not travis.
> >
> > Bill
> >
> >
> > _______________________________________________
> > 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
>



-- 

--Hynek

From Stephen.Merchant at gandlake.com  Mon Dec  5 08:41:18 2016
From: Stephen.Merchant at gandlake.com (Stephen Merchant)
Date: Mon, 5 Dec 2016 13:41:18 +0000
Subject: [keycloak-dev] Disable Keycloak 'User Federation' menu item in
 Keycloak Administrator.
Message-ID: <3DE4BF1BF8EDD84B8F8D61B0A88BD563117077@EXCH01.gandlake.local>

Hello,
Is there a legitimate method of removing the 'User Federation' menu item, and/or the 'Configure' menu section from the Keycloak Administrator web application?

For some types of users we would like these Keycloak admin menu options to be hidden.

Any help appreciated.
Thanks.

Stephen Merchant
Developer
Gandlake Limited

Crown Commercial Service Supplier
BSI ISO/IEC 27001 certification number IS 585161


Gandlake Limited, a Limited Liability Company registered in England and Wales under number 4667925. Registered Office: Gandlake House, London Road, Newbury, Berkshire. RG14 1LA. VAT Registration Number 809 7164 11

From mposolda at redhat.com  Mon Dec  5 09:52:18 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 5 Dec 2016 15:52:18 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
Message-ID: <b0e4e2f1-82a9-239e-ec4b-7f76aa97ccfe@redhat.com>

Since last week, I've added the support for running the adapter tests on 
embedded undertow and some are run during default travis build too. 
Basically everything in package 
"org.keycloak.testsuite.adapter.undertow.servlet" for now. This also 
allows running adapter tests from IDE, which is great for development 
and debugging. Previously you either needed to develop adapters in the 
old testsuite or develop against wildfly server, which sucks (constantly 
rebuilding stuff with maven, copying the jars to modules etc).

This should help to avoid most of regressions in adapters, which should 
be catched during travis build now. Unfortunately it won't help with the 
issue like KEYCLOAK-4017 because the modules inside 
testsuite/integration-arquillian/tests/other/adapters/jboss/ are 
"detached" from the main project, so removing the class in IDE won't 
automatically remove the subclasses in those detached modules. I wonder 
if we can improve to avoid those detached modules and abstract classes 
with tests and instead have just the single class with particular 
adapter test, which will just work with any app server profile ( 
-Papp-server-wildfly, -Pauth-server-eap etc)?

Marek

On 05/12/16 12:53, Hynek Mlnarik wrote:
> Speaking of the tests, we seem not to run any of the adapter test 
> suites. I believe that running at least adapter tests for wildfly 
> would be beneficial, preventing e.g. [1]. WDYT?
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>
> On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Fyi. On Friday afternoon, I've found the issue that travis didn't run
>     all the tests from the testsuite. And PartialImportTest was the one,
>     which wasn't executed. See
>     https://issues.jboss.org/browse/KEYCLOAK-4021
>     <https://issues.jboss.org/browse/KEYCLOAK-4021>
>
>     However with the travis fix, all the tests were passing (including
>     PartialImportTest). So it seems this test was just failing
>     randomly (not
>     always)?
>
>     Now I can see in latest travis build that PartialImportTest passes.
>
>     Marek
>
>
>
>
>     On 03/12/16 17:36, Bill Burke wrote:
>     > I just noticed that my local build fails while travis passes.
>     The bug is
>     > really something travis should have picked up, specifically the
>     > PartialImportsTest was removing an identity provider.  The JPA
>     > removeIdenittyProviderByAlias method was wrong as it was trying
>     to load
>     > an IdentityProviderModel after it was removed thus resulting in a
>     > Hibernate error.  Travis did not pick this up which makes me
>     wonder if
>     > the test is even running.
>     >
>     > FYI, i have a pull request that fixes this that is incoming. The
>     bug,
>     > not travis.
>     >
>     > Bill
>     >
>     >
>     > _______________________________________________
>     > 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>
>
>
>     _______________________________________________
>     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>
>
>
>
>
> -- 
>
> --Hynek



From bburke at redhat.com  Mon Dec  5 10:27:08 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 5 Dec 2016 10:27:08 -0500
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
Message-ID: <9b46fbc3-8826-46c8-e15c-ebda7dcd731f@redhat.com>

Yeah, I fixed a bug in RealmAdapter that was causing the failure.


On 12/5/16 2:39 AM, Marek Posolda wrote:
> Fyi. On Friday afternoon, I've found the issue that travis didn't run 
> all the tests from the testsuite. And PartialImportTest was the one, 
> which wasn't executed. See https://issues.jboss.org/browse/KEYCLOAK-4021
>
> However with the travis fix, all the tests were passing (including 
> PartialImportTest). So it seems this test was just failing randomly 
> (not always)?
>
> Now I can see in latest travis build that PartialImportTest passes.
>
> Marek
>
>
>
>
> On 03/12/16 17:36, Bill Burke wrote:
>> I just noticed that my local build fails while travis passes. The bug is
>> really something travis should have picked up, specifically the
>> PartialImportsTest was removing an identity provider.  The JPA
>> removeIdenittyProviderByAlias method was wrong as it was trying to load
>> an IdentityProviderModel after it was removed thus resulting in a
>> Hibernate error.  Travis did not pick this up which makes me wonder if
>> the test is even running.
>>
>> FYI, i have a pull request that fixes this that is incoming. The bug,
>> not travis.
>>
>> Bill
>>
>>
>> _______________________________________________
>> 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  5 10:29:17 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 5 Dec 2016 10:29:17 -0500
Subject: [keycloak-dev] LDAP read-only was Re: Federation Storage:
 read-only groups
In-Reply-To: <2603d4a7-5500-6a05-8775-12499a2ea8b7@redhat.com>
References: <20161202092212.GA13749@abstractj.org>
	<13e0dbd1-7264-07ff-108c-6d729da1cbf0@redhat.com>
	<2603d4a7-5500-6a05-8775-12499a2ea8b7@redhat.com>
Message-ID: <1341af40-7711-6d80-9682-ae1ad81a97ff@redhat.com>



On 12/5/16 5:01 AM, Marek Posolda wrote:
> On 02/12/16 15:26, Bill Burke wrote:
>> Providers are supposed to throw a ReadOnlyException in this scenario.  I
>> don't know if the LDAP provider handles this well.  I was a bit confused
>> on how it worked, it seems like if a mapper is read-only, it allows you
>> to edit the change in the import. Basically unsynced mode.
> Yes, the current read-only mode for GroupMapper is defacto "unsynced". 
> It allows you to add new group memberships, but those memberships are 
> saved in Keycloak DB, not in LDAP itself. So the group membership is 
> the merge of memberships from DB and from LDAP. Removing group 
> membership, which is saved in LDAP throws an exception.
>
> I am going to add new mode "read-only" and rename the current 
> read-only mode to "unsynced" to be better aligned with the modes for 
> userStorage. Created https://issues.jboss.org/browse/KEYCLOAK-4025

Don't forget to edit the migration script to handle this.


From bburke at redhat.com  Mon Dec  5 10:32:56 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 5 Dec 2016 10:32:56 -0500
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
Message-ID: <d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>

These broke because they weren't part of the main build.  I thought they 
were just dead code because when I did a "Find Usages" for them, nothing 
came up.  Minimally, things should at least be compiled with the main 
build, that way when refactorings happen, somebody doesn't delete a test 
dependency by accident.


On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
> Speaking of the tests, we seem not to run any of the adapter test 
> suites. I believe that running at least adapter tests for wildfly 
> would be beneficial, preventing e.g. [1]. WDYT?
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>
> On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Fyi. On Friday afternoon, I've found the issue that travis didn't run
>     all the tests from the testsuite. And PartialImportTest was the one,
>     which wasn't executed. See
>     https://issues.jboss.org/browse/KEYCLOAK-4021
>     <https://issues.jboss.org/browse/KEYCLOAK-4021>
>
>     However with the travis fix, all the tests were passing (including
>     PartialImportTest). So it seems this test was just failing
>     randomly (not
>     always)?
>
>     Now I can see in latest travis build that PartialImportTest passes.
>
>     Marek
>
>
>
>
>     On 03/12/16 17:36, Bill Burke wrote:
>     > I just noticed that my local build fails while travis passes.
>     The bug is
>     > really something travis should have picked up, specifically the
>     > PartialImportsTest was removing an identity provider.  The JPA
>     > removeIdenittyProviderByAlias method was wrong as it was trying
>     to load
>     > an IdentityProviderModel after it was removed thus resulting in a
>     > Hibernate error.  Travis did not pick this up which makes me
>     wonder if
>     > the test is even running.
>     >
>     > FYI, i have a pull request that fixes this that is incoming. The
>     bug,
>     > not travis.
>     >
>     > Bill
>     >
>     >
>     > _______________________________________________
>     > 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>
>
>
>     _______________________________________________
>     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>
>
>
>
>
> -- 
>
> --Hynek


From mposolda at redhat.com  Mon Dec  5 11:01:24 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 5 Dec 2016 17:01:24 +0100
Subject: [keycloak-dev] LDAP read-only was Re: Federation Storage:
 read-only groups
In-Reply-To: <1341af40-7711-6d80-9682-ae1ad81a97ff@redhat.com>
References: <20161202092212.GA13749@abstractj.org>
	<13e0dbd1-7264-07ff-108c-6d729da1cbf0@redhat.com>
	<2603d4a7-5500-6a05-8775-12499a2ea8b7@redhat.com>
	<1341af40-7711-6d80-9682-ae1ad81a97ff@redhat.com>
Message-ID: <695a9686-5a00-cdb5-4db3-2e3f3e62e6b8@redhat.com>

On 05/12/16 16:29, Bill Burke wrote:
>
>
> On 12/5/16 5:01 AM, Marek Posolda wrote:
>> On 02/12/16 15:26, Bill Burke wrote:
>>> Providers are supposed to throw a ReadOnlyException in this 
>>> scenario.  I
>>> don't know if the LDAP provider handles this well.  I was a bit 
>>> confused
>>> on how it worked, it seems like if a mapper is read-only, it allows you
>>> to edit the change in the import. Basically unsynced mode.
>> Yes, the current read-only mode for GroupMapper is defacto 
>> "unsynced". It allows you to add new group memberships, but those 
>> memberships are saved in Keycloak DB, not in LDAP itself. So the 
>> group membership is the merge of memberships from DB and from LDAP. 
>> Removing group membership, which is saved in LDAP throws an exception.
>>
>> I am going to add new mode "read-only" and rename the current 
>> read-only mode to "unsynced" to be better aligned with the modes for 
>> userStorage. Created https://issues.jboss.org/browse/KEYCLOAK-4025
>
> Don't forget to edit the migration script to handle this.
>
Yeah, sure. I have the migration in mind.

Marek


From RLaghuvaram at contractor.lb.com  Mon Dec  5 16:27:21 2016
From: RLaghuvaram at contractor.lb.com (Laghuvaram, Raghu)
Date: Mon, 5 Dec 2016 21:27:21 +0000
Subject: [keycloak-dev] Stateless using Keycloak Jetty Adapter gives NPE
Message-ID: <D46B4462.3544%rlaghuvaram@contractor.lb.com>

I am planning to use Keycloak Jetty Adapter(9.2) as I felt that the Java Servlet Filter adapter can be used only with session and we cannot make use token-store as cookie with the Servlet Adapter. But I tried with Jetty Adapter I am getting NPE and I saw an open bug https://issues.jboss.org/browse/KEYCLOAK-2514.  Is there any other workaround for this so that I can achieve stateless?


Thanks,
Raghu


________________________________

Notice: This communication may contain privileged and/or confidential information. If you are not the intended recipient, please notify the sender by email, and immediately delete the message and any attachments without copying or disclosing them. LB may, for any reason, intercept, access, use, and disclose any information that is communicated by or through, or which is stored on, its networks, applications, services, and devices.

From mposolda at redhat.com  Tue Dec  6 02:53:39 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 6 Dec 2016 08:53:39 +0100
Subject: [keycloak-dev] Stateless using Keycloak Jetty Adapter gives NPE
In-Reply-To: <D46B4462.3544%rlaghuvaram@contractor.lb.com>
References: <D46B4462.3544%rlaghuvaram@contractor.lb.com>
Message-ID: <1b7a5ece-1af8-57c7-77f8-cf62bd910977@redhat.com>

Workaround is either to:
1) Switch to session store
2) Create subclass of KeycloakJettyAuthenticator and override method:

protected Authentication register(Request request, 
KeycloakPrincipal<RefreshableKeycloakSecurityContext> principal)

and avoid NPE somehow in your overriden version.You need to use your 
overriden class in configuration and copy the JAR with your overriden 
class to the adapter.

3) Send us PR with the fix. IMO the preferred will be if it's fix with 
minimal impact and possible regressions in other adapters.

Thanks,
Marek

On 05/12/16 22:27, Laghuvaram, Raghu wrote:
> I am planning to use Keycloak Jetty Adapter(9.2) as I felt that the Java Servlet Filter adapter can be used only with session and we cannot make use token-store as cookie with the Servlet Adapter. But I tried with Jetty Adapter I am getting NPE and I saw an open bug https://issues.jboss.org/browse/KEYCLOAK-2514.  Is there any other workaround for this so that I can achieve stateless?
>
>
> Thanks,
> Raghu
>
>
> ________________________________
>
> Notice: This communication may contain privileged and/or confidential information. If you are not the intended recipient, please notify the sender by email, and immediately delete the message and any attachments without copying or disclosing them. LB may, for any reason, intercept, access, use, and disclose any information that is communicated by or through, or which is stored on, its networks, applications, services, and devices.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From RLaghuvaram at contractor.lb.com  Tue Dec  6 10:43:10 2016
From: RLaghuvaram at contractor.lb.com (Laghuvaram, Raghu)
Date: Tue, 6 Dec 2016 15:43:10 +0000
Subject: [keycloak-dev] Stateless using Keycloak Jetty Adapter gives NPE
In-Reply-To: <1b7a5ece-1af8-57c7-77f8-cf62bd910977@redhat.com>
References: <D46B4462.3544%rlaghuvaram@contractor.lb.com>
	<1b7a5ece-1af8-57c7-77f8-cf62bd910977@redhat.com>
Message-ID: <D46C44C4.3564%rlaghuvaram@contractor.lb.com>

Thanks for your response, If I use session store its not stateless right?
Rather than Jetty Adapter, can I make use of Java Servlet Filter adapter
and achieve stateless? Last time when I used Java Servlet Filter adapter
and set tokenstore to cookie, I didn?t see any KEYCLOAK_ADAPTER_STATE
cookie on my application cookies or on the key cloak cookies(I used 2.3.0
Final). Would Servlet Filter adapter work in stateless way? If possible
could you please let us know if there are any other adapters which are
working good in stateless way.


Thanks,
Raghu

On 12/6/16, 2:53 AM, "Marek Posolda" <mposolda at redhat.com> wrote:

>Workaround is either to:
>1) Switch to session store
>2) Create subclass of KeycloakJettyAuthenticator and override method:
>
>protected Authentication register(Request request,
>KeycloakPrincipal<RefreshableKeycloakSecurityContext> principal)
>
>and avoid NPE somehow in your overriden version.You need to use your
>overriden class in configuration and copy the JAR with your overriden
>class to the adapter.
>
>3) Send us PR with the fix. IMO the preferred will be if it's fix with
>minimal impact and possible regressions in other adapters.
>
>Thanks,
>Marek
>
>On 05/12/16 22:27, Laghuvaram, Raghu wrote:
>> I am planning to use Keycloak Jetty Adapter(9.2) as I felt that the
>>Java Servlet Filter adapter can be used only with session and we cannot
>>make use token-store as cookie with the Servlet Adapter. But I tried
>>with Jetty Adapter I am getting NPE and I saw an open bug
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro
>>wse_KEYCLOAK-2D2514&d=DgIC-g&c=spYp1tZ3AQD6dfuI6rqaeg&r=nVu6ptGZzG7TsBlQS
>>hAwtCFWgc86m6UyYR7paGbbkBE&m=VjwAiVJLvdsl3I-X5cOG2aig59yDf0LxJ-bdRU9QazM&
>>s=p40oWUvYe87wOt6MbQWkMF_Nsbr0qVhaE-nIKYJV7GE&e= .  Is there any other
>>workaround for this so that I can achieve stateless?
>>
>>
>> Thanks,
>> Raghu
>>
>>
>> ________________________________
>>
>> Notice: This communication may contain privileged and/or confidential
>>information. If you are not the intended recipient, please notify the
>>sender by email, and immediately delete the message and any attachments
>>without copying or disclosing them. LB may, for any reason, intercept,
>>access, use, and disclose any information that is communicated by or
>>through, or which is stored on, its networks, applications, services,
>>and devices.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail
>>man_listinfo_keycloak-2Ddev&d=DgIC-g&c=spYp1tZ3AQD6dfuI6rqaeg&r=nVu6ptGZz
>>G7TsBlQShAwtCFWgc86m6UyYR7paGbbkBE&m=VjwAiVJLvdsl3I-X5cOG2aig59yDf0LxJ-bd
>>RU9QazM&s=WJP2Fs5Fu1tAHefojVESaRgcj-4FlaLv8j3Ink3NGFs&e=
>
>


________________________________

Notice: This communication may contain privileged and/or confidential information. If you are not the intended recipient, please notify the sender by email, and immediately delete the message and any attachments without copying or disclosing them. LB may, for any reason, intercept, access, use, and disclose any information that is communicated by or through, or which is stored on, its networks, applications, services, and devices.


From RLaghuvaram at contractor.lb.com  Tue Dec  6 11:11:19 2016
From: RLaghuvaram at contractor.lb.com (Laghuvaram, Raghu)
Date: Tue, 6 Dec 2016 16:11:19 +0000
Subject: [keycloak-dev] ServletFilter Adapter Cookie Token Store
Message-ID: <D46C4CA0.357A%rlaghuvaram@contractor.lb.com>

I see that cookie token-store would not be supported until 2.x as per the
comments in https://issues.jboss.org/browse/KEYCLOAK-2662, Is it fixed in
any of the recent versions? It seems like its not working in 2.3.0 Final.

Thanks,
Raghu


________________________________

Notice: This communication may contain privileged and/or confidential information. If you are not the intended recipient, please notify the sender by email, and immediately delete the message and any attachments without copying or disclosing them. LB may, for any reason, intercept, access, use, and disclose any information that is communicated by or through, or which is stored on, its networks, applications, services, and devices.


From bruno at abstractj.org  Wed Dec  7 07:02:21 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 7 Dec 2016 10:02:21 -0200
Subject: [keycloak-dev] Groups on SSSD Federation provider
Message-ID: <20161207120221.GA26498@abstractj.org>

Good morning,

Today I was chatting with Marek, about this issue[1]. It pretty much
relates to my previous thread about having read-only groups/roles.

In summary, groups are not tightly coupled to Federation providers.
So, to prevent read-only users from joining/leaving groups, at
joinGroup and leaveGroup methods, thrown an exception,

This is pretty much fine. However, the admin still can edit
the group and it's not possible to synchronize it back to SSSD ?
everything is read-only.

That said, I was thinking if we really should synchronize user's
groups coming from SSSD or not. Because the chances of having a
group/role mismatch because someone decided to change its name is
high.

I can see two alternatives:

1. Never synchronize user's group from SSSD. We cannot synchronize it
back and I'm not sure how this information is relevant into our context.
For authentication with PAM, we don't need this information.

2. We keep it and permit the admin to change, but internally we preserve
the original name synchronized from SSSD. Maybe make the original name,
the id.

Thoughts?

[1] - https://issues.jboss.org/browse/KEYCLOAK-3904

--

abstractj
PGP: 0x84DC9914

From singhrasster at gmail.com  Wed Dec  7 07:21:20 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Wed, 7 Dec 2016 06:21:20 -0600
Subject: [keycloak-dev] Details on SAML Soap Binding support in Keycloak
Message-ID: <CAJ0vL+K7SGuYz+rB7rmn1g_pSUr-7eXsSASmSjPahnoRkK82MQ@mail.gmail.com>

We have a requirement to setup a SAML SP that sends SOAP request to the
keycloak IDP which returns the SOAP response to the SAML SP. We would like
to know if keycloak supports this? We came across something called as ECP
that probably provides this support but cant find details on how to
use/implement it. Could you provide us with some pointers on this?

Also, are there any sample SP that we can use to send SOAP requests to IDP?
If not, any pointers on how to set this all up?

From bburke at redhat.com  Wed Dec  7 09:43:41 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 7 Dec 2016 09:43:41 -0500
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <20161207120221.GA26498@abstractj.org>
References: <20161207120221.GA26498@abstractj.org>
Message-ID: <1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>

I think I agree that you shouldn't allow writes for a user backed by 
SSSD as we have no way of synchronizing changes back, so I think you 
should redo the SSSD provider so that it doesn't import a local copy of 
a user and creates a read-only implementation of UserModel.  See the 
User Storage SPI docs and examples. Specifically:

https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-simple/src/main/java/org/keycloak/examples/userstorage/readonly

This is a barebones example, but hopefully you can extract the necessary 
knowledge.  Writeup is in master docs:

https://keycloak.gitbooks.io/server-developer-guide/content/v/master/topics/user-storage.html

Really you should also expand it to be able to pull in any arbitrary 
attribute as well as currently its only name and email.

On 12/7/16 7:02 AM, Bruno Oliveira wrote:
> Good morning,
>
> Today I was chatting with Marek, about this issue[1]. It pretty much
> relates to my previous thread about having read-only groups/roles.
>
> In summary, groups are not tightly coupled to Federation providers.
> So, to prevent read-only users from joining/leaving groups, at
> joinGroup and leaveGroup methods, thrown an exception,
>
> This is pretty much fine. However, the admin still can edit
> the group and it's not possible to synchronize it back to SSSD ?
> everything is read-only.
>
> That said, I was thinking if we really should synchronize user's
> groups coming from SSSD or not. Because the chances of having a
> group/role mismatch because someone decided to change its name is
> high.
>
> I can see two alternatives:
>
> 1. Never synchronize user's group from SSSD. We cannot synchronize it
> back and I'm not sure how this information is relevant into our context.
> For authentication with PAM, we don't need this information.
>
> 2. We keep it and permit the admin to change, but internally we preserve
> the original name synchronized from SSSD. Maybe make the original name,
> the id.
>
> Thoughts?
>
> [1] - https://issues.jboss.org/browse/KEYCLOAK-3904
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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  7 09:48:44 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 7 Dec 2016 09:48:44 -0500
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
Message-ID: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>

Is there a good reason why travis does not run the tomcat and jetty 
tests?  I was just able to merge something that broke jetty.

Bill


From bruno at abstractj.org  Wed Dec  7 11:05:40 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 7 Dec 2016 14:05:40 -0200
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
Message-ID: <20161207160540.GB17975@abstractj.org>

Hi Bill,

On 2016-12-07, Bill Burke wrote:
> I think I agree that you shouldn't allow writes for a user backed by
> SSSD as we have no way of synchronizing changes back, so I think you
> should redo the SSSD provider so that it doesn't import a local copy of
> a user and creates a read-only implementation of UserModel.  See the
> User Storage SPI docs and examples. Specifically:
>
> https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-simple/src/main/java/org/keycloak/examples/userstorage/readonly
>
> This is a barebones example, but hopefully you can extract the necessary
> knowledge.  Writeup is in master docs:
>
> https://keycloak.gitbooks.io/server-developer-guide/content/v/master/topics/user-storage.html

Thanks for the references, but that's not really the problem today. Every user
attribute coming from the SSSD federation provider is already read-only.

The same is not true for groups and roles (and I understand why).
Groups imported from SSSD, still can be changed, but like I mentioned,
we cannot sync it back. And that's the real issue.

>
> Really you should also expand it to be able to pull in any arbitrary
> attribute as well as currently its only name and email.
>
> On 12/7/16 7:02 AM, Bruno Oliveira wrote:
> > Good morning,
> >
> > Today I was chatting with Marek, about this issue[1]. It pretty much
> > relates to my previous thread about having read-only groups/roles.
> >
> > In summary, groups are not tightly coupled to Federation providers.
> > So, to prevent read-only users from joining/leaving groups, at
> > joinGroup and leaveGroup methods, thrown an exception,
> >
> > This is pretty much fine. However, the admin still can edit
> > the group and it's not possible to synchronize it back to SSSD ?
> > everything is read-only.
> >
> > That said, I was thinking if we really should synchronize user's
> > groups coming from SSSD or not. Because the chances of having a
> > group/role mismatch because someone decided to change its name is
> > high.
> >
> > I can see two alternatives:
> >
> > 1. Never synchronize user's group from SSSD. We cannot synchronize it
> > back and I'm not sure how this information is relevant into our context.
> > For authentication with PAM, we don't need this information.
> >
> > 2. We keep it and permit the admin to change, but internally we preserve
> > the original name synchronized from SSSD. Maybe make the original name,
> > the id.
> >
> > Thoughts?
> >
> > [1] - https://issues.jboss.org/browse/KEYCLOAK-3904
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > 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 jdennis at redhat.com  Wed Dec  7 11:18:26 2016
From: jdennis at redhat.com (John Dennis)
Date: Wed, 7 Dec 2016 11:18:26 -0500
Subject: [keycloak-dev] Details on SAML Soap Binding support in Keycloak
In-Reply-To: <CAJ0vL+K7SGuYz+rB7rmn1g_pSUr-7eXsSASmSjPahnoRkK82MQ@mail.gmail.com>
References: <CAJ0vL+K7SGuYz+rB7rmn1g_pSUr-7eXsSASmSjPahnoRkK82MQ@mail.gmail.com>
Message-ID: <7f01ca70-f601-f30f-fe05-fd6c60dedd4b@redhat.com>

On 12/07/2016 07:21 AM, Rashmi Singh wrote:
> We have a requirement to setup a SAML SP that sends SOAP request to the
> keycloak IDP which returns the SOAP response to the SAML SP. We would like
> to know if keycloak supports this? We came across something called as ECP
> that probably provides this support but cant find details on how to
> use/implement it. Could you provide us with some pointers on this?

Yes Keycloak SOAP works, we use it in our environments to implement ECP.

> Also, are there any sample SP that we can use to send SOAP requests to IDP?
> If not, any pointers on how to set this all up?

ECP is it's own client independent of the SP and IdP, it sits between 
the SP and IdP during the authentication flow. On the SP side the SP 
must know how process a request from an ECP client. The IdP only needs 
to know how process SOAP messages (which Keycloak does). The idea behind 
ECP is it is intended for non-browser clients which cannot perform the 
necessary redirects so instead the ECP client acts as a go-between 
shuttling messages between itself and the SP and between itself and the 
IdP. ECP transactions are relatively easy to implement. I have 2 scripts 
I use for testing ECP, one is a shell script and the other is a python 
script which uses the Lasso library (same library used by our 
mod_auth_mellon SP implementation, which also supports ECP). I can 
provide you with the scripts but they are meant for testing and would 
need some clean up for your environment. The Shibboleth SP also supports 
ECP but we do not support it (we only support mod_auth_mellon at the 
moment).

If you could be more specific as to what the customer needs it would 
help focus the discussion.



-- 
John

From bruno at abstractj.org  Wed Dec  7 13:02:05 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 7 Dec 2016 16:02:05 -0200
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
Message-ID: <20161207180205.GD17975@abstractj.org>

Is it a compilation error? I'm getting the same here.

On 2016-12-07, Bill Burke wrote:
> Is there a good reason why travis does not run the tomcat and jetty
> tests?  I was just able to merge something that broke jetty.
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914

From peter.chamberlin at digital.cabinet-office.gov.uk  Wed Dec  7 13:06:08 2016
From: peter.chamberlin at digital.cabinet-office.gov.uk (Peter Chamberlin)
Date: Wed, 7 Dec 2016 18:06:08 +0000
Subject: [keycloak-dev] Passing login_hint up to IdP when using kc_idp_hint
Message-ID: <CALrL_LnS0wB3iKTy6BRUKF5=naDo=sg2eeG6qt3P6gyB5khW1Q@mail.gmail.com>

Hi Keycloak team,

I'm working on a system which uses Keycloak as a broker to both OIDC and
SAML2.0 IdPs. We are using `kc_idp_hint` for every request and Keycloak is
never exposed to the user. The system uses OIDC to connect to Keycloak.

We would like to pass a `login_hint` or `subject` upstream to  IdPs
(depending if it's OIDC or SAML) as we expect to know the user's IdP user
name, but this does not work out of the box. I can't see anything in the
documentation that would enable it.

Is it possible? If so how?

Many thanks for any help or pointers you can give.

Peter Chamberlin

From bburke at redhat.com  Wed Dec  7 15:43:15 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 7 Dec 2016 15:43:15 -0500
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <20161207160540.GB17975@abstractj.org>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
Message-ID: <508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>



On 12/7/16 11:05 AM, Bruno Oliveira wrote:
> Hi Bill,
>
> On 2016-12-07, Bill Burke wrote:
>> I think I agree that you shouldn't allow writes for a user backed by
>> SSSD as we have no way of synchronizing changes back, so I think you
>> should redo the SSSD provider so that it doesn't import a local copy of
>> a user and creates a read-only implementation of UserModel.  See the
>> User Storage SPI docs and examples. Specifically:
>>
>> https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-simple/src/main/java/org/keycloak/examples/userstorage/readonly
>>
>> This is a barebones example, but hopefully you can extract the necessary
>> knowledge.  Writeup is in master docs:
>>
>> https://keycloak.gitbooks.io/server-developer-guide/content/v/master/topics/user-storage.html
> Thanks for the references, but that's not really the problem today. Every user
> attribute coming from the SSSD federation provider is already read-only.
I don't understand why the problem isn't solvable.

> The same is not true for groups and roles (and I understand why).
> Groups imported from SSSD, still can be changed, but like I mentioned,
> we cannot sync it back. And that's the real issue.
You can fashion your UserModel implementation however you want. Again, 
you don't have to import the user and can sync things when the user is 
loaded from SSSD.  We cache it, then whenever the cache expires, reload 
from SSSD and resync groups.

If you're talking about the actual groups changing (their names or 
whatever), that's a similar problem we have with our regular LDAP adapter.

Bill


From bburke at redhat.com  Wed Dec  7 15:43:42 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 7 Dec 2016 15:43:42 -0500
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <20161207180205.GD17975@abstractj.org>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
Message-ID: <a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>

No, a test error.  Working on my branch now.


On 12/7/16 1:02 PM, Bruno Oliveira wrote:
> Is it a compilation error? I'm getting the same here.
>
> On 2016-12-07, Bill Burke wrote:
>> Is there a good reason why travis does not run the tomcat and jetty
>> tests?  I was just able to merge something that broke jetty.
>>
>> Bill
>>
>> _______________________________________________
>> 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  Wed Dec  7 20:01:54 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 08 Dec 2016 01:01:54 +0000
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
Message-ID: <CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>

On Wed, Dec 7, 2016 at 6:43 PM Bill Burke <bburke at redhat.com> wrote:

>
>
> On 12/7/16 11:05 AM, Bruno Oliveira wrote:
> > Hi Bill,
> >
> > On 2016-12-07, Bill Burke wrote:
> >> I think I agree that you shouldn't allow writes for a user backed by
> >> SSSD as we have no way of synchronizing changes back, so I think you
> >> should redo the SSSD provider so that it doesn't import a local copy of
> >> a user and creates a read-only implementation of UserModel.  See the
> >> User Storage SPI docs and examples. Specifically:
> >>
> >>
> https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-simple/src/main/java/org/keycloak/examples/userstorage/readonly
> >>
> >> This is a barebones example, but hopefully you can extract the necessary
> >> knowledge.  Writeup is in master docs:
> >>
> >>
> https://keycloak.gitbooks.io/server-developer-guide/content/v/master/topics/user-storage.html
> > Thanks for the references, but that's not really the problem today.
> Every user
> > attribute coming from the SSSD federation provider is already read-only.
> I don't understand why the problem isn't solvable.
>
> > The same is not true for groups and roles (and I understand why).
> > Groups imported from SSSD, still can be changed, but like I mentioned,
> > we cannot sync it back. And that's the real issue.
> You can fashion your UserModel implementation however you want. Again,
> you don't have to import the user and can sync things when the user is
> loaded from SSSD.  We cache it, then whenever the cache expires, reload
> from SSSD and resync groups.
>

Thanks Bill, groups are reload and re-synced during user's login for SSSD
provider.


>
> If you're talking about the actual groups changing (their names or
> whatever), that's a similar problem we have with our regular LDAP adapter.
>

That's exactly what I meant.  It's a problem that from my undestanding we
don't have a
solution now. At the same time, I'm afraid that people start to change
groups' name
and create several mismatches between KC database and IPA. For example:

group1 coming from IPA, is edited to group2 on Keycloak. On the next login,
SSSD federation
identifies that group1 does not exist and try to synchronize it again. Now
we have 2 groups.

I'm just wondering if, to prevent this, groups should be removed from SSSD
federation provider
codebase for now.


> Bill
>
>

From singhrasster at gmail.com  Thu Dec  8 04:37:43 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Thu, 8 Dec 2016 03:37:43 -0600
Subject: [keycloak-dev] Details on SAML Soap Binding support in Keycloak
In-Reply-To: <7f01ca70-f601-f30f-fe05-fd6c60dedd4b@redhat.com>
References: <CAJ0vL+K7SGuYz+rB7rmn1g_pSUr-7eXsSASmSjPahnoRkK82MQ@mail.gmail.com>
	<7f01ca70-f601-f30f-fe05-fd6c60dedd4b@redhat.com>
Message-ID: <CAJ0vL+JgPQ31cc70J6VwbFQO=rE9ixJPyR2kYd8-mk39dRpAQg@mail.gmail.com>

Thanks John. Can you please provide me the scripts you mentioned? I can get
started with that.

On 7 Dec 2016 10:18, "John Dennis" <jdennis at redhat.com> wrote:

> On 12/07/2016 07:21 AM, Rashmi Singh wrote:
>
>> We have a requirement to setup a SAML SP that sends SOAP request to the
>> keycloak IDP which returns the SOAP response to the SAML SP. We would like
>> to know if keycloak supports this? We came across something called as ECP
>> that probably provides this support but cant find details on how to
>> use/implement it. Could you provide us with some pointers on this?
>>
>
> Yes Keycloak SOAP works, we use it in our environments to implement ECP.
>
> Also, are there any sample SP that we can use to send SOAP requests to IDP?
>> If not, any pointers on how to set this all up?
>>
>
> ECP is it's own client independent of the SP and IdP, it sits between the
> SP and IdP during the authentication flow. On the SP side the SP must know
> how process a request from an ECP client. The IdP only needs to know how
> process SOAP messages (which Keycloak does). The idea behind ECP is it is
> intended for non-browser clients which cannot perform the necessary
> redirects so instead the ECP client acts as a go-between shuttling messages
> between itself and the SP and between itself and the IdP. ECP transactions
> are relatively easy to implement. I have 2 scripts I use for testing ECP,
> one is a shell script and the other is a python script which uses the Lasso
> library (same library used by our mod_auth_mellon SP implementation, which
> also supports ECP). I can provide you with the scripts but they are meant
> for testing and would need some clean up for your environment. The
> Shibboleth SP also supports ECP but we do not support it (we only support
> mod_auth_mellon at the moment).
>
> If you could be more specific as to what the customer needs it would help
> focus the discussion.
>
>
>
> --
> John
>

From mposolda at redhat.com  Thu Dec  8 06:48:33 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Dec 2016 12:48:33 +0100
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
Message-ID: <16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>

They are not included in the script running travis 
https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh#L4

It seems wee should add them here.

 From the long run, it will be better to remove them (as they rely on 
the old testsuite) and rather have them running on the 
integration-arquillian testsuite. I know it sucks during development 
that Jetty itself doesn't run in same JVM like the test (debugging etc). 
But I hope we can have the solution, which will allow to choose whether 
Jetty (or hopefully some other servers) are running in same JVM or 
different JVM.

Marek

On 07/12/16 21:43, Bill Burke wrote:
> No, a test error.  Working on my branch now.
>
>
> On 12/7/16 1:02 PM, Bruno Oliveira wrote:
>> Is it a compilation error? I'm getting the same here.
>>
>> On 2016-12-07, Bill Burke wrote:
>>> Is there a good reason why travis does not run the tomcat and jetty
>>> tests?  I was just able to merge something that broke jetty.
>>>
>>> Bill
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
> _______________________________________________
> 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  8 07:14:40 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Dec 2016 13:14:40 +0100
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
Message-ID: <c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>

Yes, the thing is that we don't have anything like federation of groups 
or roles. And not sure if we need that as it will be lots of overhead 
and corner cases around this IMO.

My vote is something like your solution 2. Maybe the group can have 
attribute like "userStorage.<storageID>.id", which will contain the 
identificator of particular group specific to particular userStorage 
provider. In case of LDAP, it will be either LDAP UUID or LDAP DN of 
that group. In case of SSSD probably something similar?

Note: I think we need the "storageID" element in the attribute name too 
as single Keycloak group "group1" can be used in group mappings of users 
from more userStorage providers.

Marek

On 08/12/16 02:01, Bruno Oliveira wrote:
>> If you're talking about the actual groups changing (their names or
>> >whatever), that's a similar problem we have with our regular LDAP adapter.
>> >
> That's exactly what I meant.  It's a problem that from my undestanding we
> don't have a
> solution now. At the same time, I'm afraid that people start to change
> groups' name
> and create several mismatches between KC database and IPA. For example:
>
> group1 coming from IPA, is edited to group2 on Keycloak. On the next login,
> SSSD federation
> identifies that group1 does not exist and try to synchronize it again. Now
> we have 2 groups.



From mposolda at redhat.com  Thu Dec  8 07:21:19 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Dec 2016 13:21:19 +0100
Subject: [keycloak-dev] Passing login_hint up to IdP when using
 kc_idp_hint
In-Reply-To: <CALrL_LnS0wB3iKTy6BRUKF5=naDo=sg2eeG6qt3P6gyB5khW1Q@mail.gmail.com>
References: <CALrL_LnS0wB3iKTy6BRUKF5=naDo=sg2eeG6qt3P6gyB5khW1Q@mail.gmail.com>
Message-ID: <47b35f69-fee4-fe25-cfee-5a4ba661019e@redhat.com>

It doesn't seem it is possible ATM. The possibility is, that you create 
your own implementation of identityProvider and you override method :

createAuthorizationUrl(AuthenticationRequest request)

The parameters of the original request, which was sent from your application to Keycloak, are available from the clientSession notes (which itself is available on the AuthenticationRequest).

Marek


On 07/12/16 19:06, Peter Chamberlin wrote:
> Hi Keycloak team,
>
> I'm working on a system which uses Keycloak as a broker to both OIDC and
> SAML2.0 IdPs. We are using `kc_idp_hint` for every request and Keycloak is
> never exposed to the user. The system uses OIDC to connect to Keycloak.
>
> We would like to pass a `login_hint` or `subject` upstream to  IdPs
> (depending if it's OIDC or SAML) as we expect to know the user's IdP user
> name, but this does not work out of the box. I can't see anything in the
> documentation that would enable it.
>
> Is it possible? If so how?
>
> Many thanks for any help or pointers you can give.
>
> Peter Chamberlin
> _______________________________________________
> 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  8 07:22:27 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 8 Dec 2016 10:22:27 -0200
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
Message-ID: <20161208122227.GG17975@abstractj.org>

On 2016-12-08, Marek Posolda wrote:
> Yes, the thing is that we don't have anything like federation of groups or
> roles. And not sure if we need that as it will be lots of overhead and
> corner cases around this IMO.
>
> My vote is something like your solution 2. Maybe the group can have
> attribute like "userStorage.<storageID>.id", which will contain the
> identificator of particular group specific to particular userStorage
> provider. In case of LDAP, it will be either LDAP UUID or LDAP DN of that
> group. In case of SSSD probably something similar?

+1 Let's do this

>
> Note: I think we need the "storageID" element in the attribute name too as
> single Keycloak group "group1" can be used in group mappings of users from
> more userStorage providers.
>
> Marek
>
> On 08/12/16 02:01, Bruno Oliveira wrote:
> > > If you're talking about the actual groups changing (their names or
> > > >whatever), that's a similar problem we have with our regular LDAP adapter.
> > > >
> > That's exactly what I meant.  It's a problem that from my undestanding we
> > don't have a
> > solution now. At the same time, I'm afraid that people start to change
> > groups' name
> > and create several mismatches between KC database and IPA. For example:
> >
> > group1 coming from IPA, is edited to group2 on Keycloak. On the next login,
> > SSSD federation
> > identifies that group1 does not exist and try to synchronize it again. Now
> > we have 2 groups.
>
>

--

abstractj
PGP: 0x84DC9914

From mposolda at redhat.com  Thu Dec  8 07:30:51 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Dec 2016 13:30:51 +0100
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <20161208122227.GG17975@abstractj.org>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
	<20161208122227.GG17975@abstractj.org>
Message-ID: <1d10e1aa-393a-d1bc-a4ee-cc20b628c8db@redhat.com>

On 08/12/16 13:22, Bruno Oliveira wrote:
> On 2016-12-08, Marek Posolda wrote:
>> Yes, the thing is that we don't have anything like federation of groups or
>> roles. And not sure if we need that as it will be lots of overhead and
>> corner cases around this IMO.
>>
>> My vote is something like your solution 2. Maybe the group can have
>> attribute like "userStorage.<storageID>.id", which will contain the
>> identificator of particular group specific to particular userStorage
>> provider. In case of LDAP, it will be either LDAP UUID or LDAP DN of that
>> group. In case of SSSD probably something similar?
> +1 Let's do this
Btv. is SSSD supporting just groups or also roles? For LDAP there is 
some solution needed for roles too. RoleModel doesn't have "attributes" 
on it ATM, but my vote is to add it.

Marek
>
>> Note: I think we need the "storageID" element in the attribute name too as
>> single Keycloak group "group1" can be used in group mappings of users from
>> more userStorage providers.
>>
>> Marek
>>
>> On 08/12/16 02:01, Bruno Oliveira wrote:
>>>> If you're talking about the actual groups changing (their names or
>>>>> whatever), that's a similar problem we have with our regular LDAP adapter.
>>>>>
>>> That's exactly what I meant.  It's a problem that from my undestanding we
>>> don't have a
>>> solution now. At the same time, I'm afraid that people start to change
>>> groups' name
>>> and create several mismatches between KC database and IPA. For example:
>>>
>>> group1 coming from IPA, is edited to group2 on Keycloak. On the next login,
>>> SSSD federation
>>> identifies that group1 does not exist and try to synchronize it again. Now
>>> we have 2 groups.
>>
> --
>
> abstractj
> PGP: 0x84DC9914



From bburke at redhat.com  Thu Dec  8 09:05:46 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 8 Dec 2016 09:05:46 -0500
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
Message-ID: <9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>



On 12/8/16 6:48 AM, Marek Posolda wrote:
> They are not included in the script running travis 
> https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh#L4
>
> It seems wee should add them here.
>
> From the long run, it will be better to remove them (as they rely on 
> the old testsuite) and rather have them running on the 
> integration-arquillian testsuite. I know it sucks during development 
> that Jetty itself doesn't run in same JVM like the test (debugging 
> etc). But I hope we can have the solution, which will allow to choose 
> whether Jetty (or hopefully some other servers) are running in same 
> JVM or different JVM.
>
Unless arquillian can support running these adapter tests within an IDE, 
they need to stay.  In general, More often than not, I don't like the 
arquillian style we've enforced because it takes a lot longer to write 
tests, is often nearly impossible to do everything through a REST 
interface, and is often really hard to debug.  Maybe its just the types 
of things I'm testing.  Some of the tests should not have been ported to 
arquillian, or, at least shouldn't have been ported to using a REST 
interface for the entire test.

Bill

From bburke at redhat.com  Thu Dec  8 09:22:41 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 8 Dec 2016 09:22:41 -0500
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
Message-ID: <7db34cfb-9fdb-0bbe-7d47-e837fe2bc2fb@redhat.com>


On 12/8/16 7:14 AM, Marek Posolda wrote:
> Yes, the thing is that we don't have anything like federation of 
> groups or roles. And not sure if we need that as it will be lots of 
> overhead and corner cases around this IMO.
>
I thought about doing that, but you still have the same synchronization 
issues.

Alternatively, LDAP and SSSD could just map groups into UserModel 
attributes, then the SAML and OIDC mappers could just map those user 
attributes into role mappings in the token or assertion.


> My vote is something like your solution 2. Maybe the group can have 
> attribute like "userStorage.<storageID>.id", which will contain the 
> identificator of particular group specific to particular userStorage 
> provider. In case of LDAP, it will be either LDAP UUID or LDAP DN of 
> that group. In case of SSSD probably something similar?
>
Should groups and roles instead have a federationLink (which points to 
the provider) and maybe also a federationIdentifier (which can contain 
things like LDAP UUID) as first class properties?  Then, you can search 
for roles and groups based on those properties so you can synchronize them.

Bill


From bburke at redhat.com  Thu Dec  8 09:31:30 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 8 Dec 2016 09:31:30 -0500
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <7db34cfb-9fdb-0bbe-7d47-e837fe2bc2fb@redhat.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
	<7db34cfb-9fdb-0bbe-7d47-e837fe2bc2fb@redhat.com>
Message-ID: <fe4355fd-4973-8c30-0f2e-95965483be1a@redhat.com>


On 12/8/16 9:22 AM, Bill Burke wrote:
>
> On 12/8/16 7:14 AM, Marek Posolda wrote:
>> Yes, the thing is that we don't have anything like federation of 
>> groups or roles. And not sure if we need that as it will be lots of 
>> overhead and corner cases around this IMO.
>>
> I thought about doing that, but you still have the same 
> synchronization issues.
>
> Alternatively, LDAP and SSSD could just map groups into UserModel 
> attributes, then the SAML and OIDC mappers could just map those user 
> attributes into role mappings in the token or assertion.
>
>
>> My vote is something like your solution 2. Maybe the group can have 
>> attribute like "userStorage.<storageID>.id", which will contain the 
>> identificator of particular group specific to particular userStorage 
>> provider. In case of LDAP, it will be either LDAP UUID or LDAP DN of 
>> that group. In case of SSSD probably something similar?
>>
> Should groups and roles instead have a federationLink (which points to 
> the provider) and maybe also a federationIdentifier (which can contain 
> things like LDAP UUID) as first class properties?  Then, you can 
> search for roles and groups based on those properties so you can 
> synchronize them.
>

See above still, but I just want to add that we have to stop doing hacks 
to support a specific edge case.  Instead the SPIs need to be improved.

Bill


From peter.chamberlin at digital.cabinet-office.gov.uk  Thu Dec  8 09:37:21 2016
From: peter.chamberlin at digital.cabinet-office.gov.uk (Peter Chamberlin)
Date: Thu, 8 Dec 2016 14:37:21 +0000
Subject: [keycloak-dev] Passing login_hint up to IdP when using
	kc_idp_hint
In-Reply-To: <47b35f69-fee4-fe25-cfee-5a4ba661019e@redhat.com>
References: <CALrL_LnS0wB3iKTy6BRUKF5=naDo=sg2eeG6qt3P6gyB5khW1Q@mail.gmail.com>
	<47b35f69-fee4-fe25-cfee-5a4ba661019e@redhat.com>
Message-ID: <CALrL_LmOb2r36JhBH09M2=+hJ9ikn0vhK-7=BgcJTJt6nOYKrA@mail.gmail.com>

Hi Marek,

Thank you for your response. That's kind of what we thought.

Would this be something that might be accepted into the core of Keycloak if
we developed it as a configurable option?

All the best,

Peter


On 8 December 2016 at 12:21, Marek Posolda <mposolda at redhat.com> wrote:

> It doesn't seem it is possible ATM. The possibility is, that you create
> your own implementation of identityProvider and you override method :
>
> createAuthorizationUrl(AuthenticationRequest request)
>
> The parameters of the original request, which was sent from your application to Keycloak, are available from the clientSession notes (which itself is available on the AuthenticationRequest).
>
> Marek
>
>
> On 07/12/16 19:06, Peter Chamberlin wrote:
>
> Hi Keycloak team,
>
> I'm working on a system which uses Keycloak as a broker to both OIDC and
> SAML2.0 IdPs. We are using `kc_idp_hint` for every request and Keycloak is
> never exposed to the user. The system uses OIDC to connect to Keycloak.
>
> We would like to pass a `login_hint` or `subject` upstream to  IdPs
> (depending if it's OIDC or SAML) as we expect to know the user's IdP user
> name, but this does not work out of the box. I can't see anything in the
> documentation that would enable it.
>
> Is it possible? If so how?
>
> Many thanks for any help or pointers you can give.
>
> Peter Chamberlin
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From bruno at abstractj.org  Thu Dec  8 10:46:57 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 8 Dec 2016 13:46:57 -0200
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <fe4355fd-4973-8c30-0f2e-95965483be1a@redhat.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
	<7db34cfb-9fdb-0bbe-7d47-e837fe2bc2fb@redhat.com>
	<fe4355fd-4973-8c30-0f2e-95965483be1a@redhat.com>
Message-ID: <20161208154657.GA6574@abstractj.org>

On 2016-12-08, Bill Burke wrote:
>
> On 12/8/16 9:22 AM, Bill Burke wrote:
> >
> > On 12/8/16 7:14 AM, Marek Posolda wrote:
> > > Yes, the thing is that we don't have anything like federation of
> > > groups or roles. And not sure if we need that as it will be lots of
> > > overhead and corner cases around this IMO.
> > >
> > I thought about doing that, but you still have the same synchronization
> > issues.
> >
> > Alternatively, LDAP and SSSD could just map groups into UserModel
> > attributes, then the SAML and OIDC mappers could just map those user
> > attributes into role mappings in the token or assertion.
> >
> >
> > > My vote is something like your solution 2. Maybe the group can have
> > > attribute like "userStorage.<storageID>.id", which will contain the
> > > identificator of particular group specific to particular userStorage
> > > provider. In case of LDAP, it will be either LDAP UUID or LDAP DN of
> > > that group. In case of SSSD probably something similar?
> > >
> > Should groups and roles instead have a federationLink (which points to
> > the provider) and maybe also a federationIdentifier (which can contain
> > things like LDAP UUID) as first class properties?  Then, you can search
> > for roles and groups based on those properties so you can synchronize
> > them.

That would be fantastic.

> >
>
> See above still, but I just want to add that we have to stop doing hacks to
> support a specific edge case.  Instead the SPIs need to be improved.

The only reason why I considered doing that, is because I thought that
we didn't want to change the API. But if that's an option, I'm all for
it.

Should we have a Jira to capture what you suggested?


>
> Bill
>

--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Thu Dec  8 10:49:41 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 8 Dec 2016 13:49:41 -0200
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <1d10e1aa-393a-d1bc-a4ee-cc20b628c8db@redhat.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
	<20161208122227.GG17975@abstractj.org>
	<1d10e1aa-393a-d1bc-a4ee-cc20b628c8db@redhat.com>
Message-ID: <20161208154941.GB6574@abstractj.org>

On 2016-12-08, Marek Posolda wrote:
> On 08/12/16 13:22, Bruno Oliveira wrote:
> > On 2016-12-08, Marek Posolda wrote:
> > > Yes, the thing is that we don't have anything like federation of groups or
> > > roles. And not sure if we need that as it will be lots of overhead and
> > > corner cases around this IMO.
> > >
> > > My vote is something like your solution 2. Maybe the group can have
> > > attribute like "userStorage.<storageID>.id", which will contain the
> > > identificator of particular group specific to particular userStorage
> > > provider. In case of LDAP, it will be either LDAP UUID or LDAP DN of that
> > > group. In case of SSSD probably something similar?
> > +1 Let's do this
> Btv. is SSSD supporting just groups or also roles? For LDAP there is some
> solution needed for roles too. RoleModel doesn't have "attributes" on it
> ATM, but my vote is to add it.

Today only groups. But I would rather to stick with what Bill suggested,
if that's an option.

>
> Marek
> >
> > > Note: I think we need the "storageID" element in the attribute name too as
> > > single Keycloak group "group1" can be used in group mappings of users from
> > > more userStorage providers.
> > >
> > > Marek
> > >
> > > On 08/12/16 02:01, Bruno Oliveira wrote:
> > > > > If you're talking about the actual groups changing (their names or
> > > > > > whatever), that's a similar problem we have with our regular LDAP adapter.
> > > > > >
> > > > That's exactly what I meant.  It's a problem that from my undestanding we
> > > > don't have a
> > > > solution now. At the same time, I'm afraid that people start to change
> > > > groups' name
> > > > and create several mismatches between KC database and IPA. For example:
> > > >
> > > > group1 coming from IPA, is edited to group2 on Keycloak. On the next login,
> > > > SSSD federation
> > > > identifies that group1 does not exist and try to synchronize it again. Now
> > > > we have 2 groups.
> > >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
>
>

--

abstractj
PGP: 0x84DC9914

From mposolda at redhat.com  Thu Dec  8 11:14:06 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Dec 2016 17:14:06 +0100
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <20161208154657.GA6574@abstractj.org>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
	<7db34cfb-9fdb-0bbe-7d47-e837fe2bc2fb@redhat.com>
	<fe4355fd-4973-8c30-0f2e-95965483be1a@redhat.com>
	<20161208154657.GA6574@abstractj.org>
Message-ID: <6be91301-177c-f483-c7a8-895e8a87175a@redhat.com>

The issue is, that single group can have more links to userStorage, not 
just the single one. That's because single group can be mapped to users 
from more different userStorages.

Example:
- I have 2 ldap userStorages (eg. ldap1, ldap2).
- I have group "mygroup" in Keycloak.
- I have user "ldap1-user" and I want him to join the group "mygroup" . 
The group mapping will be saved in LDAP and the LDAP user will be member 
of LDAP group like "cn=mygroup,dc=ldap1,dc=org"
- I have user "ldap2-user" and I want him to join the group "mygroup" . 
The group mapping will be saved in LDAP and the LDAP user will be member 
of LDAP group like "cn=mygroup,dc=ldap2,dc=org"

Note that I need this same Keycloak group in both my LDAPs. In first 
LDAP, the group is represented by DN "cn=mygroup,dc=ldap1,dc=org", but 
in second LDAP it is represented by path "cn=mygroup,dc=ldap2,dc=org" .


So the single properties federationLink+federationIdentifier is 
definitely not sufficient. At least it will need to be a map of 
federationLinks. But then you will need to have something additional in 
the admin console UI to display those federationLinks. Considering all 
of this, my vote is to rather stick with attributes.

Marek

On 08/12/16 16:46, Bruno Oliveira wrote:
>>> Should groups and roles instead have a federationLink (which points to
>>> > >the provider) and maybe also a federationIdentifier (which can contain
>>> > >things like LDAP UUID) as first class properties?  Then, you can search
>>> > >for roles and groups based on those properties so you can synchronize
>>> > >them.
> That would be fantastic.
>




From mposolda at redhat.com  Thu Dec  8 11:47:58 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Dec 2016 17:47:58 +0100
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
	<9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
Message-ID: <a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>

Arquillian can support that. All we need is just different 
implementations of arquillian DeployableContainer interface to represent 
various containers. I've managed to have adapter tests already running 
on embedded undertow and everything is running in single JVM. 
Development and debugging is fine with that.

Having the test+server+adapter in single JVM just rocks during 
development. Problem is, that it won't handle all type of errors. For 
example if Jetty adapter ZIP distribution is broken (eg. some JAR file 
is missing in it), the Jetty adapter tests, which uses embedded Jetty 
won't catch that. For those reasons, also QA team needs to test with 
"real" containers, not with the embedded ones.



On 08/12/16 15:05, Bill Burke wrote:
>
>
> On 12/8/16 6:48 AM, Marek Posolda wrote:
>> They are not included in the script running travis 
>> https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh#L4
>>
>> It seems wee should add them here.
>>
>> From the long run, it will be better to remove them (as they rely on 
>> the old testsuite) and rather have them running on the 
>> integration-arquillian testsuite. I know it sucks during development 
>> that Jetty itself doesn't run in same JVM like the test (debugging 
>> etc). But I hope we can have the solution, which will allow to choose 
>> whether Jetty (or hopefully some other servers) are running in same 
>> JVM or different JVM.
>>
> Unless arquillian can support running these adapter tests within an 
> IDE, they need to stay. 
Arquillian can support that. All we need is just different 
implementations of arquillian DeployableContainer interface to represent 
various containers. I've managed to have adapter tests already running 
on embedded undertow and everything is running in single JVM. 
Development and debugging is fine with that.
> In general, More often than not, I don't like the arquillian style 
> we've enforced because it takes a lot longer to write tests, is often 
> nearly impossible to do everything through a REST interface, and is 
> often really hard to debug.  Maybe its just the types of things I'm 
> testing.  Some of the tests should not have been ported to arquillian, 
> or, at least shouldn't have been ported to using a REST interface for 
> the entire test.
Yeah, having the test+server+adapter in single JVM just rocks during 
development. Problem is, that it won't handle all type of errors. For 
example if Jetty adapter ZIP distribution is broken (eg. some JAR file 
is missing), the Jetty adapter tests, which uses embedded Jetty, won't 
catch that. For those and similar reasons, also QA team needs to test 
with "real" containers, not with the embedded ones.

IMO ideal is, if we can have both possibilities. Test with embedded 
container during development, but also has possibility to run the same 
test against external container in different JVM. Arquillian testsuite 
can support both approaches, but the old testsuite doesn't support the 
external...

I agree some tests shouldn't use REST endpoints. Like the model tests 
from the old testsuite. But they still need to be able to run on 
external environment though. I guess we can have something like the 
"bridge" test, which will just deploy the model test to the REST 
endpoint and you will be able to test things inside this REST endpoint 
on server side? So you will be able to use all the stuff like model 
classes etc.

Marek
>
> Bill



From mposolda at redhat.com  Thu Dec  8 11:50:59 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Dec 2016 17:50:59 +0100
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
	<9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
	<a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>
Message-ID: <f8f07309-8a7a-099f-2408-e884f582acbd@redhat.com>


IMO ideal is, if we can have both possibilities. Test with embedded 
container during development, but also has possibility to run the same 
test against external container in different JVM. Arquillian testsuite 
can support both approaches, but the old testsuite doesn't support the 
external...

I agree some tests shouldn't use REST endpoints. Like the model tests 
from the old testsuite. But they still need to be able to run on 
external environment though. I guess we can have something like the 
"bridge" test, which will just deploy the model test to the REST 
endpoint and you will be able to test things inside this REST endpoint 
on server side? So you will be able to use all the stuff like model 
classes etc.

Marek

On 08/12/16 17:47, Marek Posolda wrote:
> Arquillian can support that. All we need is just different 
> implementations of arquillian DeployableContainer interface to 
> represent various containers. I've managed to have adapter tests 
> already running on embedded undertow and everything is running in 
> single JVM. Development and debugging is fine with that.
>
> Having the test+server+adapter in single JVM just rocks during 
> development. Problem is, that it won't handle all type of errors. For 
> example if Jetty adapter ZIP distribution is broken (eg. some JAR file 
> is missing in it), the Jetty adapter tests, which uses embedded Jetty 
> won't catch that. For those reasons, also QA team needs to test with 
> "real" containers, not with the embedded ones.
>
>
>
> On 08/12/16 15:05, Bill Burke wrote:
>>
>>
>> On 12/8/16 6:48 AM, Marek Posolda wrote:
>>> They are not included in the script running travis 
>>> https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh#L4
>>>
>>> It seems wee should add them here.
>>>
>>> From the long run, it will be better to remove them (as they rely on 
>>> the old testsuite) and rather have them running on the 
>>> integration-arquillian testsuite. I know it sucks during development 
>>> that Jetty itself doesn't run in same JVM like the test (debugging 
>>> etc). But I hope we can have the solution, which will allow to 
>>> choose whether Jetty (or hopefully some other servers) are running 
>>> in same JVM or different JVM.
>>>
>> Unless arquillian can support running these adapter tests within an 
>> IDE, they need to stay. 
> Arquillian can support that. All we need is just different 
> implementations of arquillian DeployableContainer interface to 
> represent various containers. I've managed to have adapter tests 
> already running on embedded undertow and everything is running in 
> single JVM. Development and debugging is fine with that.
>> In general, More often than not, I don't like the arquillian style 
>> we've enforced because it takes a lot longer to write tests, is often 
>> nearly impossible to do everything through a REST interface, and is 
>> often really hard to debug.  Maybe its just the types of things I'm 
>> testing.  Some of the tests should not have been ported to 
>> arquillian, or, at least shouldn't have been ported to using a REST 
>> interface for the entire test.
> Yeah, having the test+server+adapter in single JVM just rocks during 
> development. Problem is, that it won't handle all type of errors. For 
> example if Jetty adapter ZIP distribution is broken (eg. some JAR file 
> is missing), the Jetty adapter tests, which uses embedded Jetty, won't 
> catch that. For those and similar reasons, also QA team needs to test 
> with "real" containers, not with the embedded ones.
>
> IMO ideal is, if we can have both possibilities. Test with embedded 
> container during development, but also has possibility to run the same 
> test against external container in different JVM. Arquillian testsuite 
> can support both approaches, but the old testsuite doesn't support the 
> external...
>
> I agree some tests shouldn't use REST endpoints. Like the model tests 
> from the old testsuite. But they still need to be able to run on 
> external environment though. I guess we can have something like the 
> "bridge" test, which will just deploy the model test to the REST 
> endpoint and you will be able to test things inside this REST endpoint 
> on server side? So you will be able to use all the stuff like model 
> classes etc.
>
> Marek
>>
>> Bill
>
>


From bburke at redhat.com  Thu Dec  8 12:55:25 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 8 Dec 2016 12:55:25 -0500
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <6be91301-177c-f483-c7a8-895e8a87175a@redhat.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
	<7db34cfb-9fdb-0bbe-7d47-e837fe2bc2fb@redhat.com>
	<fe4355fd-4973-8c30-0f2e-95965483be1a@redhat.com>
	<20161208154657.GA6574@abstractj.org>
	<6be91301-177c-f483-c7a8-895e8a87175a@redhat.com>
Message-ID: <d9627007-415a-e757-ab51-575eecac588a@redhat.com>

This just sounds like a lot more work than necessary...I mean, how often 
are group names going to change?


On 12/8/16 11:14 AM, Marek Posolda wrote:
> The issue is, that single group can have more links to userStorage, 
> not just the single one. That's because single group can be mapped to 
> users from more different userStorages.
>
> Example:
> - I have 2 ldap userStorages (eg. ldap1, ldap2).
> - I have group "mygroup" in Keycloak.
> - I have user "ldap1-user" and I want him to join the group "mygroup" 
> . The group mapping will be saved in LDAP and the LDAP user will be 
> member of LDAP group like "cn=mygroup,dc=ldap1,dc=org"
> - I have user "ldap2-user" and I want him to join the group "mygroup" 
> . The group mapping will be saved in LDAP and the LDAP user will be 
> member of LDAP group like "cn=mygroup,dc=ldap2,dc=org"
>
> Note that I need this same Keycloak group in both my LDAPs. In first 
> LDAP, the group is represented by DN "cn=mygroup,dc=ldap1,dc=org", but 
> in second LDAP it is represented by path "cn=mygroup,dc=ldap2,dc=org" .
>
>
> So the single properties federationLink+federationIdentifier is 
> definitely not sufficient. At least it will need to be a map of 
> federationLinks. But then you will need to have something additional 
> in the admin console UI to display those federationLinks. Considering 
> all of this, my vote is to rather stick with attributes.
>
> Marek
>
> On 08/12/16 16:46, Bruno Oliveira wrote:
>>>> Should groups and roles instead have a federationLink (which points to
>>>> > >the provider) and maybe also a federationIdentifier (which can contain
>>>> > >things like LDAP UUID) as first class properties?  Then, you can search
>>>> > >for roles and groups based on those properties so you can synchronize
>>>> > >them.
>> That would be fantastic.
>>
>
>
>


From mposolda at redhat.com  Fri Dec  9 02:02:41 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 9 Dec 2016 08:02:41 +0100
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <d9627007-415a-e757-ab51-575eecac588a@redhat.com>
References: <20161207120221.GA26498@abstractj.org>
	<1d4e78f7-82f9-6706-8c71-29f9ce0efa62@redhat.com>
	<20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
	<7db34cfb-9fdb-0bbe-7d47-e837fe2bc2fb@redhat.com>
	<fe4355fd-4973-8c30-0f2e-95965483be1a@redhat.com>
	<20161208154657.GA6574@abstractj.org>
	<6be91301-177c-f483-c7a8-895e8a87175a@redhat.com>
	<d9627007-415a-e757-ab51-575eecac588a@redhat.com>
Message-ID: <9072ffc5-ead9-2577-5262-ceddbbe753e4@redhat.com>

On 08/12/16 18:55, Bill Burke wrote:
>
> This just sounds like a lot more work than necessary...I mean, how 
> often are group names going to change?
>
No idea. Regarding LDAP, nobody complained about the usecase for 
changing group name. So maybe not do anything for now?

Just wanted to point that if we decide to do something, the single 
federationLink is not sufficient as single Keycloak group can be mapped 
to users from more different userStorages.

Marek
>
>
> On 12/8/16 11:14 AM, Marek Posolda wrote:
>> The issue is, that single group can have more links to userStorage, 
>> not just the single one. That's because single group can be mapped to 
>> users from more different userStorages.
>>
>> Example:
>> - I have 2 ldap userStorages (eg. ldap1, ldap2).
>> - I have group "mygroup" in Keycloak.
>> - I have user "ldap1-user" and I want him to join the group "mygroup" 
>> . The group mapping will be saved in LDAP and the LDAP user will be 
>> member of LDAP group like "cn=mygroup,dc=ldap1,dc=org"
>> - I have user "ldap2-user" and I want him to join the group "mygroup" 
>> . The group mapping will be saved in LDAP and the LDAP user will be 
>> member of LDAP group like "cn=mygroup,dc=ldap2,dc=org"
>>
>> Note that I need this same Keycloak group in both my LDAPs. In first 
>> LDAP, the group is represented by DN "cn=mygroup,dc=ldap1,dc=org", 
>> but in second LDAP it is represented by path 
>> "cn=mygroup,dc=ldap2,dc=org" .
>>
>>
>> So the single properties federationLink+federationIdentifier is 
>> definitely not sufficient. At least it will need to be a map of 
>> federationLinks. But then you will need to have something additional 
>> in the admin console UI to display those federationLinks. Considering 
>> all of this, my vote is to rather stick with attributes.
>>
>> Marek
>>
>> On 08/12/16 16:46, Bruno Oliveira wrote:
>>>>> Should groups and roles instead have a federationLink (which points to
>>>>> > >the provider) and maybe also a federationIdentifier (which can contain
>>>>> > >things like LDAP UUID) as first class properties?  Then, you can search
>>>>> > >for roles and groups based on those properties so you can synchronize
>>>>> > >them.
>>> That would be fantastic.
>>>
>>
>>
>>
>


From vramik at redhat.com  Fri Dec  9 02:28:52 2016
From: vramik at redhat.com (Vlasta Ramik)
Date: Fri, 9 Dec 2016 08:28:52 +0100
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <f8f07309-8a7a-099f-2408-e884f582acbd@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
	<9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
	<a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>
	<f8f07309-8a7a-099f-2408-e884f582acbd@redhat.com>
Message-ID: <f5f1f95f-ba90-3f8b-d6c3-cfca1634697d@redhat.com>

Ahoj Marku,


On 12/08/2016 05:50 PM, Marek Posolda wrote:
> IMO ideal is, if we can have both possibilities. Test with embedded
> container during development, but also has possibility to run the same
> test against external container in different JVM. Arquillian testsuite
> can support both approaches, but the old testsuite doesn't support the
> external...
>
> I agree some tests shouldn't use REST endpoints. Like the model tests
> from the old testsuite. But they still need to be able to run on
> external environment though. I guess we can have something like the
> "bridge" test, which will just deploy the model test to the REST
> endpoint and you will be able to test things inside this REST endpoint
> on server side? So you will be able to use all the stuff like model
> classes etc.
There is https://issues.jboss.org/browse/KEYCLOAK-3729 it seems to me 
that your proposal with "bridge" test could resolve this. It would be 
great to have a meeting to discuss details or if you will have time to 
make PoC. I'd love to take a look at it.
>
> Marek
>
> On 08/12/16 17:47, Marek Posolda wrote:
>> Arquillian can support that. All we need is just different
>> implementations of arquillian DeployableContainer interface to
>> represent various containers. I've managed to have adapter tests
>> already running on embedded undertow and everything is running in
>> single JVM. Development and debugging is fine with that.
>>
>> Having the test+server+adapter in single JVM just rocks during
>> development. Problem is, that it won't handle all type of errors. For
>> example if Jetty adapter ZIP distribution is broken (eg. some JAR file
>> is missing in it), the Jetty adapter tests, which uses embedded Jetty
>> won't catch that. For those reasons, also QA team needs to test with
>> "real" containers, not with the embedded ones.
>>
>>
>>
>> On 08/12/16 15:05, Bill Burke wrote:
>>>
>>> On 12/8/16 6:48 AM, Marek Posolda wrote:
>>>> They are not included in the script running travis
>>>> https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh#L4
>>>>
>>>> It seems wee should add them here.
>>>>
>>>>  From the long run, it will be better to remove them (as they rely on
>>>> the old testsuite) and rather have them running on the
>>>> integration-arquillian testsuite. I know it sucks during development
>>>> that Jetty itself doesn't run in same JVM like the test (debugging
>>>> etc). But I hope we can have the solution, which will allow to
>>>> choose whether Jetty (or hopefully some other servers) are running
>>>> in same JVM or different JVM.
>>>>
>>> Unless arquillian can support running these adapter tests within an
>>> IDE, they need to stay.
>> Arquillian can support that. All we need is just different
>> implementations of arquillian DeployableContainer interface to
>> represent various containers. I've managed to have adapter tests
>> already running on embedded undertow and everything is running in
>> single JVM. Development and debugging is fine with that.
>>> In general, More often than not, I don't like the arquillian style
>>> we've enforced because it takes a lot longer to write tests, is often
>>> nearly impossible to do everything through a REST interface, and is
>>> often really hard to debug.  Maybe its just the types of things I'm
>>> testing.  Some of the tests should not have been ported to
>>> arquillian, or, at least shouldn't have been ported to using a REST
>>> interface for the entire test.
>> Yeah, having the test+server+adapter in single JVM just rocks during
>> development. Problem is, that it won't handle all type of errors. For
>> example if Jetty adapter ZIP distribution is broken (eg. some JAR file
>> is missing), the Jetty adapter tests, which uses embedded Jetty, won't
>> catch that. For those and similar reasons, also QA team needs to test
>> with "real" containers, not with the embedded ones.
>>
>> IMO ideal is, if we can have both possibilities. Test with embedded
>> container during development, but also has possibility to run the same
>> test against external container in different JVM. Arquillian testsuite
>> can support both approaches, but the old testsuite doesn't support the
>> external...
>>
>> I agree some tests shouldn't use REST endpoints. Like the model tests
>> from the old testsuite. But they still need to be able to run on
>> external environment though. I guess we can have something like the
>> "bridge" test, which will just deploy the model test to the REST
>> endpoint and you will be able to test things inside this REST endpoint
>> on server side? So you will be able to use all the stuff like model
>> classes etc.
>>
>> Marek
>>> Bill
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Fri Dec  9 02:51:20 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 9 Dec 2016 08:51:20 +0100
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <f5f1f95f-ba90-3f8b-d6c3-cfca1634697d@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
	<9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
	<a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>
	<f8f07309-8a7a-099f-2408-e884f582acbd@redhat.com>
	<f5f1f95f-ba90-3f8b-d6c3-cfca1634697d@redhat.com>
Message-ID: <02013474-2c60-764e-577a-548bbb56955f@redhat.com>

Ahoj Vlasto,

On 09/12/16 08:28, Vlasta Ramik wrote:
>
> Ahoj Marku,
>
>
> On 12/08/2016 05:50 PM, Marek Posolda wrote:
>> IMO ideal is, if we can have both possibilities. Test with embedded
>> container during development, but also has possibility to run the same
>> test against external container in different JVM. Arquillian testsuite
>> can support both approaches, but the old testsuite doesn't support the
>> external...
>>
>> I agree some tests shouldn't use REST endpoints. Like the model tests
>> from the old testsuite. But they still need to be able to run on
>> external environment though. I guess we can have something like the
>> "bridge" test, which will just deploy the model test to the REST
>> endpoint and you will be able to test things inside this REST endpoint
>> on server side? So you will be able to use all the stuff like model
>> classes etc.
> There is https://issues.jboss.org/browse/KEYCLOAK-3729 it seems to me 
> that your proposal with "bridge" test could resolve this. It would be 
> great to have a meeting to discuss details or if you will have time to 
> make PoC. I'd love to take a look at it.
ah, so you already tried different approach with the expose 
KeycloakSessionFactory to JNDI and remote lookup it from tests. This 
seems much easier then my approach based on deploying test on REST 
endpoint. But for the JNDI, I have no clue about the things like 
serialization etc. Maybe there is some easy solution to it, but I don't 
know ATM... I am sure that approach based on REST endpoints will work, 
but it's more work.

+1 for the meeting. Maybe next week or after Christmas? I personally 
won't have time to do any PoC or something around this before Christmas :(

Marek
>> Marek
>>
>> On 08/12/16 17:47, Marek Posolda wrote:
>>> Arquillian can support that. All we need is just different
>>> implementations of arquillian DeployableContainer interface to
>>> represent various containers. I've managed to have adapter tests
>>> already running on embedded undertow and everything is running in
>>> single JVM. Development and debugging is fine with that.
>>>
>>> Having the test+server+adapter in single JVM just rocks during
>>> development. Problem is, that it won't handle all type of errors. For
>>> example if Jetty adapter ZIP distribution is broken (eg. some JAR file
>>> is missing in it), the Jetty adapter tests, which uses embedded Jetty
>>> won't catch that. For those reasons, also QA team needs to test with
>>> "real" containers, not with the embedded ones.
>>>
>>>
>>>
>>> On 08/12/16 15:05, Bill Burke wrote:
>>>> On 12/8/16 6:48 AM, Marek Posolda wrote:
>>>>> They are not included in the script running travis
>>>>> https://github.com/keycloak/keycloak/blob/master/travis-run-tests.sh#L4
>>>>>
>>>>> It seems wee should add them here.
>>>>>
>>>>>  From the long run, it will be better to remove them (as they rely on
>>>>> the old testsuite) and rather have them running on the
>>>>> integration-arquillian testsuite. I know it sucks during development
>>>>> that Jetty itself doesn't run in same JVM like the test (debugging
>>>>> etc). But I hope we can have the solution, which will allow to
>>>>> choose whether Jetty (or hopefully some other servers) are running
>>>>> in same JVM or different JVM.
>>>>>
>>>> Unless arquillian can support running these adapter tests within an
>>>> IDE, they need to stay.
>>> Arquillian can support that. All we need is just different
>>> implementations of arquillian DeployableContainer interface to
>>> represent various containers. I've managed to have adapter tests
>>> already running on embedded undertow and everything is running in
>>> single JVM. Development and debugging is fine with that.
>>>> In general, More often than not, I don't like the arquillian style
>>>> we've enforced because it takes a lot longer to write tests, is often
>>>> nearly impossible to do everything through a REST interface, and is
>>>> often really hard to debug.  Maybe its just the types of things I'm
>>>> testing.  Some of the tests should not have been ported to
>>>> arquillian, or, at least shouldn't have been ported to using a REST
>>>> interface for the entire test.
>>> Yeah, having the test+server+adapter in single JVM just rocks during
>>> development. Problem is, that it won't handle all type of errors. For
>>> example if Jetty adapter ZIP distribution is broken (eg. some JAR file
>>> is missing), the Jetty adapter tests, which uses embedded Jetty, won't
>>> catch that. For those and similar reasons, also QA team needs to test
>>> with "real" containers, not with the embedded ones.
>>>
>>> IMO ideal is, if we can have both possibilities. Test with embedded
>>> container during development, but also has possibility to run the same
>>> test against external container in different JVM. Arquillian testsuite
>>> can support both approaches, but the old testsuite doesn't support the
>>> external...
>>>
>>> I agree some tests shouldn't use REST endpoints. Like the model tests
>>> from the old testsuite. But they still need to be able to run on
>>> external environment though. I guess we can have something like the
>>> "bridge" test, which will just deploy the model test to the REST
>>> endpoint and you will be able to test things inside this REST endpoint
>>> on server side? So you will be able to use all the stuff like model
>>> classes etc.
>>>
>>> Marek
>>>> Bill
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From singhrasster at gmail.com  Fri Dec  9 06:30:25 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Fri, 9 Dec 2016 05:30:25 -0600
Subject: [keycloak-dev] ArtifactResolve with Keycloak IDP
Message-ID: <CAJ0vL++pLuq=mL6RtA3edMm4rKnvCLyF2mTn1TK6k2ikFLrBdg@mail.gmail.com>

We have a requirement to implement a scenario where SP can send a SOAP
request with ArtifactResolve to the keycloak IDP which in turn sends a SOAP
response with user attribute back to the SP.

The complete detailed scenario will be:

1) User sends login request
2) SP sends an HTTP Redirect to keycloak IDP
3) keycloak IDP authenticates the user
4) keycloak IDP sends Http redirect to AssertionConsumerService back to SP
5) SP sends SOAP request with ArtifactResolve to keycloak IDP
6) IDP sends SOAP Response with user attribute back to SP

The first four steps is what we pretty much understand. I am not sure how
to incorprate steps 5 and 6, that is: how to send SOAP request with
ArtifactResolve to keyclaok IDP.
what needs to be done on the keycloak side to support this and send back a
SOAP response to SP with user attributes? Could you provide any pointers
that would help us with this scenario

From jdennis at redhat.com  Fri Dec  9 09:37:15 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 9 Dec 2016 09:37:15 -0500
Subject: [keycloak-dev] ArtifactResolve with Keycloak IDP
In-Reply-To: <CAJ0vL++pLuq=mL6RtA3edMm4rKnvCLyF2mTn1TK6k2ikFLrBdg@mail.gmail.com>
References: <CAJ0vL++pLuq=mL6RtA3edMm4rKnvCLyF2mTn1TK6k2ikFLrBdg@mail.gmail.com>
Message-ID: <50ef5ca2-bec4-00dc-dcba-6730247ecf73@redhat.com>

On 12/09/2016 06:30 AM, Rashmi Singh wrote:
> We have a requirement to implement a scenario where SP can send a SOAP
> request with ArtifactResolve to the keycloak IDP which in turn sends a SOAP
> response with user attribute back to the SP.
>
> The complete detailed scenario will be:
>
> 1) User sends login request
> 2) SP sends an HTTP Redirect to keycloak IDP
> 3) keycloak IDP authenticates the user
> 4) keycloak IDP sends Http redirect to AssertionConsumerService back to SP
> 5) SP sends SOAP request with ArtifactResolve to keycloak IDP
> 6) IDP sends SOAP Response with user attribute back to SP
>
> The first four steps is what we pretty much understand. I am not sure how
> to incorprate steps 5 and 6, that is: how to send SOAP request with
> ArtifactResolve to keyclaok IDP.
> what needs to be done on the keycloak side to support this and send back a
> SOAP response to SP with user attributes? Could you provide any pointers
> that would help us with this scenario

Answering your question needs more clarification, in part because I'm 
not sure if when you say in step 2 "HTTP Redirect" you're being precise 
or if you meant "SAML HTTP Redirect". If so I believe what you're 
describing is SP-Initiated SSO with POST/Artifact Bindings described in 
section 5.1.3 in SAML Technical Overview.

https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

But then in step 6 you say the response contains an attribute, not an 
assertion which makes me wonder if you're really talking about SAML HTTP 
Redirect followed by a attribute request on the IdP AttributeAuthority 
AttributeService to request a specific attribute after authentication.

I presume you're talking about the former.

I'll let the Keycloak dev's speak directly as to their support. But a 
good place to start and answer your question yourself is by looking at 
the SAML services advertised in Keycloak's IdP metadata. There is no 
ArtifactResolutionService so that eliminates using the POST/Artifact 
binding, nor is there an AttributeAuthority so that eliminates 
requesting attributes outside of an AuthnRequest. Also I'm pretty sure I 
recall hearing in the past that artifacts are not supported.

None of these features are terribly difficult to implement once you have 
basic SAML working in an IdP, they're just variants that use existing 
code slightly differently.

As for your question regarding steps 5 & 6. What do you mean how do you 
send a SOAP request? Either the SP has implemented it or it hasn't. FWIW 
sending/receive SOAP messages are relatively trivial, all you do is 
wrap/unwrap a SAML message in boilerplate XML.

-- 
John

From bruno at abstractj.org  Fri Dec  9 10:27:47 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 9 Dec 2016 13:27:47 -0200
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <9072ffc5-ead9-2577-5262-ceddbbe753e4@redhat.com>
References: <20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
	<7db34cfb-9fdb-0bbe-7d47-e837fe2bc2fb@redhat.com>
	<fe4355fd-4973-8c30-0f2e-95965483be1a@redhat.com>
	<20161208154657.GA6574@abstractj.org>
	<6be91301-177c-f483-c7a8-895e8a87175a@redhat.com>
	<d9627007-415a-e757-ab51-575eecac588a@redhat.com>
	<9072ffc5-ead9-2577-5262-ceddbbe753e4@redhat.com>
Message-ID: <20161209152747.GA32092@abstractj.org>


On 2016-12-09, Marek Posolda wrote:
> On 08/12/16 18:55, Bill Burke wrote:
> >
> > This just sounds like a lot more work than necessary...I mean, how often
> > are group names going to change?
> >
> No idea. Regarding LDAP, nobody complained about the usecase for changing
> group name. So maybe not do anything for now?
>
> Just wanted to point that if we decide to do something, the single
> federationLink is not sufficient as single Keycloak group can be mapped to
> users from more different userStorages.

The original reason behind it was the fact that's possible for admins to
create inconsistencies between IPA and Keycloak. Just like mentioned
before.

But it seems like it's not a simple change and like Bill mentioned too
much. If nobody ever complained, besides QE[1]. I can just update the
docs mentioned that people should be careful when changing or removing
groups for SSSD provider.

[1] - https://issues.jboss.org/browse/KEYCLOAK-3904

>
> Marek
> >
> >
> > On 12/8/16 11:14 AM, Marek Posolda wrote:
> > > The issue is, that single group can have more links to userStorage,
> > > not just the single one. That's because single group can be mapped
> > > to users from more different userStorages.
> > >
> > > Example:
> > > - I have 2 ldap userStorages (eg. ldap1, ldap2).
> > > - I have group "mygroup" in Keycloak.
> > > - I have user "ldap1-user" and I want him to join the group
> > > "mygroup" . The group mapping will be saved in LDAP and the LDAP
> > > user will be member of LDAP group like "cn=mygroup,dc=ldap1,dc=org"
> > > - I have user "ldap2-user" and I want him to join the group
> > > "mygroup" . The group mapping will be saved in LDAP and the LDAP
> > > user will be member of LDAP group like "cn=mygroup,dc=ldap2,dc=org"
> > >
> > > Note that I need this same Keycloak group in both my LDAPs. In first
> > > LDAP, the group is represented by DN "cn=mygroup,dc=ldap1,dc=org",
> > > but in second LDAP it is represented by path
> > > "cn=mygroup,dc=ldap2,dc=org" .
> > >
> > >
> > > So the single properties federationLink+federationIdentifier is
> > > definitely not sufficient. At least it will need to be a map of
> > > federationLinks. But then you will need to have something additional
> > > in the admin console UI to display those federationLinks.
> > > Considering all of this, my vote is to rather stick with attributes.
> > >
> > > Marek
> > >
> > > On 08/12/16 16:46, Bruno Oliveira wrote:
> > > > > > Should groups and roles instead have a federationLink (which points to
> > > > > > > >the provider) and maybe also a federationIdentifier (which can contain
> > > > > > > >things like LDAP UUID) as first class properties?  Then, you can search
> > > > > > > >for roles and groups based on those properties so you can synchronize
> > > > > > > >them.
> > > > That would be fantastic.
> > > >
> > >
> > >
> > >
> >
>

--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Sat Dec 10 23:31:58 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 10 Dec 2016 23:31:58 -0500
Subject: [keycloak-dev] alternative subflow only sort of work
Message-ID: <a4128efd-7634-15fa-0cd9-82c7bd1e0ca4@redhat.com>

In fixing a recent bug, I noticed that alternative subflows don't really 
work as advertised.  If a previous alternative was successful, then an 
alternative subflow will not execute.  I think that's really the only 
thing that works.  If for example, you added another alterantive subflow 
after the alternative subflow for username/password, some weird results 
might happen.  Like I don't think the username/password screen would 
even pop up in this scenario.  I need to check.  Remind me to log a bug 
on this. Going to bed now...

Bill


From singhrasster at gmail.com  Sun Dec 11 20:08:40 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Sun, 11 Dec 2016 19:08:40 -0600
Subject: [keycloak-dev] Details on SAML Soap Binding support in Keycloak
In-Reply-To: <CAJ0vL+JgPQ31cc70J6VwbFQO=rE9ixJPyR2kYd8-mk39dRpAQg@mail.gmail.com>
References: <CAJ0vL+K7SGuYz+rB7rmn1g_pSUr-7eXsSASmSjPahnoRkK82MQ@mail.gmail.com>
	<7f01ca70-f601-f30f-fe05-fd6c60dedd4b@redhat.com>
	<CAJ0vL+JgPQ31cc70J6VwbFQO=rE9ixJPyR2kYd8-mk39dRpAQg@mail.gmail.com>
Message-ID: <CAJ0vL+KVOxegP_rNYx9CiB-PdnoucFt85ROgVPEqHXwMHiWSDQ@mail.gmail.com>

Just a reminder if you could send across the 2 scripts that you mentioned
you use for testing ECP. Also, any instructions on how to setup and
modifications needed on the IDP and SP to make it work will be very useful
too.

On Thu, Dec 8, 2016 at 3:37 AM, Rashmi Singh <singhrasster at gmail.com> wrote:

> Thanks John. Can you please provide me the scripts you mentioned? I can
> get started with that.
>
> On 7 Dec 2016 10:18, "John Dennis" <jdennis at redhat.com> wrote:
>
>> On 12/07/2016 07:21 AM, Rashmi Singh wrote:
>>
>>> We have a requirement to setup a SAML SP that sends SOAP request to the
>>> keycloak IDP which returns the SOAP response to the SAML SP. We would
>>> like
>>> to know if keycloak supports this? We came across something called as ECP
>>> that probably provides this support but cant find details on how to
>>> use/implement it. Could you provide us with some pointers on this?
>>>
>>
>> Yes Keycloak SOAP works, we use it in our environments to implement ECP.
>>
>> Also, are there any sample SP that we can use to send SOAP requests to
>>> IDP?
>>> If not, any pointers on how to set this all up?
>>>
>>
>> ECP is it's own client independent of the SP and IdP, it sits between the
>> SP and IdP during the authentication flow. On the SP side the SP must know
>> how process a request from an ECP client. The IdP only needs to know how
>> process SOAP messages (which Keycloak does). The idea behind ECP is it is
>> intended for non-browser clients which cannot perform the necessary
>> redirects so instead the ECP client acts as a go-between shuttling messages
>> between itself and the SP and between itself and the IdP. ECP transactions
>> are relatively easy to implement. I have 2 scripts I use for testing ECP,
>> one is a shell script and the other is a python script which uses the Lasso
>> library (same library used by our mod_auth_mellon SP implementation, which
>> also supports ECP). I can provide you with the scripts but they are meant
>> for testing and would need some clean up for your environment. The
>> Shibboleth SP also supports ECP but we do not support it (we only support
>> mod_auth_mellon at the moment).
>>
>> If you could be more specific as to what the customer needs it would help
>> focus the discussion.
>>
>>
>>
>> --
>> John
>>
>

From mposolda at redhat.com  Mon Dec 12 03:05:55 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 12 Dec 2016 09:05:55 +0100
Subject: [keycloak-dev] Groups on SSSD Federation provider
In-Reply-To: <20161209152747.GA32092@abstractj.org>
References: <20161207160540.GB17975@abstractj.org>
	<508c6475-a9f5-8d82-740f-a1a89b99fdf4@redhat.com>
	<CAM5SUC4UWU=GuPU+89V5+KU8crL+2LyWDx5zXW0nYtTWq59J5Q@mail.gmail.com>
	<c1787b3e-6b4f-309b-90f3-ca8fb7dc48cb@redhat.com>
	<7db34cfb-9fdb-0bbe-7d47-e837fe2bc2fb@redhat.com>
	<fe4355fd-4973-8c30-0f2e-95965483be1a@redhat.com>
	<20161208154657.GA6574@abstractj.org>
	<6be91301-177c-f483-c7a8-895e8a87175a@redhat.com>
	<d9627007-415a-e757-ab51-575eecac588a@redhat.com>
	<9072ffc5-ead9-2577-5262-ceddbbe753e4@redhat.com>
	<20161209152747.GA32092@abstractj.org>
Message-ID: <ac113085-fc33-7ff6-e20a-0c0f9921767f@redhat.com>

On 09/12/16 16:27, Bruno Oliveira wrote:
> On 2016-12-09, Marek Posolda wrote:
>> On 08/12/16 18:55, Bill Burke wrote:
>>> This just sounds like a lot more work than necessary...I mean, how often
>>> are group names going to change?
>>>
>> No idea. Regarding LDAP, nobody complained about the usecase for changing
>> group name. So maybe not do anything for now?
>>
>> Just wanted to point that if we decide to do something, the single
>> federationLink is not sufficient as single Keycloak group can be mapped to
>> users from more different userStorages.
> The original reason behind it was the fact that's possible for admins to
> create inconsistencies between IPA and Keycloak. Just like mentioned
> before.
>
> But it seems like it's not a simple change and like Bill mentioned too
> much. If nobody ever complained, besides QE[1]. I can just update the
> docs mentioned that people should be careful when changing or removing
> groups for SSSD provider.
>
> [1] - https://issues.jboss.org/browse/KEYCLOAK-3904
+1

The changing group memberships for users (joinGroup, leaveGroup) can be 
handled easily by throwing the exception. Just the update of group 
itself is problematic, but LDAP doesn't handle this too ATM...

Marek
>
>> Marek
>>>
>>> On 12/8/16 11:14 AM, Marek Posolda wrote:
>>>> The issue is, that single group can have more links to userStorage,
>>>> not just the single one. That's because single group can be mapped
>>>> to users from more different userStorages.
>>>>
>>>> Example:
>>>> - I have 2 ldap userStorages (eg. ldap1, ldap2).
>>>> - I have group "mygroup" in Keycloak.
>>>> - I have user "ldap1-user" and I want him to join the group
>>>> "mygroup" . The group mapping will be saved in LDAP and the LDAP
>>>> user will be member of LDAP group like "cn=mygroup,dc=ldap1,dc=org"
>>>> - I have user "ldap2-user" and I want him to join the group
>>>> "mygroup" . The group mapping will be saved in LDAP and the LDAP
>>>> user will be member of LDAP group like "cn=mygroup,dc=ldap2,dc=org"
>>>>
>>>> Note that I need this same Keycloak group in both my LDAPs. In first
>>>> LDAP, the group is represented by DN "cn=mygroup,dc=ldap1,dc=org",
>>>> but in second LDAP it is represented by path
>>>> "cn=mygroup,dc=ldap2,dc=org" .
>>>>
>>>>
>>>> So the single properties federationLink+federationIdentifier is
>>>> definitely not sufficient. At least it will need to be a map of
>>>> federationLinks. But then you will need to have something additional
>>>> in the admin console UI to display those federationLinks.
>>>> Considering all of this, my vote is to rather stick with attributes.
>>>>
>>>> Marek
>>>>
>>>> On 08/12/16 16:46, Bruno Oliveira wrote:
>>>>>>> Should groups and roles instead have a federationLink (which points to
>>>>>>>>> the provider) and maybe also a federationIdentifier (which can contain
>>>>>>>>> things like LDAP UUID) as first class properties?  Then, you can search
>>>>>>>>> for roles and groups based on those properties so you can synchronize
>>>>>>>>> them.
>>>>> That would be fantastic.
>>>>>
>>>>
>>>>
> --
>
> abstractj
> PGP: 0x84DC9914



From dsbenghe at gmail.com  Mon Dec 12 06:28:01 2016
From: dsbenghe at gmail.com (Dumitru Sbenghe)
Date: Mon, 12 Dec 2016 22:28:01 +1100
Subject: [keycloak-dev] Rolling updates
Message-ID: <CAO9T6TJFqEU8sZL-bjGXGWT540rAcsHPnRjQxybJY8uz1cJFtw@mail.gmail.com>

Hi,

There is any plan to support blue/green deployments or rolling updates (or
any kind of deployment which requires two versions of keycloak to run on
top of the same data schema)? I did see a discussion around one year ago
about this - a comment that it was nice to have, but I could not find any
other mention.

Thanks,
Dumitru

From sthorger at redhat.com  Mon Dec 12 08:01:37 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 14:01:37 +0100
Subject: [keycloak-dev] Rolling updates
In-Reply-To: <CAO9T6TJFqEU8sZL-bjGXGWT540rAcsHPnRjQxybJY8uz1cJFtw@mail.gmail.com>
References: <CAO9T6TJFqEU8sZL-bjGXGWT540rAcsHPnRjQxybJY8uz1cJFtw@mail.gmail.com>
Message-ID: <CAJgngAcyzMsOrGuyxj2_vcbFrNecd698Hf0iQO2a53n3RQHodA@mail.gmail.com>

If we did introduce support for rolling updates we would most likely only
provide this for RH-SSO (the supported version of Keycloak) and not for
community releases.

On 12 December 2016 at 12:28, Dumitru Sbenghe <dsbenghe at gmail.com> wrote:

> Hi,
>
> There is any plan to support blue/green deployments or rolling updates (or
> any kind of deployment which requires two versions of keycloak to run on
> top of the same data schema)? I did see a discussion around one year ago
> about this - a comment that it was nice to have, but I could not find any
> other mention.
>
> Thanks,
> Dumitru
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Dec 12 08:06:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 14:06:19 +0100
Subject: [keycloak-dev] Validate Token on IDP
In-Reply-To: <D46744D9.3528%rlaghuvaram@contractor.lb.com>
References: <D4674191.3517%rlaghuvaram@contractor.lb.com>
	<D46744D9.3528%rlaghuvaram@contractor.lb.com>
Message-ID: <CAJgngAdQt9Q6A1Moj8EAKsis=A-Ywh-twooYy41RDZ_rJFCSNQ@mail.gmail.com>

Please use the user mailing list for general questions. This mailing list
is to discuss development of Keycloak only.

On 2 December 2016 at 21:34, Laghuvaram, Raghu <
RLaghuvaram at contractor.lb.com> wrote:

> I am trying to validate the token(Access Token) using the URL
> /auth/realms/<realm>/protocol/openid-connect/validate?access_token=<token>
> but I am getting 404 all the time. I am using 2.3.0 Final, is the token
> validate URL still valid?
>
>
> Thanks,
> Raghu.
>
>
> ________________________________
>
> Notice: This communication may contain privileged and/or confidential
> information. If you are not the intended recipient, please notify the
> sender by email, and immediately delete the message and any attachments
> without copying or disclosing them. LB may, for any reason, intercept,
> access, use, and disclose any information that is communicated by or
> through, or which is stored on, its networks, applications, services, and
> devices.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Dec 12 08:06:55 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 14:06:55 +0100
Subject: [keycloak-dev] Stateless using Java Servlet Filter Adapter
In-Reply-To: <D4674514.352B%rlaghuvaram@contractor.lb.com>
References: <D4674514.352B%rlaghuvaram@contractor.lb.com>
Message-ID: <CAJgngAfyVrsZWmzQJ_3Ovk-eqz7sz=rseQvwrWjkmqRa9YpDXA@mail.gmail.com>

Please use the user mailing list for general questions. This mailing list
is to discuss development of Keycloak only.

On 2 December 2016 at 21:36, Laghuvaram, Raghu <
RLaghuvaram at contractor.lb.com> wrote:

> Currently I am using Java Servlet Filter Adapter to make use of KeyCloak,
> I gave my secured pages url (/secured/*) for the filter KeycloakOIDCFilter
> and I am using tokenstore to use cookie so that stateless token store is
> achieved. But still I am not able to see any KEYCLOAK_ADAPTER_STATE cookie
> on my application cookies or on the keycloak(http://keycloakhost:
> keycloakport/auth/realms/{realmname}) cookies? I am using 2.3.0 Final. Is
> there anything I need to change to make my application use stateless token
> store?
>
> Thanks,
> Raghu
>
> ________________________________
>
> Notice: This communication may contain privileged and/or confidential
> information. If you are not the intended recipient, please notify the
> sender by email, and immediately delete the message and any attachments
> without copying or disclosing them. LB may, for any reason, intercept,
> access, use, and disclose any information that is communicated by or
> through, or which is stored on, its networks, applications, services, and
> devices.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Dec 12 08:14:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 14:14:41 +0100
Subject: [keycloak-dev] Disable Keycloak 'User Federation' menu item in
 Keycloak Administrator.
In-Reply-To: <3DE4BF1BF8EDD84B8F8D61B0A88BD563117077@EXCH01.gandlake.local>
References: <3DE4BF1BF8EDD84B8F8D61B0A88BD563117077@EXCH01.gandlake.local>
Message-ID: <CAJgngAd97U=rkY+vX+WKP=sVLoFpY2wv5rLEp=8Gsh3mtJwChA@mail.gmail.com>

Please use the user mailing list for general questions. This mailing list
is to discuss development of Keycloak only.

On 5 December 2016 at 14:41, Stephen Merchant <Stephen.Merchant at gandlake.com
> wrote:

> Hello,
> Is there a legitimate method of removing the 'User Federation' menu item,
> and/or the 'Configure' menu section from the Keycloak Administrator web
> application?
>
> For some types of users we would like these Keycloak admin menu options to
> be hidden.
>
> Any help appreciated.
> Thanks.
>
> Stephen Merchant
> Developer
> Gandlake Limited
>
> Crown Commercial Service Supplier
> BSI ISO/IEC 27001 certification number IS 585161
>
>
> Gandlake Limited, a Limited Liability Company registered in England and
> Wales under number 4667925. Registered Office: Gandlake House, London Road,
> Newbury, Berkshire. RG14 1LA. VAT Registration Number 809 7164 11
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Dec 12 08:19:54 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 14:19:54 +0100
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <02013474-2c60-764e-577a-548bbb56955f@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
	<9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
	<a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>
	<f8f07309-8a7a-099f-2408-e884f582acbd@redhat.com>
	<f5f1f95f-ba90-3f8b-d6c3-cfca1634697d@redhat.com>
	<02013474-2c60-764e-577a-548bbb56955f@redhat.com>
Message-ID: <CAJgngAfbuxFJYHMPMZVGhVY29fExgPTJ1X6vN7hsgM058A6ekg@mail.gmail.com>

Let's put this on hold for after 7.1 GA and make it a priority after that.

We are going to use Arquillian bases tests and removing the old tests as
they have less value from a QE perspective. This has been discussed many
times now and we have agreed that this will be done a long time ago so
please let's not reiterate this discussion again and again. If dev and QE
are going to collaborate on the tests we need to share the approach and QE
has to have full functional tests.

We need to resolve this issue though so we can get access to the
KeycloakSession from within certain tests. Ability to run adapter tests
from within the IDE is also a nice to have, but that may be harder to
achieve (and the effort may not be worth it, at least not for all adapters).

On 9 December 2016 at 08:51, Marek Posolda <mposolda at redhat.com> wrote:

> Ahoj Vlasto,
>
> On 09/12/16 08:28, Vlasta Ramik wrote:
> >
> > Ahoj Marku,
> >
> >
> > On 12/08/2016 05:50 PM, Marek Posolda wrote:
> >> IMO ideal is, if we can have both possibilities. Test with embedded
> >> container during development, but also has possibility to run the same
> >> test against external container in different JVM. Arquillian testsuite
> >> can support both approaches, but the old testsuite doesn't support the
> >> external...
> >>
> >> I agree some tests shouldn't use REST endpoints. Like the model tests
> >> from the old testsuite. But they still need to be able to run on
> >> external environment though. I guess we can have something like the
> >> "bridge" test, which will just deploy the model test to the REST
> >> endpoint and you will be able to test things inside this REST endpoint
> >> on server side? So you will be able to use all the stuff like model
> >> classes etc.
> > There is https://issues.jboss.org/browse/KEYCLOAK-3729 it seems to me
> > that your proposal with "bridge" test could resolve this. It would be
> > great to have a meeting to discuss details or if you will have time to
> > make PoC. I'd love to take a look at it.
> ah, so you already tried different approach with the expose
> KeycloakSessionFactory to JNDI and remote lookup it from tests. This
> seems much easier then my approach based on deploying test on REST
> endpoint. But for the JNDI, I have no clue about the things like
> serialization etc. Maybe there is some easy solution to it, but I don't
> know ATM... I am sure that approach based on REST endpoints will work,
> but it's more work.
>
> +1 for the meeting. Maybe next week or after Christmas? I personally
> won't have time to do any PoC or something around this before Christmas :(
>
> Marek
> >> Marek
> >>
> >> On 08/12/16 17:47, Marek Posolda wrote:
> >>> Arquillian can support that. All we need is just different
> >>> implementations of arquillian DeployableContainer interface to
> >>> represent various containers. I've managed to have adapter tests
> >>> already running on embedded undertow and everything is running in
> >>> single JVM. Development and debugging is fine with that.
> >>>
> >>> Having the test+server+adapter in single JVM just rocks during
> >>> development. Problem is, that it won't handle all type of errors. For
> >>> example if Jetty adapter ZIP distribution is broken (eg. some JAR file
> >>> is missing in it), the Jetty adapter tests, which uses embedded Jetty
> >>> won't catch that. For those reasons, also QA team needs to test with
> >>> "real" containers, not with the embedded ones.
> >>>
> >>>
> >>>
> >>> On 08/12/16 15:05, Bill Burke wrote:
> >>>> On 12/8/16 6:48 AM, Marek Posolda wrote:
> >>>>> They are not included in the script running travis
> >>>>> https://github.com/keycloak/keycloak/blob/master/travis-
> run-tests.sh#L4
> >>>>>
> >>>>> It seems wee should add them here.
> >>>>>
> >>>>>  From the long run, it will be better to remove them (as they rely on
> >>>>> the old testsuite) and rather have them running on the
> >>>>> integration-arquillian testsuite. I know it sucks during development
> >>>>> that Jetty itself doesn't run in same JVM like the test (debugging
> >>>>> etc). But I hope we can have the solution, which will allow to
> >>>>> choose whether Jetty (or hopefully some other servers) are running
> >>>>> in same JVM or different JVM.
> >>>>>
> >>>> Unless arquillian can support running these adapter tests within an
> >>>> IDE, they need to stay.
> >>> Arquillian can support that. All we need is just different
> >>> implementations of arquillian DeployableContainer interface to
> >>> represent various containers. I've managed to have adapter tests
> >>> already running on embedded undertow and everything is running in
> >>> single JVM. Development and debugging is fine with that.
> >>>> In general, More often than not, I don't like the arquillian style
> >>>> we've enforced because it takes a lot longer to write tests, is often
> >>>> nearly impossible to do everything through a REST interface, and is
> >>>> often really hard to debug.  Maybe its just the types of things I'm
> >>>> testing.  Some of the tests should not have been ported to
> >>>> arquillian, or, at least shouldn't have been ported to using a REST
> >>>> interface for the entire test.
> >>> Yeah, having the test+server+adapter in single JVM just rocks during
> >>> development. Problem is, that it won't handle all type of errors. For
> >>> example if Jetty adapter ZIP distribution is broken (eg. some JAR file
> >>> is missing), the Jetty adapter tests, which uses embedded Jetty, won't
> >>> catch that. For those and similar reasons, also QA team needs to test
> >>> with "real" containers, not with the embedded ones.
> >>>
> >>> IMO ideal is, if we can have both possibilities. Test with embedded
> >>> container during development, but also has possibility to run the same
> >>> test against external container in different JVM. Arquillian testsuite
> >>> can support both approaches, but the old testsuite doesn't support the
> >>> external...
> >>>
> >>> I agree some tests shouldn't use REST endpoints. Like the model tests
> >>> from the old testsuite. But they still need to be able to run on
> >>> external environment though. I guess we can have something like the
> >>> "bridge" test, which will just deploy the model test to the REST
> >>> endpoint and you will be able to test things inside this REST endpoint
> >>> on server side? So you will be able to use all the stuff like model
> >>> classes etc.
> >>>
> >>> Marek
> >>>> Bill
> >> _______________________________________________
> >> 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 sthorger at redhat.com  Mon Dec 12 08:24:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 14:24:49 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
Message-ID: <CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>

Let's review the tests ran by Travis after the new year, but with Travis
having the option to run groups of tests in parallel we should be able to
tests more including adapters and console. Travis should also be changed to
tests with the full KC server and WildFly for adapters rather than embedded
Undertow.

On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com> wrote:

> These broke because they weren't part of the main build.  I thought they
> were just dead code because when I did a "Find Usages" for them, nothing
> came up.  Minimally, things should at least be compiled with the main
> build, that way when refactorings happen, somebody doesn't delete a test
> dependency by accident.
>
>
> On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
> > Speaking of the tests, we seem not to run any of the adapter test
> > suites. I believe that running at least adapter tests for wildfly
> > would be beneficial, preventing e.g. [1]. WDYT?
> >
> > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
> >
> > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda <mposolda at redhat.com
> > <mailto:mposolda at redhat.com>> wrote:
> >
> >     Fyi. On Friday afternoon, I've found the issue that travis didn't run
> >     all the tests from the testsuite. And PartialImportTest was the one,
> >     which wasn't executed. See
> >     https://issues.jboss.org/browse/KEYCLOAK-4021
> >     <https://issues.jboss.org/browse/KEYCLOAK-4021>
> >
> >     However with the travis fix, all the tests were passing (including
> >     PartialImportTest). So it seems this test was just failing
> >     randomly (not
> >     always)?
> >
> >     Now I can see in latest travis build that PartialImportTest passes.
> >
> >     Marek
> >
> >
> >
> >
> >     On 03/12/16 17:36, Bill Burke wrote:
> >     > I just noticed that my local build fails while travis passes.
> >     The bug is
> >     > really something travis should have picked up, specifically the
> >     > PartialImportsTest was removing an identity provider.  The JPA
> >     > removeIdenittyProviderByAlias method was wrong as it was trying
> >     to load
> >     > an IdentityProviderModel after it was removed thus resulting in a
> >     > Hibernate error.  Travis did not pick this up which makes me
> >     wonder if
> >     > the test is even running.
> >     >
> >     > FYI, i have a pull request that fixes this that is incoming. The
> >     bug,
> >     > not travis.
> >     >
> >     > Bill
> >     >
> >     >
> >     > _______________________________________________
> >     > 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>
> >
> >
> >     _______________________________________________
> >     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>
> >
> >
> >
> >
> > --
> >
> > --Hynek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Dec 12 08:26:32 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 14:26:32 +0100
Subject: [keycloak-dev] alternative subflow only sort of work
In-Reply-To: <a4128efd-7634-15fa-0cd9-82c7bd1e0ca4@redhat.com>
References: <a4128efd-7634-15fa-0cd9-82c7bd1e0ca4@redhat.com>
Message-ID: <CAJgngAdGw_bdO83CetDAm3qsNY5y_zkkk_u+LvDmBEb62zYV3w@mail.gmail.com>

Reminder :)

On 11 December 2016 at 05:31, Bill Burke <bburke at redhat.com> wrote:

> In fixing a recent bug, I noticed that alternative subflows don't really
> work as advertised.  If a previous alternative was successful, then an
> alternative subflow will not execute.  I think that's really the only
> thing that works.  If for example, you added another alterantive subflow
> after the alternative subflow for username/password, some weird results
> might happen.  Like I don't think the username/password screen would
> even pop up in this scenario.  I need to check.  Remind me to log a bug
> on this. Going to bed now...
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Dec 12 08:28:32 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 14:28:32 +0100
Subject: [keycloak-dev] Passing login_hint up to IdP when using
	kc_idp_hint
In-Reply-To: <CALrL_LmOb2r36JhBH09M2=+hJ9ikn0vhK-7=BgcJTJt6nOYKrA@mail.gmail.com>
References: <CALrL_LnS0wB3iKTy6BRUKF5=naDo=sg2eeG6qt3P6gyB5khW1Q@mail.gmail.com>
	<47b35f69-fee4-fe25-cfee-5a4ba661019e@redhat.com>
	<CALrL_LmOb2r36JhBH09M2=+hJ9ikn0vhK-7=BgcJTJt6nOYKrA@mail.gmail.com>
Message-ID: <CAJgngAc3gj9P8e5TJpGGBDQQfnTMEh6kR8URS_g6mmH-gGL6rw@mail.gmail.com>

If you use login_hint + add an option to an IdP "pass login_hint", and also
remember to write some tests for it, we'd gladly accept it.

On 8 December 2016 at 15:37, Peter Chamberlin <
peter.chamberlin at digital.cabinet-office.gov.uk> wrote:

> Hi Marek,
>
> Thank you for your response. That's kind of what we thought.
>
> Would this be something that might be accepted into the core of Keycloak if
> we developed it as a configurable option?
>
> All the best,
>
> Peter
>
>
> On 8 December 2016 at 12:21, Marek Posolda <mposolda at redhat.com> wrote:
>
> > It doesn't seem it is possible ATM. The possibility is, that you create
> > your own implementation of identityProvider and you override method :
> >
> > createAuthorizationUrl(AuthenticationRequest request)
> >
> > The parameters of the original request, which was sent from your
> application to Keycloak, are available from the clientSession notes (which
> itself is available on the AuthenticationRequest).
> >
> > Marek
> >
> >
> > On 07/12/16 19:06, Peter Chamberlin wrote:
> >
> > Hi Keycloak team,
> >
> > I'm working on a system which uses Keycloak as a broker to both OIDC and
> > SAML2.0 IdPs. We are using `kc_idp_hint` for every request and Keycloak
> is
> > never exposed to the user. The system uses OIDC to connect to Keycloak.
> >
> > We would like to pass a `login_hint` or `subject` upstream to  IdPs
> > (depending if it's OIDC or SAML) as we expect to know the user's IdP user
> > name, but this does not work out of the box. I can't see anything in the
> > documentation that would enable it.
> >
> > Is it possible? If so how?
> >
> > Many thanks for any help or pointers you can give.
> >
> > Peter Chamberlin
> > _______________________________________________
> > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://
> 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 corinnekrych at gmail.com  Mon Dec 12 09:00:58 2016
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 12 Dec 2016 15:00:58 +0100
Subject: [keycloak-dev] SAML and nodejs adapter
Message-ID: <CAL8vO=ewAjfcz7XDw7rRpLGSNjn2CPkaD+P3+mOiTarup5oRmQ@mail.gmail.com>

Hello Bruno, Sebi & KC team,

I'd like to know how I could configure Keycloak to be a SAML 2.0 provider
on a nodejs environment.
Looking in the demo folder, I can see a Wildfly java based example [1]
using keycloak-saml.xml [2]
I couldn't find a nodejs adapter in the gitbook [3].
how could I do similar demo but with a nodejs app?

++
Corinne
[1] https://github.com/keycloak/keycloak/tree/master/examples/saml
[2]
https://github.com/keycloak/keycloak/blob/master/examples/saml/post-with-signature/src/main/webapp/WEB-INF/keycloak-saml.xml

[3]
https://keycloak.gitbooks.io/securing-client-applications-guide/content/topics/saml/saml-overview.html

From bburke at redhat.com  Mon Dec 12 10:22:56 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Dec 2016 10:22:56 -0500
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <CAJgngAfbuxFJYHMPMZVGhVY29fExgPTJ1X6vN7hsgM058A6ekg@mail.gmail.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
	<9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
	<a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>
	<f8f07309-8a7a-099f-2408-e884f582acbd@redhat.com>
	<f5f1f95f-ba90-3f8b-d6c3-cfca1634697d@redhat.com>
	<02013474-2c60-764e-577a-548bbb56955f@redhat.com>
	<CAJgngAfbuxFJYHMPMZVGhVY29fExgPTJ1X6vN7hsgM058A6ekg@mail.gmail.com>
Message-ID: <f237437f-5ca9-2cc9-3487-38846dd4b870@redhat.com>



On 12/12/16 8:19 AM, Stian Thorgersen wrote:
> Let's put this on hold for after 7.1 GA and make it a priority after that.
We can't have tomcat and jetty adapters failing and regressions 
happening.  There's a lot of people that depend on them.  Our customer 
base comes from a successful community project.  You don't start 
undercutting community just because its not supported in product.  I'm 
adding them back to the build because its the right thing to do.  I 
shouldn't have even asked and just did it, but I just found it quite 
annoying that they were removed as I knew they were removed on purpose.

> We are going to use Arquillian bases tests and removing the old tests as
> they have less value from a QE perspective.
Negative.  You are just 100% wrong on this.  I've said this over and 
over and you just don't listen and its getting really annoying. There 
are many tests which it doesn't matter if they run in the container or 
not.  Many tests it is not possible to even run as its impossible to set 
up the conditions you want to happen.  Many tests are functional SPI 
tests and it doesn't matter at all if they run inside the app server or 
not and its much easier to setup and debug.


> This has been discussed many
> times now and we have agreed that this will be done a long time ago so
> please let's not reiterate this discussion again and again. If dev and QE
> are going to collaborate on the tests we need to share the approach and QE
> has to have full functional tests.
Discussed many times and I never agreed to anything.  And kept telling 
you over and over that this mandate is uneccessary, hurtful to 
development, and is a lot of wasted effort, but you don't want to listen.

> We need to resolve this issue though so we can get access to the
> KeycloakSession from within certain tests. Ability to run adapter tests
> from within the IDE is also a nice to have, but that may be harder to
> achieve (and the effort may not be worth it, at least not for all adapters).
There's a difference between unit tests, functional tests, and 
integration tests that you are missing.  Everything is not an 
integration test.  Its  unacceptable for adapter tests to not be able to 
run in the IDE.  If you want to have additional non-IDE runnable 
integration tests, that is fine, but to be able to develop new features 
and debug most problems, running in the IDE is a must and you're just 
being stubborn to state otherwise.  Its quite annoying.

Bill

From sthorger at redhat.com  Mon Dec 12 11:31:31 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 17:31:31 +0100
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <f237437f-5ca9-2cc9-3487-38846dd4b870@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
	<9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
	<a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>
	<f8f07309-8a7a-099f-2408-e884f582acbd@redhat.com>
	<f5f1f95f-ba90-3f8b-d6c3-cfca1634697d@redhat.com>
	<02013474-2c60-764e-577a-548bbb56955f@redhat.com>
	<CAJgngAfbuxFJYHMPMZVGhVY29fExgPTJ1X6vN7hsgM058A6ekg@mail.gmail.com>
	<f237437f-5ca9-2cc9-3487-38846dd4b870@redhat.com>
Message-ID: <CAJgngAcK9qm9T+7NmZc4U9iriByN9GR4GXQzo7Q=uJzHDxJpUQ@mail.gmail.com>

On 12 December 2016 at 16:22, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 12/12/16 8:19 AM, Stian Thorgersen wrote:
> > Let's put this on hold for after 7.1 GA and make it a priority after
> that.
> We can't have tomcat and jetty adapters failing and regressions
> happening.  There's a lot of people that depend on them.  Our customer
> base comes from a successful community project.  You don't start
> undercutting community just because its not supported in product.  I'm
> adding them back to the build because its the right thing to do.  I
> shouldn't have even asked and just did it, but I just found it quite
> annoying that they were removed as I knew they were removed on purpose.
>

You completely miss understood me. No one removed them on purpose. AFAIK
these tests have never actually ran on Travis.

No one has ever said that we are undercutting the community and that Tomcat
and Jetty is not still important. I've got absolutely no clue why you think
anyone has suggested that?!


>
> > We are going to use Arquillian bases tests and removing the old tests as
> > they have less value from a QE perspective.
> Negative.  You are just 100% wrong on this.  I've said this over and
> over and you just don't listen and its getting really annoying. There
> are many tests which it doesn't matter if they run in the container or
> not.  Many tests it is not possible to even run as its impossible to set
> up the conditions you want to happen.  Many tests are functional SPI
> tests and it doesn't matter at all if they run inside the app server or
> not and its much easier to setup and debug


All tests matter if they run in the container! Bad imports, wrong module
definitons and bad/different versions of dependencies can all cause tests
to pass in the embedded/fake container while not working properly when
running within WildFly/EAP.

All tests that rely on the DB layer also needs to test different DB
vendors! Setting up and configuring CI is already complicated for the real
containers and that effort would have to be duplicated for a fake
environment as datasources are not available.


> .
>
>
> > This has been discussed many
> > times now and we have agreed that this will be done a long time ago so
> > please let's not reiterate this discussion again and again. If dev and QE
> > are going to collaborate on the tests we need to share the approach and
> QE
> > has to have full functional tests.
> Discussed many times and I never agreed to anything.  And kept telling
> you over and over that this mandate is uneccessary, hurtful to
> development, and is a lot of wasted effort, but you don't want to listen.
>

See above


>
> > We need to resolve this issue though so we can get access to the
> > KeycloakSession from within certain tests. Ability to run adapter tests
> > from within the IDE is also a nice to have, but that may be harder to
> > achieve (and the effort may not be worth it, at least not for all
> adapters).
> There's a difference between unit tests, functional tests, and
> integration tests that you are missing.  Everything is not an
> integration test.  Its  unacceptable for adapter tests to not be able to
> run in the IDE.  If you want to have additional non-IDE runnable
> integration tests, that is fine, but to be able to develop new features
> and debug most problems, running in the IDE is a must and you're just
> being stubborn to state otherwise.  Its quite annoying.
>

 I agree that adapter tests should run within the IDE, but I disagree with
the approach you are suggesting. Adapter tests are even more important to
have a real environment IMO.


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

From sthorger at redhat.com  Mon Dec 12 11:37:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 17:37:56 +0100
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <CAJgngAcK9qm9T+7NmZc4U9iriByN9GR4GXQzo7Q=uJzHDxJpUQ@mail.gmail.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
	<9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
	<a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>
	<f8f07309-8a7a-099f-2408-e884f582acbd@redhat.com>
	<f5f1f95f-ba90-3f8b-d6c3-cfca1634697d@redhat.com>
	<02013474-2c60-764e-577a-548bbb56955f@redhat.com>
	<CAJgngAfbuxFJYHMPMZVGhVY29fExgPTJ1X6vN7hsgM058A6ekg@mail.gmail.com>
	<f237437f-5ca9-2cc9-3487-38846dd4b870@redhat.com>
	<CAJgngAcK9qm9T+7NmZc4U9iriByN9GR4GXQzo7Q=uJzHDxJpUQ@mail.gmail.com>
Message-ID: <CAJgngAfXRGs1KZE1rBbFNdYJbsODrTTtWS_05rZ=FNV67DYBgQ@mail.gmail.com>

To add - I've said many many times that we need to be able to get the same
access to the server as we have from the old testsuite and get direct
access to KeycloakSession from within tests. So your argument about tests
not being possi8ble to run is bs.

On 12 December 2016 at 17:31, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On 12 December 2016 at 16:22, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 12/12/16 8:19 AM, Stian Thorgersen wrote:
>> > Let's put this on hold for after 7.1 GA and make it a priority after
>> that.
>> We can't have tomcat and jetty adapters failing and regressions
>> happening.  There's a lot of people that depend on them.  Our customer
>> base comes from a successful community project.  You don't start
>> undercutting community just because its not supported in product.  I'm
>> adding them back to the build because its the right thing to do.  I
>> shouldn't have even asked and just did it, but I just found it quite
>> annoying that they were removed as I knew they were removed on purpose.
>>
>
> You completely miss understood me. No one removed them on purpose. AFAIK
> these tests have never actually ran on Travis.
>
> No one has ever said that we are undercutting the community and that
> Tomcat and Jetty is not still important. I've got absolutely no clue why
> you think anyone has suggested that?!
>
>
>>
>> > We are going to use Arquillian bases tests and removing the old tests as
>> > they have less value from a QE perspective.
>> Negative.  You are just 100% wrong on this.  I've said this over and
>> over and you just don't listen and its getting really annoying. There
>> are many tests which it doesn't matter if they run in the container or
>> not.  Many tests it is not possible to even run as its impossible to set
>> up the conditions you want to happen.  Many tests are functional SPI
>> tests and it doesn't matter at all if they run inside the app server or
>> not and its much easier to setup and debug
>
>
> All tests matter if they run in the container! Bad imports, wrong module
> definitons and bad/different versions of dependencies can all cause tests
> to pass in the embedded/fake container while not working properly when
> running within WildFly/EAP.
>
> All tests that rely on the DB layer also needs to test different DB
> vendors! Setting up and configuring CI is already complicated for the real
> containers and that effort would have to be duplicated for a fake
> environment as datasources are not available.
>
>
>> .
>>
>>
>> > This has been discussed many
>> > times now and we have agreed that this will be done a long time ago so
>> > please let's not reiterate this discussion again and again. If dev and
>> QE
>> > are going to collaborate on the tests we need to share the approach and
>> QE
>> > has to have full functional tests.
>> Discussed many times and I never agreed to anything.  And kept telling
>> you over and over that this mandate is uneccessary, hurtful to
>> development, and is a lot of wasted effort, but you don't want to listen.
>>
>
> See above
>
>
>>
>> > We need to resolve this issue though so we can get access to the
>> > KeycloakSession from within certain tests. Ability to run adapter tests
>> > from within the IDE is also a nice to have, but that may be harder to
>> > achieve (and the effort may not be worth it, at least not for all
>> adapters).
>> There's a difference between unit tests, functional tests, and
>> integration tests that you are missing.  Everything is not an
>> integration test.  Its  unacceptable for adapter tests to not be able to
>> run in the IDE.  If you want to have additional non-IDE runnable
>> integration tests, that is fine, but to be able to develop new features
>> and debug most problems, running in the IDE is a must and you're just
>> being stubborn to state otherwise.  Its quite annoying.
>>
>
>  I agree that adapter tests should run within the IDE, but I disagree
> with the approach you are suggesting. Adapter tests are even more important
> to have a real environment IMO.
>
>
>>
>> Bill
>> _______________________________________________
>> 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 12 11:46:07 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Dec 2016 11:46:07 -0500
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
	<CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
Message-ID: <d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>

This wasn't just the adapter tests, initially it was the 
PartialImportsTest which lives under org.keycloak.testsuite.admin 
somewhere and should have run and should have failed.

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

On 12/12/16 8:24 AM, Stian Thorgersen wrote:
> Let's review the tests ran by Travis after the new year, but with 
> Travis having the option to run groups of tests in parallel we should 
> be able to tests more including adapters and console. Travis should 
> also be changed to tests with the full KC server and WildFly for 
> adapters rather than embedded Undertow.
>
> On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     These broke because they weren't part of the main build.  I
>     thought they
>     were just dead code because when I did a "Find Usages" for them,
>     nothing
>     came up.  Minimally, things should at least be compiled with the main
>     build, that way when refactorings happen, somebody doesn't delete
>     a test
>     dependency by accident.
>
>
>     On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
>     > Speaking of the tests, we seem not to run any of the adapter test
>     > suites. I believe that running at least adapter tests for wildfly
>     > would be beneficial, preventing e.g. [1]. WDYT?
>     >
>     > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>     <https://issues.jboss.org/browse/KEYCLOAK-4017>
>     >
>     > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda
>     <mposolda at redhat.com <mailto:mposolda at redhat.com>
>     > <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>> wrote:
>     >
>     >     Fyi. On Friday afternoon, I've found the issue that travis
>     didn't run
>     >     all the tests from the testsuite. And PartialImportTest was
>     the one,
>     >     which wasn't executed. See
>     > https://issues.jboss.org/browse/KEYCLOAK-4021
>     <https://issues.jboss.org/browse/KEYCLOAK-4021>
>     >     <https://issues.jboss.org/browse/KEYCLOAK-4021
>     <https://issues.jboss.org/browse/KEYCLOAK-4021>>
>     >
>     >     However with the travis fix, all the tests were passing
>     (including
>     >     PartialImportTest). So it seems this test was just failing
>     >     randomly (not
>     >     always)?
>     >
>     >     Now I can see in latest travis build that PartialImportTest
>     passes.
>     >
>     >     Marek
>     >
>     >
>     >
>     >
>     >     On 03/12/16 17:36, Bill Burke wrote:
>     >     > I just noticed that my local build fails while travis passes.
>     >     The bug is
>     >     > really something travis should have picked up,
>     specifically the
>     >     > PartialImportsTest was removing an identity provider.  The JPA
>     >     > removeIdenittyProviderByAlias method was wrong as it was
>     trying
>     >     to load
>     >     > an IdentityProviderModel after it was removed thus
>     resulting in a
>     >     > Hibernate error.  Travis did not pick this up which makes me
>     >     wonder if
>     >     > the test is even running.
>     >     >
>     >     > FYI, i have a pull request that fixes this that is
>     incoming. The
>     >     bug,
>     >     > not travis.
>     >     >
>     >     > Bill
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > keycloak-dev mailing list
>     >     > keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     <mailto: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>
>     >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>     >
>     >
>     >     _______________________________________________
>     >     keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     <mailto: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>
>     >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>     >
>     >
>     >
>     >
>     > --
>     >
>     > --Hynek
>
>     _______________________________________________
>     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>
>
>


From sthorger at redhat.com  Mon Dec 12 11:51:23 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 17:51:23 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
	<CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
	<d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>
Message-ID: <CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>

It should run at least what it used to run before I broke it up into
multiple parallell jobs (seems I did a poor job when I did that and messed
some stuff up). That can be fixed straight away, but adding more tests (new
adapter tests, clustering tests, console tests, etc.) we should probably
review later as it may impact stability and time to test a PR on Travis.

On 12 December 2016 at 17:46, Bill Burke <bburke at redhat.com> wrote:

> This wasn't just the adapter tests, initially it was the
> PartialImportsTest which lives under org.keycloak.testsuite.admin somewhere
> and should have run and should have failed.
>
> https://issues.jboss.org/browse/KEYCLOAK-4068
>
>
> On 12/12/16 8:24 AM, Stian Thorgersen wrote:
>
> Let's review the tests ran by Travis after the new year, but with Travis
> having the option to run groups of tests in parallel we should be able to
> tests more including adapters and console. Travis should also be changed to
> tests with the full KC server and WildFly for adapters rather than embedded
> Undertow.
>
> On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com> wrote:
>
>> These broke because they weren't part of the main build.  I thought they
>> were just dead code because when I did a "Find Usages" for them, nothing
>> came up.  Minimally, things should at least be compiled with the main
>> build, that way when refactorings happen, somebody doesn't delete a test
>> dependency by accident.
>>
>>
>> On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
>> > Speaking of the tests, we seem not to run any of the adapter test
>> > suites. I believe that running at least adapter tests for wildfly
>> > would be beneficial, preventing e.g. [1]. WDYT?
>> >
>> > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>> >
>> > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda <mposolda at redhat.com
>> > <mailto:mposolda at redhat.com>> wrote:
>> >
>> >     Fyi. On Friday afternoon, I've found the issue that travis didn't
>> run
>> >     all the tests from the testsuite. And PartialImportTest was the one,
>> >     which wasn't executed. See
>> >     https://issues.jboss.org/browse/KEYCLOAK-4021
>> >     <https://issues.jboss.org/browse/KEYCLOAK-4021>
>> >
>> >     However with the travis fix, all the tests were passing (including
>> >     PartialImportTest). So it seems this test was just failing
>> >     randomly (not
>> >     always)?
>> >
>> >     Now I can see in latest travis build that PartialImportTest passes.
>> >
>> >     Marek
>> >
>> >
>> >
>> >
>> >     On 03/12/16 17:36, Bill Burke wrote:
>> >     > I just noticed that my local build fails while travis passes.
>> >     The bug is
>> >     > really something travis should have picked up, specifically the
>> >     > PartialImportsTest was removing an identity provider.  The JPA
>> >     > removeIdenittyProviderByAlias method was wrong as it was trying
>> >     to load
>> >     > an IdentityProviderModel after it was removed thus resulting in a
>> >     > Hibernate error.  Travis did not pick this up which makes me
>> >     wonder if
>> >     > the test is even running.
>> >     >
>> >     > FYI, i have a pull request that fixes this that is incoming. The
>> >     bug,
>> >     > not travis.
>> >     >
>> >     > Bill
>> >     >
>> >     >
>> >     > _______________________________________________
>> >     > 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>
>> >
>> >
>> >     _______________________________________________
>> >     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>
>> >
>> >
>> >
>> >
>> > --
>> >
>> > --Hynek
>>
>> _______________________________________________
>> 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 12 11:54:05 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Dec 2016 11:54:05 -0500
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
	<CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
	<d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>
	<CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>
Message-ID: <6e2e7261-b1e3-39ce-8879-d692ca9c04e8@redhat.com>

The filter you have looks like the test should have run which is why the 
review needs to happen.

On 12/12/16 11:51 AM, Stian Thorgersen wrote:
> It should run at least what it used to run before I broke it up into 
> multiple parallell jobs (seems I did a poor job when I did that and 
> messed some stuff up). That can be fixed straight away, but adding 
> more tests (new adapter tests, clustering tests, console tests, etc.) 
> we should probably review later as it may impact stability and time to 
> test a PR on Travis.
>
> On 12 December 2016 at 17:46, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     This wasn't just the adapter tests, initially it was the
>     PartialImportsTest which lives under org.keycloak.testsuite.admin
>     somewhere and should have run and should have failed.
>
>     https://issues.jboss.org/browse/KEYCLOAK-4068
>     <https://issues.jboss.org/browse/KEYCLOAK-4068>
>
>
>     On 12/12/16 8:24 AM, Stian Thorgersen wrote:
>>     Let's review the tests ran by Travis after the new year, but with
>>     Travis having the option to run groups of tests in parallel we
>>     should be able to tests more including adapters and console.
>>     Travis should also be changed to tests with the full KC server
>>     and WildFly for adapters rather than embedded Undertow.
>>
>>     On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         These broke because they weren't part of the main build.  I
>>         thought they
>>         were just dead code because when I did a "Find Usages" for
>>         them, nothing
>>         came up.  Minimally, things should at least be compiled with
>>         the main
>>         build, that way when refactorings happen, somebody doesn't
>>         delete a test
>>         dependency by accident.
>>
>>
>>         On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
>>         > Speaking of the tests, we seem not to run any of the
>>         adapter test
>>         > suites. I believe that running at least adapter tests for
>>         wildfly
>>         > would be beneficial, preventing e.g. [1]. WDYT?
>>         >
>>         > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>>         <https://issues.jboss.org/browse/KEYCLOAK-4017>
>>         >
>>         > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>
>>         > <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>>
>>         wrote:
>>         >
>>         >     Fyi. On Friday afternoon, I've found the issue that
>>         travis didn't run
>>         >     all the tests from the testsuite. And PartialImportTest
>>         was the one,
>>         >     which wasn't executed. See
>>         > https://issues.jboss.org/browse/KEYCLOAK-4021
>>         <https://issues.jboss.org/browse/KEYCLOAK-4021>
>>         >     <https://issues.jboss.org/browse/KEYCLOAK-4021
>>         <https://issues.jboss.org/browse/KEYCLOAK-4021>>
>>         >
>>         >     However with the travis fix, all the tests were passing
>>         (including
>>         >     PartialImportTest). So it seems this test was just failing
>>         >     randomly (not
>>         >     always)?
>>         >
>>         >     Now I can see in latest travis build that
>>         PartialImportTest passes.
>>         >
>>         >     Marek
>>         >
>>         >
>>         >
>>         >
>>         >     On 03/12/16 17:36, Bill Burke wrote:
>>         >     > I just noticed that my local build fails while travis
>>         passes.
>>         >     The bug is
>>         >     > really something travis should have picked up,
>>         specifically the
>>         >     > PartialImportsTest was removing an identity
>>         provider.  The JPA
>>         >     > removeIdenittyProviderByAlias method was wrong as it
>>         was trying
>>         >     to load
>>         >     > an IdentityProviderModel after it was removed thus
>>         resulting in a
>>         >     > Hibernate error.  Travis did not pick this up which
>>         makes me
>>         >     wonder if
>>         >     > the test is even running.
>>         >     >
>>         >     > FYI, i have a pull request that fixes this that is
>>         incoming. The
>>         >     bug,
>>         >     > not travis.
>>         >     >
>>         >     > Bill
>>         >     >
>>         >     >
>>         >     > _______________________________________________
>>         >     > keycloak-dev mailing list
>>         >     > keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         <mailto: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>
>>         >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>         >
>>         >
>>         >     _______________________________________________
>>         >     keycloak-dev mailing list
>>         > keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         <mailto: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>
>>         >  <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>         >
>>         >
>>         >
>>         >
>>         > --
>>         >
>>         > --Hynek
>>
>>         _______________________________________________
>>         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>
>>
>>
>
>


From sthorger at redhat.com  Mon Dec 12 11:56:46 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Dec 2016 17:56:46 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <6e2e7261-b1e3-39ce-8879-d692ca9c04e8@redhat.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
	<CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
	<d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>
	<CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>
	<6e2e7261-b1e3-39ce-8879-d692ca9c04e8@redhat.com>
Message-ID: <CAJgngAfp0FDoxWb6q7urM2Xpi7+wep7j2d1Q6a7hLHxBsqkpfQ@mail.gmail.com>

There was an issue before that the script didn't return the exit code so it
would look like it passed even though the tests failed. That's fixed though:
https://github.com/keycloak/keycloak/commit/a52f7f9baa5972fb606714d0f370fbbd3549fdcb

On 12 December 2016 at 17:54, Bill Burke <bburke at redhat.com> wrote:

> The filter you have looks like the test should have run which is why the
> review needs to happen.
> On 12/12/16 11:51 AM, Stian Thorgersen wrote:
>
> It should run at least what it used to run before I broke it up into
> multiple parallell jobs (seems I did a poor job when I did that and messed
> some stuff up). That can be fixed straight away, but adding more tests (new
> adapter tests, clustering tests, console tests, etc.) we should probably
> review later as it may impact stability and time to test a PR on Travis.
>
> On 12 December 2016 at 17:46, Bill Burke <bburke at redhat.com> wrote:
>
>> This wasn't just the adapter tests, initially it was the
>> PartialImportsTest which lives under org.keycloak.testsuite.admin somewhere
>> and should have run and should have failed.
>>
>> https://issues.jboss.org/browse/KEYCLOAK-4068
>>
>>
>> On 12/12/16 8:24 AM, Stian Thorgersen wrote:
>>
>> Let's review the tests ran by Travis after the new year, but with Travis
>> having the option to run groups of tests in parallel we should be able to
>> tests more including adapters and console. Travis should also be changed to
>> tests with the full KC server and WildFly for adapters rather than embedded
>> Undertow.
>>
>> On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com> wrote:
>>
>>> These broke because they weren't part of the main build.  I thought they
>>> were just dead code because when I did a "Find Usages" for them, nothing
>>> came up.  Minimally, things should at least be compiled with the main
>>> build, that way when refactorings happen, somebody doesn't delete a test
>>> dependency by accident.
>>>
>>>
>>> On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
>>> > Speaking of the tests, we seem not to run any of the adapter test
>>> > suites. I believe that running at least adapter tests for wildfly
>>> > would be beneficial, preventing e.g. [1]. WDYT?
>>> >
>>> > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>>> >
>>> > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda <mposolda at redhat.com
>>> > <mailto:mposolda at redhat.com>> wrote:
>>> >
>>> >     Fyi. On Friday afternoon, I've found the issue that travis didn't
>>> run
>>> >     all the tests from the testsuite. And PartialImportTest was the
>>> one,
>>> >     which wasn't executed. See
>>> >     https://issues.jboss.org/browse/KEYCLOAK-4021
>>> >     <https://issues.jboss.org/browse/KEYCLOAK-4021>
>>> >
>>> >     However with the travis fix, all the tests were passing (including
>>> >     PartialImportTest). So it seems this test was just failing
>>> >     randomly (not
>>> >     always)?
>>> >
>>> >     Now I can see in latest travis build that PartialImportTest passes.
>>> >
>>> >     Marek
>>> >
>>> >
>>> >
>>> >
>>> >     On 03/12/16 17:36, Bill Burke wrote:
>>> >     > I just noticed that my local build fails while travis passes.
>>> >     The bug is
>>> >     > really something travis should have picked up, specifically the
>>> >     > PartialImportsTest was removing an identity provider.  The JPA
>>> >     > removeIdenittyProviderByAlias method was wrong as it was trying
>>> >     to load
>>> >     > an IdentityProviderModel after it was removed thus resulting in a
>>> >     > Hibernate error.  Travis did not pick this up which makes me
>>> >     wonder if
>>> >     > the test is even running.
>>> >     >
>>> >     > FYI, i have a pull request that fixes this that is incoming. The
>>> >     bug,
>>> >     > not travis.
>>> >     >
>>> >     > Bill
>>> >     >
>>> >     >
>>> >     > _______________________________________________
>>> >     > keycloak-dev mailing list
>>> >     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jbo
>>> ss.org>
>>> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>> >
>>> >
>>> >     _______________________________________________
>>> >     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>
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > --Hynek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
>

From mposolda at redhat.com  Mon Dec 12 15:05:40 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 12 Dec 2016 21:05:40 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <CAJgngAfp0FDoxWb6q7urM2Xpi7+wep7j2d1Q6a7hLHxBsqkpfQ@mail.gmail.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
	<CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
	<d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>
	<CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>
	<6e2e7261-b1e3-39ce-8879-d692ca9c04e8@redhat.com>
	<CAJgngAfp0FDoxWb6q7urM2Xpi7+wep7j2d1Q6a7hLHxBsqkpfQ@mail.gmail.com>
Message-ID: <f6b5be12-497b-224b-308f-6bd6fd10bd4d@redhat.com>

FYI. There was also an issue that some tests weren't executed due to the 
filter, which didn't include sub-packages of specified packages. See 
commit https://github.com/keycloak/keycloak/pull/3596/files and JIRA 
https://issues.jboss.org/browse/KEYCLOAK-4021 . PartialImportTest was 
one of the tests, which weren't executed, but now it is.

Marek

On 12/12/16 17:56, Stian Thorgersen wrote:
> There was an issue before that the script didn't return the exit code 
> so it would look like it passed even though the tests failed. That's 
> fixed though:
> https://github.com/keycloak/keycloak/commit/a52f7f9baa5972fb606714d0f370fbbd3549fdcb
>
> On 12 December 2016 at 17:54, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     The filter you have looks like the test should have run which is
>     why the review needs to happen.
>
>     On 12/12/16 11:51 AM, Stian Thorgersen wrote:
>>     It should run at least what it used to run before I broke it up
>>     into multiple parallell jobs (seems I did a poor job when I did
>>     that and messed some stuff up). That can be fixed straight away,
>>     but adding more tests (new adapter tests, clustering tests,
>>     console tests, etc.) we should probably review later as it may
>>     impact stability and time to test a PR on Travis.
>>
>>     On 12 December 2016 at 17:46, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         This wasn't just the adapter tests, initially it was the
>>         PartialImportsTest which lives under
>>         org.keycloak.testsuite.admin somewhere and should have run
>>         and should have failed.
>>
>>         https://issues.jboss.org/browse/KEYCLOAK-4068
>>         <https://issues.jboss.org/browse/KEYCLOAK-4068>
>>
>>
>>         On 12/12/16 8:24 AM, Stian Thorgersen wrote:
>>>         Let's review the tests ran by Travis after the new year, but
>>>         with Travis having the option to run groups of tests in
>>>         parallel we should be able to tests more including adapters
>>>         and console. Travis should also be changed to tests with the
>>>         full KC server and WildFly for adapters rather than embedded
>>>         Undertow.
>>>
>>>         On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com
>>>         <mailto:bburke at redhat.com>> wrote:
>>>
>>>             These broke because they weren't part of the main
>>>             build.  I thought they
>>>             were just dead code because when I did a "Find Usages"
>>>             for them, nothing
>>>             came up.  Minimally, things should at least be compiled
>>>             with the main
>>>             build, that way when refactorings happen, somebody
>>>             doesn't delete a test
>>>             dependency by accident.
>>>
>>>
>>>             On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
>>>             > Speaking of the tests, we seem not to run any of the
>>>             adapter test
>>>             > suites. I believe that running at least adapter tests
>>>             for wildfly
>>>             > would be beneficial, preventing e.g. [1]. WDYT?
>>>             >
>>>             > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>>>             <https://issues.jboss.org/browse/KEYCLOAK-4017>
>>>             >
>>>             > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda
>>>             <mposolda at redhat.com <mailto:mposolda at redhat.com>
>>>             > <mailto:mposolda at redhat.com
>>>             <mailto:mposolda at redhat.com>>> wrote:
>>>             >
>>>             >     Fyi. On Friday afternoon, I've found the issue
>>>             that travis didn't run
>>>             >     all the tests from the testsuite. And
>>>             PartialImportTest was the one,
>>>             >     which wasn't executed. See
>>>             > https://issues.jboss.org/browse/KEYCLOAK-4021
>>>             <https://issues.jboss.org/browse/KEYCLOAK-4021>
>>>             >     <https://issues.jboss.org/browse/KEYCLOAK-4021
>>>             <https://issues.jboss.org/browse/KEYCLOAK-4021>>
>>>             >
>>>             >     However with the travis fix, all the tests were
>>>             passing (including
>>>             >     PartialImportTest). So it seems this test was just
>>>             failing
>>>             >     randomly (not
>>>             >     always)?
>>>             >
>>>             >     Now I can see in latest travis build that
>>>             PartialImportTest passes.
>>>             >
>>>             >     Marek
>>>             >
>>>             >
>>>             >
>>>             >
>>>             >     On 03/12/16 17:36, Bill Burke wrote:
>>>             >     > I just noticed that my local build fails while
>>>             travis passes.
>>>             >     The bug is
>>>             >     > really something travis should have picked up,
>>>             specifically the
>>>             >     > PartialImportsTest was removing an identity
>>>             provider.  The JPA
>>>             >     > removeIdenittyProviderByAlias method was wrong
>>>             as it was trying
>>>             >     to load
>>>             >     > an IdentityProviderModel after it was removed
>>>             thus resulting in a
>>>             >     > Hibernate error.  Travis did not pick this up
>>>             which makes me
>>>             >     wonder if
>>>             >     > the test is even running.
>>>             >     >
>>>             >     > FYI, i have a pull request that fixes this that
>>>             is incoming. The
>>>             >     bug,
>>>             >     > not travis.
>>>             >     >
>>>             >     > Bill
>>>             >     >
>>>             >     >
>>>             >     > _______________________________________________
>>>             >     > keycloak-dev mailing list
>>>             >     > keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             <mailto: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>
>>>             >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>             <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>             >
>>>             >
>>>             >  _______________________________________________
>>>             >     keycloak-dev mailing list
>>>             > keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             <mailto: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>
>>>             >  
>>>              <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>             <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>             >
>>>             >
>>>             >
>>>             >
>>>             > --
>>>             >
>>>             > --Hynek
>>>
>>>             _______________________________________________
>>>             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>
>>>
>>>
>>
>>
>
>


From mposolda at redhat.com  Mon Dec 12 15:44:19 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 12 Dec 2016 21:44:19 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
	<CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
	<d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>
	<CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>
Message-ID: <c153278b-57a2-12ad-fd1e-e429823d8c7b@redhat.com>

On 12/12/16 17:51, Stian Thorgersen wrote:
> It should run at least what it used to run before I broke it up into 
> multiple parallell jobs (seems I did a poor job when I did that and 
> messed some stuff up). That can be fixed straight away, but adding 
> more tests (new adapter tests, clustering tests, console tests, etc.) 
> we should probably review later as it may impact stability and time to 
> test a PR on Travis.
+1 for better review. Few things:

* Unit tests in the modules outside testsuite are not executed during 
travis build. For example tests under core/src/test/java .

* Everything in testsuite/integration and 
testsuite/integration-arquillian/tests/base is running in Travis build 
ATM. However if we add new package with tests into the testsuite (For 
example org.keycloak.testsuite.zzz.NewTest), it is possible that it 
won't be running due to missing filter in the travis-run-tests.sh for 
the package starting with "z" . I hope we can have the list of packages 
by travis-run-tests.sh to be more dynamic.

* IMO it is sufficient that travis will run all the tests (including 
adapters and cluster) on embedded undertow. Running the tests on Wildfly 
is unecessary overhead, which will slightly increase the travis build 
time (as it will need to build distribution, start server etc) . There 
is not much added value as 95 % of regressions are catched with undertow 
too.

* I've added some undertow adapter tests to be executed during default 
travis build. They are all in the package 
org.keycloak.testsuite.adapter.undertow.servlet . Problem is, that not 
all adapter tests are executed as it will require creating subclass for 
every "Abstract" class with test and I just didn't create all the 
classes for embedded undertow. I've created JIRA 
https://issues.jboss.org/browse/KEYCLOAK-4069 to omprove adapter tests 
to avoid "dead" modules and many classes needed for single adapter test.

Marek
> On 12 December 2016 at 17:46, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     This wasn't just the adapter tests, initially it was the
>     PartialImportsTest which lives under org.keycloak.testsuite.admin
>     somewhere and should have run and should have failed.
>
>     https://issues.jboss.org/browse/KEYCLOAK-4068
>     <https://issues.jboss.org/browse/KEYCLOAK-4068>
>
>
>     On 12/12/16 8:24 AM, Stian Thorgersen wrote:
>>     Let's review the tests ran by Travis after the new year, but with
>>     Travis having the option to run groups of tests in parallel we
>>     should be able to tests more including adapters and console.
>>     Travis should also be changed to tests with the full KC server
>>     and WildFly for adapters rather than embedded Undertow.
>>
>>     On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         These broke because they weren't part of the main build.  I
>>         thought they
>>         were just dead code because when I did a "Find Usages" for
>>         them, nothing
>>         came up.  Minimally, things should at least be compiled with
>>         the main
>>         build, that way when refactorings happen, somebody doesn't
>>         delete a test
>>         dependency by accident.
>>
>>
>>         On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
>>         > Speaking of the tests, we seem not to run any of the
>>         adapter test
>>         > suites. I believe that running at least adapter tests for
>>         wildfly
>>         > would be beneficial, preventing e.g. [1]. WDYT?
>>         >
>>         > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>>         <https://issues.jboss.org/browse/KEYCLOAK-4017>
>>         >
>>         > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>
>>         > <mailto:mposolda at redhat.com <mailto:mposolda at redhat.com>>>
>>         wrote:
>>         >
>>         >     Fyi. On Friday afternoon, I've found the issue that
>>         travis didn't run
>>         >     all the tests from the testsuite. And PartialImportTest
>>         was the one,
>>         >     which wasn't executed. See
>>         > https://issues.jboss.org/browse/KEYCLOAK-4021
>>         <https://issues.jboss.org/browse/KEYCLOAK-4021>
>>         >     <https://issues.jboss.org/browse/KEYCLOAK-4021
>>         <https://issues.jboss.org/browse/KEYCLOAK-4021>>
>>         >
>>         >     However with the travis fix, all the tests were passing
>>         (including
>>         >     PartialImportTest). So it seems this test was just failing
>>         >     randomly (not
>>         >     always)?
>>         >
>>         >     Now I can see in latest travis build that
>>         PartialImportTest passes.
>>         >
>>         >     Marek
>>         >
>>         >
>>         >
>>         >
>>         >     On 03/12/16 17:36, Bill Burke wrote:
>>         >     > I just noticed that my local build fails while travis
>>         passes.
>>         >     The bug is
>>         >     > really something travis should have picked up,
>>         specifically the
>>         >     > PartialImportsTest was removing an identity
>>         provider.  The JPA
>>         >     > removeIdenittyProviderByAlias method was wrong as it
>>         was trying
>>         >     to load
>>         >     > an IdentityProviderModel after it was removed thus
>>         resulting in a
>>         >     > Hibernate error.  Travis did not pick this up which
>>         makes me
>>         >     wonder if
>>         >     > the test is even running.
>>         >     >
>>         >     > FYI, i have a pull request that fixes this that is
>>         incoming. The
>>         >     bug,
>>         >     > not travis.
>>         >     >
>>         >     > Bill
>>         >     >
>>         >     >
>>         >     > _______________________________________________
>>         >     > keycloak-dev mailing list
>>         >     > keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         <mailto: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>
>>         >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>         >
>>         >
>>         >     _______________________________________________
>>         >     keycloak-dev mailing list
>>         > keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         <mailto: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>
>>         >  <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>         >
>>         >
>>         >
>>         >
>>         > --
>>         >
>>         > --Hynek
>>
>>         _______________________________________________
>>         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>
>>
>>
>
>


From sthorger at redhat.com  Tue Dec 13 02:26:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 13 Dec 2016 08:26:56 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <c153278b-57a2-12ad-fd1e-e429823d8c7b@redhat.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
	<CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
	<d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>
	<CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>
	<c153278b-57a2-12ad-fd1e-e429823d8c7b@redhat.com>
Message-ID: <CAJgngAfLv_U_tCw=9oPwmWrCDemOVC4PN4U5aa8w0ZvyWaFgrQ@mail.gmail.com>

On 12 December 2016 at 21:44, Marek Posolda <mposolda at redhat.com> wrote:

> On 12/12/16 17:51, Stian Thorgersen wrote:
>
> It should run at least what it used to run before I broke it up into
> multiple parallell jobs (seems I did a poor job when I did that and messed
> some stuff up). That can be fixed straight away, but adding more tests (new
> adapter tests, clustering tests, console tests, etc.) we should probably
> review later as it may impact stability and time to test a PR on Travis.
>
> +1 for better review. Few things:
>
> * Unit tests in the modules outside testsuite are not executed during
> travis build. For example tests under core/src/test/java .
>
> * Everything in testsuite/integration and testsuite/integration-arquillian/tests/base
> is running in Travis build ATM. However if we add new package with tests
> into the testsuite (For example org.keycloak.testsuite.zzz.NewTest), it
> is possible that it won't be running due to missing filter in the
> travis-run-tests.sh for the package starting with "z" . I hope we can have
> the list of packages by travis-run-tests.sh to be more dynamic.
>
> * IMO it is sufficient that travis will run all the tests (including
> adapters and cluster) on embedded undertow. Running the tests on Wildfly is
> unecessary overhead, which will slightly increase the travis build time (as
> it will need to build distribution, start server etc) . There is not much
> added value as 95 % of regressions are catched with undertow too.
>

-1 We've seen this many times where Travis is happy, but the distribution
is broken. This happened several times last year so we need to prevent this.


>
> * I've added some undertow adapter tests to be executed during default
> travis build. They are all in the package org.keycloak.testsuite.
> adapter.undertow.servlet . Problem is, that not all adapter tests are
> executed as it will require creating subclass for every "Abstract" class
> with test and I just didn't create all the classes for embedded undertow.
> I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-4069 to
> omprove adapter tests to avoid "dead" modules and many classes needed for
> single adapter test.
>
> Marek
>
> On 12 December 2016 at 17:46, Bill Burke <bburke at redhat.com> wrote:
>
>> This wasn't just the adapter tests, initially it was the
>> PartialImportsTest which lives under org.keycloak.testsuite.admin somewhere
>> and should have run and should have failed.
>>
>> https://issues.jboss.org/browse/KEYCLOAK-4068
>>
>>
>> On 12/12/16 8:24 AM, Stian Thorgersen wrote:
>>
>> Let's review the tests ran by Travis after the new year, but with Travis
>> having the option to run groups of tests in parallel we should be able to
>> tests more including adapters and console. Travis should also be changed to
>> tests with the full KC server and WildFly for adapters rather than embedded
>> Undertow.
>>
>> On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com> wrote:
>>
>>> These broke because they weren't part of the main build.  I thought they
>>> were just dead code because when I did a "Find Usages" for them, nothing
>>> came up.  Minimally, things should at least be compiled with the main
>>> build, that way when refactorings happen, somebody doesn't delete a test
>>> dependency by accident.
>>>
>>>
>>> On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
>>> > Speaking of the tests, we seem not to run any of the adapter test
>>> > suites. I believe that running at least adapter tests for wildfly
>>> > would be beneficial, preventing e.g. [1]. WDYT?
>>> >
>>> > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>>> >
>>> > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda <mposolda at redhat.com
>>> > <mailto:mposolda at redhat.com>> wrote:
>>> >
>>> >     Fyi. On Friday afternoon, I've found the issue that travis didn't
>>> run
>>> >     all the tests from the testsuite. And PartialImportTest was the
>>> one,
>>> >     which wasn't executed. See
>>> >     https://issues.jboss.org/browse/KEYCLOAK-4021
>>> >     <https://issues.jboss.org/browse/KEYCLOAK-4021>
>>> >
>>> >     However with the travis fix, all the tests were passing (including
>>> >     PartialImportTest). So it seems this test was just failing
>>> >     randomly (not
>>> >     always)?
>>> >
>>> >     Now I can see in latest travis build that PartialImportTest passes.
>>> >
>>> >     Marek
>>> >
>>> >
>>> >
>>> >
>>> >     On 03/12/16 17:36, Bill Burke wrote:
>>> >     > I just noticed that my local build fails while travis passes.
>>> >     The bug is
>>> >     > really something travis should have picked up, specifically the
>>> >     > PartialImportsTest was removing an identity provider.  The JPA
>>> >     > removeIdenittyProviderByAlias method was wrong as it was trying
>>> >     to load
>>> >     > an IdentityProviderModel after it was removed thus resulting in a
>>> >     > Hibernate error.  Travis did not pick this up which makes me
>>> >     wonder if
>>> >     > the test is even running.
>>> >     >
>>> >     > FYI, i have a pull request that fixes this that is incoming. The
>>> >     bug,
>>> >     > not travis.
>>> >     >
>>> >     > Bill
>>> >     >
>>> >     >
>>> >     > _______________________________________________
>>> >     > keycloak-dev mailing list
>>> >     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jbo
>>> ss.org>
>>> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>> >
>>> >
>>> >     _______________________________________________
>>> >     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>
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > --Hynek
>>>
>>> _______________________________________________
>>> 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 13 02:50:13 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 13 Dec 2016 08:50:13 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <CAJgngAfLv_U_tCw=9oPwmWrCDemOVC4PN4U5aa8w0ZvyWaFgrQ@mail.gmail.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
	<CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
	<d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>
	<CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>
	<c153278b-57a2-12ad-fd1e-e429823d8c7b@redhat.com>
	<CAJgngAfLv_U_tCw=9oPwmWrCDemOVC4PN4U5aa8w0ZvyWaFgrQ@mail.gmail.com>
Message-ID: <1650a677-a7ff-2b69-310f-abd6ccdacef2@redhat.com>

On 13/12/16 08:26, Stian Thorgersen wrote:
>
>
> On 12 December 2016 at 21:44, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 12/12/16 17:51, Stian Thorgersen wrote:
>>     It should run at least what it used to run before I broke it up
>>     into multiple parallell jobs (seems I did a poor job when I did
>>     that and messed some stuff up). That can be fixed straight away,
>>     but adding more tests (new adapter tests, clustering tests,
>>     console tests, etc.) we should probably review later as it may
>>     impact stability and time to test a PR on Travis.
>     +1 for better review. Few things:
>
>     * Unit tests in the modules outside testsuite are not executed
>     during travis build. For example tests under core/src/test/java .
>
>     * Everything in testsuite/integration and
>     testsuite/integration-arquillian/tests/base is running in Travis
>     build ATM. However if we add new package with tests into the
>     testsuite (For example org.keycloak.testsuite.zzz.NewTest), it is
>     possible that it won't be running due to missing filter in the
>     travis-run-tests.sh for the package starting with "z" . I hope we
>     can have the list of packages by travis-run-tests.sh to be more
>     dynamic.
>
>     * IMO it is sufficient that travis will run all the tests
>     (including adapters and cluster) on embedded undertow. Running the
>     tests on Wildfly is unecessary overhead, which will slightly
>     increase the travis build time (as it will need to build
>     distribution, start server etc) . There is not much added value as
>     95 % of regressions are catched with undertow too.
>
>
> -1 We've seen this many times where Travis is happy, but the 
> distribution is broken. This happened several times last year so we 
> need to prevent this.
Isn't it better to have travis run just on "simple" environment for each 
PR and then rely on Central CI daily jobs to run the tests on real 
servers? Even if we setup travis to run adapter tests on Wildfly, it 
won't catch all the other broken adapters (EAP6, Tomcat, Jetty, ...).

IMO it is generally better to have CI for each PR, which will be able to 
catch 95% of regressions (not necessarily 100%) and doesn't take hours 
to wait for every PR. And then separate daily jobs to test everything.

Marek
>
>
>     * I've added some undertow adapter tests to be executed during
>     default travis build. They are all in the package
>     org.keycloak.testsuite.adapter.undertow.servlet . Problem is, that
>     not all adapter tests are executed as it will require creating
>     subclass for every "Abstract" class with test and I just didn't
>     create all the classes for embedded undertow. I've created JIRA
>     https://issues.jboss.org/browse/KEYCLOAK-4069
>     <https://issues.jboss.org/browse/KEYCLOAK-4069> to omprove adapter
>     tests to avoid "dead" modules and many classes needed for single
>     adapter test.
>
>     Marek
>>     On 12 December 2016 at 17:46, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         This wasn't just the adapter tests, initially it was the
>>         PartialImportsTest which lives under
>>         org.keycloak.testsuite.admin somewhere and should have run
>>         and should have failed.
>>
>>         https://issues.jboss.org/browse/KEYCLOAK-4068
>>         <https://issues.jboss.org/browse/KEYCLOAK-4068>
>>
>>
>>         On 12/12/16 8:24 AM, Stian Thorgersen wrote:
>>>         Let's review the tests ran by Travis after the new year, but
>>>         with Travis having the option to run groups of tests in
>>>         parallel we should be able to tests more including adapters
>>>         and console. Travis should also be changed to tests with the
>>>         full KC server and WildFly for adapters rather than embedded
>>>         Undertow.
>>>
>>>         On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com
>>>         <mailto:bburke at redhat.com>> wrote:
>>>
>>>             These broke because they weren't part of the main
>>>             build.  I thought they
>>>             were just dead code because when I did a "Find Usages"
>>>             for them, nothing
>>>             came up.  Minimally, things should at least be compiled
>>>             with the main
>>>             build, that way when refactorings happen, somebody
>>>             doesn't delete a test
>>>             dependency by accident.
>>>
>>>
>>>             On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
>>>             > Speaking of the tests, we seem not to run any of the
>>>             adapter test
>>>             > suites. I believe that running at least adapter tests
>>>             for wildfly
>>>             > would be beneficial, preventing e.g. [1]. WDYT?
>>>             >
>>>             > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>>>             <https://issues.jboss.org/browse/KEYCLOAK-4017>
>>>             >
>>>             > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda
>>>             <mposolda at redhat.com <mailto:mposolda at redhat.com>
>>>             > <mailto:mposolda at redhat.com
>>>             <mailto:mposolda at redhat.com>>> wrote:
>>>             >
>>>             >     Fyi. On Friday afternoon, I've found the issue
>>>             that travis didn't run
>>>             >     all the tests from the testsuite. And
>>>             PartialImportTest was the one,
>>>             >     which wasn't executed. See
>>>             > https://issues.jboss.org/browse/KEYCLOAK-4021
>>>             <https://issues.jboss.org/browse/KEYCLOAK-4021>
>>>             >     <https://issues.jboss.org/browse/KEYCLOAK-4021
>>>             <https://issues.jboss.org/browse/KEYCLOAK-4021>>
>>>             >
>>>             >     However with the travis fix, all the tests were
>>>             passing (including
>>>             >  PartialImportTest). So it seems this test was just
>>>             failing
>>>             >     randomly (not
>>>             >     always)?
>>>             >
>>>             >     Now I can see in latest travis build that
>>>             PartialImportTest passes.
>>>             >
>>>             >     Marek
>>>             >
>>>             >
>>>             >
>>>             >
>>>             >     On 03/12/16 17:36, Bill Burke wrote:
>>>             >     > I just noticed that my local build fails while
>>>             travis passes.
>>>             >     The bug is
>>>             >     > really something travis should have picked up,
>>>             specifically the
>>>             >     > PartialImportsTest was removing an identity
>>>             provider.  The JPA
>>>             >     > removeIdenittyProviderByAlias method was wrong
>>>             as it was trying
>>>             >     to load
>>>             >     > an IdentityProviderModel after it was removed
>>>             thus resulting in a
>>>             >     > Hibernate error.  Travis did not pick this up
>>>             which makes me
>>>             >     wonder if
>>>             >     > the test is even running.
>>>             >     >
>>>             >     > FYI, i have a pull request that fixes this that
>>>             is incoming. The
>>>             >     bug,
>>>             >     > not travis.
>>>             >     >
>>>             >     > Bill
>>>             >     >
>>>             >     >
>>>             >     > _______________________________________________
>>>             >     > keycloak-dev mailing list
>>>             >     > keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             <mailto: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>
>>>             >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>             <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>             >
>>>             >
>>>             >  _______________________________________________
>>>             >     keycloak-dev mailing list
>>>             > keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             <mailto: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>
>>>             >  
>>>              <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>             <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>>             >
>>>             >
>>>             >
>>>             >
>>>             > --
>>>             >
>>>             > --Hynek
>>>
>>>             _______________________________________________
>>>             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>
>>>
>>>
>>
>>
>
>


From sthorger at redhat.com  Tue Dec 13 02:55:51 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 13 Dec 2016 08:55:51 +0100
Subject: [keycloak-dev] local build failing, travis passing
In-Reply-To: <1650a677-a7ff-2b69-310f-abd6ccdacef2@redhat.com>
References: <cce3bde5-d096-995b-87e7-db8123b7a75d@redhat.com>
	<a80971b8-fe83-da8d-c57f-560071a119e0@redhat.com>
	<CAMvXD=H8j6TdQ2zX=0hxtR-y4Y43MqnLMuOYzQRugx-YenGFKQ@mail.gmail.com>
	<d72eb55e-3421-ad1b-426a-8ce25dbd554e@redhat.com>
	<CAJgngAdpVHVAL7Qq345z+_NATwVLnjOKo7tfAFejgtz333pxfQ@mail.gmail.com>
	<d7f76a7c-2469-c403-4064-3110fd44c5ec@redhat.com>
	<CAJgngAdT82wrQfzQ6nxgkH9+1mJhhnNtfyOp4CkiWgktme1Vcg@mail.gmail.com>
	<c153278b-57a2-12ad-fd1e-e429823d8c7b@redhat.com>
	<CAJgngAfLv_U_tCw=9oPwmWrCDemOVC4PN4U5aa8w0ZvyWaFgrQ@mail.gmail.com>
	<1650a677-a7ff-2b69-310f-abd6ccdacef2@redhat.com>
Message-ID: <CAJgngAcqrdF2tLDWgXPnDD2oZijbx_h=0U80H3kZ695_+FN8wA@mail.gmail.com>

On 13 December 2016 at 08:50, Marek Posolda <mposolda at redhat.com> wrote:

> On 13/12/16 08:26, Stian Thorgersen wrote:
>
>
>
> On 12 December 2016 at 21:44, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 12/12/16 17:51, Stian Thorgersen wrote:
>>
>> It should run at least what it used to run before I broke it up into
>> multiple parallell jobs (seems I did a poor job when I did that and messed
>> some stuff up). That can be fixed straight away, but adding more tests (new
>> adapter tests, clustering tests, console tests, etc.) we should probably
>> review later as it may impact stability and time to test a PR on Travis.
>>
>> +1 for better review. Few things:
>>
>> * Unit tests in the modules outside testsuite are not executed during
>> travis build. For example tests under core/src/test/java .
>>
>> * Everything in testsuite/integration and testsuite/integration-arquillian/tests/base
>> is running in Travis build ATM. However if we add new package with tests
>> into the testsuite (For example org.keycloak.testsuite.zzz.NewTest), it
>> is possible that it won't be running due to missing filter in the
>> travis-run-tests.sh for the package starting with "z" . I hope we can have
>> the list of packages by travis-run-tests.sh to be more dynamic.
>>
>> * IMO it is sufficient that travis will run all the tests (including
>> adapters and cluster) on embedded undertow. Running the tests on Wildfly is
>> unecessary overhead, which will slightly increase the travis build time (as
>> it will need to build distribution, start server etc) . There is not much
>> added value as 95 % of regressions are catched with undertow too.
>>
>
> -1 We've seen this many times where Travis is happy, but the distribution
> is broken. This happened several times last year so we need to prevent this.
>
> Isn't it better to have travis run just on "simple" environment for each
> PR and then rely on Central CI daily jobs to run the tests on real servers?
> Even if we setup travis to run adapter tests on Wildfly, it won't catch all
> the other broken adapters (EAP6, Tomcat, Jetty, ...).
>
> IMO it is generally better to have CI for each PR, which will be able to
> catch 95% of regressions (not necessarily 100%) and doesn't take hours to
> wait for every PR. And then separate daily jobs to test everything.
>

Yes, we can't run it all on Travis, but I don't think making it run with WF
is going to add that much overhead (I think we're talking a few min). If
it's a big overhead then we should keep it on Undertow for sure.


>
>
> Marek
>
>
>
>>
>> * I've added some undertow adapter tests to be executed during default
>> travis build. They are all in the package org.keycloak.testsuite.adapter
>> .undertow.servlet . Problem is, that not all adapter tests are executed
>> as it will require creating subclass for every "Abstract" class with test
>> and I just didn't create all the classes for embedded undertow. I've
>> created JIRA https://issues.jboss.org/browse/KEYCLOAK-4069 to omprove
>> adapter tests to avoid "dead" modules and many classes needed for single
>> adapter test.
>>
>> Marek
>>
>> On 12 December 2016 at 17:46, Bill Burke <bburke at redhat.com> wrote:
>>
>>> This wasn't just the adapter tests, initially it was the
>>> PartialImportsTest which lives under org.keycloak.testsuite.admin somewhere
>>> and should have run and should have failed.
>>>
>>> https://issues.jboss.org/browse/KEYCLOAK-4068
>>>
>>>
>>> On 12/12/16 8:24 AM, Stian Thorgersen wrote:
>>>
>>> Let's review the tests ran by Travis after the new year, but with Travis
>>> having the option to run groups of tests in parallel we should be able to
>>> tests more including adapters and console. Travis should also be changed to
>>> tests with the full KC server and WildFly for adapters rather than embedded
>>> Undertow.
>>>
>>> On 5 December 2016 at 16:32, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> These broke because they weren't part of the main build.  I thought they
>>>> were just dead code because when I did a "Find Usages" for them, nothing
>>>> came up.  Minimally, things should at least be compiled with the main
>>>> build, that way when refactorings happen, somebody doesn't delete a test
>>>> dependency by accident.
>>>>
>>>>
>>>> On 12/5/16 6:53 AM, Hynek Mlnarik wrote:
>>>> > Speaking of the tests, we seem not to run any of the adapter test
>>>> > suites. I believe that running at least adapter tests for wildfly
>>>> > would be beneficial, preventing e.g. [1]. WDYT?
>>>> >
>>>> > [1] https://issues.jboss.org/browse/KEYCLOAK-4017
>>>> >
>>>> > On Mon, Dec 5, 2016 at 8:39 AM, Marek Posolda <mposolda at redhat.com
>>>> > <mailto:mposolda at redhat.com>> wrote:
>>>> >
>>>> >     Fyi. On Friday afternoon, I've found the issue that travis didn't
>>>> run
>>>> >     all the tests from the testsuite. And PartialImportTest was the
>>>> one,
>>>> >     which wasn't executed. See
>>>> >     https://issues.jboss.org/browse/KEYCLOAK-4021
>>>> >     <https://issues.jboss.org/browse/KEYCLOAK-4021>
>>>> >
>>>> >     However with the travis fix, all the tests were passing (including
>>>> >     PartialImportTest). So it seems this test was just failing
>>>> >     randomly (not
>>>> >     always)?
>>>> >
>>>> >     Now I can see in latest travis build that PartialImportTest
>>>> passes.
>>>> >
>>>> >     Marek
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >     On 03/12/16 17:36, Bill Burke wrote:
>>>> >     > I just noticed that my local build fails while travis passes.
>>>> >     The bug is
>>>> >     > really something travis should have picked up, specifically the
>>>> >     > PartialImportsTest was removing an identity provider.  The JPA
>>>> >     > removeIdenittyProviderByAlias method was wrong as it was trying
>>>> >     to load
>>>> >     > an IdentityProviderModel after it was removed thus resulting in
>>>> a
>>>> >     > Hibernate error.  Travis did not pick this up which makes me
>>>> >     wonder if
>>>> >     > the test is even running.
>>>> >     >
>>>> >     > FYI, i have a pull request that fixes this that is incoming. The
>>>> >     bug,
>>>> >     > not travis.
>>>> >     >
>>>> >     > Bill
>>>> >     >
>>>> >     >
>>>> >     > _______________________________________________
>>>> >     > keycloak-dev mailing list
>>>> >     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jbo
>>>> ss.org>
>>>> >     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>> >
>>>> >
>>>> >     _______________________________________________
>>>> >     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>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > --Hynek
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>>
>>
>>
>
>

From pdrozd at redhat.com  Tue Dec 13 03:17:09 2016
From: pdrozd at redhat.com (Pavel Drozd)
Date: Tue, 13 Dec 2016 09:17:09 +0100
Subject: [keycloak-dev] Why aren't tomcat and jetty tests run!?
In-Reply-To: <f237437f-5ca9-2cc9-3487-38846dd4b870@redhat.com>
References: <58a0a13c-91c5-44e0-aca4-528a75061208@redhat.com>
	<20161207180205.GD17975@abstractj.org>
	<a864a499-1f29-bb93-d315-4a3637dd9623@redhat.com>
	<16e42433-3c3d-8382-1a5a-3a08592c48b7@redhat.com>
	<9a624fc0-41b2-7a89-28ff-daf6adc4fe48@redhat.com>
	<a407c64f-3cb6-d299-4c3c-b9c09c49a4af@redhat.com>
	<f8f07309-8a7a-099f-2408-e884f582acbd@redhat.com>
	<f5f1f95f-ba90-3f8b-d6c3-cfca1634697d@redhat.com>
	<02013474-2c60-764e-577a-548bbb56955f@redhat.com>
	<CAJgngAfbuxFJYHMPMZVGhVY29fExgPTJ1X6vN7hsgM058A6ekg@mail.gmail.com>
	<f237437f-5ca9-2cc9-3487-38846dd4b870@redhat.com>
Message-ID: <584FAE85.30007@redhat.com>

Dne 12.12.2016 v 16:22 Bill Burke napsal(a):
>
> On 12/12/16 8:19 AM, Stian Thorgersen wrote:
>> Let's put this on hold for after 7.1 GA and make it a priority after that.
> We can't have tomcat and jetty adapters failing and regressions
> happening.  There's a lot of people that depend on them.  Our customer
> base comes from a successful community project.  You don't start
> undercutting community just because its not supported in product.  I'm
> adding them back to the build because its the right thing to do.  I
> shouldn't have even asked and just did it, but I just found it quite
> annoying that they were removed as I knew they were removed on purpose.
>
>> We are going to use Arquillian bases tests and removing the old tests as
>> they have less value from a QE perspective.
> Negative.  You are just 100% wrong on this.  I've said this over and
> over and you just don't listen and its getting really annoying. There
> are many tests which it doesn't matter if they run in the container or
> not.  Many tests it is not possible to even run as its impossible to set
> up the conditions you want to happen.  Many tests are functional SPI
> tests and it doesn't matter at all if they run inside the app server or
> not and its much easier to setup and debug.
>

Running the tests in the container is crucial requirement for QE. We 
have to run the tests against the container built by productization, 
there is no other option here. We should be able to test RH-SSO/Keycloak 
patches, RH-SSO/Keycloak with EAP CPs. There can be many errors which we 
are not able to catch in embedded container.
If we will not able to collaborate on the tests and will not use the 
shared approach, it will be a big step back in our effort to correctly 
setup CI jobs for community and the product.

>> This has been discussed many
>> times now and we have agreed that this will be done a long time ago so
>> please let's not reiterate this discussion again and again. If dev and QE
>> are going to collaborate on the tests we need to share the approach and QE
>> has to have full functional tests.
> Discussed many times and I never agreed to anything.  And kept telling
> you over and over that this mandate is uneccessary, hurtful to
> development, and is a lot of wasted effort, but you don't want to listen.
>
>> We need to resolve this issue though so we can get access to the
>> KeycloakSession from within certain tests. Ability to run adapter tests
>> from within the IDE is also a nice to have, but that may be harder to
>> achieve (and the effort may not be worth it, at least not for all adapters).
> There's a difference between unit tests, functional tests, and
> integration tests that you are missing.  Everything is not an
> integration test.  Its  unacceptable for adapter tests to not be able to
> run in the IDE.  If you want to have additional non-IDE runnable
> integration tests, that is fine, but to be able to develop new features
> and debug most problems, running in the IDE is a must and you're just
> being stubborn to state otherwise.  Its quite annoying.
>
> Bill
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Tue Dec 13 13:26:40 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 13 Dec 2016 16:26:40 -0200
Subject: [keycloak-dev] Preserve role id during export/import
Message-ID: <20161213182640.GC13218@abstractj.org>

Hi, I was reading this issue[1] and was wondering if this expected
behavior or a bug.

Should we preserve ids during import/export?

[1] - https://issues.jboss.org/browse/KEYCLOAK-3657

--

abstractj
PGP: 0x84DC9914

From mposolda at redhat.com  Tue Dec 13 15:15:12 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 13 Dec 2016 21:15:12 +0100
Subject: [keycloak-dev] Preserve role id during export/import
In-Reply-To: <20161213182640.GC13218@abstractj.org>
References: <20161213182640.GC13218@abstractj.org>
Message-ID: <60585ac3-c472-94f7-65ad-4b5e33016014@redhat.com>

Yes, this looks like a bug to me. AFAIK it was working some time ago, 
but probably was somehow broken.

Marek

On 13/12/16 19:26, Bruno Oliveira wrote:
> Hi, I was reading this issue[1] and was wondering if this expected
> behavior or a bug.
>
> Should we preserve ids during import/export?
>
> [1] - https://issues.jboss.org/browse/KEYCLOAK-3657
>
> --
>
> 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  Tue Dec 13 15:28:16 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 13 Dec 2016 20:28:16 +0000
Subject: [keycloak-dev] Preserve role id during export/import
In-Reply-To: <60585ac3-c472-94f7-65ad-4b5e33016014@redhat.com>
References: <20161213182640.GC13218@abstractj.org>
	<60585ac3-c472-94f7-65ad-4b5e33016014@redhat.com>
Message-ID: <CAM5SUC7zWWQxM8nwGwbd98FCjWswb8J7FqiJewAHD9n6aXLsUQ@mail.gmail.com>

Np, thanks Marek

On Tue, Dec 13, 2016, 6:15 PM Marek Posolda <mposolda at redhat.com> wrote:

> Yes, this looks like a bug to me. AFAIK it was working some time ago,
> but probably was somehow broken.
>
> Marek
>
> On 13/12/16 19:26, Bruno Oliveira wrote:
> > Hi, I was reading this issue[1] and was wondering if this expected
> > behavior or a bug.
> >
> > Should we preserve ids during import/export?
> >
> > [1] - https://issues.jboss.org/browse/KEYCLOAK-3657
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From srossillo at smartling.com  Tue Dec 13 19:27:39 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Tue, 13 Dec 2016 19:27:39 -0500
Subject: [keycloak-dev] Admin client interfaces not implemented in services
Message-ID: <81BB088B-8D9E-47F3-ABC1-523CC868F1C5@smartling.com>

I?ve been doing some work around the admin client and endpoints. I noticed that org.keycloak.services.resources.admin.UsersResource does not implement the org.keycloak.admin.client.resource.UsersResource interface. Is there an intentional reason for this?

It would be easier to keep the server implementation honest to the APIs if the interfaces were implemented plus simplify implementation discovery. Seems there are redundant POJOs as a result of this too.

What do you guys think about modifying the admin service to implement the client interfaces?

Thanks,
Scott

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com


From sthorger at redhat.com  Tue Dec 13 23:32:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 14 Dec 2016 05:32:19 +0100
Subject: [keycloak-dev] Admin client interfaces not implemented in
	services
In-Reply-To: <81BB088B-8D9E-47F3-ABC1-523CC868F1C5@smartling.com>
References: <81BB088B-8D9E-47F3-ABC1-523CC868F1C5@smartling.com>
Message-ID: <CAJgngAd2vwCJj3UC1jCS0a29825Qj79nPj3ri13DWEr2PLJ6sg@mail.gmail.com>

I agree that would be better, but there's not a one to one mapping between
the admin client interfaces and the admin services, so not sure if this
would be possible at the moment without radically changing the client api.
We're also planning on re-doing the admin endpoints completely at some
point and introduce a much improved v2.

On 14 December 2016 at 01:27, Scott Rossillo <srossillo at smartling.com>
wrote:

> I?ve been doing some work around the admin client and endpoints. I noticed
> that org.keycloak.services.resources.admin.UsersResource does not
> implement the org.keycloak.admin.client.resource.UsersResource interface.
> Is there an intentional reason for this?
>
> It would be easier to keep the server implementation honest to the APIs if
> the interfaces were implemented plus simplify implementation discovery.
> Seems there are redundant POJOs as a result of this too.
>
> What do you guys think about modifying the admin service to implement the
> client interfaces?
>
> Thanks,
> Scott
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Wed Dec 14 00:32:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 14 Dec 2016 06:32:48 +0100
Subject: [keycloak-dev] [keycloak-user] Considering removing Mongo
	support
In-Reply-To: <CAELTqdr0n6RppEzdOVyk+LLk17Eb1yj+3fw-6Peg6VFobFR6OQ@mail.gmail.com>
References: <CAJgngAfSGLq3q=T3rBFypDPmkb68QjEv8c+JVL=ZYC6Pz0HC_w@mail.gmail.com>
	<CAELTqdr0n6RppEzdOVyk+LLk17Eb1yj+3fw-6Peg6VFobFR6OQ@mail.gmail.com>
Message-ID: <CAJgngAdCfs8ix8Du+P-7EJfC2iNf445tFbq7eqMqS-tJEqnd6w@mail.gmail.com>

You can't go wrong with Oracle (other than price obviously) and PostgreSQL
is a good database as well. That's my 2 cents at least, but then again I'm
not a db guru ;)

On 3 December 2016 at 10:09, Byte Flinger <byteflinger at gmail.com> wrote:

> Does that mean that the only supported backends would be SQL databases? I
> have recently started to look into Keycloak and I was thinking that Mongodb
> support was nice for scalability as it can be sharded, something SQL dbs
> cannot. Wouldn't that mean giving up on scalability for large deployments?
>
> Are there plans to support any other more scalable type of database such
> as Cassandra?
>
> On Fri, 2 Dec 2016, 11:30 Stian Thorgersen, <sthorger at redhat.com> wrote:
>
>> All,
>>
>> We are considering removing Mongo support from Keycloak in 3.x. The
>> reasons
>> behind it is that there are a fair few issues in the current
>> implementation, especially around consistency due to lack of transaction
>> support in Mongo and often we update multiple documents. In many cases we
>> rely on transactions to rollback to prevent partial updates, but this
>> obviously doesn't work in Mongo.
>>
>> With the fact that Mongo is already partially broken and the constant
>> maintenance involved we're considering removing it and rather focus purely
>> on the relational database back-end.
>>
>> Another point to make is that we are not considering supporting Mongo in
>> the supported version of Keycloak (Red Hat Single Sign-On). So we are
>> never
>> able to provide the same level of care and attention to it as we can for
>> relational databases.
>>
>> If we do decide to remove it we would make sure we provide a seamless and
>> easy option to migrate from Mongo to a relational database!
>>
>> I would like to gather some feedback from the community before doing
>> anything. So please vote on the following Doodle:
>>
>> http://doodle.com/poll/nnimebpkx774ppus
>>
>> Also, comments to this thread is more than welcome!
>>
>> I'll end with a comment - Time spent by core developer on maintaining
>> Mongo
>> could be better spent on awesome new features, testing and bug fixing!
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>

From srossillo at smartling.com  Wed Dec 14 00:42:12 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Wed, 14 Dec 2016 00:42:12 -0500
Subject: [keycloak-dev] Admin client interfaces not implemented in
 services
In-Reply-To: <CAJgngAd2vwCJj3UC1jCS0a29825Qj79nPj3ri13DWEr2PLJ6sg@mail.gmail.com>
References: <81BB088B-8D9E-47F3-ABC1-523CC868F1C5@smartling.com>
	<CAJgngAd2vwCJj3UC1jCS0a29825Qj79nPj3ri13DWEr2PLJ6sg@mail.gmail.com>
Message-ID: <74D92A0F-B4BC-438C-AFCF-106439B12D90@smartling.com>

Well, if a redo is in the plans, I think putting a priority on implementing the client interfaces would be 100% beneficial, reduce redundant code, and ensure endpoints are compliant with the SDKs.

:)

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Dec 13, 2016, at 11:32 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> I agree that would be better, but there's not a one to one mapping between the admin client interfaces and the admin services, so not sure if this would be possible at the moment without radically changing the client api. We're also planning on re-doing the admin endpoints completely at some point and introduce a much improved v2.
> 
> On 14 December 2016 at 01:27, Scott Rossillo <srossillo at smartling.com <mailto:srossillo at smartling.com>> wrote:
> I?ve been doing some work around the admin client and endpoints. I noticed that org.keycloak.services.resources.admin.UsersResource does not implement the org.keycloak.admin.client.resource.UsersResource interface. Is there an intentional reason for this?
> 
> It would be easier to keep the server implementation honest to the APIs if the interfaces were implemented plus simplify implementation discovery. Seems there are redundant POJOs as a result of this too.
> 
> What do you guys think about modifying the admin service to implement the client interfaces?
> 
> Thanks,
> Scott
> 
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.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>


From sthorger at redhat.com  Wed Dec 14 00:47:51 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 14 Dec 2016 06:47:51 +0100
Subject: [keycloak-dev] [keycloak-user] ServletFilter Adapter Cookie
	Token Store
In-Reply-To: <D46C4CA0.357A%rlaghuvaram@contractor.lb.com>
References: <D46C4CA0.357A%rlaghuvaram@contractor.lb.com>
Message-ID: <CAJgngAd4Ui6Sj9X2uwxCMF_55TWDkPXKMXby0FaCBqYn=XiNOw@mail.gmail.com>

Cookie token store is supported by the regular adapters, but not the
servlet filter afaik

On 6 December 2016 at 17:11, Laghuvaram, Raghu <
RLaghuvaram at contractor.lb.com> wrote:

> I see that cookie token-store would not be supported until 2.x as per the
> comments in https://issues.jboss.org/browse/KEYCLOAK-2662, Is it fixed in
> any of the recent versions? It seems like its not working in 2.3.0 Final.
>
> Thanks,
> Raghu
>
>
> ________________________________
>
> Notice: This communication may contain privileged and/or confidential
> information. If you are not the intended recipient, please notify the
> sender by email, and immediately delete the message and any attachments
> without copying or disclosing them. LB may, for any reason, intercept,
> access, use, and disclose any information that is communicated by or
> through, or which is stored on, its networks, applications, services, and
> devices.
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From sthorger at redhat.com  Wed Dec 14 01:08:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 14 Dec 2016 07:08:56 +0100
Subject: [keycloak-dev] Admin client interfaces not implemented in
	services
In-Reply-To: <74D92A0F-B4BC-438C-AFCF-106439B12D90@smartling.com>
References: <81BB088B-8D9E-47F3-ABC1-523CC868F1C5@smartling.com>
	<CAJgngAd2vwCJj3UC1jCS0a29825Qj79nPj3ri13DWEr2PLJ6sg@mail.gmail.com>
	<74D92A0F-B4BC-438C-AFCF-106439B12D90@smartling.com>
Message-ID: <CAJgngAfFXj2XJ-v1DadFCungAv0mYKSffo2JjhWYqO1G=r9orQ@mail.gmail.com>

In the plans, but when we get time to do it is another question :(

On 14 December 2016 at 06:42, Scott Rossillo <srossillo at smartling.com>
wrote:

> Well, if a redo is in the plans, I think putting a priority on
> implementing the client interfaces would be 100% beneficial, reduce
> redundant code, and ensure endpoints are compliant with the SDKs.
>
> :)
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> On Dec 13, 2016, at 11:32 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> I agree that would be better, but there's not a one to one mapping between
> the admin client interfaces and the admin services, so not sure if this
> would be possible at the moment without radically changing the client api.
> We're also planning on re-doing the admin endpoints completely at some
> point and introduce a much improved v2.
>
> On 14 December 2016 at 01:27, Scott Rossillo <srossillo at smartling.com>
> wrote:
>
>> I?ve been doing some work around the admin client and endpoints. I
>> noticed that org.keycloak.services.resources.admin.UsersResource does
>> not implement the org.keycloak.admin.client.resource.UsersResource
>> interface. Is there an intentional reason for this?
>>
>> It would be easier to keep the server implementation honest to the APIs
>> if the interfaces were implemented plus simplify implementation discovery.
>> Seems there are redundant POJOs as a result of this too.
>>
>> What do you guys think about modifying the admin service to implement the
>> client interfaces?
>>
>> Thanks,
>> Scott
>>
>> Scott Rossillo
>> Smartling | Senior Software Engineer
>> srossillo at smartling.com
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>

From gambol99 at gmail.com  Wed Dec 14 06:23:26 2016
From: gambol99 at gmail.com (gambol)
Date: Wed, 14 Dec 2016 11:23:26 +0000
Subject: [keycloak-dev] Federated Users
Message-ID: <CA+AP+fOsaiJqafppJNBmm9N6JhMZzm4jDM-vUhUgA1oM2GTpeQ@mail.gmail.com>

Hiya

What would the authentication flow for the following scenario; I've added
SAML provider to Office365, but I only want self-registration and associate
to if a user with the same email address has already been created in the
realm. I've tried disabling the "Create if unique" but it complains with
"No duplication detected"

Rohith

From bburke at redhat.com  Wed Dec 14 09:28:54 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 14 Dec 2016 09:28:54 -0500
Subject: [keycloak-dev] broker import should be local only?
Message-ID: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>

I'm looking at the broker flow code and it seems that we import users 
into whatever storage provider supports adding users. Should this import 
be local only and bypass any User Storage Providers?  This breaks 
backwards compatbility, but I'm not sure the old approach was the 
correct one.

Thoughts?


From sthorger at redhat.com  Wed Dec 14 09:51:11 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 14 Dec 2016 15:51:11 +0100
Subject: [keycloak-dev] broker import should be local only?
In-Reply-To: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>
References: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>
Message-ID: <CAJgngAc+YAoJAX5d3VO48rXE+NwhjKTOfir741CwWf0ihnC+kg@mail.gmail.com>

As the registration form and admin console results in creating new users in
a user storage provider if it supports registration I don't see why it
should be any different for brokered users. They are used "automatically
registered" on first login.

On 14 December 2016 at 15:28, Bill Burke <bburke at redhat.com> wrote:

> I'm looking at the broker flow code and it seems that we import users
> into whatever storage provider supports adding users. Should this import
> be local only and bypass any User Storage Providers?  This breaks
> backwards compatbility, but I'm not sure the old approach was the
> correct one.
>
> Thoughts?
>
> _______________________________________________
> 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 14 11:32:40 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 14 Dec 2016 17:32:40 +0100
Subject: [keycloak-dev] broker import should be local only?
In-Reply-To: <CAJgngAc+YAoJAX5d3VO48rXE+NwhjKTOfir741CwWf0ihnC+kg@mail.gmail.com>
References: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>
	<CAJgngAc+YAoJAX5d3VO48rXE+NwhjKTOfir741CwWf0ihnC+kg@mail.gmail.com>
Message-ID: <bc5bcebc-afd1-c166-aae0-feae35be23ed@redhat.com>

+1

IMO it is perfectly valid to have same user linked to both LDAP (or 
other userStorage) and identity providers. I think that for 
https://issues.jboss.org/browse/KEYCLOAK-2943 we should just have a way 
to bypass calling IdentityProviderMapper.updateBrokeredUser to avoid 
updating read-only user. I think that all those JIRAS are very similar 
and should be addressed together:
https://issues.jboss.org/browse/KEYCLOAK-2943
https://issues.jboss.org/browse/KEYCLOAK-2950
https://issues.jboss.org/browse/KEYCLOAK-3829

Marek


On 14/12/16 15:51, Stian Thorgersen wrote:
> As the registration form and admin console results in creating new users in
> a user storage provider if it supports registration I don't see why it
> should be any different for brokered users. They are used "automatically
> registered" on first login.
>
> On 14 December 2016 at 15:28, Bill Burke <bburke at redhat.com> wrote:
>
>> I'm looking at the broker flow code and it seems that we import users
>> into whatever storage provider supports adding users. Should this import
>> be local only and bypass any User Storage Providers?  This breaks
>> backwards compatbility, but I'm not sure the old approach was the
>> correct one.
>>
>> Thoughts?
>>
>> _______________________________________________
>> 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  Wed Dec 14 11:47:08 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 14 Dec 2016 11:47:08 -0500
Subject: [keycloak-dev] broker import should be local only?
In-Reply-To: <bc5bcebc-afd1-c166-aae0-feae35be23ed@redhat.com>
References: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>
	<CAJgngAc+YAoJAX5d3VO48rXE+NwhjKTOfir741CwWf0ihnC+kg@mail.gmail.com>
	<bc5bcebc-afd1-c166-aae0-feae35be23ed@redhat.com>
Message-ID: <012f6dc9-6025-50d7-08a6-22a358384416@redhat.com>

There is a difference here...linking vs. import.  Linking is linking a 
brokered user to an existing account.  Import is when the user doesn't 
exist.  I guess nobody has had a problem with this so my concern doesn't 
matter.


On 12/14/16 11:32 AM, Marek Posolda wrote:
> +1
>
> IMO it is perfectly valid to have same user linked to both LDAP (or 
> other userStorage) and identity providers. I think that for 
> https://issues.jboss.org/browse/KEYCLOAK-2943 we should just have a 
> way to bypass calling IdentityProviderMapper.updateBrokeredUser to 
> avoid updating read-only user. I think that all those JIRAS are very 
> similar and should be addressed together:
> https://issues.jboss.org/browse/KEYCLOAK-2943
> https://issues.jboss.org/browse/KEYCLOAK-2950
> https://issues.jboss.org/browse/KEYCLOAK-3829
>
> Marek
>
>
> On 14/12/16 15:51, Stian Thorgersen wrote:
>> As the registration form and admin console results in creating new 
>> users in
>> a user storage provider if it supports registration I don't see why it
>> should be any different for brokered users. They are used "automatically
>> registered" on first login.
>>
>> On 14 December 2016 at 15:28, Bill Burke <bburke at redhat.com> wrote:
>>
>>> I'm looking at the broker flow code and it seems that we import users
>>> into whatever storage provider supports adding users. Should this 
>>> import
>>> be local only and bypass any User Storage Providers?  This breaks
>>> backwards compatbility, but I'm not sure the old approach was the
>>> correct one.
>>>
>>> Thoughts?
>>>
>>> _______________________________________________
>>> 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 dpassos at redhat.com  Wed Dec 14 13:19:36 2016
From: dpassos at redhat.com (Daniel Passos)
Date: Wed, 14 Dec 2016 16:19:36 -0200
Subject: [keycloak-dev] Keycloak release process document
Message-ID: <CADF=h2uBfjmsZ7-PJkRwkxEaW+5POK449qqPmeTbU58bZCzmGQ@mail.gmail.com>

Hi all,

I realized openshift-wildfly-cartridge[1] and the released process[2] links
are broken in openshift-keycloak-cartridge README[3] and I wanna fix it. I
have found the correct one for openshift-wildfly-cartridge but not for
released process. I have found the links bellow but seems all of that did
not work anymore.

https://issues.jboss.org/browse/KEYCLOAK-1756
http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001885.html
https://issues.jboss.org/browse/KEYCLOAK-1756

Should I remove that section there or link to some other place/document?

[1]
https://github.com/keycloak/openshift-keycloak-cartridge#thanks-to-the-following
[2]
https://github.com/keycloak/openshift-keycloak-cartridge#updating-keycloak
[3]
https://github.com/keycloak/openshift-keycloak-cartridge/blob/master/README.md


-- 
-- Passos

From sthorger at redhat.com  Thu Dec 15 04:36:33 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 15 Dec 2016 10:36:33 +0100
Subject: [keycloak-dev] Keycloak release process document
In-Reply-To: <CADF=h2uBfjmsZ7-PJkRwkxEaW+5POK449qqPmeTbU58bZCzmGQ@mail.gmail.com>
References: <CADF=h2uBfjmsZ7-PJkRwkxEaW+5POK449qqPmeTbU58bZCzmGQ@mail.gmail.com>
Message-ID: <CAJgngAdtp2mK1WzbmkjqSNb8=F5cPKP0VG_7Y5Qphf+GaMA9qw@mail.gmail.com>

Just remove it is fine. The cartridge is actually updated by a CI job
automatically when Keycloak release is done (it failed for 2.4 for some
reason, but no one has complained so I haven't prioritized fixing it).

On 14 December 2016 at 19:19, Daniel Passos <dpassos at redhat.com> wrote:

> Hi all,
>
> I realized openshift-wildfly-cartridge[1] and the released process[2] links
> are broken in openshift-keycloak-cartridge README[3] and I wanna fix it. I
> have found the correct one for openshift-wildfly-cartridge but not for
> released process. I have found the links bellow but seems all of that did
> not work anymore.
>
> https://issues.jboss.org/browse/KEYCLOAK-1756
> http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001885.html
> https://issues.jboss.org/browse/KEYCLOAK-1756
>
> Should I remove that section there or link to some other place/document?
>
> [1]
> https://github.com/keycloak/openshift-keycloak-cartridge#
> thanks-to-the-following
> [2]
> https://github.com/keycloak/openshift-keycloak-cartridge#updating-keycloak
> [3]
> https://github.com/keycloak/openshift-keycloak-cartridge/
> blob/master/README.md
>
>
> --
> -- Passos
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Dec 15 04:38:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 15 Dec 2016 10:38:04 +0100
Subject: [keycloak-dev] broker import should be local only?
In-Reply-To: <012f6dc9-6025-50d7-08a6-22a358384416@redhat.com>
References: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>
	<CAJgngAc+YAoJAX5d3VO48rXE+NwhjKTOfir741CwWf0ihnC+kg@mail.gmail.com>
	<bc5bcebc-afd1-c166-aae0-feae35be23ed@redhat.com>
	<012f6dc9-6025-50d7-08a6-22a358384416@redhat.com>
Message-ID: <CAJgngAeZqBCXYSyNtFkr5T7TzTB=XmGdS=CLiru-dkT4-kgP9A@mail.gmail.com>

Someone might want to have all their users in the LDAP server. Including
social registered, self registered and registered by admin in KC admin
console.

Do we have a way to control where new users are created?

On 14 December 2016 at 17:47, Bill Burke <bburke at redhat.com> wrote:

> There is a difference here...linking vs. import.  Linking is linking a
> brokered user to an existing account.  Import is when the user doesn't
> exist.  I guess nobody has had a problem with this so my concern doesn't
> matter.
>
>
>
> On 12/14/16 11:32 AM, Marek Posolda wrote:
>
>> +1
>>
>> IMO it is perfectly valid to have same user linked to both LDAP (or other
>> userStorage) and identity providers. I think that for
>> https://issues.jboss.org/browse/KEYCLOAK-2943 we should just have a way
>> to bypass calling IdentityProviderMapper.updateBrokeredUser to avoid
>> updating read-only user. I think that all those JIRAS are very similar and
>> should be addressed together:
>> https://issues.jboss.org/browse/KEYCLOAK-2943
>> https://issues.jboss.org/browse/KEYCLOAK-2950
>> https://issues.jboss.org/browse/KEYCLOAK-3829
>>
>> Marek
>>
>>
>> On 14/12/16 15:51, Stian Thorgersen wrote:
>>
>>> As the registration form and admin console results in creating new users
>>> in
>>> a user storage provider if it supports registration I don't see why it
>>> should be any different for brokered users. They are used "automatically
>>> registered" on first login.
>>>
>>> On 14 December 2016 at 15:28, Bill Burke <bburke at redhat.com> wrote:
>>>
>>> I'm looking at the broker flow code and it seems that we import users
>>>> into whatever storage provider supports adding users. Should this import
>>>> be local only and bypass any User Storage Providers?  This breaks
>>>> backwards compatbility, but I'm not sure the old approach was the
>>>> correct one.
>>>>
>>>> Thoughts?
>>>>
>>>> _______________________________________________
>>>> 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 15 05:17:25 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 15 Dec 2016 11:17:25 +0100
Subject: [keycloak-dev] broker import should be local only?
In-Reply-To: <CAJgngAeZqBCXYSyNtFkr5T7TzTB=XmGdS=CLiru-dkT4-kgP9A@mail.gmail.com>
References: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>
	<CAJgngAc+YAoJAX5d3VO48rXE+NwhjKTOfir741CwWf0ihnC+kg@mail.gmail.com>
	<bc5bcebc-afd1-c166-aae0-feae35be23ed@redhat.com>
	<012f6dc9-6025-50d7-08a6-22a358384416@redhat.com>
	<CAJgngAeZqBCXYSyNtFkr5T7TzTB=XmGdS=CLiru-dkT4-kgP9A@mail.gmail.com>
Message-ID: <dbbcd384-6a0d-6270-09a6-a6b2d8ec830c@redhat.com>

We have various methods on KeycloakSession (users(), userLocalStorage(), 
...), so in the code we have a way to specify that some user should be 
just local KC user. For example export/import is importing just to local 
DB as users already exists in LDAP.

We don't have a way for people to configure (eg. admin configures "Don't 
save broker-imported users into the LDAP" ). Not sure if we need that? 
As Bill mentioned, nobody requested this yet?

But if really needed for a broker, they can override authenticator for 
"First Broker Login" flow though. If we want to support OOTB, we can add 
a flag to this authenticator whether to save broker-imported user just 
to the "local" DB or whether use userStorage layer too. But not sure if 
rather wait if it's needed by someone then introduce another flag? :)

Marek


On 15/12/16 10:38, Stian Thorgersen wrote:
> Someone might want to have all their users in the LDAP server. 
> Including social registered, self registered and registered by admin 
> in KC admin console.
>
> Do we have a way to control where new users are created?
>
> On 14 December 2016 at 17:47, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     There is a difference here...linking vs. import.  Linking is
>     linking a brokered user to an existing account.  Import is when
>     the user doesn't exist.  I guess nobody has had a problem with
>     this so my concern doesn't matter.
>
>
>
>     On 12/14/16 11:32 AM, Marek Posolda wrote:
>
>         +1
>
>         IMO it is perfectly valid to have same user linked to both
>         LDAP (or other userStorage) and identity providers. I think
>         that for https://issues.jboss.org/browse/KEYCLOAK-2943
>         <https://issues.jboss.org/browse/KEYCLOAK-2943> we should just
>         have a way to bypass calling
>         IdentityProviderMapper.updateBrokeredUser to avoid updating
>         read-only user. I think that all those JIRAS are very similar
>         and should be addressed together:
>         https://issues.jboss.org/browse/KEYCLOAK-2943
>         <https://issues.jboss.org/browse/KEYCLOAK-2943>
>         https://issues.jboss.org/browse/KEYCLOAK-2950
>         <https://issues.jboss.org/browse/KEYCLOAK-2950>
>         https://issues.jboss.org/browse/KEYCLOAK-3829
>         <https://issues.jboss.org/browse/KEYCLOAK-3829>
>
>         Marek
>
>
>         On 14/12/16 15:51, Stian Thorgersen wrote:
>
>             As the registration form and admin console results in
>             creating new users in
>             a user storage provider if it supports registration I
>             don't see why it
>             should be any different for brokered users. They are used
>             "automatically
>             registered" on first login.
>
>             On 14 December 2016 at 15:28, Bill Burke
>             <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>
>                 I'm looking at the broker flow code and it seems that
>                 we import users
>                 into whatever storage provider supports adding users.
>                 Should this import
>                 be local only and bypass any User Storage Providers? 
>                 This breaks
>                 backwards compatbility, but I'm not sure the old
>                 approach was the
>                 correct one.
>
>                 Thoughts?
>
>                 _______________________________________________
>                 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>
>
>             _______________________________________________
>             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>
>
>
>
>
>


From sthorger at redhat.com  Thu Dec 15 05:21:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 15 Dec 2016 11:21:20 +0100
Subject: [keycloak-dev] broker import should be local only?
In-Reply-To: <dbbcd384-6a0d-6270-09a6-a6b2d8ec830c@redhat.com>
References: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>
	<CAJgngAc+YAoJAX5d3VO48rXE+NwhjKTOfir741CwWf0ihnC+kg@mail.gmail.com>
	<bc5bcebc-afd1-c166-aae0-feae35be23ed@redhat.com>
	<012f6dc9-6025-50d7-08a6-22a358384416@redhat.com>
	<CAJgngAeZqBCXYSyNtFkr5T7TzTB=XmGdS=CLiru-dkT4-kgP9A@mail.gmail.com>
	<dbbcd384-6a0d-6270-09a6-a6b2d8ec830c@redhat.com>
Message-ID: <CAJgngAdfrp26Fbh7ZSr6D4=ThK+HvA9qeR5D33LQ0Ff3aa=nmw@mail.gmail.com>

I don't mean for a broker only, I mean for all new users". Can we say all
new users should be created locally and not in LDAP?

On 15 December 2016 at 11:17, Marek Posolda <mposolda at redhat.com> wrote:

> We have various methods on KeycloakSession (users(), userLocalStorage(),
> ...), so in the code we have a way to specify that some user should be just
> local KC user. For example export/import is importing just to local DB as
> users already exists in LDAP.
>
> We don't have a way for people to configure (eg. admin configures "Don't
> save broker-imported users into the LDAP" ). Not sure if we need that? As
> Bill mentioned, nobody requested this yet?
>
> But if really needed for a broker, they can override authenticator for
> "First Broker Login" flow though. If we want to support OOTB, we can add a
> flag to this authenticator whether to save broker-imported user just to the
> "local" DB or whether use userStorage layer too. But not sure if rather
> wait if it's needed by someone then introduce another flag? :)
>
> Marek
>
>
>
> On 15/12/16 10:38, Stian Thorgersen wrote:
>
> Someone might want to have all their users in the LDAP server. Including
> social registered, self registered and registered by admin in KC admin
> console.
>
> Do we have a way to control where new users are created?
>
> On 14 December 2016 at 17:47, Bill Burke <bburke at redhat.com> wrote:
>
>> There is a difference here...linking vs. import.  Linking is linking a
>> brokered user to an existing account.  Import is when the user doesn't
>> exist.  I guess nobody has had a problem with this so my concern doesn't
>> matter.
>>
>>
>>
>> On 12/14/16 11:32 AM, Marek Posolda wrote:
>>
>>> +1
>>>
>>> IMO it is perfectly valid to have same user linked to both LDAP (or
>>> other userStorage) and identity providers. I think that for
>>> https://issues.jboss.org/browse/KEYCLOAK-2943 we should just have a way
>>> to bypass calling IdentityProviderMapper.updateBrokeredUser to avoid
>>> updating read-only user. I think that all those JIRAS are very similar and
>>> should be addressed together:
>>> https://issues.jboss.org/browse/KEYCLOAK-2943
>>> https://issues.jboss.org/browse/KEYCLOAK-2950
>>> https://issues.jboss.org/browse/KEYCLOAK-3829
>>>
>>> Marek
>>>
>>>
>>> On 14/12/16 15:51, Stian Thorgersen wrote:
>>>
>>>> As the registration form and admin console results in creating new
>>>> users in
>>>> a user storage provider if it supports registration I don't see why it
>>>> should be any different for brokered users. They are used "automatically
>>>> registered" on first login.
>>>>
>>>> On 14 December 2016 at 15:28, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>> I'm looking at the broker flow code and it seems that we import users
>>>>> into whatever storage provider supports adding users. Should this
>>>>> import
>>>>> be local only and bypass any User Storage Providers?  This breaks
>>>>> backwards compatbility, but I'm not sure the old approach was the
>>>>> correct one.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> _______________________________________________
>>>>> 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 15 05:40:04 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 15 Dec 2016 11:40:04 +0100
Subject: [keycloak-dev] broker import should be local only?
In-Reply-To: <CAJgngAdfrp26Fbh7ZSr6D4=ThK+HvA9qeR5D33LQ0Ff3aa=nmw@mail.gmail.com>
References: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>
	<CAJgngAc+YAoJAX5d3VO48rXE+NwhjKTOfir741CwWf0ihnC+kg@mail.gmail.com>
	<bc5bcebc-afd1-c166-aae0-feae35be23ed@redhat.com>
	<012f6dc9-6025-50d7-08a6-22a358384416@redhat.com>
	<CAJgngAeZqBCXYSyNtFkr5T7TzTB=XmGdS=CLiru-dkT4-kgP9A@mail.gmail.com>
	<dbbcd384-6a0d-6270-09a6-a6b2d8ec830c@redhat.com>
	<CAJgngAdfrp26Fbh7ZSr6D4=ThK+HvA9qeR5D33LQ0Ff3aa=nmw@mail.gmail.com>
Message-ID: <554a1000-bdfa-1014-2223-cfe2f59b9b85@redhat.com>

Yes, the LDAP provider has "Synchronize registrations" flag on it.

Custom userStorage implementation can decide as well what to do. It 
seems that if they don't implement UserRegistrationProvider interface 
(or return null from "addUser" like LDAP provider is doing), then user 
will be added to Keycloak DB only.

Marek

On 15/12/16 11:21, Stian Thorgersen wrote:
> I don't mean for a broker only, I mean for all new users". Can we say 
> all new users should be created locally and not in LDAP?
>
> On 15 December 2016 at 11:17, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     We have various methods on KeycloakSession (users(),
>     userLocalStorage(), ...), so in the code we have a way to specify
>     that some user should be just local KC user. For example
>     export/import is importing just to local DB as users already
>     exists in LDAP.
>
>     We don't have a way for people to configure (eg. admin configures
>     "Don't save broker-imported users into the LDAP" ). Not sure if we
>     need that? As Bill mentioned, nobody requested this yet?
>
>     But if really needed for a broker, they can override authenticator
>     for "First Broker Login" flow though. If we want to support OOTB,
>     we can add a flag to this authenticator whether to save
>     broker-imported user just to the "local" DB or whether use
>     userStorage layer too. But not sure if rather wait if it's needed
>     by someone then introduce another flag? :)
>
>     Marek
>
>
>
>     On 15/12/16 10:38, Stian Thorgersen wrote:
>>     Someone might want to have all their users in the LDAP server.
>>     Including social registered, self registered and registered by
>>     admin in KC admin console.
>>
>>     Do we have a way to control where new users are created?
>>
>>     On 14 December 2016 at 17:47, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         There is a difference here...linking vs. import.  Linking is
>>         linking a brokered user to an existing account. Import is
>>         when the user doesn't exist.  I guess nobody has had a
>>         problem with this so my concern doesn't matter.
>>
>>
>>
>>         On 12/14/16 11:32 AM, Marek Posolda wrote:
>>
>>             +1
>>
>>             IMO it is perfectly valid to have same user linked to
>>             both LDAP (or other userStorage) and identity providers.
>>             I think that for
>>             https://issues.jboss.org/browse/KEYCLOAK-2943
>>             <https://issues.jboss.org/browse/KEYCLOAK-2943> we should
>>             just have a way to bypass calling
>>             IdentityProviderMapper.updateBrokeredUser to avoid
>>             updating read-only user. I think that all those JIRAS are
>>             very similar and should be addressed together:
>>             https://issues.jboss.org/browse/KEYCLOAK-2943
>>             <https://issues.jboss.org/browse/KEYCLOAK-2943>
>>             https://issues.jboss.org/browse/KEYCLOAK-2950
>>             <https://issues.jboss.org/browse/KEYCLOAK-2950>
>>             https://issues.jboss.org/browse/KEYCLOAK-3829
>>             <https://issues.jboss.org/browse/KEYCLOAK-3829>
>>
>>             Marek
>>
>>
>>             On 14/12/16 15:51, Stian Thorgersen wrote:
>>
>>                 As the registration form and admin console results in
>>                 creating new users in
>>                 a user storage provider if it supports registration I
>>                 don't see why it
>>                 should be any different for brokered users. They are
>>                 used "automatically
>>                 registered" on first login.
>>
>>                 On 14 December 2016 at 15:28, Bill Burke
>>                 <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>
>>                     I'm looking at the broker flow code and it seems
>>                     that we import users
>>                     into whatever storage provider supports adding
>>                     users. Should this import
>>                     be local only and bypass any User Storage
>>                     Providers?  This breaks
>>                     backwards compatbility, but I'm not sure the old
>>                     approach was the
>>                     correct one.
>>
>>                     Thoughts?
>>
>>                     _______________________________________________
>>                     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>
>>
>>                 _______________________________________________
>>                 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>
>>
>>
>>
>>
>>
>
>


From sthorger at redhat.com  Thu Dec 15 08:36:31 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 15 Dec 2016 14:36:31 +0100
Subject: [keycloak-dev] broker import should be local only?
In-Reply-To: <554a1000-bdfa-1014-2223-cfe2f59b9b85@redhat.com>
References: <cee154c7-6440-1a5e-2fb7-54216ed6eb6e@redhat.com>
	<CAJgngAc+YAoJAX5d3VO48rXE+NwhjKTOfir741CwWf0ihnC+kg@mail.gmail.com>
	<bc5bcebc-afd1-c166-aae0-feae35be23ed@redhat.com>
	<012f6dc9-6025-50d7-08a6-22a358384416@redhat.com>
	<CAJgngAeZqBCXYSyNtFkr5T7TzTB=XmGdS=CLiru-dkT4-kgP9A@mail.gmail.com>
	<dbbcd384-6a0d-6270-09a6-a6b2d8ec830c@redhat.com>
	<CAJgngAdfrp26Fbh7ZSr6D4=ThK+HvA9qeR5D33LQ0Ff3aa=nmw@mail.gmail.com>
	<554a1000-bdfa-1014-2223-cfe2f59b9b85@redhat.com>
Message-ID: <CAJgngAdF2hmt+ntX_p5KLp6Z4BVMoFc5XxuradXYJb8UhJhQfg@mail.gmail.com>

Seems like we've got what we need then

On 15 December 2016 at 11:40, Marek Posolda <mposolda at redhat.com> wrote:

> Yes, the LDAP provider has "Synchronize registrations" flag on it.
>
> Custom userStorage implementation can decide as well what to do. It seems
> that if they don't implement UserRegistrationProvider interface (or return
> null from "addUser" like LDAP provider is doing), then user will be added
> to Keycloak DB only.
>
> Marek
>
>
> On 15/12/16 11:21, Stian Thorgersen wrote:
>
> I don't mean for a broker only, I mean for all new users". Can we say all
> new users should be created locally and not in LDAP?
>
> On 15 December 2016 at 11:17, Marek Posolda <mposolda at redhat.com> wrote:
>
>> We have various methods on KeycloakSession (users(), userLocalStorage(),
>> ...), so in the code we have a way to specify that some user should be just
>> local KC user. For example export/import is importing just to local DB as
>> users already exists in LDAP.
>>
>> We don't have a way for people to configure (eg. admin configures "Don't
>> save broker-imported users into the LDAP" ). Not sure if we need that? As
>> Bill mentioned, nobody requested this yet?
>>
>> But if really needed for a broker, they can override authenticator for
>> "First Broker Login" flow though. If we want to support OOTB, we can add a
>> flag to this authenticator whether to save broker-imported user just to the
>> "local" DB or whether use userStorage layer too. But not sure if rather
>> wait if it's needed by someone then introduce another flag? :)
>>
>> Marek
>>
>>
>>
>> On 15/12/16 10:38, Stian Thorgersen wrote:
>>
>> Someone might want to have all their users in the LDAP server. Including
>> social registered, self registered and registered by admin in KC admin
>> console.
>>
>> Do we have a way to control where new users are created?
>>
>> On 14 December 2016 at 17:47, Bill Burke <bburke at redhat.com> wrote:
>>
>>> There is a difference here...linking vs. import.  Linking is linking a
>>> brokered user to an existing account.  Import is when the user doesn't
>>> exist.  I guess nobody has had a problem with this so my concern doesn't
>>> matter.
>>>
>>>
>>>
>>> On 12/14/16 11:32 AM, Marek Posolda wrote:
>>>
>>>> +1
>>>>
>>>> IMO it is perfectly valid to have same user linked to both LDAP (or
>>>> other userStorage) and identity providers. I think that for
>>>> https://issues.jboss.org/browse/KEYCLOAK-2943 we should just have a
>>>> way to bypass calling IdentityProviderMapper.updateBrokeredUser to
>>>> avoid updating read-only user. I think that all those JIRAS are very
>>>> similar and should be addressed together:
>>>> https://issues.jboss.org/browse/KEYCLOAK-2943
>>>> https://issues.jboss.org/browse/KEYCLOAK-2950
>>>> https://issues.jboss.org/browse/KEYCLOAK-3829
>>>>
>>>> Marek
>>>>
>>>>
>>>> On 14/12/16 15:51, Stian Thorgersen wrote:
>>>>
>>>>> As the registration form and admin console results in creating new
>>>>> users in
>>>>> a user storage provider if it supports registration I don't see why it
>>>>> should be any different for brokered users. They are used
>>>>> "automatically
>>>>> registered" on first login.
>>>>>
>>>>> On 14 December 2016 at 15:28, Bill Burke <bburke at redhat.com> wrote:
>>>>>
>>>>> I'm looking at the broker flow code and it seems that we import users
>>>>>> into whatever storage provider supports adding users. Should this
>>>>>> import
>>>>>> be local only and bypass any User Storage Providers?  This breaks
>>>>>> backwards compatbility, but I'm not sure the old approach was the
>>>>>> correct one.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 sthorger at redhat.com  Fri Dec 16 04:02:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 16 Dec 2016 10:02:49 +0100
Subject: [keycloak-dev] Keycloak 2.5.0.CR1 release
Message-ID: <CAJgngAeRJN8LcNRWLa8U=UNfJvZTuqxF7ctPvcok35wAnW=RAw@mail.gmail.com>

2.5.0.CR1 will be released on 21st December. Due to Christmas breaks
2.5.0.Final will not be released until 4th January.

I want all changes in by end of 19th December. Everyone around should help
with testing on Tuesday 20th.

Please check what issues are assigned to you for Keycloak 2.5.0.CR1 and
RH-SSO 7.1.0.ER3. If you don't believe you can complete yours by end of
Monday 19th December let me know.

From gerbermichi at me.com  Fri Dec 16 07:10:24 2016
From: gerbermichi at me.com (Michael Gerber)
Date: Fri, 16 Dec 2016 12:10:24 +0000 (GMT)
Subject: [keycloak-dev] IE login in new session logs out the other user
Message-ID: <9a2dab98-5ef0-4556-8a8d-c7f341697355@me.com>

Hi,

I am using Windows 7 and Internet Explorer 11.

IE can create a new window with a new session. It should be possible to work with two different users in this two windows. However, the second login logs the older user out, because of the?KEYCLOAK_SESSION cookie which is stored in the "C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Cookies" directory. The problem is, that this cookie is not set to httpOnly.?

Is this a known bug? Or can I solve this problem?

kind regards
Michael

From sthorger at redhat.com  Fri Dec 16 09:13:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 16 Dec 2016 15:13:50 +0100
Subject: [keycloak-dev] IE login in new session logs out the other user
In-Reply-To: <9a2dab98-5ef0-4556-8a8d-c7f341697355@me.com>
References: <9a2dab98-5ef0-4556-8a8d-c7f341697355@me.com>
Message-ID: <CAJgngAfyWvmLftBqk+KR2BWZC0PqfvZe-jz3tB0LU347290k5Q@mail.gmail.com>

Does sound like IE actually creates a clean new session as it's sharing
some cookies.

On 16 December 2016 at 13:10, Michael Gerber <gerbermichi at me.com> wrote:

> Hi,
>
> I am using Windows 7 and Internet Explorer 11.
>
> IE can create a new window with a new session. It should be possible to
> work with two different users in this two windows. However, the second
> login logs the older user out, because of the KEYCLOAK_SESSION cookie which
> is stored in the "C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Cookies"
> directory. The problem is, that this cookie is not set to httpOnly.
>
> Is this a known bug? Or can I solve this problem?
>
> kind regards
> Michael
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Fri Dec 16 09:13:58 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 16 Dec 2016 15:13:58 +0100
Subject: [keycloak-dev] IE login in new session logs out the other user
In-Reply-To: <CAJgngAfyWvmLftBqk+KR2BWZC0PqfvZe-jz3tB0LU347290k5Q@mail.gmail.com>
References: <9a2dab98-5ef0-4556-8a8d-c7f341697355@me.com>
	<CAJgngAfyWvmLftBqk+KR2BWZC0PqfvZe-jz3tB0LU347290k5Q@mail.gmail.com>
Message-ID: <CAJgngAeXsCnYh=-S6cvNZKB4-oN_hEw+y_x5ntgu4wQswcSAug@mail.gmail.com>

... Doesn't

On 16 December 2016 at 15:13, Stian Thorgersen <sthorger at redhat.com> wrote:

> Does sound like IE actually creates a clean new session as it's sharing
> some cookies.
>
> On 16 December 2016 at 13:10, Michael Gerber <gerbermichi at me.com> wrote:
>
>> Hi,
>>
>> I am using Windows 7 and Internet Explorer 11.
>>
>> IE can create a new window with a new session. It should be possible to
>> work with two different users in this two windows. However, the second
>> login logs the older user out, because of the KEYCLOAK_SESSION cookie which
>> is stored in the "C:\Users\{username}\AppData\R
>> oaming\Microsoft\Windows\Cookies" directory. The problem is, that this
>> cookie is not set to httpOnly.
>>
>> Is this a known bug? Or can I solve this problem?
>>
>> kind regards
>> Michael
>> _______________________________________________
>> 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 16 09:44:40 2016
From: gerbermichi at me.com (Michael Gerber)
Date: Fri, 16 Dec 2016 14:44:40 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_Re=3A__IE_login_in_new_session_logs_out?=
 =?utf-8?q?_the_other_user?=
Message-ID: <fd3a727d-932e-4a24-8d88-e240c3005a22@me.com>

That's true. It shares the cookie which does not have set httpOnly to true.

It's obviously an IE fail, however, I need a workaround for that :)
Do you have any idea how to solve this?

Am 16. Dezember 2016 um 15:14 schrieb Stian Thorgersen <sthorger at redhat.com>:

... Doesn't

On 16 December 2016 at 15:13, Stian Thorgersen <sthorger at redhat.com> wrote:
Does sound like IE actually creates a clean new session as it's sharing some cookies.

On 16 December 2016 at 13:10, Michael Gerber <gerbermichi at me.com> wrote:
Hi,

I am using Windows 7 and Internet Explorer 11.

IE can create a new window with a new session. It should be possible to work with two different users in this two windows. However, the second login logs the older user out, because of the?KEYCLOAK_SESSION cookie which is stored in the "C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Cookies" directory. The problem is, that this cookie is not set to httpOnly.?

Is this a known bug? Or can I solve this problem?

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



From sthorger at redhat.com  Fri Dec 16 10:00:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 16 Dec 2016 16:00:21 +0100
Subject: [keycloak-dev] IE login in new session logs out the other user
In-Reply-To: <fd3a727d-932e-4a24-8d88-e240c3005a22@me.com>
References: <fd3a727d-932e-4a24-8d88-e240c3005a22@me.com>
Message-ID: <CAJgngAemCiQwmKHkLJ5Om-Rz-bZMB6RjVWtwimLQmc0of1TN+Q@mail.gmail.com>

Use Chrome or Firefox ;)

On 16 December 2016 at 15:44, Michael Gerber <gerbermichi at me.com> wrote:

> That's true. It shares the cookie which does not have set httpOnly to true.
>
> It's obviously an IE fail, however, I need a workaround for that :)
> Do you have any idea how to solve this?
>
> Am 16. Dezember 2016 um 15:14 schrieb Stian Thorgersen <
> sthorger at redhat.com>:
>
> ... Doesn't
>
> On 16 December 2016 at 15:13, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Does sound like IE actually creates a clean new session as it's sharing
>> some cookies.
>>
>> On 16 December 2016 at 13:10, Michael Gerber <gerbermichi at me.com> wrote:
>>
>>> Hi,
>>>
>>> I am using Windows 7 and Internet Explorer 11.
>>>
>>> IE can create a new window with a new session. It should be possible to
>>> work with two different users in this two windows. However, the second
>>> login logs the older user out, because of the KEYCLOAK_SESSION cookie which
>>> is stored in the "C:\Users\{username}\AppData\R
>>> oaming\Microsoft\Windows\Cookies" directory. The problem is, that this
>>> cookie is not set to httpOnly.
>>>
>>> Is this a known bug? Or can I solve this problem?
>>>
>>> kind regards
>>> Michael
>>> _______________________________________________
>>> 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 16 10:36:37 2016
From: gerbermichi at me.com (Michael Gerber)
Date: Fri, 16 Dec 2016 16:36:37 +0100
Subject: [keycloak-dev] IE login in new session logs out the other user
In-Reply-To: <CAJgngAemCiQwmKHkLJ5Om-Rz-bZMB6RjVWtwimLQmc0of1TN+Q@mail.gmail.com>
References: <fd3a727d-932e-4a24-8d88-e240c3005a22@me.com>
	<CAJgngAemCiQwmKHkLJ5Om-Rz-bZMB6RjVWtwimLQmc0of1TN+Q@mail.gmail.com>
Message-ID: <FD5090FF-048A-49D9-A991-191C3A503228@me.com>

Why is the KEYLOAK_SESSION cookie not an http only cookie? Is there a reason for that?


> On 16 Dec 2016, at 16:00, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> Use Chrome or Firefox ;)
> 
>> On 16 December 2016 at 15:44, Michael Gerber <gerbermichi at me.com> wrote:
>> That's true. It shares the cookie which does not have set httpOnly to true.
>> 
>> It's obviously an IE fail, however, I need a workaround for that :)
>> Do you have any idea how to solve this?
>> 
>>> Am 16. Dezember 2016 um 15:14 schrieb Stian Thorgersen <sthorger at redhat.com>:
>>> 
>> 
>>> ... Doesn't
>>> 
>>>> On 16 December 2016 at 15:13, Stian Thorgersen <sthorger at redhat.com> wrote:
>>>> Does sound like IE actually creates a clean new session as it's sharing some cookies.
>>>> 
>>>>> On 16 December 2016 at 13:10, Michael Gerber <gerbermichi at me.com> wrote:
>>>>> Hi,
>>>>> 
>>>>> I am using Windows 7 and Internet Explorer 11.
>>>>> 
>>>>> IE can create a new window with a new session. It should be possible to work with two different users in this two windows. However, the second login logs the older user out, because of the KEYCLOAK_SESSION cookie which is stored in the "C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Cookies" directory. The problem is, that this cookie is not set to httpOnly. 
>>>>> 
>>>>> Is this a known bug? Or can I solve this problem?
>>>>> 
>>>>> kind regards
>>>>> Michael
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> 
>>> 
> 

From hmlnarik at redhat.com  Fri Dec 16 14:12:10 2016
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 16 Dec 2016 20:12:10 +0100
Subject: [keycloak-dev] Database types for primary and foreign keys
Message-ID: <56f78fcd-8087-4757-9bcf-396e63a1d324@redhat.com>

Hi All,

Apologies for a long e-mail.

TLDR: We need to define format of primary keys (UUID) so that it is possible to transform the primary and foreign keys from VARCHAR(36) columns into database-native binary format. This is in particular important to document in 2.5 in Storage Ids section of the new User Storage SPI [1]

Long version:

I have looked at current database model and while generally it looks well, there is an interesting issue with primary / foreign keys that causes performance degradation on both Java and - most importantly - database side, causing even deadlocks for some databases.

The issue comes from database handling of IDs. IDs are in fact UUIDs, i.e. series of bytes that are represented by Strings in KC JPA classes. Why this causes performance degradation is due to various representations conversions (byte array vs String in Java) and - most importantly for database - character set conversions. In the worst case, The conversions occur both in JDBC driver and the database. The consequences are demonstrated by Jira issue KEYCLOAK-3210 [2] when several simultaneous requests lead to deadlocking the database.

When JDBC driver obtains a string, it converts its representation into a character set understood by database. Database might need to convert the string to a character set specified for the column. This is nicely illustrated in MSSQL which makes distinction between VARCHAR (8-bit codepages) and NVARCHAR (UCS-2 Unicode charset). IDs are VARCHARs which is indeed an efficient way to use strings that consist of ASCII-only characters (though not optimal for UUID, read below). However, if Unicode characters are to be supported, MSSQL JDBC driver sends all character parameters as Unicode Strings [3]. Database then performs a conversion from Unicode to 8-bit charset which generally loses some data. To account for this loss, instead of performing an index scan that directly points to a requested row, it returns a range where the requested record should be. This has fatal impact on performance. For more detailed analysis of the resulting plans, see comment in [2].

Clearly, the scan by id should be fast and the format of IDs in database matters. It should avoid conversions as much as possible. Hence the following plan came:

* In the result, all primary keys and corresponding keys have to be represented by binary UUID data type (where supported, some databases represent UUID as e.g. VARBINARY(16)), i.e. 16 bytes instead of 36 bytes
* All keys in the JPA classes should be of type UUID, not String

As a result, database indices get smaller (16 bytes of indexed data per record vs 36 bytes as it is now in case of 8-bit storage of characters), and no character conversions are in place, hence the overall performance increases.

This task is a slighty big one so it won't fit into KC 2.5 timeframe, but we should definitely aim for 3.0.

This has several preconditions:
* The String keys in keycloak JPA classes, wherever used, are restricted to UUID format
* This format is documented and respected by all custom implementations, namely User Storage implementations.
* There exists conversion from String to native UUID for used databases (this is certainly possible for PostgreSQL MSSQL, DB2, and MySQL, most likely others)

Similarly to JPA, Infinispan classes should be revisited and optimized to save some bytes that might be important for cluster replication by replacing String with UUIDs

Thoughts?

--Hynek

[1] https://github.com/keycloak/server_development_guide/blob/6b82f0868c0d7a148a084a30e0d8fda192f01502/topics/user-storage/model-interfaces.adoc
[2] https://issues.jboss.org/browse/KEYCLOAK-3210
[3] https://msdn.microsoft.com/en-us/library/ms378857(v=sql.110).aspx


From bburke at redhat.com  Fri Dec 16 15:30:34 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 Dec 2016 15:30:34 -0500
Subject: [keycloak-dev] Database types for primary and foreign keys
In-Reply-To: <56f78fcd-8087-4757-9bcf-396e63a1d324@redhat.com>
References: <56f78fcd-8087-4757-9bcf-396e63a1d324@redhat.com>
Message-ID: <e11fd30f-3297-18f6-0b2d-977e8757da23@redhat.com>

Not every key is a simple UUID.  Specifically any table that references 
a user:  UserFederatedStorageProvider tables and offline tokens.  THis 
is because of the user storage spi.  These tables must be searchable by 
user id which can either be a UUID (keycloak database) or  "f:" + 
componentUUID + ":" + opaque_external_identifier (External User Storage 
Provider database).  So breaking up a User Storage SPI USER_ID isn't 
going to help as you'll still need to create an index based on these 
columns.  Also, there's been some talk of using this ID format for other 
model types like Roles and Groups.

Also, Everything has to remain backward compatible.  We will need to 
support existing databases.  So, can you support changing to a 
completely different id format and type without screwing up existing 
databases???  I don't think doing a full export/import to/from JSON is 
going to work with large deployments.  Will this @Nationalize Hibernate 
annotation allow us to turn off the SQl Server implicit unicode 
conversion and send everything via ascii by default?

Finally, I'm going to freak if I have to do a lot of refactoring to the 
User Storage SPI.  A solution that keeps existing user storage and SPIs 
backward compatible with very little work on the backend should be made 
a  priority instead of completely rearchitecting something so 
fundamental to our datamodel.


On 12/16/16 2:12 PM, Hynek Mlnarik wrote:
> Hi All,
>
> Apologies for a long e-mail.
>
> TLDR: We need to define format of primary keys (UUID) so that it is possible to transform the primary and foreign keys from VARCHAR(36) columns into database-native binary format. This is in particular important to document in 2.5 in Storage Ids section of the new User Storage SPI [1]
>
> Long version:
>
> I have looked at current database model and while generally it looks well, there is an interesting issue with primary / foreign keys that causes performance degradation on both Java and - most importantly - database side, causing even deadlocks for some databases.
>
> The issue comes from database handling of IDs. IDs are in fact UUIDs, i.e. series of bytes that are represented by Strings in KC JPA classes. Why this causes performance degradation is due to various representations conversions (byte array vs String in Java) and - most importantly for database - character set conversions. In the worst case, The conversions occur both in JDBC driver and the database. The consequences are demonstrated by Jira issue KEYCLOAK-3210 [2] when several simultaneous requests lead to deadlocking the database.
>
> When JDBC driver obtains a string, it converts its representation into a character set understood by database. Database might need to convert the string to a character set specified for the column. This is nicely illustrated in MSSQL which makes distinction between VARCHAR (8-bit codepages) and NVARCHAR (UCS-2 Unicode charset). IDs are VARCHARs which is indeed an efficient way to use strings that consist of ASCII-only characters (though not optimal for UUID, read below). However, if Unicode characters are to be supported, MSSQL JDBC driver sends all character parameters as Unicode Strings [3]. Database then performs a conversion from Unicode to 8-bit charset which generally loses some data. To account for this loss, instead of performing an index scan that directly points to a requested row, it returns a range where the requested record should be. This has fatal impact on performance. For more detailed analysis of the resulting plans, see comment in [2].
>
> Clearly, the scan by id should be fast and the format of IDs in database matters. It should avoid conversions as much as possible. Hence the following plan came:
>
> * In the result, all primary keys and corresponding keys have to be represented by binary UUID data type (where supported, some databases represent UUID as e.g. VARBINARY(16)), i.e. 16 bytes instead of 36 bytes
> * All keys in the JPA classes should be of type UUID, not String
>
> As a result, database indices get smaller (16 bytes of indexed data per record vs 36 bytes as it is now in case of 8-bit storage of characters), and no character conversions are in place, hence the overall performance increases.
>
> This task is a slighty big one so it won't fit into KC 2.5 timeframe, but we should definitely aim for 3.0.
>
> This has several preconditions:
> * The String keys in keycloak JPA classes, wherever used, are restricted to UUID format
> * This format is documented and respected by all custom implementations, namely User Storage implementations.
> * There exists conversion from String to native UUID for used databases (this is certainly possible for PostgreSQL MSSQL, DB2, and MySQL, most likely others)
>
> Similarly to JPA, Infinispan classes should be revisited and optimized to save some bytes that might be important for cluster replication by replacing String with UUIDs
>
> Thoughts?
>
> --Hynek
>
> [1] https://github.com/keycloak/server_development_guide/blob/6b82f0868c0d7a148a084a30e0d8fda192f01502/topics/user-storage/model-interfaces.adoc
> [2] https://issues.jboss.org/browse/KEYCLOAK-3210
> [3] https://msdn.microsoft.com/en-us/library/ms378857(v=sql.110).aspx
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Mon Dec 19 02:00:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 19 Dec 2016 08:00:19 +0100
Subject: [keycloak-dev] IE login in new session logs out the other user
In-Reply-To: <FD5090FF-048A-49D9-A991-191C3A503228@me.com>
References: <fd3a727d-932e-4a24-8d88-e240c3005a22@me.com>
	<CAJgngAemCiQwmKHkLJ5Om-Rz-bZMB6RjVWtwimLQmc0of1TN+Q@mail.gmail.com>
	<FD5090FF-048A-49D9-A991-191C3A503228@me.com>
Message-ID: <CAJgngAfE-Ggm7BzPwUkz2RhWd_XcPN0UOCEtZpUg-f+6-SSfDQ@mail.gmail.com>

Yes - it's only there as a marker for when the session is active and is
used by the session iframe to detect if the session is valid without having
to do a http request. For more details see the session management spec from
OpenID Connect.

On 16 December 2016 at 16:36, Michael Gerber <gerbermichi at me.com> wrote:

> Why is the KEYLOAK_SESSION cookie not an http only cookie? Is there a
> reason for that?
>
>
> On 16 Dec 2016, at 16:00, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> Use Chrome or Firefox ;)
>
> On 16 December 2016 at 15:44, Michael Gerber <gerbermichi at me.com> wrote:
>
>> That's true. It shares the cookie which does not have set httpOnly to
>> true.
>>
>> It's obviously an IE fail, however, I need a workaround for that :)
>> Do you have any idea how to solve this?
>>
>> Am 16. Dezember 2016 um 15:14 schrieb Stian Thorgersen <
>> sthorger at redhat.com>:
>>
>> ... Doesn't
>>
>> On 16 December 2016 at 15:13, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Does sound like IE actually creates a clean new session as it's sharing
>>> some cookies.
>>>
>>> On 16 December 2016 at 13:10, Michael Gerber <gerbermichi at me.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am using Windows 7 and Internet Explorer 11.
>>>>
>>>> IE can create a new window with a new session. It should be possible to
>>>> work with two different users in this two windows. However, the second
>>>> login logs the older user out, because of the KEYCLOAK_SESSION cookie which
>>>> is stored in the "C:\Users\{username}\AppData\R
>>>> oaming\Microsoft\Windows\Cookies" directory. The problem is, that this
>>>> cookie is not set to httpOnly.
>>>>
>>>> Is this a known bug? Or can I solve this problem?
>>>>
>>>> kind regards
>>>> Michael
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>
>

From sthorger at redhat.com  Mon Dec 19 05:34:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 19 Dec 2016 11:34:21 +0100
Subject: [keycloak-dev] Database types for primary and foreign keys
In-Reply-To: <e11fd30f-3297-18f6-0b2d-977e8757da23@redhat.com>
References: <56f78fcd-8087-4757-9bcf-396e63a1d324@redhat.com>
	<e11fd30f-3297-18f6-0b2d-977e8757da23@redhat.com>
Message-ID: <CAJgngAeb=+UJZx+CvT3_5KC4nk+-=G3HRsqW3wiFnUMSVccbRw@mail.gmail.com>

I'm not convinced that the proposed changes would make a significant
difference in performance. We heavily cache things and complicated queries
are usually limited to admin operations. That being said if we can do a POC
to check the performance it may be worth it, especially with large number
of entries (we recently had someone talking about 150 million users!).

As Bill points out is has to be backwards compatible and it has to be
possible to automatically perform the changes to the database. From talking
to Hynek it seems like this may be possible. Since the User Storage SPI is
being supported in RHSSO 7.1 there's also no option for us to make changes
to this, but it doesn't seem like we'd have to.

This is something that is worth considering to investigate more at some
point (first step would be to evaluate the real benefits if any), but when
we can prioritize is another question.

On 16 December 2016 at 21:30, Bill Burke <bburke at redhat.com> wrote:

> Not every key is a simple UUID.  Specifically any table that references
> a user:  UserFederatedStorageProvider tables and offline tokens.  THis
> is because of the user storage spi.  These tables must be searchable by
> user id which can either be a UUID (keycloak database) or  "f:" +
> componentUUID + ":" + opaque_external_identifier (External User Storage
> Provider database).  So breaking up a User Storage SPI USER_ID isn't
> going to help as you'll still need to create an index based on these
> columns.  Also, there's been some talk of using this ID format for other
> model types like Roles and Groups.
>
> Also, Everything has to remain backward compatible.  We will need to
> support existing databases.  So, can you support changing to a
> completely different id format and type without screwing up existing
> databases???  I don't think doing a full export/import to/from JSON is
> going to work with large deployments.  Will this @Nationalize Hibernate
> annotation allow us to turn off the SQl Server implicit unicode
> conversion and send everything via ascii by default?
>
> Finally, I'm going to freak if I have to do a lot of refactoring to the
> User Storage SPI.  A solution that keeps existing user storage and SPIs
> backward compatible with very little work on the backend should be made
> a  priority instead of completely rearchitecting something so
> fundamental to our datamodel.
>
>
> On 12/16/16 2:12 PM, Hynek Mlnarik wrote:
> > Hi All,
> >
> > Apologies for a long e-mail.
> >
> > TLDR: We need to define format of primary keys (UUID) so that it is
> possible to transform the primary and foreign keys from VARCHAR(36) columns
> into database-native binary format. This is in particular important to
> document in 2.5 in Storage Ids section of the new User Storage SPI [1]
> >
> > Long version:
> >
> > I have looked at current database model and while generally it looks
> well, there is an interesting issue with primary / foreign keys that causes
> performance degradation on both Java and - most importantly - database
> side, causing even deadlocks for some databases.
> >
> > The issue comes from database handling of IDs. IDs are in fact UUIDs,
> i.e. series of bytes that are represented by Strings in KC JPA classes. Why
> this causes performance degradation is due to various representations
> conversions (byte array vs String in Java) and - most importantly for
> database - character set conversions. In the worst case, The conversions
> occur both in JDBC driver and the database. The consequences are
> demonstrated by Jira issue KEYCLOAK-3210 [2] when several simultaneous
> requests lead to deadlocking the database.
> >
> > When JDBC driver obtains a string, it converts its representation into a
> character set understood by database. Database might need to convert the
> string to a character set specified for the column. This is nicely
> illustrated in MSSQL which makes distinction between VARCHAR (8-bit
> codepages) and NVARCHAR (UCS-2 Unicode charset). IDs are VARCHARs which is
> indeed an efficient way to use strings that consist of ASCII-only
> characters (though not optimal for UUID, read below). However, if Unicode
> characters are to be supported, MSSQL JDBC driver sends all character
> parameters as Unicode Strings [3]. Database then performs a conversion from
> Unicode to 8-bit charset which generally loses some data. To account for
> this loss, instead of performing an index scan that directly points to a
> requested row, it returns a range where the requested record should be.
> This has fatal impact on performance. For more detailed analysis of the
> resulting plans, see comment in [2].
> >
> > Clearly, the scan by id should be fast and the format of IDs in database
> matters. It should avoid conversions as much as possible. Hence the
> following plan came:
> >
> > * In the result, all primary keys and corresponding keys have to be
> represented by binary UUID data type (where supported, some databases
> represent UUID as e.g. VARBINARY(16)), i.e. 16 bytes instead of 36 bytes
> > * All keys in the JPA classes should be of type UUID, not String
> >
> > As a result, database indices get smaller (16 bytes of indexed data per
> record vs 36 bytes as it is now in case of 8-bit storage of characters),
> and no character conversions are in place, hence the overall performance
> increases.
> >
> > This task is a slighty big one so it won't fit into KC 2.5 timeframe,
> but we should definitely aim for 3.0.
> >
> > This has several preconditions:
> > * The String keys in keycloak JPA classes, wherever used, are restricted
> to UUID format
> > * This format is documented and respected by all custom implementations,
> namely User Storage implementations.
> > * There exists conversion from String to native UUID for used databases
> (this is certainly possible for PostgreSQL MSSQL, DB2, and MySQL, most
> likely others)
> >
> > Similarly to JPA, Infinispan classes should be revisited and optimized
> to save some bytes that might be important for cluster replication by
> replacing String with UUIDs
> >
> > Thoughts?
> >
> > --Hynek
> >
> > [1] https://github.com/keycloak/server_development_guide/blob/
> 6b82f0868c0d7a148a084a30e0d8fda192f01502/topics/user-
> storage/model-interfaces.adoc
> > [2] https://issues.jboss.org/browse/KEYCLOAK-3210
> > [3] https://msdn.microsoft.com/en-us/library/ms378857(v=sql.110).aspx
> >
> > _______________________________________________
> > 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 hmlnarik at redhat.com  Mon Dec 19 07:16:07 2016
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 19 Dec 2016 13:16:07 +0100
Subject: [keycloak-dev] Database types for primary and foreign keys
In-Reply-To: <e11fd30f-3297-18f6-0b2d-977e8757da23@redhat.com>
References: <56f78fcd-8087-4757-9bcf-396e63a1d324@redhat.com>
	<e11fd30f-3297-18f6-0b2d-977e8757da23@redhat.com>
Message-ID: <8941c908-cdaa-bf5d-c1a2-337fbcd09e82@redhat.com>

On 12/16/2016 09:30 PM, Bill Burke wrote:
> Not every key is a simple UUID.  Specifically any table that references
> a user:  UserFederatedStorageProvider tables and offline tokens.  THis
> is because of the user storage spi.  These tables must be searchable by
> user id which can either be a UUID (keycloak database) or  "f:" +
> componentUUID + ":" + opaque_external_identifier (External User Storage
> Provider database).  So breaking up a User Storage SPI USER_ID isn't
> going to help as you'll still need to create an index based on these
> columns.

It is, though you're right that the composite index will be in the end introduced on these columns. In the first step, the column will be on string fields (due to time constraints) but constrained by the format you describe here. That will be optimized to store uuid in binary form in 3.x (it is possible without JSON import and export, see below). Index on the UUID part would be then operating on just 16 bytes. That is more efficient than 36 or 2*36 bytes, as more a single database index page can fit in 2-4 times as much records.

So the way I suggest is to have an index on field with UUID part (be it user or component) and a field with the opaque part. No foreign key would be defined on these fields.

>Also, there's been some talk of using this ID format for other
> model types like Roles and Groups.
>
> Also, Everything has to remain backward compatible.  We will need to
> support existing databases.  So, can you support changing to a
> completely different id format and type without screwing up existing
> databases??? I don't think doing a full export/import to/from JSON is
> going to work with large deployments.

Yes, I can. I've checked that conversion of UUID columns works in database-only mode for PgSQL, Oracle, MySQL, MSSQL, DB2 being checked now. Result is that no JSON import/export is needed for these DBs.

> Will this @Nationalize Hibernate
> annotation allow us to turn off the SQl Server implicit unicode
> conversion and send everything via ascii by default?

This is only a partial solution as it depends not only on our end but also on database settings that is out of KC control (how database has been created, what charset is the default one for VARCHAR fields etc.). The approach where UUID is represented via character representation (with character set conversions on the way even for 8-bit encodings) suffers from performance penalty. Using raw 16 bytes for UUID storage does not.

> Finally, I'm going to freak if I have to do a lot of refactoring to the
> User Storage SPI.  A solution that keeps existing user storage and SPIs
> backward compatible with very little work on the backend should be made
> a  priority instead of completely rearchitecting something so
> fundamental to our datamodel.

I don't think that there would be a lot of refactoring though it won't be for free. It will work with existing interfaces implemented by custom providers.

For this to be possible, it only needs to be stressed that the key format is strictly "either UUID pointing of a user entity or the "f:" format" - as you mentioned in the e-mail. I've sent a PR [1] to make this visible for custom User Storage SPIs not only in documentation but also in server log. Please consider it for merging.

--Hynek

[1] https://github.com/keycloak/keycloak/pull/3666

> On 12/16/16 2:12 PM, Hynek Mlnarik wrote:
>> Hi All,
>>
>> Apologies for a long e-mail.
>>
>> TLDR: We need to define format of primary keys (UUID) so that it is possible to transform the primary and foreign keys from VARCHAR(36) columns into database-native binary format. This is in particular important to document in 2.5 in Storage Ids section of the new User Storage SPI [1]
>>
>> Long version:
>>
>> I have looked at current database model and while generally it looks well, there is an interesting issue with primary / foreign keys that causes performance degradation on both Java and - most importantly - database side, causing even deadlocks for some databases.
>>
>> The issue comes from database handling of IDs. IDs are in fact UUIDs, i.e. series of bytes that are represented by Strings in KC JPA classes. Why this causes performance degradation is due to various representations conversions (byte array vs String in Java) and - most importantly for database - character set conversions. In the worst case, The conversions occur both in JDBC driver and the database. The consequences are demonstrated by Jira issue KEYCLOAK-3210 [2] when several simultaneous requests lead to deadlocking the database.
>>
>> When JDBC driver obtains a string, it converts its representation into a character set understood by database. Database might need to convert the string to a character set specified for the column. This is nicely illustrated in MSSQL which makes distinction between VARCHAR (8-bit codepages) and NVARCHAR (UCS-2 Unicode charset). IDs are VARCHARs which is indeed an efficient way to use strings that consist of ASCII-only characters (though not optimal for UUID, read below). However, if Unicode characters are to be supported, MSSQL JDBC driver sends all character parameters as Unicode Strings [3]. Database then performs a conversion from Unicode to 8-bit charset which generally loses some data. To account for this loss, instead of performing an index scan that directly points to a requested row, it returns a range where the requested record should be. This has fatal impact on performance. For more detailed analysis of the resulting plans, see comment in [2].
>>
>> Clearly, the scan by id should be fast and the format of IDs in database matters. It should avoid conversions as much as possible. Hence the following plan came:
>>
>> * In the result, all primary keys and corresponding keys have to be represented by binary UUID data type (where supported, some databases represent UUID as e.g. VARBINARY(16)), i.e. 16 bytes instead of 36 bytes
>> * All keys in the JPA classes should be of type UUID, not String
>>
>> As a result, database indices get smaller (16 bytes of indexed data per record vs 36 bytes as it is now in case of 8-bit storage of characters), and no character conversions are in place, hence the overall performance increases.
>>
>> This task is a slighty big one so it won't fit into KC 2.5 timeframe, but we should definitely aim for 3.0.
>>
>> This has several preconditions:
>> * The String keys in keycloak JPA classes, wherever used, are restricted to UUID format
>> * This format is documented and respected by all custom implementations, namely User Storage implementations.
>> * There exists conversion from String to native UUID for used databases (this is certainly possible for PostgreSQL MSSQL, DB2, and MySQL, most likely others)
>>
>> Similarly to JPA, Infinispan classes should be revisited and optimized to save some bytes that might be important for cluster replication by replacing String with UUIDs
>>
>> Thoughts?
>>
>> --Hynek
>>
>> [1] https://github.com/keycloak/server_development_guide/blob/6b82f0868c0d7a148a084a30e0d8fda192f01502/topics/user-storage/model-interfaces.adoc
>> [2] https://issues.jboss.org/browse/KEYCLOAK-3210
>> [3] https://msdn.microsoft.com/en-us/library/ms378857(v=sql.110).aspx
>>
>> _______________________________________________
>> 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 321j.con at gmail.com  Tue Dec 20 09:58:54 2016
From: 321j.con at gmail.com (Jordan Conner)
Date: Tue, 20 Dec 2016 09:58:54 -0500
Subject: [keycloak-dev] Keycloak adapter wildfly EAR
Message-ID: <CABq7iBJ0Pf7J5q6eEiNJnE9y9DtUFYcJencuK4EKuRaopdLHYg@mail.gmail.com>

Using keycloak-wildfly-adapter-dist-2.4.0.Final and Wildfly 9.0.2.Final


I am having the same issue as KEYCLOAK-3186
<https://issues.jboss.org/browse/KEYCLOAK-3186>

However, I do not receive an "Invalid User" error, the protected method in
the EJB via @RolesAllowed is ignored (no errors.)

I have the same structure. I use the keycloak-offline-adapter installer,
and the security domain is created in standalone.xml file.

EAR

WAR - contains keycloak.json and security constraints to certain urls in
web.xml with certain roles (WORKING.)

EJB - In my @Stateless beans I've tried @SecurityDomain("keycloak") and
I've tried setting it in jboss-ejb3.xml. I then use @RolesAllowed("admin")
on a single method, this is ignored when invoking that method as a "user"
role.


If I try this same thing in a @Stateless bean inside my WAR it works.

His solution was to convert EAR package to WAR. I would really like to
stick to EAR->EJB-WAR structure.


Thanks,

Jordan

From sthorger at redhat.com  Thu Dec 22 02:24:55 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 22 Dec 2016 08:24:55 +0100
Subject: [keycloak-dev] Master updated to 2.5.1.Final-SNAPSHOT
Message-ID: <CAJgngAfwR-SL-PGjHmkcazx3+SBSsmo9SCpcXmAqyggnivvZDw@mail.gmail.com>

Master is now ready for bug fixes to be included in 2.5.1.Final.

We're not accepting anything beyond bug fixes into master until 2.5.1.Final
is released! After that we'll get started on 3.0.0.CR1.

From abhi.raghav007 at gmail.com  Thu Dec 22 05:03:21 2016
From: abhi.raghav007 at gmail.com (abhishek raghav)
Date: Thu, 22 Dec 2016 15:33:21 +0530
Subject: [keycloak-dev] Recommendation for the choice of RDBMS with keycloak
Message-ID: <CAJmz6fs09qPKMT=FhYZvY-QRD=BEr962dv-4JrM+szQTprdd=A@mail.gmail.com>

Hi,


We?re looking into databases to use with Keycloak. We have been using
Mongo, but Keycloak has indicated they might drop support for that. Does
anyone keycloak or somebody who is using RDBMS have a strong or weak
recommendation between Postgres, MySQL, and SQL Server?



Keycloak seems to have good support for Postgres and MySQL, while also
supporting SQL Server. Does it matter which one to choose and if yes in
what manner.


We might be dealing with users between 2k to 5k in a multitenant
environment.


Let me know the thoughts on that.


Thanks

Abhishek

From gaalvarez0910 at gmail.com  Thu Dec 22 07:46:44 2016
From: gaalvarez0910 at gmail.com (Gustavo Alvarez)
Date: Thu, 22 Dec 2016 12:46:44 +0000
Subject: [keycloak-dev] External request to REST endpoint return 403 code
In-Reply-To: <mailman.113168.1482387413.3352.keycloak-user@lists.jboss.org>
References: <mailman.113168.1482387413.3352.keycloak-user@lists.jboss.org>
Message-ID: <CAAhLkKN3aqV1WjXmELRBfgUjxuxqPqUPFbvoaQL+dfmsC6x=_w@mail.gmail.com>

Cordial greetings.

I have a configuration of a client of type confidential and with
authorization through role policy. This configuration works correctly in
local, when I do the deployment to access from the public network, despite
having all the same, I only get answers with code 403.

Thanks for your help.

From asrafalianwarali.shaikh at gi-de.com  Fri Dec 23 01:42:00 2016
From: asrafalianwarali.shaikh at gi-de.com (Shaikh Asrafali Anwarali)
Date: Fri, 23 Dec 2016 06:42:00 +0000
Subject: [keycloak-dev] First use of initial passwords MUST be within
	configurable timeframe
Message-ID: <7124405868aa41b4add75224528c80fc@DEL1EXMBXP2P.accounts.intern>

Hi,

Currently we are exploring keycloak for our IAMS requirement "First use of initial or temporary passwords MUST be within configurable timeframe of receipt".

We explore through keycloak but did not find such functionality , could you let us know is such functionality does exist or it can be configured.

To elaborate more on requirement.
When user is created we assign Temporary password for activating account , user uses temporary password to login into keyclaok and at first attempt update for password is asked wherein user needs to  changes his/her credential.
This use of temporary password, we want to put constraint like it should be used, say in a day or else account cannot be activated.

Regards,
Asraf Shaikh

From michael_furman at hotmail.com  Fri Dec 23 08:22:57 2016
From: michael_furman at hotmail.com (Michael Furman)
Date: Fri, 23 Dec 2016 13:22:57 +0000
Subject: [keycloak-dev] What code in Keycloak IDP is responsible to return
 the configuration to Java adapters?
Message-ID: <AM5PR0701MB2530DD60021A76002C99AB54F4950@AM5PR0701MB2530.eurprd07.prod.outlook.com>

Dear Keycloak people,
I need our help.
What code in Keycloak IDP is responsible to return the configuration to Java adapters (Spring Security Adapter) ?
I mean all URLs in the org.keycloak.adapters.KeycloakDeployment class (authServerBaseUrl, tokenUrl etc.).
I have modified org.keycloak.protocol.oidc.OIDCWellKnownProvider but this code is not executed during OIDC protocol with java adapters.
Thanks in advance for your help,
Michael


From singhrasster at gmail.com  Fri Dec 23 22:01:51 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Fri, 23 Dec 2016 21:01:51 -0600
Subject: [keycloak-dev] Getting error with authentication using ecp.sh script
Message-ID: <CAJ0vL++zBN9+00kp3x8kEuFWNKBvh5mgk+oNxMVb8pmvM_mDog@mail.gmail.com>

Hi All,

I am using ecp.sh (provided by keycloak team, ofcourse with changes on
idp_endpoint based on my keycloak environment) to perform authentication.

I am using spring saml SP and keycloak IDP. I enabled ecp on the SP side
and then I execute ecp.sh script as:

./ecp.sh -d rhsso http://192.168.99.100:8888/saml-sp/first.jsp newuser4


My idp_endpoint is: "
http://192.168.99.100:9990/auth/realms/xxxxxxxxxx/protocol/saml"
where xxxxxxxxxx is my realm (replaced my realm with xxxxxxxxxx for this
email)

The script prompts me to enter password and then it sends an auth request
to keycloak IDP.

Now, something goes wrong at the IDP.
I enabled saml logs on keycloak to see the incoming request and the
following error from the logs:

00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-2)
SAML POST Binding
00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-2)
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://192.168.99.100:8888/saml-sp/saml/SSO"
ForceAuthn="false" ID="a31ah57718g27gd149da6jeb08620ig" IsPassive="false"
IssueInstant="2016-12-24T00:51:34.799Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
http://192.168.99.100:8888/saml-sp/saml/metadata</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#a31ah57718g27gd149da6jeb08620ig">
<ds:Transforms>
<ds:Transform Algorithm="
http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>nfLQ9IFs9IFnSgw3HHHKuPkAbRY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>iULSwpjBb38Vmtan4ZIocRx4PNr6fHRuhVbL+7yXNz3wqjlSavtk7haUiADwUS2cTofRM5KDzUvIkaQPXBZqEkz2xnrhpNj71eIqJ6H4ZqW3mpvP8Bk9z3VEmcEQhZSd6j8rMf4JOdIBRtE7cea0wJhuQ1UdsHdcKeIdp+wuRvn8t9vS/mPKd9GAt11JpC+bgMQS0MDy+r1+AZof2+XMyMuwECVIkouTzwlgKDEmgvQh6Aq61f+QzIeeZ9+3efwJyIH61x7J4CaiSTpesezlXx8UQnqIL+AToL1OFHSp2bgXXxkP1rHSkyNM34Eg92LmI5cN3oBfQDR8r+mCoEctWA==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDUjCCAjqgAwIBAgIEUOLIQTANBgkqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAxWhcNMjIxMjMwMTEyODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrDtUt00E5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7KqxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/KSaal3R26pONUUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/R93vBA6lnl5nTctZIRsyg0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGOM6A8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/dgixKb1Rvby/tBuRogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEWbHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/GuHE=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml2p:AuthnRequest>

00:51:41,265 DEBUG [org.keycloak.saml.common] (default task-2) The provider
ApacheXMLDSig - 2.05 was added at position: 2
00:51:41,545 WARN  [org.keycloak.services] (default task-2)
KC-SERVICES0013: Failed authentication:
org.keycloak.authentication.AuthenticationFlowException
        at
org.keycloak.authentication.DefaultAuthenticationFlow.processResult(DefaultAuthenticationFlow.java:242)
        at
org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:185)
        at
org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:792)
        at
org.keycloak.protocol.AuthorizationEndpointBase.handleBrowserAuthenticationRequest(AuthorizationEndpointBase.java:100)
        at
org.keycloak.protocol.saml.SamlService.newBrowserAuthentication(SamlService.java:505)
        at
org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService.newBrowserAuthentication(SamlEcpProfileService.java:89)
        at
org.keycloak.protocol.saml.SamlService.newBrowserAuthentication(SamlService.java:501)
        at
org.keycloak.protocol.saml.SamlService$BindingProtocol.loginRequest(SamlService.java:297)
        at
org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService$1.loginRequest(SamlEcpProfileService.java:72)
        at
org.keycloak.protocol.saml.SamlService$BindingProtocol.handleSamlRequest(SamlService.java:209)
        at
org.keycloak.protocol.saml.SamlService$PostBindingProtocol.execute(SamlService.java:453)
        at
org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService.authenticate(SamlEcpProfileService.java:74)
        at
org.keycloak.protocol.saml.SamlService.soapBinding(SamlService.java:619)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
        at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
        at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
        at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
        at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
        at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
        at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
        at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
        at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
        at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
        at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
        at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
        at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
        at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
        at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
        at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
        at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
        at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
        at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
        at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
        at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
        at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
        at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
        at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
        at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
        at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
        at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
        at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

00:51:41,548 WARN  [org.keycloak.events] (default task-2) type=LOGIN_ERROR,
realmId=O4ZR9N2V6U, clientId=
http://192.168.99.100:8888/saml-sp/saml/metadata, userId=null,
ipAddress=192.168.99.1, error=in
valid_user_credentials, auth_method=saml, redirect_uri=
http://192.168.99.100:8888/saml-sp/saml/SSO,
code_id=fa04e6ff-3767-419c-a5bf-7bc2c94e8300


I am a bit lost here on what is wrong. Does this request I pasted above
look correct? If not, let me know what is wrong/missing there. Also, my
understanding is that I don't need to enable anything on keycloak for this.
I was earlier able to do browser based authentication using this same saml
SP, IDP and the user. Then, I enabled ECP on SP to test authentication
using ecp.sh script but I encountered the above error and output. I would
appreciate any help or pointers on this.








Also, for reference, this is the SP response (I printed the $sp_resp
variable in ecp.sh):

<?xml version="1.0" encoding="UTF-8"?>
<soap11:Envelope xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
<soap11:Header>
<paos:Request xmlns:paos="urn:liberty:paos:2003-08" responseConsumerURL="
http://192.168.99.100:8888/saml-sp/saml/SSO"
service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" soap11:actor="
http://schemas.xmlsoap.org/soap/actor/next" soap11:mustUnderstand="1"/>
<ecp:Request xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"
IsPassive="false" soap11:actor="http://schemas.xmlsoap.org/soap/actor/next"
soap11:mustUnderstand="1">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
http://192.168.99.100:8888/saml-sp/saml/metadata</saml2:Issuer>
</ecp:Request>
</soap11:Header>
<soap11:Body>
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://192.168.99.100:8888/saml-sp/saml/SSO"
ForceAuthn="false" ID="a1bj9ed5f38c4c1f1331hifbg36363" IsPassive="false"
IssueInstant="2016-12-24T01:14:48.538Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
http://192.168.99.100:8888/saml-sp/saml/metadata</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#a1bj9ed5f38c4c1f1331hifbg36363">
<ds:Transforms>
<ds:Transform Algorithm="
http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>sOgymsP3qFQ4QQFiGP7oUjtutUw=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ZGxJgqOcGe2XarIF1JtfjikRmpsIjglB4mKeYdfUbwUavtH25XgZ/YmgTDFlCYbq2piAM0NvibcyPtXjgX26zATtWJg3URqHpqWclccql8I5arrVfkHTKUQxIx0Rk9bxxytsS012SptubO9F4a+b4LAWoaE9L4IymGVtLpZRLYRL2rhhjwIehT/hSXTWWNRWrLWYb03klaCp/1hZIEUIUW1nyeveyWfaeN1LF7BJ63yMdWOrtUEaF388chUcg1dpFB7HeYq1Q5GCYyEsFk3yi1CEcZ/qeXyfbHAwixFOG0pPNyeunn6QDZzFD8sSVepXzuFLb8MuuthNYSb0hVLrwQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDUjCCAjqgAwIBAgIEUOLIQTANBgkqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UE
CBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEM
MAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAxWhcNMjIxMjMwMTEy
ODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kx
GDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrDtUt00E
5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13
F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7K
qxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/KSaal3R26pON
UUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/R93vBA6lnl5nTctZIRsyg
0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL
82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGOM6A
8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/dgixKb1Rvby/tBu
RogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEW
bHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/GuHE=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml2p:AuthnRequest>
</soap11:Body>
</soap11:Envelope>

From psilva at redhat.com  Sat Dec 24 13:00:08 2016
From: psilva at redhat.com (Pedro Igor)
Date: Sat, 24 Dec 2016 16:00:08 -0200
Subject: [keycloak-dev] External request to REST endpoint return 403 code
In-Reply-To: <CAAhLkKN3aqV1WjXmELRBfgUjxuxqPqUPFbvoaQL+dfmsC6x=_w@mail.gmail.com>
References: <mailman.113168.1482387413.3352.keycloak-user@lists.jboss.org>
	<CAAhLkKN3aqV1WjXmELRBfgUjxuxqPqUPFbvoaQL+dfmsC6x=_w@mail.gmail.com>
Message-ID: <63d24eb4-881e-4713-8f0f-1f25d62d88ae@getmailbird.com>

Are you hitting?https://issues.jboss.org/browse/KEYCLOAK-3261 ? Currently, there is an issue when handling paths from the ROOT context path.
On 12/22/2016 10:48:32 AM, Gustavo Alvarez <gaalvarez0910 at gmail.com> wrote:
Cordial greetings.

I have a configuration of a client of type confidential and with
authorization through role policy. This configuration works correctly in
local, when I do the deployment to access from the public network, despite
having all the same, I only get answers with code 403.

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

From dekela at perfectomobile.com  Sun Dec 25 10:36:43 2016
From: dekela at perfectomobile.com (Dekel Aslan)
Date: Sun, 25 Dec 2016 15:36:43 +0000
Subject: [keycloak-dev] SpringSecurity adapter best practices
Message-ID: <AM4PR0302MB2627481A12BF61B05A59037BAB970@AM4PR0302MB2627.eurprd03.prod.outlook.com>

Greetings,
We were wondering what is the best practice for the use of spring security adapter:
I notice that the security context is an instance of RefreshableKeycloakSecurityContext, which means (correct me if I'm wrong) that whenever a token is about to revoke, a refresh is issued.
I used all xml beans that's in the documentation<https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.4/topics/oidc/java/spring-security-adapter.html>, but still, when I put a breakpoint on RefreshableKeycloakSecurityContext -> refreshExpiredToken, it stops only once - on logout (which is another mystery to me). I also noticed that this method is public yet no other class uses it.
Do I need to invoke it explicitly? Where?

Thanks,
Dekel.

The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.

From michael_furman at hotmail.com  Mon Dec 26 00:42:16 2016
From: michael_furman at hotmail.com (Michael Furman)
Date: Mon, 26 Dec 2016 05:42:16 +0000
Subject: [keycloak-dev] The provider configuration
In-Reply-To: <AM5PR0701MB2530DD60021A76002C99AB54F4950@AM5PR0701MB2530.eurprd07.prod.outlook.com>
References: <AM5PR0701MB2530DD60021A76002C99AB54F4950@AM5PR0701MB2530.eurprd07.prod.outlook.com>
Message-ID: <AM5PR0701MB253021B5737A7FA5369C1842F4960@AM5PR0701MB2530.eurprd07.prod.outlook.com>

Dear Bill,
I will happy for your reply.
I have found that the provider configuration of Java adapters (Spring Security Adapter) implemented in org.keycloak.adapters.KeycloakDeployment#resolveUrls
Just interesting why Keycloak Java adapter do not request the provider configuration via /.well-known/openid-configuration (https://openid.net/specs/openid-connect-discovery-1_0-17.html#ProviderConfig)?
One more question:
We need to support Keycloak behind the Network Address Tranlation (NAT) and therefore we need to modify org.keycloak.adapters.KeycloakDeployment#resolveUrls and org.keycloak.protocol.oidc.OIDCWellKnownProvider#getConfig.

What is the best way to contribute it to Keycloak?

Thanks in advance for your help,
Michael



________________________________
From: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-bounces at lists.jboss.org> on behalf of Michael Furman <michael_furman at hotmail.com>
Sent: Friday, December 23, 2016 3:22 PM
To: keycloak-dev at lists.jboss.org
Subject: [keycloak-dev] What code in Keycloak IDP is responsible to return the configuration to Java adapters?

Dear Keycloak people,
I need our help.
What code in Keycloak IDP is responsible to return the configuration to Java adapters (Spring Security Adapter) ?
I mean all URLs in the org.keycloak.adapters.KeycloakDeployment class (authServerBaseUrl, tokenUrl etc.).
I have modified org.keycloak.protocol.oidc.OIDCWellKnownProvider but this code is not executed during OIDC protocol with java adapters.
Thanks in advance for your help,
Michael

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
keycloak-dev Info Page - lists.jboss.org<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
lists.jboss.org
To see the collection of prior postings to the list, visit the keycloak-dev Archives. Using keycloak-dev: To post a message to all the list members ...



From singhrasster at gmail.com  Tue Dec 27 08:52:19 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Tue, 27 Dec 2016 07:52:19 -0600
Subject: [keycloak-dev] Getting error with authentication using ecp.sh
	script
In-Reply-To: <CAJ0vL++zBN9+00kp3x8kEuFWNKBvh5mgk+oNxMVb8pmvM_mDog@mail.gmail.com>
References: <CAJ0vL++zBN9+00kp3x8kEuFWNKBvh5mgk+oNxMVb8pmvM_mDog@mail.gmail.com>
Message-ID: <CAJ0vL+LM0k7GB+jKR=SW5LLVJyPZ_nNwJcb4us3G_pGsdn1tBA@mail.gmail.com>

Hi All, Just a reminder if some insights/help could be provided on my SAML
request and the issue I am facing.

On Fri, Dec 23, 2016 at 9:01 PM, Rashmi Singh <singhrasster at gmail.com>
wrote:

> Hi All,
>
> I am using ecp.sh (provided by keycloak team, ofcourse with changes on
> idp_endpoint based on my keycloak environment) to perform authentication.
>
> I am using spring saml SP and keycloak IDP. I enabled ecp on the SP side
> and then I execute ecp.sh script as:
>
> ./ecp.sh -d rhsso http://192.168.99.100:8888/saml-sp/first.jsp newuser4
>
>
> My idp_endpoint is: "http://192.168.99.100:9990/auth/realms/xxxxxxxxxx/
> protocol/saml"
> where xxxxxxxxxx is my realm (replaced my realm with xxxxxxxxxx for this
> email)
>
> The script prompts me to enter password and then it sends an auth request
> to keycloak IDP.
>
> Now, something goes wrong at the IDP.
> I enabled saml logs on keycloak to see the incoming request and the
> following error from the logs:
>
> 00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-2)
> SAML POST Binding
> 00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-2)
> <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
> AssertionConsumerServiceURL="http://192.168.99.100:8888/saml-sp/saml/SSO"
> ForceAuthn="false" ID="a31ah57718g27gd149da6jeb08620ig" IsPassive="false"
> IssueInstant="2016-12-24T00:51:34.799Z" ProtocolBinding="urn:oasis:
> names:tc:SAML:2.0:bindings:PAOS" Version="2.0">
> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://
> 192.168.99.100:8888/saml-sp/saml/metadata</saml2:Issuer>
> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <ds:SignedInfo>
> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/
> 2001/10/xml-exc-c14n#"/>
> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1
> "/>
> <ds:Reference URI="#a31ah57718g27gd149da6jeb08620ig">
> <ds:Transforms>
> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-
> signature"/>
> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:Transforms>
> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> <ds:DigestValue>nfLQ9IFs9IFnSgw3HHHKuPkAbRY=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
> <ds:SignatureValue>iULSwpjBb38Vmtan4ZIocRx4PNr6fHRuhVbL+
> 7yXNz3wqjlSavtk7haUiADwUS2cTofRM5KDzUvIkaQPXBZqEkz2xnrhpNj71
> eIqJ6H4ZqW3mpvP8Bk9z3VEmcEQhZSd6j8rMf4JOdIBRtE7cea0wJhuQ1Uds
> HdcKeIdp+wuRvn8t9vS/mPKd9GAt11JpC+bgMQS0MDy+r1+AZof2+
> XMyMuwECVIkouTzwlgKDEmgvQh6Aq61f+QzIeeZ9+3efwJyIH61x7J4CaiSTpesezlXx8UQ
> nqIL+AToL1OFHSp2bgXXxkP1rHSkyNM34Eg92LmI5cN3oBfQDR8r+mCoEctWA==</
> ds:SignatureValue>
> <ds:KeyInfo>
> <ds:X509Data>
> <ds:X509Certificate>MIIDUjCCAjqgAwIBAgIEUOLIQTANBg
> kqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYT
> ERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeT
> EMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyOD
> AxWhcNMjIxMjMwMTEyODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVX
> VzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2
> FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wggEiMA0GCS
> qGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrD
> tUt00E5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/
> yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/
> rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7KqxpHx6No83WNZj4B
> 3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/
> KSaal3R26pONUUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/
> R93vBA6lnl5nTctZIRsyg0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQ
> wAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL82IvnKouGixGq
> AcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGO
> M6A8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/
> dgixKb1Rvby/tBuRogWgPONNSACiW+Z5o8UdAOqNMZQozD/
> i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEWbHwSoBy5hLPNALaE
> Uoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/
> GuHE=</ds:X509Certificate>
> </ds:X509Data>
> </ds:KeyInfo>
> </ds:Signature>
> </saml2p:AuthnRequest>
>
> 00:51:41,265 DEBUG [org.keycloak.saml.common] (default task-2) The
> provider ApacheXMLDSig - 2.05 was added at position: 2
> 00:51:41,545 WARN  [org.keycloak.services] (default task-2)
> KC-SERVICES0013: Failed authentication: org.keycloak.authentication.
> AuthenticationFlowException
>         at org.keycloak.authentication.DefaultAuthenticationFlow.
> processResult(DefaultAuthenticationFlow.java:242)
>         at org.keycloak.authentication.DefaultAuthenticationFlow.
> processFlow(DefaultAuthenticationFlow.java:185)
>         at org.keycloak.authentication.AuthenticationProcessor.
> authenticateOnly(AuthenticationProcessor.java:792)
>         at org.keycloak.protocol.AuthorizationEndpointBase.
> handleBrowserAuthenticationRequest(AuthorizationEndpointBase.java:100)
>         at org.keycloak.protocol.saml.SamlService.
> newBrowserAuthentication(SamlService.java:505)
>         at org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService.
> newBrowserAuthentication(SamlEcpProfileService.java:89)
>         at org.keycloak.protocol.saml.SamlService.
> newBrowserAuthentication(SamlService.java:501)
>         at org.keycloak.protocol.saml.SamlService$BindingProtocol.
> loginRequest(SamlService.java:297)
>         at org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService$1.
> loginRequest(SamlEcpProfileService.java:72)
>         at org.keycloak.protocol.saml.SamlService$BindingProtocol.
> handleSamlRequest(SamlService.java:209)
>         at org.keycloak.protocol.saml.SamlService$
> PostBindingProtocol.execute(SamlService.java:453)
>         at org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService.
> authenticate(SamlEcpProfileService.java:74)
>         at org.keycloak.protocol.saml.SamlService.soapBinding(
> SamlService.java:619)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:498)
>         at org.jboss.resteasy.core.MethodInjectorImpl.invoke(
> MethodInjectorImpl.java:139)
>         at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(
> ResourceMethodInvoker.java:295)
>         at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(
> ResourceMethodInvoker.java:249)
>         at org.jboss.resteasy.core.ResourceLocatorInvoker.
> invokeOnTargetObject(ResourceLocatorInvoker.java:138)
>         at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
> ResourceLocatorInvoker.java:101)
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(
> SynchronousDispatcher.java:395)
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(
> SynchronousDispatcher.java:202)
>         at org.jboss.resteasy.plugins.server.servlet.
> ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
>         at org.jboss.resteasy.plugins.server.servlet.
> HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>         at org.jboss.resteasy.plugins.server.servlet.
> HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(
> ServletHandler.java:85)
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.
> doFilter(FilterHandler.java:129)
>         at org.keycloak.services.filters.KeycloakSessionServletFilter.
> doFilter(KeycloakSessionServletFilter.java:90)
>         at io.undertow.servlet.core.ManagedFilter.doFilter(
> ManagedFilter.java:60)
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.
> doFilter(FilterHandler.java:131)
>         at io.undertow.servlet.handlers.FilterHandler.handleRequest(
> FilterHandler.java:84)
>         at io.undertow.servlet.handlers.security.
> ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.
> java:62)
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.
> handleRequest(ServletDispatchingHandler.java:36)
>         at org.wildfly.extension.undertow.security.
> SecurityContextAssociationHandler.handleRequest(
> SecurityContextAssociationHandler.java:78)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
>         at io.undertow.servlet.handlers.security.
> SSLInformationAssociationHandler.handleRequest(
> SSLInformationAssociationHandler.java:131)
>         at io.undertow.servlet.handlers.security.
> ServletAuthenticationCallHandler.handleRequest(
> ServletAuthenticationCallHandler.java:57)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
>         at io.undertow.security.handlers.AbstractConfidentialityHandler
> .handleRequest(AbstractConfidentialityHandler.java:46)
>         at io.undertow.servlet.handlers.security.
> ServletConfidentialityConstraintHandler.handleRequest(
> ServletConfidentialityConstraintHandler.java:64)
>         at io.undertow.security.handlers.AuthenticationMechanismsHandle
> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>         at io.undertow.servlet.handlers.security.
> CachedAuthenticatedSessionHandler.handleRequest(
> CachedAuthenticatedSessionHandler.java:77)
>         at io.undertow.security.handlers.NotificationReceiverHandler.
> handleRequest(NotificationReceiverHandler.java:50)
>         at io.undertow.security.handlers.AbstractSecurityContextAssocia
> tionHandler.handleRequest(AbstractSecurityContextAssocia
> tionHandler.java:43)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
>         at org.wildfly.extension.undertow.security.jacc.
> JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
>         at io.undertow.servlet.handlers.ServletInitialHandler.
> handleFirstRequest(ServletInitialHandler.java:284)
>         at io.undertow.servlet.handlers.ServletInitialHandler.
> dispatchRequest(ServletInitialHandler.java:263)
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$
> 000(ServletInitialHandler.java:81)
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.
> handleRequest(ServletInitialHandler.java:174)
>         at io.undertow.server.Connectors.executeRootHandler(Connectors.
> java:202)
>         at io.undertow.server.HttpServerExchange$1.run(
> HttpServerExchange.java:793)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
>
> 00:51:41,548 WARN  [org.keycloak.events] (default task-2)
> type=LOGIN_ERROR, realmId=O4ZR9N2V6U, clientId=http://192.168.99.
> 100:8888/saml-sp/saml/metadata, userId=null, ipAddress=192.168.99.1,
> error=in
> valid_user_credentials, auth_method=saml, redirect_uri=http://192.168.
> 99.100:8888/saml-sp/saml/SSO, code_id=fa04e6ff-3767-419c-a5bf-7bc2c94e8300
>
>
> I am a bit lost here on what is wrong. Does this request I pasted above
> look correct? If not, let me know what is wrong/missing there. Also, my
> understanding is that I don't need to enable anything on keycloak for this.
> I was earlier able to do browser based authentication using this same saml
> SP, IDP and the user. Then, I enabled ECP on SP to test authentication
> using ecp.sh script but I encountered the above error and output. I would
> appreciate any help or pointers on this.
>
>
>
>
>
>
>
>
> Also, for reference, this is the SP response (I printed the $sp_resp
> variable in ecp.sh):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <soap11:Envelope xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
> <soap11:Header>
> <paos:Request xmlns:paos="urn:liberty:paos:2003-08" responseConsumerURL="
> http://192.168.99.100:8888/saml-sp/saml/SSO" service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"
> soap11:actor="http://schemas.xmlsoap.org/soap/actor/next"
> soap11:mustUnderstand="1"/>
> <ecp:Request xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"
> IsPassive="false" soap11:actor="http://schemas.xmlsoap.org/soap/actor/next"
> soap11:mustUnderstand="1">
> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://
> 192.168.99.100:8888/saml-sp/saml/metadata</saml2:Issuer>
> </ecp:Request>
> </soap11:Header>
> <soap11:Body>
> <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
> AssertionConsumerServiceURL="http://192.168.99.100:8888/saml-sp/saml/SSO"
> ForceAuthn="false" ID="a1bj9ed5f38c4c1f1331hifbg36363" IsPassive="false"
> IssueInstant="2016-12-24T01:14:48.538Z" ProtocolBinding="urn:oasis:
> names:tc:SAML:2.0:bindings:PAOS" Version="2.0">
> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://
> 192.168.99.100:8888/saml-sp/saml/metadata</saml2:Issuer>
> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <ds:SignedInfo>
> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/
> 2001/10/xml-exc-c14n#"/>
> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1
> "/>
> <ds:Reference URI="#a1bj9ed5f38c4c1f1331hifbg36363">
> <ds:Transforms>
> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-
> signature"/>
> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:Transforms>
> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> <ds:DigestValue>sOgymsP3qFQ4QQFiGP7oUjtutUw=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
> <ds:SignatureValue>ZGxJgqOcGe2XarIF1JtfjikRmpsIjglB4mKeYdfUbwUavtH25XgZ/
> YmgTDFlCYbq2piAM0NvibcyPtXjgX26zATtWJg3URqHpqWclccql8I5arrVf
> kHTKUQxIx0Rk9bxxytsS012SptubO9F4a+b4LAWoaE9L4IymGVtLpZRLYRL2rhhj
> wIehT/hSXTWWNRWrLWYb03klaCp/1hZIEUIUW1nyeveyWfaeN1LF7BJ63y
> MdWOrtUEaF388chUcg1dpFB7HeYq1Q5GCYyEsFk3yi1CEcZ/
> qeXyfbHAwixFOG0pPNyeunn6QDZzFD8sSVepXzuFLb8MuuthNYSb0hVLrwQ=
> =</ds:SignatureValue>
> <ds:KeyInfo>
> <ds:X509Data>
> <ds:X509Certificate>MIIDUjCCAjqgAwIBAgIEUOLIQTANBg
> kqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UE
> CBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEM
> MAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAxWhcNMjIxMjMwMTEy
> ODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kx
> GDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8w
> ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrDtUt00E
> 5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13
> F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7K
> qxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/KSaal3R26pON
> UUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/R93vBA6lnl5nTctZIRsyg
> 0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL
> 82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGOM6A
> 8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/dgixKb1Rvby/tBu
> RogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEW
> bHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+
> Y5QRhyXnLqgO67BlLYW/GuHE=</ds:X509Certificate>
> </ds:X509Data>
> </ds:KeyInfo>
> </ds:Signature>
> </saml2p:AuthnRequest>
> </soap11:Body>
> </soap11:Envelope>
>