From jdennis at redhat.com  Wed Jun  1 14:29:09 2016
From: jdennis at redhat.com (John Dennis)
Date: Wed, 1 Jun 2016 14:29:09 -0400
Subject: [keycloak-dev] 1.9.4.Final and 1.9.5.Final throw
	NoClassDefFoundError for SOAP
Message-ID: <6ca1c200-44a0-d0a4-ddb6-4a8ae39e88d1@redhat.com>

We've been trying to test SAML ECP with the last 2 Keycloak releases and 
we are getting a server 500 error caused by a NoClassDefFoundError for 
javax/xml/soap/MessageFactory. The odd thing is that the class is in one 
of the jars:

% jar -tf 
modules/system/layers/base/javax/xml/soap/api/main/jboss-saaj-api_1.3_spec-1.0.3.Final.jar

lists

javax/xml/soap/MessageFactory.class

Can someone explain what is going on or how to fix it?

Attached (so the mailer does not mangle it) is the exception in the 
server.log file

-- 
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.log
Type: text/x-log
Size: 34299 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160601/fbe4829d/attachment-0001.bin 

From sthorger at redhat.com  Wed Jun  1 14:44:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 1 Jun 2016 20:44:12 +0200
Subject: [keycloak-dev] 1.9.4.Final and 1.9.5.Final throw
 NoClassDefFoundError for SOAP
In-Reply-To: <6ca1c200-44a0-d0a4-ddb6-4a8ae39e88d1@redhat.com>
References: <6ca1c200-44a0-d0a4-ddb6-4a8ae39e88d1@redhat.com>
Message-ID: <CAJgngAdK=zZgBLRk9pigXqCO0_JoWsOhSqwZ3T=S5Fyu0zoP6w@mail.gmail.com>

Have you tried SAML ECP with any older versions of Keycloak with success?

Can you try adding dependency on javax.xml.soap.api
to layers/keycloak/org/keycloak/keycloak-services/main/module.xml?

On 1 June 2016 at 20:29, John Dennis <jdennis at redhat.com> wrote:

> We've been trying to test SAML ECP with the last 2 Keycloak releases and
> we are getting a server 500 error caused by a NoClassDefFoundError for
> javax/xml/soap/MessageFactory. The odd thing is that the class is in one of
> the jars:
>
> % jar -tf
> modules/system/layers/base/javax/xml/soap/api/main/jboss-saaj-api_1.3_spec-1.0.3.Final.jar
>
> lists
>
> javax/xml/soap/MessageFactory.class
>
> Can someone explain what is going on or how to fix it?
>
> Attached (so the mailer does not mangle it) is the exception in the
> server.log file
>
> --
> John
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160601/dc816e3b/attachment.html 

From thomas.raehalme at aitiofinland.com  Thu Jun  2 09:21:48 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Thu, 2 Jun 2016 16:21:48 +0300
Subject: [keycloak-dev] User's locale changes at login?
Message-ID: <CAPyAMobFHQgUgRGrrfFGzVb1nhqi8B0Bn4O_w9-xW2EV+Px+2A@mail.gmail.com>

Hi,

While localizing the Keycloak UI for end-users (login, account, email) we
noticed that the user's locale changes to whatever locale is active when
logging in. Is this intended behavior?

If it is, I think it would be better to honor the locale on user
preferences, and allow the user to change the locale in the account
settings instead. The locale setting on the browser may not reflect the
desired locale set on user preferences.

What do you think?

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160602/9313e178/attachment.html 

From sthorger at redhat.com  Thu Jun  2 13:20:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 2 Jun 2016 19:20:49 +0200
Subject: [keycloak-dev] User's locale changes at login?
In-Reply-To: <CAPyAMobFHQgUgRGrrfFGzVb1nhqi8B0Bn4O_w9-xW2EV+Px+2A@mail.gmail.com>
References: <CAPyAMobFHQgUgRGrrfFGzVb1nhqi8B0Bn4O_w9-xW2EV+Px+2A@mail.gmail.com>
Message-ID: <CAJgngAc9AJjFva-U=XAFV5EM9jQZBURmwFymbL9my6DkKfNJZw@mail.gmail.com>

It's the intended behavior. The problem with honoring the locale on the
user preference is that the user is not available if not logged-in, so we
need to rely on the cookie if the user is not available. This further
complicates things as if the user uses the dropdown prior to authenticating
the cookie is updated, but not the user. If we then switched to whatever
the user had set when the user was authenticated we'd revert the changes
the user just did.

Then why would different users use the same browser aka share a locale
cookie? I don't think that's a frequent thing, especially not as os has
user support, browsers have support for profiles and then there's also
incognito sessions. Finally, even if users do share a machine would they
not then in most case have the same locale?

On 2 June 2016 at 15:21, Thomas Raehalme <thomas.raehalme at aitiofinland.com>
wrote:

> Hi,
>
> While localizing the Keycloak UI for end-users (login, account, email) we
> noticed that the user's locale changes to whatever locale is active when
> logging in. Is this intended behavior?
>
> If it is, I think it would be better to honor the locale on user
> preferences, and allow the user to change the locale in the account
> settings instead. The locale setting on the browser may not reflect the
> desired locale set on user preferences.
>
> What do you think?
>
> Best regards,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160602/9743250d/attachment.html 

From sthorger at redhat.com  Fri Jun  3 08:46:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 3 Jun 2016 14:46:24 +0200
Subject: [keycloak-dev] Keycloak 1.9.7.Final released
Message-ID: <CAJgngAcYukYi8bDpd_S7XpTXMAgxT5QvWSX-7=sZzyPFBwcWvg@mail.gmail.com>

Keycloak 1.9.7.Final has just been released.

For the full list of resolved issues check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.7.Final>
and
to download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160603/1c758ca2/attachment.html 

From thomas.darimont at googlemail.com  Fri Jun  3 10:00:19 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 3 Jun 2016 16:00:19 +0200
Subject: [keycloak-dev] Keycloak 1.9.7.Final released
In-Reply-To: <CAJgngAcYukYi8bDpd_S7XpTXMAgxT5QvWSX-7=sZzyPFBwcWvg@mail.gmail.com>
References: <CAJgngAcYukYi8bDpd_S7XpTXMAgxT5QvWSX-7=sZzyPFBwcWvg@mail.gmail.com>
Message-ID: <CAK-7U1j7Gp+y-+0tSZP4CAQVHvsCxMr5hcNG9=Czf7YoJ9NV9Q@mail.gmail.com>

Great Job! :)

You should tweet for every release so we can retweet.
https://twitter.com/keycloak

Cheers,
Thomas

2016-06-03 14:46 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> Keycloak 1.9.7.Final has just been released.
>
> For the full list of resolved issues check out JIRA
> <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.7.Final> and
> to download the release go to the Keycloak homepage
> <http://www.keycloak.org/downloads>.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160603/67ea16ad/attachment.html 

From thomas.darimont at googlemail.com  Fri Jun  3 11:25:47 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 3 Jun 2016 17:25:47 +0200
Subject: [keycloak-dev] Support for signing and encrypting of JWT tokens
Message-ID: <CAK-7U1gOx+Kaif7rJF5+iQ+dXkqMPGS3uF0iuTi-C7oC6UE4JQ@mail.gmail.com>

Hello,

does keycloak currently support to sign and encryption of issued JWT tokens?
http://connect2id.com/products/nimbus-jose-jwt/examples/signed-and-encrypted-jwt

According to the org.keycloak.protocol.oidc.TokenManager JWT tokens are
only signed
but encryption seems to be not supported at the moment.

I couldn't find a JIRA issue for that so I'm wondering whether this is
already on some agenda...

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160603/1b6fe47a/attachment.html 

From desk3016 at live.com  Fri Jun  3 13:09:13 2016
From: desk3016 at live.com (Eric Son 3016)
Date: Fri, 3 Jun 2016 10:09:13 -0700
Subject: [keycloak-dev] Config File for token validator endpoints url in
	keycloak?
Message-ID: <BAY172-W32E76D10F741212ED00495BE590@phx.gbl>

Hi, 

I would like to use external token validator with the keycloak.
 Is there any existing configuration file for storing token validator API endpoints url and its public key info?
I want to set them up in "System level" rather than the "Execution level" in the code.

Thanks for the help!

Best Regards,

WJ

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

From brooks.isoldi at traversed.com  Fri Jun  3 15:56:25 2016
From: brooks.isoldi at traversed.com (Brooks Isoldi)
Date: Fri, 3 Jun 2016 15:56:25 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
Message-ID: <5751E0E9.7030708@traversed.com>

I've configured Keycloak as a service on Ubuntu 14.04 and I'm finding 
that terminating and restarting the Wildfly service (sudo service 
wildfly restart) sometimes results in the keycloak-server.war being 
undeployed and removed.

Other times it happens by restarting from within the CLI.

How do I restart Wildfly without terminating Keycloak?

Thank you.



-Brooks

From ssilvert at redhat.com  Fri Jun  3 20:35:00 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 03 Jun 2016 20:35:00 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <5751E0E9.7030708@traversed.com>
References: <5751E0E9.7030708@traversed.com>
Message-ID: <57522234.5040301@redhat.com>

On 6/3/2016 3:56 PM, Brooks Isoldi wrote:
> I've configured Keycloak as a service on Ubuntu 14.04 and I'm finding
> that terminating and restarting the Wildfly service (sudo service
> wildfly restart) sometimes results in the keycloak-server.war being
> undeployed and removed.
>
> Other times it happens by restarting from within the CLI.
I can't recreate your problem.  I don't have Ubuntu, but I've tried 
restarting several times from CLI and I don't see it.

What CLI command(s) are causing the issue?
>
> How do I restart Wildfly without terminating Keycloak?
>
> Thank you.
>
>
>
> -Brooks
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mitya at cargosoft.ru  Sat Jun  4 11:21:12 2016
From: mitya at cargosoft.ru (Mitya)
Date: Sat, 04 Jun 2016 18:21:12 +0300
Subject: [keycloak-dev] Support for LDAP referrals
In-Reply-To: <573E19F7.2060304@redhat.com>
References: <1463542629.13752.20.camel@cargosoft.ru>
	<573E19F7.2060304@redhat.com>
Message-ID: <1465053672.8711.1.camel@cargosoft.ru>

Marek,
Sorry for delay. Here we go:?https://issues.jboss.org/browse/KEYCLOAK-3
083
> LDAP referrals were not yet tested and supported, could you please
> create JIRA for this??
> 
> Thanks,
> Marek
> 
> On 18/05/16 05:37, Mitya wrote:
> 
> > Hi,
> > 
> > 
> > In replicated LDAP setups, it's a common situation where the slave
> > is read-only,?and if a write operation is attempted, it returns a
> > so-called referral (see more here). Simply put, a referral is an
> > instruction to proceed with the same LDAP operation but using
> > different URL, contained within response. In a replicated setup,
> > this URL would point to master instance, which is read-write.
> > 
> > 
> > Currently, KeyCloak cannot use such a slave replica as a federation
> > provider in a WRITABLE edit mode. LDAP entries are imported
> > successfully; but further attempts to modify them in KeyCloak admin
> > console give success message, while the actual values are not
> > modified. If Sync Registrations is on, attempt to create a user
> > results in the following exception:
> > 
> > 
> > javax.naming.PartialResultException: [LDAP: error code 10 -
> > Referral]; remaining name 'uid=foo,ou=People,dc=foobar,dc=com'
> > 	at
> > com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971)
> > 	at
> > com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> > 	at
> > com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:812)
> > 	at
> > com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(Com
> > ponentDirContext.java:341)
> > 	at
> > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontex
> > t(PartialCompositeDirContext.java:268)
> > 	at
> > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontex
> > t(PartialCompositeDirContext.java:256)
> > 	at
> > javax.naming.directory.InitialDirContext.createSubcontext(InitialDi
> > rContext.java:197)
> > 	at
> > javax.naming.directory.InitialDirContext.createSubcontext(InitialDi
> > rContext.java:197)
> > 	at
> > org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.
> > execute(LDAPOperationManager.java:434)
> > 	at
> > org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.
> > execute(LDAPOperationManager.java:431)
> > 	at
> > org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.ex
> > ecute(LDAPOperationManager.java:536)
> > 	at
> > org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.cr
> > eateSubContext(LDAPOperationManager.java:431)
> > LDAP referrals are fully supported by JNDI and LDAP stack; the only
> > thing we need is to set a Context.REFERRAL ("java.naming.referral")
> > environment property to "follow" before creating an
> > InitialLdapContext. I've noticed that in
> > org.keycloak.federation.ldap.LDAPConfig, there is an initial
> > support for additional connection properties (currently hardcoded
> > to return null). Are there any plans to implement this?
> > 
> > 
> > Cheers,
> > Mitya
> > 
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160604/ffc8a297/attachment.html 

From mitya at cargosoft.ru  Sat Jun  4 11:58:27 2016
From: mitya at cargosoft.ru (Mitya)
Date: Sat, 04 Jun 2016 18:58:27 +0300
Subject: [keycloak-dev] Extending the Credential entity
Message-ID: <1465055907.8711.26.camel@cargosoft.ru>

Hi,

1. I've implemented a custom JPA entity, let's call it DeviceEntity (by
making direct changes to the org.keycloak.keycloak-model-jpa module, as
Entity SPI is not yet available). Now I want to have an entity, let's
name it DeviceCredentialEntity, that would inherit from
CredentialEntity an would extend it in the follwing ways:
?a) it would reference DeviceEntity in a many-to-one manner (one device
supplies several credentials);
?b) it would introduce a lockout mechanism (if a device is lost/stolen,
all its credentials should be locked out), maybe a boolean field.

All the custom functionality (assigning devices, locking/unlocking)
will be handled by my extensions; otherwise, device credentials should
behave identically to normal ones.

I see two ways of implementing this:
- extending CredentialEntity directly, adding necessary fields and
making DeviceCredentials live in a separate table. This design is
fairly straightforward, but it will introduce additional SQL and
probably modifications to authenticator (to support per-credential
locked-out bit);
- not creating a dedicated entity, but rather emulating many-to-one
with many-to-many relationship (intermediate table between devices and
credentials + unique constraint on credential ID) and emulating locked-
out status by setting credential type to something invalid. This is
less clean, but also less intrusive, as it will require no
modifications to authenticator.

Which way is better at the moment (v1.9.7)? Will the upcoming v2.0.0 +
Entity SPI address problems like this?

2. Imagine the storage contains a lot of CredentialEntities with user
field set to null (in other words, a pool of non-owned credentials
available for enrollment). Wouldn't it break the system? Wouldn't these
entities be considered orphaned and be "scavenged" by some kind of
cleanup process?

Thanks!
Mitya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160604/cc826b89/attachment.html 

From sthorger at redhat.com  Mon Jun  6 01:59:28 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 6 Jun 2016 07:59:28 +0200
Subject: [keycloak-dev] Support for signing and encrypting of JWT tokens
In-Reply-To: <CAK-7U1gOx+Kaif7rJF5+iQ+dXkqMPGS3uF0iuTi-C7oC6UE4JQ@mail.gmail.com>
References: <CAK-7U1gOx+Kaif7rJF5+iQ+dXkqMPGS3uF0iuTi-C7oC6UE4JQ@mail.gmail.com>
Message-ID: <CAJgngAfj8OuwyNo-d_LXRZtrTMtQB8_mWqFxJ4DYBvF96=RKQw@mail.gmail.com>

We don't currently support this, nor is it on the road-map at the moment.
We are planning on improving OIDC support over the next few months as we're
hoping to pass the OIDC certification tests, but I don't think support
encryption of tokens is required. We haven't had anyone else request this
afaik.

On 3 June 2016 at 17:25, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello,
>
> does keycloak currently support to sign and encryption of issued JWT
> tokens?
>
> http://connect2id.com/products/nimbus-jose-jwt/examples/signed-and-encrypted-jwt
>
> According to the org.keycloak.protocol.oidc.TokenManager JWT tokens are
> only signed
> but encryption seems to be not supported at the moment.
>
> I couldn't find a JIRA issue for that so I'm wondering whether this is
> already on some agenda...
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160606/5ebe3283/attachment.html 

From sthorger at redhat.com  Mon Jun  6 02:00:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 6 Jun 2016 08:00:07 +0200
Subject: [keycloak-dev] Config File for token validator endpoints url in
	keycloak?
In-Reply-To: <BAY172-W32E76D10F741212ED00495BE590@phx.gbl>
References: <BAY172-W32E76D10F741212ED00495BE590@phx.gbl>
Message-ID: <CAJgngAfuNHQ=uyGyq1TRUkvdi18MBbtos4vunTJaGP8qC7QwKQ@mail.gmail.com>

Please elaborate on what your use-case is.

On 3 June 2016 at 19:09, Eric Son 3016 <desk3016 at live.com> wrote:

> Hi,
>
> I would like to use external token validator with the keycloak.
>  Is there any existing configuration file for storing token validator API
> endpoints url and its public key info?
> I want to set them up in "System level" rather than the "Execution level"
> in the code.
>
> Thanks for the help!
>
> Best Regards,
>
> WJ
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160606/0f6ce322/attachment-0001.html 

From sthorger at redhat.com  Mon Jun  6 02:00:55 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 6 Jun 2016 08:00:55 +0200
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <5751E0E9.7030708@traversed.com>
References: <5751E0E9.7030708@traversed.com>
Message-ID: <CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>

What version of Keycloak and what distribution (standalone, overlay or
demo) do you use?

On 3 June 2016 at 21:56, Brooks Isoldi <brooks.isoldi at traversed.com> wrote:

> I've configured Keycloak as a service on Ubuntu 14.04 and I'm finding
> that terminating and restarting the Wildfly service (sudo service
> wildfly restart) sometimes results in the keycloak-server.war being
> undeployed and removed.
>
> Other times it happens by restarting from within the CLI.
>
> How do I restart Wildfly without terminating Keycloak?
>
> Thank you.
>
>
>
> -Brooks
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160606/b330d410/attachment.html 

From grossws at gmail.com  Mon Jun  6 06:12:33 2016
From: grossws at gmail.com (Konstantin Gribov)
Date: Mon, 06 Jun 2016 10:12:33 +0000
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
Message-ID: <CALvb29xugcUhRWsTWyJhaFE1LbW-bkOb77dmxH639ojWMi8u4w@mail.gmail.com>

I had similar issue with my webapps in JBoss AS 7.x (till 7.1.1.Final) on
different distributions (centos/rhel, debian). But I hadn't found a
reliable way to reproduce it.

??, 6 ???. 2016 ?. ? 9:01, Stian Thorgersen <sthorger at redhat.com>:

> What version of Keycloak and what distribution (standalone, overlay or
> demo) do you use?
>
> On 3 June 2016 at 21:56, Brooks Isoldi <brooks.isoldi at traversed.com>
> wrote:
>
>> I've configured Keycloak as a service on Ubuntu 14.04 and I'm finding
>> that terminating and restarting the Wildfly service (sudo service
>> wildfly restart) sometimes results in the keycloak-server.war being
>> undeployed and removed.
>>
>> Other times it happens by restarting from within the CLI.
>>
>> How do I restart Wildfly without terminating Keycloak?
>>
>> Thank you.
>>
>>
>>
>> -Brooks
>> _______________________________________________
>> 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

-- 
Best regards,
Konstantin Gribov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160606/6ef0769d/attachment.html 

From e.berdoncesbonelo at campus.tu-berlin.de  Mon Jun  6 08:39:08 2016
From: e.berdoncesbonelo at campus.tu-berlin.de (Erik Berdonces Bonelo)
Date: Mon, 6 Jun 2016 14:39:08 +0200
Subject: [keycloak-dev] Client Self-Registration and Administration Plugin
In-Reply-To: <etPan.5755683e.2150b7c4.b0fd@campus.tu-berlin.de>
References: <etPan.5755683e.2150b7c4.b0fd@campus.tu-berlin.de>
Message-ID: <etPan.57556ef1.7e79dbfa.b0fd@campus.tu-berlin.de>

?

Hello,  

I?m working at the moment in a Master Thesis project in TU Berlin where we are using Keycloak for Authentication and Authorisation purposes.  
We are planning on extending Keycloak in order to provide users a way to register clients/applications by themselves into the platform, while having an admin overseeing the system.

This would mean that as a user, if I have the proper rights I should be able to create and manage my own clients. With, this it comes the idea of ownership, as this would mean that a client ownership could be transferred to someone else.  
Also, the admin should be able to accept, revoke and delete the clients and requests to create clients in my Keycloak.

At the moment the only option would be giving the permission to create clients to the user, but that would allow to change ANY of the possible clients.  

Then, I have two questions:  
? 1. Would it make sense to integrate this to the Keycloak core?
? 2. If it doesn?t make sense to merge it in the core, is there any plugin system to extend Keycloak?s core? I?ve seen a discussion related to a plugin system in GitHub but there is no outcome yet. We would rather like to integrate it with Keycloak itself, otherwise the other option would be creating a client that uses Keycloak?s REST API to manage the clients remotely.

Thanks a lot in advance!?

???
?Best Regards,  
?Erik Berdonces Bonelo



From brooks.isoldi at traversed.com  Mon Jun  6 10:52:27 2016
From: brooks.isoldi at traversed.com (Brooks Isoldi)
Date: Mon, 6 Jun 2016 10:52:27 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
Message-ID: <57558E2B.1010307@traversed.com>

I'm using the standalone distribution of 1.9.4.Final.

We have had this issue after executing "sudo service wildfly restart" on 
command line.  We've also had it happen after starting Keycloak by 
simply running ./$JBOSS_HOME/bin/standalone.sh and after it starts up, 
hitting cntrl-c.  Additionally, we think it happened once while running 
shutdown --restart=true within the JBOSS CLI.

This has happened numerous times now, however we have not been able to 
create a reliable reproduction procedure.  I don't have logs to share 
right now, however I have seen in the server.log references to 
keycloak-server.war being undeployed.



On 06/06/2016 02:00 AM, Stian Thorgersen wrote:
> What version of Keycloak and what distribution (standalone, overlay or 
> demo) do you use?
>
> On 3 June 2016 at 21:56, Brooks Isoldi <brooks.isoldi at traversed.com 
> <mailto:brooks.isoldi at traversed.com>> wrote:
>
>     I've configured Keycloak as a service on Ubuntu 14.04 and I'm finding
>     that terminating and restarting the Wildfly service (sudo service
>     wildfly restart) sometimes results in the keycloak-server.war being
>     undeployed and removed.
>
>     Other times it happens by restarting from within the CLI.
>
>     How do I restart Wildfly without terminating Keycloak?
>
>     Thank you.
>
>
>
>     -Brooks
>     _______________________________________________
>     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
>
>

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

From jm85martins at gmail.com  Mon Jun  6 13:12:53 2016
From: jm85martins at gmail.com (Jorge M.)
Date: Mon, 6 Jun 2016 18:12:53 +0100
Subject: [keycloak-dev] OAuth2 Offline Token Introspection
Message-ID: <CAHEpHR+TqZ91tTsNJb3GiB29Kuse47C6O_cAQGA4aCav3c=WQA@mail.gmail.com>

Hi,

I'm using the oauth2 token introspection feature in order to validate and
get info about tokens, however I'm not being able to get info of
offline_tokens. Is that possible? Or does it make sense?

Thank you,
JM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160606/997e166b/attachment.html 

From sthorger at redhat.com  Mon Jun  6 13:18:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 6 Jun 2016 19:18:27 +0200
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <57558E2B.1010307@traversed.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
	<57558E2B.1010307@traversed.com>
Message-ID: <CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>

Do you modify the standalone distribution in any way? Do you deploy
applications to it? Anything else that you do to it that could affect this?

On 6 June 2016 at 16:52, Brooks Isoldi <brooks.isoldi at traversed.com> wrote:

> I'm using the standalone distribution of 1.9.4.Final.
>
> We have had this issue after executing "sudo service wildfly restart" on
> command line.  We've also had it happen after starting Keycloak by simply
> running ./$JBOSS_HOME/bin/standalone.sh and after it starts up, hitting
> cntrl-c.  Additionally, we think it happened once while running shutdown
> --restart=true within the JBOSS CLI.
>
> This has happened numerous times now, however we have not been able to
> create a reliable reproduction procedure.  I don't have logs to share right
> now, however I have seen in the server.log references to
> keycloak-server.war being undeployed.
>
>
>
>
> On 06/06/2016 02:00 AM, Stian Thorgersen wrote:
>
> What version of Keycloak and what distribution (standalone, overlay or
> demo) do you use?
>
> On 3 June 2016 at 21:56, Brooks Isoldi <brooks.isoldi at traversed.com>
> wrote:
>
>> I've configured Keycloak as a service on Ubuntu 14.04 and I'm finding
>> that terminating and restarting the Wildfly service (sudo service
>> wildfly restart) sometimes results in the keycloak-server.war being
>> undeployed and removed.
>>
>> Other times it happens by restarting from within the CLI.
>>
>> How do I restart Wildfly without terminating Keycloak?
>>
>> Thank you.
>>
>>
>>
>> -Brooks
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160606/838ff3a4/attachment-0001.html 

From bburke at redhat.com  Mon Jun  6 13:26:23 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 6 Jun 2016 13:26:23 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
	<57558E2B.1010307@traversed.com>
	<CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>
Message-ID: <eb892974-ed52-55a8-9a9b-02ad1e72a603@redhat.com>

DO you see the war being redeployed?  It does take a few seconds for the 
war to be available.


On 6/6/16 1:18 PM, Stian Thorgersen wrote:
> Do you modify the standalone distribution in any way? Do you deploy 
> applications to it? Anything else that you do to it that could affect 
> this?
>
> On 6 June 2016 at 16:52, Brooks Isoldi <brooks.isoldi at traversed.com 
> <mailto:brooks.isoldi at traversed.com>> wrote:
>
>     I'm using the standalone distribution of 1.9.4.Final.
>
>     We have had this issue after executing "sudo service wildfly
>     restart" on command line.  We've also had it happen after starting
>     Keycloak by simply running ./$JBOSS_HOME/bin/standalone.sh and
>     after it starts up, hitting cntrl-c.  Additionally, we think it
>     happened once while running shutdown --restart=true within the
>     JBOSS CLI.
>
>     This has happened numerous times now, however we have not been
>     able to create a reliable reproduction procedure.  I don't have
>     logs to share right now, however I have seen in the server.log
>     references to keycloak-server.war being undeployed.
>
>
>
>
>     On 06/06/2016 02:00 AM, Stian Thorgersen wrote:
>>     What version of Keycloak and what distribution (standalone,
>>     overlay or demo) do you use?
>>
>>     On 3 June 2016 at 21:56, Brooks Isoldi
>>     <brooks.isoldi at traversed.com
>>     <mailto:brooks.isoldi at traversed.com>> wrote:
>>
>>         I've configured Keycloak as a service on Ubuntu 14.04 and I'm
>>         finding
>>         that terminating and restarting the Wildfly service (sudo service
>>         wildfly restart) sometimes results in the keycloak-server.war
>>         being
>>         undeployed and removed.
>>
>>         Other times it happens by restarting from within the CLI.
>>
>>         How do I restart Wildfly without terminating Keycloak?
>>
>>         Thank you.
>>
>>
>>
>>         -Brooks
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Mon Jun  6 13:36:03 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 6 Jun 2016 19:36:03 +0200
Subject: [keycloak-dev] Client Self-Registration and Administration
	Plugin
In-Reply-To: <etPan.57556ef1.7e79dbfa.b0fd@campus.tu-berlin.de>
References: <etPan.5755683e.2150b7c4.b0fd@campus.tu-berlin.de>
	<etPan.57556ef1.7e79dbfa.b0fd@campus.tu-berlin.de>
Message-ID: <CAJgngAcF=z7kVZO45NEpqmUkmNASNfh+4FP3TYFJUKOi57oRnw@mail.gmail.com>

Hi,

We are planing to add more fine-grained permissions on admin endpoints in
the future, but it will be a while until we get to it. I'm not very keen on
accepting something like this now as we are planning to do fairly big
changes around this in the future. You're also the first person to ask
about having clients specific to user, other people have so far requested
groups of clients that groups of users can manage.

I'd recommend using the Realm Resource SPI to create custom endpoints to
accomplish this. You can use an attribute on the clients to store the user
that has created the client and only allow that user to modify it in the
future. You can also consider using the client registration service. The
client registration service allows anyone with a create-role or an initial
access token to create clients. When a client is created it returns a
registration access token that gives permission to modify/delete that
particular client in the future.

On 6 June 2016 at 14:39, Erik Berdonces Bonelo <
e.berdoncesbonelo at campus.tu-berlin.de> wrote:

>
>
> Hello,
>
> I?m working at the moment in a Master Thesis project in TU Berlin where we
> are using Keycloak for Authentication and Authorisation purposes.
> We are planning on extending Keycloak in order to provide users a way to
> register clients/applications by themselves into the platform, while having
> an admin overseeing the system.
>
> This would mean that as a user, if I have the proper rights I should be
> able to create and manage my own clients. With, this it comes the idea of
> ownership, as this would mean that a client ownership could be transferred
> to someone else.
> Also, the admin should be able to accept, revoke and delete the clients
> and requests to create clients in my Keycloak.
>
> At the moment the only option would be giving the permission to create
> clients to the user, but that would allow to change ANY of the possible
> clients.
>
> Then, I have two questions:
>   1. Would it make sense to integrate this to the Keycloak core?
>   2. If it doesn?t make sense to merge it in the core, is there any plugin
> system to extend Keycloak?s core? I?ve seen a discussion related to a
> plugin system in GitHub but there is no outcome yet. We would rather like
> to integrate it with Keycloak itself, otherwise the other option would be
> creating a client that uses Keycloak?s REST API to manage the clients
> remotely.
>
> Thanks a lot in advance!
>
>  ?
>  Best Regards,
>  Erik Berdonces Bonelo
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160606/91317d0d/attachment.html 

From brooks.isoldi at traversed.com  Mon Jun  6 14:19:57 2016
From: brooks.isoldi at traversed.com (Brooks Isoldi)
Date: Mon, 6 Jun 2016 14:19:57 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
	<57558E2B.1010307@traversed.com>
	<CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>
Message-ID: <5755BECD.2060801@traversed.com>

Bill,

We do not see the war being redeployed upon startup.


Stian,

We are deploying a non-JEE application to the Keycloak Wildfly instance 
and our initial setup process includes the following commands:


sudo ./jboss-cli.sh -c <<EOF
module add --name=org.postgres 
--resources=${KEYCLOAK_INSTALL_DIR}/${JDBC_FILENAME} 
--dependencies=javax.api,javax.transaction.api
/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver)
data-source add --jndi-name=java:/PostgresDS --name=PostgrePool 
--connection-url=jdbc:postgresql://${POSTGRES_SERVER_URL} 
--driver-name=postgres --user-name=<<USERNAME>> --password=<<PASSWORD>>
/core-service=management/security-realm=ApplicationRealm/server-identity=ssl/:add(keystore-path=keystore.jks, 
keystore-relative-to=jboss.server.config.dir, 
keystore-password=<<PASSWORD>>, alias=keystore, key-password=<<PASSWORD>>)
EOF

sleep 10

sudo service wildfly restart

sleep 10

sudo ./jboss-cli.sh -c <<EOF
/subsystem=undertow/server=default-server/https-listener=https/:add(socket-binding=https, 
security-realm=ApplicationRealm)
EOF

sleep 10

sudo service wildfly restart

sleep 10

cd ${KEYCLOAK_INSTALL_DIR}/bin
sudo ./jboss-cli.sh -c --file=adapter-install.cli




On 06/06/2016 01:18 PM, Stian Thorgersen wrote:
> Do you modify the standalone distribution in any way? Do you deploy 
> applications to it? Anything else that you do to it that could affect 
> this?
>
> On 6 June 2016 at 16:52, Brooks Isoldi <brooks.isoldi at traversed.com 
> <mailto:brooks.isoldi at traversed.com>> wrote:
>
>     I'm using the standalone distribution of 1.9.4.Final.
>
>     We have had this issue after executing "sudo service wildfly
>     restart" on command line.  We've also had it happen after starting
>     Keycloak by simply running ./$JBOSS_HOME/bin/standalone.sh and
>     after it starts up, hitting cntrl-c.  Additionally, we think it
>     happened once while running shutdown --restart=true within the
>     JBOSS CLI.
>
>     This has happened numerous times now, however we have not been
>     able to create a reliable reproduction procedure.  I don't have
>     logs to share right now, however I have seen in the server.log
>     references to keycloak-server.war being undeployed.
>
>
>
>
>     On 06/06/2016 02:00 AM, Stian Thorgersen wrote:
>>     What version of Keycloak and what distribution (standalone,
>>     overlay or demo) do you use?
>>
>>     On 3 June 2016 at 21:56, Brooks Isoldi
>>     <brooks.isoldi at traversed.com
>>     <mailto:brooks.isoldi at traversed.com>> wrote:
>>
>>         I've configured Keycloak as a service on Ubuntu 14.04 and I'm
>>         finding
>>         that terminating and restarting the Wildfly service (sudo service
>>         wildfly restart) sometimes results in the keycloak-server.war
>>         being
>>         undeployed and removed.
>>
>>         Other times it happens by restarting from within the CLI.
>>
>>         How do I restart Wildfly without terminating Keycloak?
>>
>>         Thank you.
>>
>>
>>
>>         -Brooks
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From brooks.isoldi at traversed.com  Mon Jun  6 16:00:35 2016
From: brooks.isoldi at traversed.com (Brooks Isoldi)
Date: Mon, 6 Jun 2016 16:00:35 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <5755BECD.2060801@traversed.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
	<57558E2B.1010307@traversed.com>
	<CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>
	<5755BECD.2060801@traversed.com>
Message-ID: <5755D663.1050800@traversed.com>

Stian,

I apologize, by "non-JEE" application, I meant only that it does not 
rely on standalone-full.xml.  We're using only standalone.xml for the 
application deployed to the keycloak wildfly server.

Thanks.




On 06/06/2016 02:19 PM, Brooks Isoldi wrote:
> Bill,
>
> We do not see the war being redeployed upon startup.
>
>
> Stian,
>
> We are deploying a non-JEE application to the Keycloak Wildfly 
> instance and our initial setup process includes the following commands:
>
>
> sudo ./jboss-cli.sh -c <<EOF
> module add --name=org.postgres 
> --resources=${KEYCLOAK_INSTALL_DIR}/${JDBC_FILENAME} 
> --dependencies=javax.api,javax.transaction.api
> /subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver)
> data-source add --jndi-name=java:/PostgresDS --name=PostgrePool 
> --connection-url=jdbc:postgresql://${POSTGRES_SERVER_URL} 
> --driver-name=postgres --user-name=<<USERNAME>> --password=<<PASSWORD>>
> /core-service=management/security-realm=ApplicationRealm/server-identity=ssl/:add(keystore-path=keystore.jks, 
> keystore-relative-to=jboss.server.config.dir, 
> keystore-password=<<PASSWORD>>, alias=keystore, key-password=<<PASSWORD>>)
> EOF
>
> sleep 10
>
> sudo service wildfly restart
>
> sleep 10
>
> sudo ./jboss-cli.sh -c <<EOF
> /subsystem=undertow/server=default-server/https-listener=https/:add(socket-binding=https, 
> security-realm=ApplicationRealm)
> EOF
>
> sleep 10
>
> sudo service wildfly restart
>
> sleep 10
>
> cd ${KEYCLOAK_INSTALL_DIR}/bin
> sudo ./jboss-cli.sh -c --file=adapter-install.cli
>
>
>
>
> On 06/06/2016 01:18 PM, Stian Thorgersen wrote:
>> Do you modify the standalone distribution in any way? Do you deploy 
>> applications to it? Anything else that you do to it that could affect 
>> this?
>>
>> On 6 June 2016 at 16:52, Brooks Isoldi <brooks.isoldi at traversed.com 
>> <mailto:brooks.isoldi at traversed.com>> wrote:
>>
>>     I'm using the standalone distribution of 1.9.4.Final.
>>
>>     We have had this issue after executing "sudo service wildfly
>>     restart" on command line.  We've also had it happen after
>>     starting Keycloak by simply running
>>     ./$JBOSS_HOME/bin/standalone.sh and after it starts up, hitting
>>     cntrl-c.  Additionally, we think it happened once while running
>>     shutdown --restart=true within the JBOSS CLI.
>>
>>     This has happened numerous times now, however we have not been
>>     able to create a reliable reproduction procedure.  I don't have
>>     logs to share right now, however I have seen in the server.log
>>     references to keycloak-server.war being undeployed.
>>
>>
>>
>>
>>     On 06/06/2016 02:00 AM, Stian Thorgersen wrote:
>>>     What version of Keycloak and what distribution (standalone,
>>>     overlay or demo) do you use?
>>>
>>>     On 3 June 2016 at 21:56, Brooks Isoldi
>>>     <brooks.isoldi at traversed.com> wrote:
>>>
>>>         I've configured Keycloak as a service on Ubuntu 14.04 and
>>>         I'm finding
>>>         that terminating and restarting the Wildfly service (sudo
>>>         service
>>>         wildfly restart) sometimes results in the
>>>         keycloak-server.war being
>>>         undeployed and removed.
>>>
>>>         Other times it happens by restarting from within the CLI.
>>>
>>>         How do I restart Wildfly without terminating Keycloak?
>>>
>>>         Thank you.
>>>
>>>
>>>
>>>         -Brooks
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>

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

From ssilvert at redhat.com  Mon Jun  6 16:34:18 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 06 Jun 2016 16:34:18 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <5755D663.1050800@traversed.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
	<57558E2B.1010307@traversed.com>
	<CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>
	<5755BECD.2060801@traversed.com> <5755D663.1050800@traversed.com>
Message-ID: <5755DE4A.2060004@redhat.com>

We strongly, strongly, strongly discourage application deployment on the 
Keycloak server.  In fact, we might soon be taking steps keep people 
from doing that.

Can you re-create the problem with the Keycloak server alone?

On 6/6/2016 4:00 PM, Brooks Isoldi wrote:
> Stian,
>
> I apologize, by "non-JEE" application, I meant only that it does not 
> rely on standalone-full.xml.  We're using only standalone.xml for the 
> application deployed to the keycloak wildfly server.
>
> Thanks.
>
>
>
>
> On 06/06/2016 02:19 PM, Brooks Isoldi wrote:
>> Bill,
>>
>> We do not see the war being redeployed upon startup.
>>
>>
>> Stian,
>>
>> We are deploying a non-JEE application to the Keycloak Wildfly 
>> instance and our initial setup process includes the following commands:
>>
>>
>> sudo ./jboss-cli.sh -c <<EOF
>> module add --name=org.postgres 
>> --resources=${KEYCLOAK_INSTALL_DIR}/${JDBC_FILENAME} 
>> --dependencies=javax.api,javax.transaction.api
>> /subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver)
>> data-source add --jndi-name=java:/PostgresDS --name=PostgrePool 
>> --connection-url=jdbc:postgresql://${POSTGRES_SERVER_URL} 
>> --driver-name=postgres --user-name=<<USERNAME>> --password=<<PASSWORD>>
>> /core-service=management/security-realm=ApplicationRealm/server-identity=ssl/:add(keystore-path=keystore.jks, 
>> keystore-relative-to=jboss.server.config.dir, 
>> keystore-password=<<PASSWORD>>, alias=keystore, 
>> key-password=<<PASSWORD>>)
>> EOF
>>
>> sleep 10
>>
>> sudo service wildfly restart
>>
>> sleep 10
>>
>> sudo ./jboss-cli.sh -c <<EOF
>> /subsystem=undertow/server=default-server/https-listener=https/:add(socket-binding=https, 
>> security-realm=ApplicationRealm)
>> EOF
>>
>> sleep 10
>>
>> sudo service wildfly restart
>>
>> sleep 10
>>
>> cd ${KEYCLOAK_INSTALL_DIR}/bin
>> sudo ./jboss-cli.sh -c --file=adapter-install.cli
>>
>>
>>
>>
>> On 06/06/2016 01:18 PM, Stian Thorgersen wrote:
>>> Do you modify the standalone distribution in any way? Do you deploy 
>>> applications to it? Anything else that you do to it that could 
>>> affect this?
>>>
>>> On 6 June 2016 at 16:52, Brooks Isoldi <brooks.isoldi at traversed.com 
>>> <mailto:brooks.isoldi at traversed.com>> wrote:
>>>
>>>     I'm using the standalone distribution of 1.9.4.Final.
>>>
>>>     We have had this issue after executing "sudo service wildfly
>>>     restart" on command line.  We've also had it happen after
>>>     starting Keycloak by simply running
>>>     ./$JBOSS_HOME/bin/standalone.sh and after it starts up, hitting
>>>     cntrl-c.  Additionally, we think it happened once while running
>>>     shutdown --restart=true within the JBOSS CLI.
>>>
>>>     This has happened numerous times now, however we have not been
>>>     able to create a reliable reproduction procedure.  I don't have
>>>     logs to share right now, however I have seen in the server.log
>>>     references to keycloak-server.war being undeployed.
>>>
>>>
>>>
>>>
>>>     On 06/06/2016 02:00 AM, Stian Thorgersen wrote:
>>>>     What version of Keycloak and what distribution (standalone,
>>>>     overlay or demo) do you use?
>>>>
>>>>     On 3 June 2016 at 21:56, Brooks Isoldi
>>>>     <brooks.isoldi at traversed.com> wrote:
>>>>
>>>>         I've configured Keycloak as a service on Ubuntu 14.04 and
>>>>         I'm finding
>>>>         that terminating and restarting the Wildfly service (sudo
>>>>         service
>>>>         wildfly restart) sometimes results in the
>>>>         keycloak-server.war being
>>>>         undeployed and removed.
>>>>
>>>>         Other times it happens by restarting from within the CLI.
>>>>
>>>>         How do I restart Wildfly without terminating Keycloak?
>>>>
>>>>         Thank you.
>>>>
>>>>
>>>>
>>>>         -Brooks
>>>>         _______________________________________________
>>>>         keycloak-dev mailing list
>>>>         keycloak-dev at lists.jboss.org
>>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>
>>>
>>>     _______________________________________________
>>>     keycloak-dev mailing list
>>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From brooks.isoldi at traversed.com  Mon Jun  6 16:55:33 2016
From: brooks.isoldi at traversed.com (Brooks Isoldi)
Date: Mon, 6 Jun 2016 16:55:33 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <5755DE4A.2060004@redhat.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
	<57558E2B.1010307@traversed.com>
	<CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>
	<5755BECD.2060801@traversed.com> <5755D663.1050800@traversed.com>
	<5755DE4A.2060004@redhat.com>
Message-ID: <5755E345.6040703@traversed.com>

We will give it a shot and try to reproduce with just the 
keycloak-server.war file alone.

Meanwhile, can you give some instruction on how to tie my application 
into the Keycloak authentication?  The manual says to drop the following 
into the web.xml file:

     <login-config>
         <auth-method>KEYCLOAK</auth-method>
         <realm-name>app-name</realm-name>
     </login-config>

I assume that will not work if keycloak resides on a totally separate 
server...Or will that be taken care of by the "auth-server-url" in the 
keycloak.json file?

Thanks.




On 06/06/2016 04:34 PM, Stan Silvert wrote:
> We strongly, strongly, strongly discourage application deployment on 
> the Keycloak server.  In fact, we might soon be taking steps keep 
> people from doing that.
>
> Can you re-create the problem with the Keycloak server alone?
>
> On 6/6/2016 4:00 PM, Brooks Isoldi wrote:
>> Stian,
>>
>> I apologize, by "non-JEE" application, I meant only that it does not 
>> rely on standalone-full.xml.  We're using only standalone.xml for the 
>> application deployed to the keycloak wildfly server.
>>
>> Thanks.
>>
>>
>>
>>
>> On 06/06/2016 02:19 PM, Brooks Isoldi wrote:
>>> Bill,
>>>
>>> We do not see the war being redeployed upon startup.
>>>
>>>
>>> Stian,
>>>
>>> We are deploying a non-JEE application to the Keycloak Wildfly 
>>> instance and our initial setup process includes the following commands:
>>>
>>>
>>> sudo ./jboss-cli.sh -c <<EOF
>>> module add --name=org.postgres 
>>> --resources=${KEYCLOAK_INSTALL_DIR}/${JDBC_FILENAME} 
>>> --dependencies=javax.api,javax.transaction.api
>>> /subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver)
>>> data-source add --jndi-name=java:/PostgresDS --name=PostgrePool 
>>> --connection-url=jdbc:postgresql://${POSTGRES_SERVER_URL} 
>>> --driver-name=postgres --user-name=<<USERNAME>> --password=<<PASSWORD>>
>>> /core-service=management/security-realm=ApplicationRealm/server-identity=ssl/:add(keystore-path=keystore.jks, 
>>> keystore-relative-to=jboss.server.config.dir, 
>>> keystore-password=<<PASSWORD>>, alias=keystore, 
>>> key-password=<<PASSWORD>>)
>>> EOF
>>>
>>> sleep 10
>>>
>>> sudo service wildfly restart
>>>
>>> sleep 10
>>>
>>> sudo ./jboss-cli.sh -c <<EOF
>>> /subsystem=undertow/server=default-server/https-listener=https/:add(socket-binding=https, 
>>> security-realm=ApplicationRealm)
>>> EOF
>>>
>>> sleep 10
>>>
>>> sudo service wildfly restart
>>>
>>> sleep 10
>>>
>>> cd ${KEYCLOAK_INSTALL_DIR}/bin
>>> sudo ./jboss-cli.sh -c --file=adapter-install.cli
>>>
>>>
>>>
>>>
>>> On 06/06/2016 01:18 PM, Stian Thorgersen wrote:
>>>> Do you modify the standalone distribution in any way? Do you deploy 
>>>> applications to it? Anything else that you do to it that could 
>>>> affect this?
>>>>
>>>> On 6 June 2016 at 16:52, Brooks Isoldi <brooks.isoldi at traversed.com 
>>>> <mailto:brooks.isoldi at traversed.com>> wrote:
>>>>
>>>>     I'm using the standalone distribution of 1.9.4.Final.
>>>>
>>>>     We have had this issue after executing "sudo service wildfly
>>>>     restart" on command line.  We've also had it happen after
>>>>     starting Keycloak by simply running
>>>>     ./$JBOSS_HOME/bin/standalone.sh and after it starts up, hitting
>>>>     cntrl-c.  Additionally, we think it happened once while running
>>>>     shutdown --restart=true within the JBOSS CLI.
>>>>
>>>>     This has happened numerous times now, however we have not been
>>>>     able to create a reliable reproduction procedure.  I don't have
>>>>     logs to share right now, however I have seen in the server.log
>>>>     references to keycloak-server.war being undeployed.
>>>>
>>>>
>>>>
>>>>
>>>>     On 06/06/2016 02:00 AM, Stian Thorgersen wrote:
>>>>>     What version of Keycloak and what distribution (standalone,
>>>>>     overlay or demo) do you use?
>>>>>
>>>>>     On 3 June 2016 at 21:56, Brooks Isoldi
>>>>>     <brooks.isoldi at traversed.com> wrote:
>>>>>
>>>>>         I've configured Keycloak as a service on Ubuntu 14.04 and
>>>>>         I'm finding
>>>>>         that terminating and restarting the Wildfly service (sudo
>>>>>         service
>>>>>         wildfly restart) sometimes results in the
>>>>>         keycloak-server.war being
>>>>>         undeployed and removed.
>>>>>
>>>>>         Other times it happens by restarting from within the CLI.
>>>>>
>>>>>         How do I restart Wildfly without terminating Keycloak?
>>>>>
>>>>>         Thank you.
>>>>>
>>>>>
>>>>>
>>>>>         -Brooks
>>>>>         _______________________________________________
>>>>>         keycloak-dev mailing list
>>>>>         keycloak-dev at lists.jboss.org
>>>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     keycloak-dev mailing list
>>>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From ssilvert at redhat.com  Mon Jun  6 17:08:29 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 06 Jun 2016 17:08:29 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <5755E345.6040703@traversed.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
	<57558E2B.1010307@traversed.com>
	<CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>
	<5755BECD.2060801@traversed.com>
	<5755D663.1050800@traversed.com> <5755DE4A.2060004@redhat.com>
	<5755E345.6040703@traversed.com>
Message-ID: <5755E64D.1090809@redhat.com>

On 6/6/2016 4:55 PM, Brooks Isoldi wrote:
> We will give it a shot and try to reproduce with just the 
> keycloak-server.war file alone.
>
> Meanwhile, can you give some instruction on how to tie my application 
> into the Keycloak authentication?  The manual says to drop the 
> following into the web.xml file:
>
>     <login-config>
>         <auth-method>KEYCLOAK</auth-method>
>         <realm-name>app-name</realm-name>
>     </login-config>
You will still need the auth-method.
>
> I assume that will not work if keycloak resides on a totally separate 
> server...Or will that be taken care of by the "auth-server-url" in the 
> keycloak.json file?
See the section on how to use the WildFly adapter for your 
application/client. 
http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#jboss-adapter
>
> Thanks.
>
>
>
>
> On 06/06/2016 04:34 PM, Stan Silvert wrote:
>> We strongly, strongly, strongly discourage application deployment on 
>> the Keycloak server.  In fact, we might soon be taking steps keep 
>> people from doing that.
>>
>> Can you re-create the problem with the Keycloak server alone?
>>
>> On 6/6/2016 4:00 PM, Brooks Isoldi wrote:
>>> Stian,
>>>
>>> I apologize, by "non-JEE" application, I meant only that it does not 
>>> rely on standalone-full.xml.  We're using only standalone.xml for 
>>> the application deployed to the keycloak wildfly server.
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>> On 06/06/2016 02:19 PM, Brooks Isoldi wrote:
>>>> Bill,
>>>>
>>>> We do not see the war being redeployed upon startup.
>>>>
>>>>
>>>> Stian,
>>>>
>>>> We are deploying a non-JEE application to the Keycloak Wildfly 
>>>> instance and our initial setup process includes the following commands:
>>>>
>>>>
>>>> sudo ./jboss-cli.sh -c <<EOF
>>>> module add --name=org.postgres 
>>>> --resources=${KEYCLOAK_INSTALL_DIR}/${JDBC_FILENAME} 
>>>> --dependencies=javax.api,javax.transaction.api
>>>> /subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver)
>>>> data-source add --jndi-name=java:/PostgresDS --name=PostgrePool 
>>>> --connection-url=jdbc:postgresql://${POSTGRES_SERVER_URL} 
>>>> --driver-name=postgres --user-name=<<USERNAME>> --password=<<PASSWORD>>
>>>> /core-service=management/security-realm=ApplicationRealm/server-identity=ssl/:add(keystore-path=keystore.jks, 
>>>> keystore-relative-to=jboss.server.config.dir, 
>>>> keystore-password=<<PASSWORD>>, alias=keystore, 
>>>> key-password=<<PASSWORD>>)
>>>> EOF
>>>>
>>>> sleep 10
>>>>
>>>> sudo service wildfly restart
>>>>
>>>> sleep 10
>>>>
>>>> sudo ./jboss-cli.sh -c <<EOF
>>>> /subsystem=undertow/server=default-server/https-listener=https/:add(socket-binding=https, 
>>>> security-realm=ApplicationRealm)
>>>> EOF
>>>>
>>>> sleep 10
>>>>
>>>> sudo service wildfly restart
>>>>
>>>> sleep 10
>>>>
>>>> cd ${KEYCLOAK_INSTALL_DIR}/bin
>>>> sudo ./jboss-cli.sh -c --file=adapter-install.cli
>>>>
>>>>
>>>>
>>>>
>>>> On 06/06/2016 01:18 PM, Stian Thorgersen wrote:
>>>>> Do you modify the standalone distribution in any way? Do you 
>>>>> deploy applications to it? Anything else that you do to it that 
>>>>> could affect this?
>>>>>
>>>>> On 6 June 2016 at 16:52, Brooks Isoldi 
>>>>> <brooks.isoldi at traversed.com <mailto:brooks.isoldi at traversed.com>> 
>>>>> wrote:
>>>>>
>>>>>     I'm using the standalone distribution of 1.9.4.Final.
>>>>>
>>>>>     We have had this issue after executing "sudo service wildfly
>>>>>     restart" on command line.  We've also had it happen after
>>>>>     starting Keycloak by simply running
>>>>>     ./$JBOSS_HOME/bin/standalone.sh and after it starts up,
>>>>>     hitting cntrl-c. Additionally, we think it happened once while
>>>>>     running shutdown --restart=true within the JBOSS CLI.
>>>>>
>>>>>     This has happened numerous times now, however we have not been
>>>>>     able to create a reliable reproduction procedure.  I don't
>>>>>     have logs to share right now, however I have seen in the
>>>>>     server.log references to keycloak-server.war being undeployed.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     On 06/06/2016 02:00 AM, Stian Thorgersen wrote:
>>>>>>     What version of Keycloak and what distribution (standalone,
>>>>>>     overlay or demo) do you use?
>>>>>>
>>>>>>     On 3 June 2016 at 21:56, Brooks Isoldi
>>>>>>     <brooks.isoldi at traversed.com> wrote:
>>>>>>
>>>>>>         I've configured Keycloak as a service on Ubuntu 14.04 and
>>>>>>         I'm finding
>>>>>>         that terminating and restarting the Wildfly service (sudo
>>>>>>         service
>>>>>>         wildfly restart) sometimes results in the
>>>>>>         keycloak-server.war being
>>>>>>         undeployed and removed.
>>>>>>
>>>>>>         Other times it happens by restarting from within the CLI.
>>>>>>
>>>>>>         How do I restart Wildfly without terminating Keycloak?
>>>>>>
>>>>>>         Thank you.
>>>>>>
>>>>>>
>>>>>>
>>>>>>         -Brooks
>>>>>>         _______________________________________________
>>>>>>         keycloak-dev mailing list
>>>>>>         keycloak-dev at lists.jboss.org
>>>>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     keycloak-dev mailing list
>>>>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> 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

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

From mposolda at redhat.com  Tue Jun  7 02:35:11 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 7 Jun 2016 08:35:11 +0200
Subject: [keycloak-dev] OAuth2 Offline Token Introspection
In-Reply-To: <CAHEpHR+TqZ91tTsNJb3GiB29Kuse47C6O_cAQGA4aCav3c=WQA@mail.gmail.com>
References: <CAHEpHR+TqZ91tTsNJb3GiB29Kuse47C6O_cAQGA4aCav3c=WQA@mail.gmail.com>
Message-ID: <57566B1F.6000202@redhat.com>

Hi,

it seems that oauth2 token introspection specs doesn't have any direct 
support for OIDC offline tokens. However you can possibly create JIRA 
for it. Currently it seems we consider token as valid just if there is 
"online" valid userSession. In case of offlineToken, it should check 
"offline" session instead.

Marek

On 06/06/16 19:12, Jorge M. wrote:
> Hi,
>
> I'm using the oauth2 token introspection feature in order to validate 
> and get info about tokens, however I'm not being able to get info of 
> offline_tokens. Is that possible? Or does it make sense?
>
> Thank you,
> JM
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Tue Jun  7 03:17:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 7 Jun 2016 09:17:47 +0200
Subject: [keycloak-dev] OAuth2 Offline Token Introspection
In-Reply-To: <57566B1F.6000202@redhat.com>
References: <CAHEpHR+TqZ91tTsNJb3GiB29Kuse47C6O_cAQGA4aCav3c=WQA@mail.gmail.com>
	<57566B1F.6000202@redhat.com>
Message-ID: <CAJgngAcPmKeKAxTvSzkYoFR58AHoRxEtdWjfCQ9akp2n2Hg_1g@mail.gmail.com>

The token introspection endpoint is for access tokens though, not refresh
tokens and offline tokens. You should introspect an access token retrieved
using the offline token, not the offline token itself.

On 7 June 2016 at 08:35, Marek Posolda <mposolda at redhat.com> wrote:

> Hi,
>
> it seems that oauth2 token introspection specs doesn't have any direct
> support for OIDC offline tokens. However you can possibly create JIRA for
> it. Currently it seems we consider token as valid just if there is "online"
> valid userSession. In case of offlineToken, it should check "offline"
> session instead.
>
> Marek
>
>
> On 06/06/16 19:12, Jorge M. wrote:
>
> Hi,
>
> I'm using the oauth2 token introspection feature in order to validate and
> get info about tokens, however I'm not being able to get info of
> offline_tokens. Is that possible? Or does it make sense?
>
> Thank you,
> JM
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160607/a4a3629c/attachment.html 

From mposolda at redhat.com  Tue Jun  7 03:29:07 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 7 Jun 2016 09:29:07 +0200
Subject: [keycloak-dev] OAuth2 Offline Token Introspection
In-Reply-To: <CAJgngAcPmKeKAxTvSzkYoFR58AHoRxEtdWjfCQ9akp2n2Hg_1g@mail.gmail.com>
References: <CAHEpHR+TqZ91tTsNJb3GiB29Kuse47C6O_cAQGA4aCav3c=WQA@mail.gmail.com>
	<57566B1F.6000202@redhat.com>
	<CAJgngAcPmKeKAxTvSzkYoFR58AHoRxEtdWjfCQ9akp2n2Hg_1g@mail.gmail.com>
Message-ID: <575677C3.8080000@redhat.com>

The introspection specs has some support for refresh tokens and our impl 
supports it too. You can even provide "token_type_hint" parameter and 
use either the value "access_token" or "refresh_token" .

The offline token is not directly supported, but I am personally not 
seeing an issue for us to be a bit more "clever" and lookup offline 
sessions instead of online sessions in case that type of provided token 
is offline token?

Marek

On 07/06/16 09:17, Stian Thorgersen wrote:
> The token introspection endpoint is for access tokens though, not 
> refresh tokens and offline tokens. You should introspect an access 
> token retrieved using the offline token, not the offline token itself.
>
> On 7 June 2016 at 08:35, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Hi,
>
>     it seems that oauth2 token introspection specs doesn't have any
>     direct support for OIDC offline tokens. However you can possibly
>     create JIRA for it. Currently it seems we consider token as valid
>     just if there is "online" valid userSession. In case of
>     offlineToken, it should check "offline" session instead.
>
>     Marek
>
>
>     On 06/06/16 19:12, Jorge M. wrote:
>>     Hi,
>>
>>     I'm using the oauth2 token introspection feature in order to
>>     validate and get info about tokens, however I'm not being able to
>>     get info of offline_tokens. Is that possible? Or does it make sense?
>>
>>     Thank you,
>>     JM
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Tue Jun  7 03:34:28 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 7 Jun 2016 09:34:28 +0200
Subject: [keycloak-dev] OAuth2 Offline Token Introspection
In-Reply-To: <575677C3.8080000@redhat.com>
References: <CAHEpHR+TqZ91tTsNJb3GiB29Kuse47C6O_cAQGA4aCav3c=WQA@mail.gmail.com>
	<57566B1F.6000202@redhat.com>
	<CAJgngAcPmKeKAxTvSzkYoFR58AHoRxEtdWjfCQ9akp2n2Hg_1g@mail.gmail.com>
	<575677C3.8080000@redhat.com>
Message-ID: <CAJgngAdx2r-v=iL-sdbCgwDuAf8Yok8K7Wu_H0Xu7KHmZ_jP9Q@mail.gmail.com>

In that case +1 to support offline tokens.

On 7 June 2016 at 09:29, Marek Posolda <mposolda at redhat.com> wrote:

> The introspection specs has some support for refresh tokens and our impl
> supports it too. You can even provide "token_type_hint" parameter and use
> either the value "access_token" or "refresh_token" .
>
> The offline token is not directly supported, but I am personally not
> seeing an issue for us to be a bit more "clever" and lookup offline
> sessions instead of online sessions in case that type of provided token is
> offline token?
>
> Marek
>
>
> On 07/06/16 09:17, Stian Thorgersen wrote:
>
> The token introspection endpoint is for access tokens though, not refresh
> tokens and offline tokens. You should introspect an access token retrieved
> using the offline token, not the offline token itself.
>
> On 7 June 2016 at 08:35, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Hi,
>>
>> it seems that oauth2 token introspection specs doesn't have any direct
>> support for OIDC offline tokens. However you can possibly create JIRA for
>> it. Currently it seems we consider token as valid just if there is "online"
>> valid userSession. In case of offlineToken, it should check "offline"
>> session instead.
>>
>> Marek
>>
>>
>> On 06/06/16 19:12, Jorge M. wrote:
>>
>> Hi,
>>
>> I'm using the oauth2 token introspection feature in order to validate and
>> get info about tokens, however I'm not being able to get info of
>> offline_tokens. Is that possible? Or does it make sense?
>>
>> Thank you,
>> JM
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160607/12031905/attachment.html 

From thomas.darimont at googlemail.com  Tue Jun  7 03:57:32 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 7 Jun 2016 09:57:32 +0200
Subject: [keycloak-dev] Record activity for user accounts
Message-ID: <CAK-7U1hnuCqACkYUHopay=qF7gdGp1AHu1KQFVGMMPj62HgOsQ@mail.gmail.com>

Hello Group,

Some account services like google for instance record and list activities
that
happend in an account like: Access Type, Location, Date time.

I think this would make a great addition to the account pages in Keycloak,
since it would help users to detect suspicious account activity early.

What do you think?

Google shows the following information:
* Access Type (Which device was used to access the account: Browser,
Mobile, etc...)
For this one could add a device detection library to the account page like
mobile-detect.js
http://hgoebl.github.io/mobile-detect.js/

* Location (based on IP-Address)
IP Geolocation could be based on free geolite database
http://dev.maxmind.com/geoip/legacy/geolite/
https://github.com/maxmind/GeoIP2-java

* Date time
Datetime of access + humanized "x mins ago"

* current "access point"
The current "access point" is also shown like:
Your computer uses the IP XXX.XXX.XXX.XXX. (Some Country)

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160607/88e4683d/attachment-0001.html 

From thomas.darimont at googlemail.com  Tue Jun  7 05:22:01 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 7 Jun 2016 11:22:01 +0200
Subject: [keycloak-dev] Narrowed down event subjects for AdminEvents
Message-ID: <CAK-7U1i8fCbfU83RxQk9pMr7k5_dxZs1oLys3X73Gse2gaRVXg@mail.gmail.com>

Hello Group,

when writing custom EventListeners for propagating Keycloak Events to
inform downstream systems
of any user related changes one also needs to consider events that are
caused by admins, e.g. AdminEvent.

Examples are the grant / revoke of a role, group membership changes
(derived roles) or user account changes
performed by an admin user.

Currently it is not possible to differentiate those admin events when
looking at the AdminEvent object
without actually parsing / inspecting the representation. This makes it
rather complicated to correctly react
specfic ways for an AdminEvent, e.g. on a Role Membership change, detect
and resolve the new role, the user involved and propagate that to the
downstream systems.

With https://issues.jboss.org/browse/KEYCLOAK-2961 I tried a simple
workround by adding the
actual realm resource paths to the AdminEvent objekt which allows me to
deduce what actually happend.

Since the associated PR (https://github.com/keycloak/keycloak/pull/2774)
was rejected I think a better solution would be to add dedicated "Event
Subject" Information to the AdminEvents.

Marek agreed that this would be a good idea in the PR discussion.

Subjects could be an enum with "ROLE", "USER/ACCOUNT", "GROUP", however for
ROLE one would need to differentiate between REALM_ROLE / CLIENT_ROLE (for
proper lookup) and ROLE creation and ROLE_ASSIGNEMNT, same with GROUP.

Together with the AdminEvent#OperationType one could deduce what happended,
e.g.:
Event Subject: ROLE_ASSIGNMENT
Event OperationType: CREATE
-> role was granted

Event Subject: ROLE_ASSIGNMENT
Event OperationType: DELETE
-> role was revoked

It would be great if the event would carry some narrowed context
information (OperationContext?),
e.g. in case of a CLIENT_ROLE ROLE_ASSIGNMENT: clientId, roleId, userId

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160607/2936dce9/attachment.html 

From sthorger at redhat.com  Tue Jun  7 07:22:08 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 7 Jun 2016 13:22:08 +0200
Subject: [keycloak-dev] Record activity for user accounts
In-Reply-To: <CAK-7U1hnuCqACkYUHopay=qF7gdGp1AHu1KQFVGMMPj62HgOsQ@mail.gmail.com>
References: <CAK-7U1hnuCqACkYUHopay=qF7gdGp1AHu1KQFVGMMPj62HgOsQ@mail.gmail.com>
Message-ID: <CAJgngAcisO3iZJ2jOV9uoy3VuF+g+jOzBS8EDWFmHf4B_xT7hg@mail.gmail.com>

We're planning to do exactly that when we revamp the account management
console.

On 7 June 2016 at 09:57, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello Group,
>
> Some account services like google for instance record and list activities
> that
> happend in an account like: Access Type, Location, Date time.
>
> I think this would make a great addition to the account pages in Keycloak,
> since it would help users to detect suspicious account activity early.
>
> What do you think?
>
> Google shows the following information:
> * Access Type (Which device was used to access the account: Browser,
> Mobile, etc...)
> For this one could add a device detection library to the account page like
> mobile-detect.js
> http://hgoebl.github.io/mobile-detect.js/
>
> * Location (based on IP-Address)
> IP Geolocation could be based on free geolite database
> http://dev.maxmind.com/geoip/legacy/geolite/
> https://github.com/maxmind/GeoIP2-java
>
> * Date time
> Datetime of access + humanized "x mins ago"
>
> * current "access point"
> The current "access point" is also shown like:
> Your computer uses the IP XXX.XXX.XXX.XXX. (Some Country)
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160607/7eb63904/attachment.html 

From sthorger at redhat.com  Tue Jun  7 07:23:53 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 7 Jun 2016 13:23:53 +0200
Subject: [keycloak-dev] Record activity for user accounts
In-Reply-To: <CAJgngAcisO3iZJ2jOV9uoy3VuF+g+jOzBS8EDWFmHf4B_xT7hg@mail.gmail.com>
References: <CAK-7U1hnuCqACkYUHopay=qF7gdGp1AHu1KQFVGMMPj62HgOsQ@mail.gmail.com>
	<CAJgngAcisO3iZJ2jOV9uoy3VuF+g+jOzBS8EDWFmHf4B_xT7hg@mail.gmail.com>
Message-ID: <CAJgngAd738KQDG3EM_=YJ_gxWg89WnjUTFh-ReWAxky3=1OnnA@mail.gmail.com>

You can add comments to https://issues.jboss.org/browse/KEYCLOAK-1250

On 7 June 2016 at 13:22, Stian Thorgersen <sthorger at redhat.com> wrote:

> We're planning to do exactly that when we revamp the account management
> console.
>
> On 7 June 2016 at 09:57, Thomas Darimont <thomas.darimont at googlemail.com>
> wrote:
>
>> Hello Group,
>>
>> Some account services like google for instance record and list activities
>> that
>> happend in an account like: Access Type, Location, Date time.
>>
>> I think this would make a great addition to the account pages in Keycloak,
>> since it would help users to detect suspicious account activity early.
>>
>> What do you think?
>>
>> Google shows the following information:
>> * Access Type (Which device was used to access the account: Browser,
>> Mobile, etc...)
>> For this one could add a device detection library to the account page
>> like mobile-detect.js
>> http://hgoebl.github.io/mobile-detect.js/
>>
>> * Location (based on IP-Address)
>> IP Geolocation could be based on free geolite database
>> http://dev.maxmind.com/geoip/legacy/geolite/
>> https://github.com/maxmind/GeoIP2-java
>>
>> * Date time
>> Datetime of access + humanized "x mins ago"
>>
>> * current "access point"
>> The current "access point" is also shown like:
>> Your computer uses the IP XXX.XXX.XXX.XXX. (Some Country)
>>
>> Cheers,
>> Thomas
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160607/9d1a3e57/attachment.html 

From sthorger at redhat.com  Tue Jun  7 07:44:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 7 Jun 2016 13:44:29 +0200
Subject: [keycloak-dev] Move API documentation to server distro?
Message-ID: <CAJgngAcHr3yGBoGHyWgHCC0FKW5sGzw1x-p49a8E2R7Ro4-LUQ@mail.gmail.com>

Now that docs are moved to Gitbook they won't be included in the docs
distribution. That leaves only JavaDoc and Admin REST docs. Should we
consider moving these to the standalone server distro or is it best left as
a separate API docs download?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160607/936f21df/attachment.html 

From jm85martins at gmail.com  Tue Jun  7 08:26:05 2016
From: jm85martins at gmail.com (Jorge M.)
Date: Tue, 7 Jun 2016 13:26:05 +0100
Subject: [keycloak-dev] OAuth2 Offline Token Introspection
In-Reply-To: <CAJgngAdx2r-v=iL-sdbCgwDuAf8Yok8K7Wu_H0Xu7KHmZ_jP9Q@mail.gmail.com>
References: <CAHEpHR+TqZ91tTsNJb3GiB29Kuse47C6O_cAQGA4aCav3c=WQA@mail.gmail.com>
	<57566B1F.6000202@redhat.com>
	<CAJgngAcPmKeKAxTvSzkYoFR58AHoRxEtdWjfCQ9akp2n2Hg_1g@mail.gmail.com>
	<575677C3.8080000@redhat.com>
	<CAJgngAdx2r-v=iL-sdbCgwDuAf8Yok8K7Wu_H0Xu7KHmZ_jP9Q@mail.gmail.com>
Message-ID: <CAHEpHRLPmsXeyed_nJASfijaLr11__WwTc91HioDoESddmPHWA@mail.gmail.com>

That sounds good. Should I create a Jira ticket for this one?

By the way... We are planning to use offline tokens on native mobile client
apps. Basically the apps only use KC for authentication (using aerogear
oauth2). Do you think that a regular access_token is more suitable for this
scenario, rather than the offline token?

Thanks,
JM

2016-06-07 8:34 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> In that case +1 to support offline tokens.
>
> On 7 June 2016 at 09:29, Marek Posolda <mposolda at redhat.com> wrote:
>
>> The introspection specs has some support for refresh tokens and our impl
>> supports it too. You can even provide "token_type_hint" parameter and use
>> either the value "access_token" or "refresh_token" .
>>
>> The offline token is not directly supported, but I am personally not
>> seeing an issue for us to be a bit more "clever" and lookup offline
>> sessions instead of online sessions in case that type of provided token is
>> offline token?
>>
>> Marek
>>
>>
>> On 07/06/16 09:17, Stian Thorgersen wrote:
>>
>> The token introspection endpoint is for access tokens though, not refresh
>> tokens and offline tokens. You should introspect an access token retrieved
>> using the offline token, not the offline token itself.
>>
>> On 7 June 2016 at 08:35, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> it seems that oauth2 token introspection specs doesn't have any direct
>>> support for OIDC offline tokens. However you can possibly create JIRA for
>>> it. Currently it seems we consider token as valid just if there is "online"
>>> valid userSession. In case of offlineToken, it should check "offline"
>>> session instead.
>>>
>>> Marek
>>>
>>>
>>> On 06/06/16 19:12, Jorge M. wrote:
>>>
>>> Hi,
>>>
>>> I'm using the oauth2 token introspection feature in order to validate
>>> and get info about tokens, however I'm not being able to get info of
>>> offline_tokens. Is that possible? Or does it make sense?
>>>
>>> Thank you,
>>> JM
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160607/f4240f70/attachment-0001.html 

From bburke at redhat.com  Tue Jun  7 09:10:27 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 7 Jun 2016 09:10:27 -0400
Subject: [keycloak-dev] Move API documentation to server distro?
In-Reply-To: <CAJgngAcHr3yGBoGHyWgHCC0FKW5sGzw1x-p49a8E2R7Ro4-LUQ@mail.gmail.com>
References: <CAJgngAcHr3yGBoGHyWgHCC0FKW5sGzw1x-p49a8E2R7Ro4-LUQ@mail.gmail.com>
Message-ID: <fd99552e-d11e-8d71-6099-f82256dc64f2@redhat.com>

Just put them on the website and not distribute them?


On 6/7/16 7:44 AM, Stian Thorgersen wrote:
> Now that docs are moved to Gitbook they won't be included in the docs 
> distribution. That leaves only JavaDoc and Admin REST docs. Should we 
> consider moving these to the standalone server distro or is it best 
> left as a separate API docs download?
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From e.berdoncesbonelo at campus.tu-berlin.de  Tue Jun  7 09:32:50 2016
From: e.berdoncesbonelo at campus.tu-berlin.de (Erik Berdonces Bonelo)
Date: Tue, 7 Jun 2016 15:32:50 +0200
Subject: [keycloak-dev] Client Self-Registration and Administration
 Plugin
In-Reply-To: <CAJgngAcF=z7kVZO45NEpqmUkmNASNfh+4FP3TYFJUKOi57oRnw@mail.gmail.com>
References: <etPan.5755683e.2150b7c4.b0fd@campus.tu-berlin.de>
	<etPan.57556ef1.7e79dbfa.b0fd@campus.tu-berlin.de>
	<CAJgngAcF=z7kVZO45NEpqmUkmNASNfh+4FP3TYFJUKOi57oRnw@mail.gmail.com>
Message-ID: <etPan.5756cd08.5db05291.b0fd@campus.tu-berlin.de>

Hi,

Thanks for the fast answer. I totally understand the permissions issue, and well, the reason to send the previous mail was just to avoid this kind of problems.

Regarding to your suggestion on how to implement the self-registration, I understand (after reading the documentation again) how to use the Realm Resource SPI ?together with user attributes or either use the Client Registration Service.

However, as I see, there is no way to integrate it with the existing UI that Keycloak has,doesn?t it? I?ve only been able to find that there are ways to extend the ServerInfo page with some information, (example found in chapter 4.1.1 in the documentation). Is there anything similar to a FormAction as described in 34.5.1 in the documentation to integrate this extension with Keycloak?s UI, or I should create my own UI to create the interface for this custom endpoints?

I?m sorry if this questions may be a bit basic, but even with the documentation, as it is so extensive, I get sometimes a bit lost on what tools I have available to implement with in this platform.

??
Best Regards,?

Erik Berdonces Bonelo

On 6 June 2016 at 19:36:07, Stian Thorgersen (sthorger at redhat.com) wrote:

Hi,

We are planing to add more fine-grained permissions on admin endpoints in the future, but it will be a while until we get to it. I'm not very keen on accepting something like this now as we are planning to do fairly big changes around this in the future. You're also the first person to ask about having clients specific to user, other people have so far requested groups of clients that groups of users can manage.

I'd recommend using the Realm Resource SPI to create custom endpoints to accomplish this. You can use an attribute on the clients to store the user that has created the client and only allow that user to modify it in the future. You can also consider using the client registration service. The client registration service allows anyone with a create-role or an initial access token to create clients. When a client is created it returns a registration access token that gives permission to modify/delete that particular client in the future.

On 6 June 2016 at 14:39, Erik Berdonces Bonelo <e.berdoncesbonelo at campus.tu-berlin.de> wrote:
?

Hello,

I?m working at the moment in a Master Thesis project in TU Berlin where we are using Keycloak for Authentication and Authorisation purposes.
We are planning on extending Keycloak in order to provide users a way to register clients/applications by themselves into the platform, while having an admin overseeing the system.

This would mean that as a user, if I have the proper rights I should be able to create and manage my own clients. With, this it comes the idea of ownership, as this would mean that a client ownership could be transferred to someone else.
Also, the admin should be able to accept, revoke and delete the clients and requests to create clients in my Keycloak.

At the moment the only option would be giving the permission to create clients to the user, but that would allow to change ANY of the possible clients.

Then, I have two questions:
? 1. Would it make sense to integrate this to the Keycloak core?
? 2. If it doesn?t make sense to merge it in the core, is there any plugin system to extend Keycloak?s core? I?ve seen a discussion related to a plugin system in GitHub but there is no outcome yet. We would rather like to integrate it with Keycloak itself, otherwise the other option would be creating a client that uses Keycloak?s REST API to manage the clients remotely.

Thanks a lot in advance!?

???
?Best Regards,
?Erik Berdonces Bonelo


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

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

From singhrasster at gmail.com  Tue Jun  7 11:29:40 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Tue, 7 Jun 2016 10:29:40 -0500
Subject: [keycloak-dev] Optional authenticator inside an alternative subflow,
 how and when is it invoked?
Message-ID: <CAJ0vL++gxxYXdjgoht0GLX2c5WFCUHumS8uUUndMmeTR7_ns3Q@mail.gmail.com>

>From the keycloak documentation and
https://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html

it is not very clear to me what the OPTIONAL setting for an execution mean.

For example, when we have the following:

Forms Subflow - ALTERNATIVE
           Username/Password Form - REQUIRED
           OTP Password Form - OPTIONAL



When can it enter the Optional OTP form? Do we need to add some code (some
condition ?) in the UsernamePasswordAuthentication Code, so it enters the
optional OTP form authenticator? Or something else? I am not so clear about
the concept of this optional field and how to enter it. Can someone please
explain this in detail?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160607/64600dc3/attachment.html 

From mposolda at redhat.com  Tue Jun  7 12:44:55 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 7 Jun 2016 18:44:55 +0200
Subject: [keycloak-dev] OAuth2 Offline Token Introspection
In-Reply-To: <CAHEpHRLPmsXeyed_nJASfijaLr11__WwTc91HioDoESddmPHWA@mail.gmail.com>
References: <CAHEpHR+TqZ91tTsNJb3GiB29Kuse47C6O_cAQGA4aCav3c=WQA@mail.gmail.com>
	<57566B1F.6000202@redhat.com>
	<CAJgngAcPmKeKAxTvSzkYoFR58AHoRxEtdWjfCQ9akp2n2Hg_1g@mail.gmail.com>
	<575677C3.8080000@redhat.com>
	<CAJgngAdx2r-v=iL-sdbCgwDuAf8Yok8K7Wu_H0Xu7KHmZ_jP9Q@mail.gmail.com>
	<CAHEpHRLPmsXeyed_nJASfijaLr11__WwTc91HioDoESddmPHWA@mail.gmail.com>
Message-ID: <5756FA07.7050508@redhat.com>

On 07/06/16 14:26, Jorge M. wrote:
> That sounds good. Should I create a Jira ticket for this one?
Yes
>
> By the way... We are planning to use offline tokens on native mobile 
> client apps. Basically the apps only use KC for authentication (using 
> aerogear oauth2). Do you think that a regular access_token is more 
> suitable for this scenario, rather than the offline token?
Depends on the use-case. Access token is always valid just for few 
minutes and can be used to invoke 3rd party REST services. When offline 
token is just special type of refresh token. It can be used just for 
refreshing and retrieve new accessTokens, but it can't be used to invoke 
3rd party REST services. Only difference between offline token and 
refresh token is, that offline token is long-lived and valid for days or 
weeks. So once you authenticate to Keycloak and you have offlineToken, 
you can use this offlineToken after a very long time to "refresh" and 
retrieve new accessToken and then use this retrieved accessToken to 
invoke 3rd party REST endpoints.

Marek
>
> Thanks,
> JM
>
> 2016-06-07 8:34 GMT+01:00 Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>>:
>
>     In that case +1 to support offline tokens.
>
>     On 7 June 2016 at 09:29, Marek Posolda <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>> wrote:
>
>         The introspection specs has some support for refresh tokens
>         and our impl supports it too. You can even provide
>         "token_type_hint" parameter and use either the value
>         "access_token" or "refresh_token" .
>
>         The offline token is not directly supported, but I am
>         personally not seeing an issue for us to be a bit more
>         "clever" and lookup offline sessions instead of online
>         sessions in case that type of provided token is offline token?
>
>         Marek
>
>
>         On 07/06/16 09:17, Stian Thorgersen wrote:
>>         The token introspection endpoint is for access tokens though,
>>         not refresh tokens and offline tokens. You should introspect
>>         an access token retrieved using the offline token, not the
>>         offline token itself.
>>
>>         On 7 June 2016 at 08:35, Marek Posolda <mposolda at redhat.com
>>         <mailto:mposolda at redhat.com>> wrote:
>>
>>             Hi,
>>
>>             it seems that oauth2 token introspection specs doesn't
>>             have any direct support for OIDC offline tokens. However
>>             you can possibly create JIRA for it. Currently it seems
>>             we consider token as valid just if there is "online"
>>             valid userSession. In case of offlineToken, it should
>>             check "offline" session instead.
>>
>>             Marek
>>
>>
>>             On 06/06/16 19:12, Jorge M. wrote:
>>>             Hi,
>>>
>>>             I'm using the oauth2 token introspection feature in
>>>             order to validate and get info about tokens, however I'm
>>>             not being able to get info of offline_tokens. Is that
>>>             possible? Or does it make sense?
>>>
>>>             Thank you,
>>>             JM
>>>
>>>
>>>             _______________________________________________
>>>             keycloak-dev mailing list
>>>             keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>             _______________________________________________
>>             keycloak-dev mailing list
>>             keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>
>

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

From bruno at abstractj.org  Tue Jun  7 16:42:30 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 7 Jun 2016 17:42:30 -0300
Subject: [keycloak-dev] Move API documentation to server distro?
In-Reply-To: <fd99552e-d11e-8d71-6099-f82256dc64f2@redhat.com>
References: <CAJgngAcHr3yGBoGHyWgHCC0FKW5sGzw1x-p49a8E2R7Ro4-LUQ@mail.gmail.com>
	<fd99552e-d11e-8d71-6099-f82256dc64f2@redhat.com>
Message-ID: <20160607204230.GA11591@abstractj.org>

On 2016-06-07, Bill Burke wrote:
> Just put them on the website and not distribute them?

+1

>
>
> On 6/7/16 7:44 AM, Stian Thorgersen wrote:
> > Now that docs are moved to Gitbook they won't be included in the docs
> > distribution. That leaves only JavaDoc and Admin REST docs. Should we
> > consider moving these to the standalone server distro or is it best left
> > as a separate API docs download?
> >
> >
> > _______________________________________________
> > 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 sthorger at redhat.com  Wed Jun  8 00:33:40 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 8 Jun 2016 06:33:40 +0200
Subject: [keycloak-dev] OAuth2 Offline Token Introspection
In-Reply-To: <CAHEpHRLPmsXeyed_nJASfijaLr11__WwTc91HioDoESddmPHWA@mail.gmail.com>
References: <CAHEpHR+TqZ91tTsNJb3GiB29Kuse47C6O_cAQGA4aCav3c=WQA@mail.gmail.com>
	<57566B1F.6000202@redhat.com>
	<CAJgngAcPmKeKAxTvSzkYoFR58AHoRxEtdWjfCQ9akp2n2Hg_1g@mail.gmail.com>
	<575677C3.8080000@redhat.com>
	<CAJgngAdx2r-v=iL-sdbCgwDuAf8Yok8K7Wu_H0Xu7KHmZ_jP9Q@mail.gmail.com>
	<CAHEpHRLPmsXeyed_nJASfijaLr11__WwTc91HioDoESddmPHWA@mail.gmail.com>
Message-ID: <CAJgngAdrSNmtXsoDx2aaSWU2tehQm0Yz5kSPy1ACgo82PEOwdA@mail.gmail.com>

Would you be able to send a PR for the issue? Looks like it should be
relatively simple to add.

I'm curious when you say it's only used for authentication. Authentication
to what? Are you not invoking any external services?



On 7 June 2016 at 14:26, Jorge M. <jm85martins at gmail.com> wrote:

> That sounds good. Should I create a Jira ticket for this one?
>
> By the way... We are planning to use offline tokens on native mobile
> client apps. Basically the apps only use KC for authentication (using
> aerogear oauth2). Do you think that a regular access_token is more suitable
> for this scenario, rather than the offline token?
>
> Thanks,
> JM
>
> 2016-06-07 8:34 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> In that case +1 to support offline tokens.
>>
>> On 7 June 2016 at 09:29, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> The introspection specs has some support for refresh tokens and our impl
>>> supports it too. You can even provide "token_type_hint" parameter and use
>>> either the value "access_token" or "refresh_token" .
>>>
>>> The offline token is not directly supported, but I am personally not
>>> seeing an issue for us to be a bit more "clever" and lookup offline
>>> sessions instead of online sessions in case that type of provided token is
>>> offline token?
>>>
>>> Marek
>>>
>>>
>>> On 07/06/16 09:17, Stian Thorgersen wrote:
>>>
>>> The token introspection endpoint is for access tokens though, not
>>> refresh tokens and offline tokens. You should introspect an access token
>>> retrieved using the offline token, not the offline token itself.
>>>
>>> On 7 June 2016 at 08:35, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> it seems that oauth2 token introspection specs doesn't have any direct
>>>> support for OIDC offline tokens. However you can possibly create JIRA for
>>>> it. Currently it seems we consider token as valid just if there is "online"
>>>> valid userSession. In case of offlineToken, it should check "offline"
>>>> session instead.
>>>>
>>>> Marek
>>>>
>>>>
>>>> On 06/06/16 19:12, Jorge M. wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm using the oauth2 token introspection feature in order to validate
>>>> and get info about tokens, however I'm not being able to get info of
>>>> offline_tokens. Is that possible? Or does it make sense?
>>>>
>>>> Thank you,
>>>> JM
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160608/97334aac/attachment.html 

From sthorger at redhat.com  Wed Jun  8 00:35:37 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 8 Jun 2016 06:35:37 +0200
Subject: [keycloak-dev] Move API documentation to server distro?
In-Reply-To: <fd99552e-d11e-8d71-6099-f82256dc64f2@redhat.com>
References: <CAJgngAcHr3yGBoGHyWgHCC0FKW5sGzw1x-p49a8E2R7Ro4-LUQ@mail.gmail.com>
	<fd99552e-d11e-8d71-6099-f82256dc64f2@redhat.com>
Message-ID: <CAJgngAd4zR1Wy1TfaR_3Ly8qHFzckgO09V5C7VPJBb3Dt5fqhQ@mail.gmail.com>

Sounds good to me. I'll remove the docs dist then.

Any objections to removing the source dist as well? The source can be
retrieved from github (as a ZIP archive as well).

On 7 June 2016 at 15:10, Bill Burke <bburke at redhat.com> wrote:

> Just put them on the website and not distribute them?
>
> On 6/7/16 7:44 AM, Stian Thorgersen wrote:
>
> Now that docs are moved to Gitbook they won't be included in the docs
> distribution. That leaves only JavaDoc and Admin REST docs. Should we
> consider moving these to the standalone server distro or is it best left as
> a separate API docs download?
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160608/c9d18aea/attachment.html 

From a.nekrasov at ftc.ru  Wed Jun  8 00:36:19 2016
From: a.nekrasov at ftc.ru (Nekrasov Aleksandr)
Date: Wed, 8 Jun 2016 04:36:19 +0000
Subject: [keycloak-dev] Russian localization
Message-ID: <9ce77698dcf74c24b366d80333249d85@nut-mbx-4.win.ftc.ru>

Hi all,

I have translated all base theme message resources to russian language and want to create PR.
I believe, it will be good, if keycloak will be supports russian locale. How do you think?

Nekrasov Aleksander,
Developer,
Center of Financial Techologies

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

From sthorger at redhat.com  Wed Jun  8 00:40:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 8 Jun 2016 06:40:43 +0200
Subject: [keycloak-dev] Client Self-Registration and Administration
	Plugin
In-Reply-To: <etPan.5756cd08.5db05291.b0fd@campus.tu-berlin.de>
References: <etPan.5755683e.2150b7c4.b0fd@campus.tu-berlin.de>
	<etPan.57556ef1.7e79dbfa.b0fd@campus.tu-berlin.de>
	<CAJgngAcF=z7kVZO45NEpqmUkmNASNfh+4FP3TYFJUKOi57oRnw@mail.gmail.com>
	<etPan.5756cd08.5db05291.b0fd@campus.tu-berlin.de>
Message-ID: <CAJgngAcoXQR+V4AJtzxenfmQ_CNQeZ9M_BKsp-4OuwVoAk0t9g@mail.gmail.com>

On 7 June 2016 at 15:32, Erik Berdonces Bonelo <
e.berdoncesbonelo at campus.tu-berlin.de> wrote:

> Hi,
>
> Thanks for the fast answer. I totally understand the permissions issue,
> and well, the reason to send the previous mail was just to avoid this kind
> of problems.
>
> Regarding to your suggestion on how to implement the self-registration, I
> understand (after reading the documentation again) how to use the Realm
> Resource SPI  together with user attributes or either use the Client
> Registration Service.
>
> However, as I see, there is no way to integrate it with the existing UI
> that Keycloak has,doesn?t it? I?ve only been able to find that there are
> ways to extend the ServerInfo page with some information, (example found in
> chapter 4.1.1 in the documentation). Is there anything similar to a
> FormAction as described in 34.5.1 in the documentation to integrate this
> extension with Keycloak?s UI, or I should create my own UI to create the
> interface for this custom endpoints?
>

You can extend the admin console by adding a custom admin theme. It's not
to elegant and requires some effort when upgrading to new versions, but
it's possible. It may be simpler to create your own UI. If you create the
UI as a HTML5 you can add the html files, javascript, etc. to a custom
admin theme and all you'd have to do is to have a realm resource provide
the landing page and then point to resource like our admin console does
(which is then loaded from the theme).


>
> I?m sorry if this questions may be a bit basic, but even with the
> documentation, as it is so extensive, I get sometimes a bit lost on what
> tools I have available to implement with in this platform.
>

A lot of the SPIs and customization parts are not polished or documented
well so not to worry ;)


>
> ?
> Best Regards,
>
> Erik Berdonces Bonelo
>
> On 6 June 2016 at 19:36:07, Stian Thorgersen (sthorger at redhat.com) wrote:
>
> Hi,
>
> We are planing to add more fine-grained permissions on admin endpoints in
> the future, but it will be a while until we get to it. I'm not very keen on
> accepting something like this now as we are planning to do fairly big
> changes around this in the future. You're also the first person to ask
> about having clients specific to user, other people have so far requested
> groups of clients that groups of users can manage.
>
> I'd recommend using the Realm Resource SPI to create custom endpoints to
> accomplish this. You can use an attribute on the clients to store the user
> that has created the client and only allow that user to modify it in the
> future. You can also consider using the client registration service. The
> client registration service allows anyone with a create-role or an initial
> access token to create clients. When a client is created it returns a
> registration access token that gives permission to modify/delete that
> particular client in the future.
>
> On 6 June 2016 at 14:39, Erik Berdonces Bonelo <
> e.berdoncesbonelo at campus.tu-berlin.de> wrote:
>
>>
>>
>> Hello,
>>
>> I?m working at the moment in a Master Thesis project in TU Berlin where
>> we are using Keycloak for Authentication and Authorisation purposes.
>> We are planning on extending Keycloak in order to provide users a way to
>> register clients/applications by themselves into the platform, while having
>> an admin overseeing the system.
>>
>> This would mean that as a user, if I have the proper rights I should be
>> able to create and manage my own clients. With, this it comes the idea of
>> ownership, as this would mean that a client ownership could be transferred
>> to someone else.
>> Also, the admin should be able to accept, revoke and delete the clients
>> and requests to create clients in my Keycloak.
>>
>> At the moment the only option would be giving the permission to create
>> clients to the user, but that would allow to change ANY of the possible
>> clients.
>>
>> Then, I have two questions:
>>   1. Would it make sense to integrate this to the Keycloak core?
>>   2. If it doesn?t make sense to merge it in the core, is there any
>> plugin system to extend Keycloak?s core? I?ve seen a discussion related to
>> a plugin system in GitHub but there is no outcome yet. We would rather like
>> to integrate it with Keycloak itself, otherwise the other option would be
>> creating a client that uses Keycloak?s REST API to manage the clients
>> remotely.
>>
>> Thanks a lot in advance!
>>
>>  ?
>>  Best Regards,
>>  Erik Berdonces Bonelo
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160608/866f27e9/attachment-0001.html 

From sthorger at redhat.com  Wed Jun  8 00:52:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 8 Jun 2016 06:52:50 +0200
Subject: [keycloak-dev] Russian localization
In-Reply-To: <9ce77698dcf74c24b366d80333249d85@nut-mbx-4.win.ftc.ru>
References: <9ce77698dcf74c24b366d80333249d85@nut-mbx-4.win.ftc.ru>
Message-ID: <CAJgngAcT5AR8yuZY7Dh84Fa81GM1O=Or_h00UdV9Rh6_LD-R=w@mail.gmail.com>

We would welcome a contribution for Russian. However, we are not able to
maintain this translation ourselves. Would you be able to maintain it and
update it when it's needed?

On 8 June 2016 at 06:36, Nekrasov Aleksandr <a.nekrasov at ftc.ru> wrote:

> Hi all,
>
>
>
> I have translated all base theme message resources to russian language and
> want to create PR.
>
> I believe, it will be good, if keycloak will be supports russian locale.
> How do you think?
>
>
>
> Nekrasov Aleksander,
>
> Developer,
>
> Center of Financial Techologies
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160608/9f62dde9/attachment.html 

From sthorger at redhat.com  Wed Jun  8 00:58:18 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 8 Jun 2016 06:58:18 +0200
Subject: [keycloak-dev] Moving translations to a separate repository
Message-ID: <CAJgngAegHCWo1cGewa_6v+zmpwDMKPbf3ZGovwO6TiPw-K0zhg@mail.gmail.com>

I'm thinking of moving translations to a separate repository.

The plan is to not have them included in the standard distribution and not
part of the release. Often a release comes with changes to the English
message bundles and we can't afford to wait for all translations to be
updated before a release.

The repository would have a page listing the languages and each language
would have a maintainer listed (by Github username). Ideally we'd also have
the page automatically updated with % keys translated and somehow figure
out if it needs to be updated (in the event the English translation has
changed).

Adding translations to the base theme should be made as simple as possible.
This will need some work to make as it's not simple at the moment to add
additional translations as it requires a custom theme.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160608/bdbe2359/attachment.html 

From a.nekrasov at ftc.ru  Wed Jun  8 01:42:14 2016
From: a.nekrasov at ftc.ru (Nekrasov Aleksandr)
Date: Wed, 8 Jun 2016 05:42:14 +0000
Subject: [keycloak-dev] Russian localization
In-Reply-To: <CAJgngAcT5AR8yuZY7Dh84Fa81GM1O=Or_h00UdV9Rh6_LD-R=w@mail.gmail.com>
References: <9ce77698dcf74c24b366d80333249d85@nut-mbx-4.win.ftc.ru>
	<CAJgngAcT5AR8yuZY7Dh84Fa81GM1O=Or_h00UdV9Rh6_LD-R=w@mail.gmail.com>
Message-ID: <814aec0ea038434e983b95c26ccfe311@nut-mbx-4.win.ftc.ru>

Yes, I will trying to update it, when it necessary.

From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Wednesday, June 08, 2016 10:53 AM
To: ???????? ????????? ?????????
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Russian localization

We would welcome a contribution for Russian. However, we are not able to maintain this translation ourselves. Would you be able to maintain it and update it when it's needed?

On 8 June 2016 at 06:36, Nekrasov Aleksandr <a.nekrasov at ftc.ru<mailto:a.nekrasov at ftc.ru>> wrote:
Hi all,

I have translated all base theme message resources to russian language and want to create PR.
I believe, it will be good, if keycloak will be supports russian locale. How do you think?

Nekrasov Aleksander,
Developer,
Center of Financial Techologies


_______________________________________________
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

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

From christian.froehlich at agfa.com  Wed Jun  8 05:07:56 2016
From: christian.froehlich at agfa.com (Christian Froehlich)
Date: Wed, 8 Jun 2016 11:07:56 +0200
Subject: [keycloak-dev] [KEYCLOAK-1733] Adapters: support for authentication
 with bearer token sent in query param
Message-ID: <OF8B907D0A.3B8AB826-ONC1257FCC.00301FDA-C1257FCC.00322A6A@agfa.com>

Hi,

I'm interested in the feature and I would like to contribute to do a pull 
request to the keycloak project. My first Idea is to implement a new 
"RequestAuthenticator" just like the BasicAuthRequestAuthenticator and to 
handle the request inside the method RequestAuthenticator.authenticate(). 
Does it run in the right direction? If yes, I would like to create a pull 
request for further discussions.... If not any other comment or tip is 
welcome!

Regards Christian

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

From mposolda at redhat.com  Wed Jun  8 05:56:33 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 8 Jun 2016 11:56:33 +0200
Subject: [keycloak-dev] Moving translations to a separate repository
In-Reply-To: <CAJgngAegHCWo1cGewa_6v+zmpwDMKPbf3ZGovwO6TiPw-K0zhg@mail.gmail.com>
References: <CAJgngAegHCWo1cGewa_6v+zmpwDMKPbf3ZGovwO6TiPw-K0zhg@mail.gmail.com>
Message-ID: <5757EBD1.7020200@redhat.com>

On 08/06/16 06:58, Stian Thorgersen wrote:
> I'm thinking of moving translations to a separate repository.
>
> The plan is to not have them included in the standard distribution and 
> not part of the release. Often a release comes with changes to the 
> English message bundles and we can't afford to wait for all 
> translations to be updated before a release.
>
> The repository would have a page listing the languages and each 
> language would have a maintainer listed (by Github username). Ideally 
> we'd also have the page automatically updated with % keys translated 
> and somehow figure out if it needs to be updated (in the event the 
> English translation has changed).
>
> Adding translations to the base theme should be made as simple as 
> possible. This will need some work to make as it's not simple at the 
> moment to add additional translations as it requires a custom theme.
+1

Maybe the theme can just read the available property files and 
automatically set the available locales based on that? So only needed 
action will be to copy property file to the folder inside theme and it 
will work automatically without need to change anything in 
theme.properties or creating new theme.

One thing is, that combobox with available locales should be also 
automatically updated. So when you add new locale, you don't need to 
update all other property files to see new language in combobx.  I think 
that each locale can provide the known key with it's own name for it's 
own language and that will be added to the combobox. The property will 
be in the language itself, which I can't see as big issue, but rather 
more proper behaviour?

So for example, when you have english locale active, then in combobox 
you won't see:
- English
- French
- Czech

but you will see:
- English
- Fran?ais
- ?esky

Marek

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

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

From mposolda at redhat.com  Wed Jun  8 06:21:41 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 8 Jun 2016 12:21:41 +0200
Subject: [keycloak-dev] Optional authenticator inside an alternative
 subflow, how and when is it invoked?
In-Reply-To: <CAJ0vL++gxxYXdjgoht0GLX2c5WFCUHumS8uUUndMmeTR7_ns3Q@mail.gmail.com>
References: <CAJ0vL++gxxYXdjgoht0GLX2c5WFCUHumS8uUUndMmeTR7_ns3Q@mail.gmail.com>
Message-ID: <5757F1B5.9060306@redhat.com>

Currently the OPTIONAL means that authenticator is used just if it's 
configured for particular user ( Authenticator.configuredFor returns 
true for that user). In case of OTP, it means that OTP form is shown 
just if OTP is configured for particular user.

It looks that OPTIONAL authenticator needs to return "requiresUser" with 
true, otherwise if it doesn't require user the error will be returned 
(even if authenticator is OPTIONAL).

Marek

On 07/06/16 17:29, Rashmi Singh wrote:
> From the keycloak documentation and 
> https://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html 
>
>
> it is not very clear to me what the OPTIONAL setting for an execution 
> mean.
>
> For example, when we have the following:
>
> Forms Subflow - ALTERNATIVE
>             Username/Password Form - REQUIRED
>             OTP Password Form - OPTIONAL
>
>
> When can it enter the Optional OTP form? Do we need to add some code 
> (some condition ?) in the UsernamePasswordAuthentication Code, so it 
> enters the optional OTP form authenticator? Or something else? I am 
> not so clear about the concept of this optional field and how to enter 
> it. Can someone please explain this in detail?
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From ssilvert at redhat.com  Wed Jun  8 08:19:03 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 08 Jun 2016 08:19:03 -0400
Subject: [keycloak-dev] Moving translations to a separate repository
In-Reply-To: <CAJgngAegHCWo1cGewa_6v+zmpwDMKPbf3ZGovwO6TiPw-K0zhg@mail.gmail.com>
References: <CAJgngAegHCWo1cGewa_6v+zmpwDMKPbf3ZGovwO6TiPw-K0zhg@mail.gmail.com>
Message-ID: <57580D37.4070605@redhat.com>

On 6/8/2016 12:58 AM, Stian Thorgersen wrote:
> I'm thinking of moving translations to a separate repository.
+1
>
> The plan is to not have them included in the standard distribution and 
> not part of the release. Often a release comes with changes to the 
> English message bundles and we can't afford to wait for all 
> translations to be updated before a release.
>
> The repository would have a page listing the languages and each 
> language would have a maintainer listed (by Github username). Ideally 
> we'd also have the page automatically updated with % keys translated 
> and somehow figure out if it needs to be updated (in the event the 
> English translation has changed).
>
> Adding translations to the base theme should be made as simple as 
> possible. This will need some work to make as it's not simple at the 
> moment to add additional translations as it requires a custom theme.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From ivan at akvo.org  Wed Jun  8 10:14:26 2016
From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=)
Date: Wed, 8 Jun 2016 16:14:26 +0200
Subject: [keycloak-dev] Moving translations to a separate repository
In-Reply-To: <CAJgngAegHCWo1cGewa_6v+zmpwDMKPbf3ZGovwO6TiPw-K0zhg@mail.gmail.com>
References: <CAJgngAegHCWo1cGewa_6v+zmpwDMKPbf3ZGovwO6TiPw-K0zhg@mail.gmail.com>
Message-ID: <57f7fbbb-9e7a-7283-da71-d1d88348add9@akvo.org>

Hi,

On 06/08/2016 06:58 AM, Stian Thorgersen wrote:
> The repository would have a page listing the languages and each language
> would have a maintainer listed (by Github username). Ideally we'd also
> have the page automatically updated with % keys translated and somehow
> figure out if it needs to be updated (in the event the English
> translation has changed).

We're using Transifex for handling translations, e.g. [1] They support
open source projects [2]. It's an "easy" way to know which translations
are lagging and which one are up-to-date.

It seems they have integrations with GitHub, but we're not using it. We
just point some particular properties|xml file and set it up as resource
that needs automatic update.

Not sure if the Keycloak project want to use another tool, but I wanted
to share our positive experience.

[1] https://www.transifex.com/akvo-foundation/public/
[2] http://docs.transifex.com/faq/#what-is-considered-an-open-source-project

My five cents,

-- 
Iv?n

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160608/57d6ee5b/attachment.bin 

From psilva at redhat.com  Wed Jun  8 11:23:37 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 8 Jun 2016 11:23:37 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <2038202996.16766367.1465399375155.JavaMail.zimbra@redhat.com>
Message-ID: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>

Hi All,

Asked Bill for some feedback about AuthZ docs [1] and would like to share with you.

@Bill, my initial comments inline.

[1] https://keycloak.gitbooks.io/authorization-services-guide/content/

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Sent: Wednesday, June 8, 2016 11:15:03 AM
> Subject: Re: Feedback
> 
> * Example is too complex.  Needs to be broken down and explained for
> each policy that was created.

OK. By "broken down" you mean using sub-topics (pages) or just sections on the same page ?

The "Hello World" one should be fine because it is just a single policy example. The "Securing a Servlet Application" may have more details about each of those policies, will work on that. Or even just point to their respective documentation, as we also have doc for each policy type.

> 
> * Example should not use JSON import.  It should walk through screen
> shots to explain how to set up things.

The idea behind using JSON import is that it provides an easy and fast way to users get started. After all, you just need to copy&paste configuration (or obtain from examples dir) and import to KC. IMO, that makes the tutorial more easy to follow with focus on the main concepts being explained.

I'm trying to keep documentation about UI on each topic, so you can see how to use admin console to create/configure things.

> 
> * Need more screenshots throughout doc

Probably related with your previous feedback. I'm going to take some more screenshots ....

> 
> * Is Resource Server->Client always a one-to-one thing?  

No, RS<->Client is not always a 1:1 mapping. Usually, they would be different entities, where the client is acting on behalf of the RO to access protected resources on a resource server. That is true for most API security use cases. 

However, an app may use both hats. For instance, monolithic JEE apps.

>Maybe Authorization should move under clients tab?

That is a good question. And my quick answer for that would be to keep it separated for now.

I think changes like that may involve more discussions around UI design. For instance, today clients and resource servers are managed in the same space (Clients in left menu bar). As you know, clients (entities accessing a RS on behalf of an user) and RSs are different things and although they share a lot of things, I think we could have have them *visually* separated somehow.

AuthZ includes more tabs and flows, so I don't think move under clients tab would be a good idea. I'm not a UX expert, there is probably a way to do what you want nicely ...

> 
> * Looks like there is a bit of redundant config for adapters. How big is
> authz at the adapter side?  

>From an adapter perspective, AuthZ code is pretty much straightforward and small. The redundant config you are talking about is probably the "client" property in keycloak-authz.json. So yes, it is.

Today, authz code is basically provided by a Servlet Filter. See Policy Enforcers.

> Maybe this code should be merged with our
> adapters so config for user becomes simpler? 

Well, I was trying to avoid change adapters. At least for now.

We can get those changes merged with our OIDC adapters, for sure. So I could move that *enforcer* property to a keycloak.json file.

The question is if we should just leave that way for now and release this stuff. It is your call, if you want them merged I'll do it.

> Something to think about
> and look into.  Really probably depends how many dependencies authz
> brings in.

There is no additional deps ...

> 
> * Need to unify scripting and SPI objects.  Authz should share SPI
> objects (i.e. client IP address) with AuthenticationFlow SPI and other
> things.  Looks like you might have duplicate things.

Saw that you merged some scripting stuff to authentication flow recently. But I'm not sure about have both authc and authz sharing the same SPI right now.

I don't think I'm replicating things. We are basically exposing a Evaluation API (that should be as simple as possible) that users can use to build rule-based policyes (eg.: JS, Drools, etc). Here are basically ABAC and policies can obtain
information using both identities and environment/runtime attributes.

For instance, whatever you put in a access token (eg.: using a protocol mapper) would be available as an attribute. Thus, available to policies.

> 
> 
> On 6/7/16 4:40 PM, Pedro Igor Silva wrote:
> > Hey Bill !
> >
> > When you get some time, could you please take a quick look at
> > https://keycloak.gitbooks.io/authorization-services-guide/content/index.html.
> >
> > There you will find the documentation for AuthZ Services and what I've
> > documented so far.
> >
> > Your feedback is really appreciated :)
> >
> > Thanks.
> > Pedro Igor
> 
> 

From singhrasster at gmail.com  Wed Jun  8 11:43:42 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Wed, 8 Jun 2016 10:43:42 -0500
Subject: [keycloak-dev] Optional authenticator inside an alternative
 subflow, how and when is it invoked?
In-Reply-To: <5757F1B5.9060306@redhat.com>
References: <CAJ0vL++gxxYXdjgoht0GLX2c5WFCUHumS8uUUndMmeTR7_ns3Q@mail.gmail.com>
	<5757F1B5.9060306@redhat.com>
Message-ID: <CAJ0vL++OP4OF992J6FGpGNpA2BYwuavcw86EcVCf0CFL6xDZeQ@mail.gmail.com>

In general, if we have any two authenticators under ALTERNATIVE flow, the
second being OPTIONAL, is the optional one invoked only when
context.setUser(user) is set in the first authenticator? otherwise, the
second OPTIONAL authenticator is never invoked (irrespective of
whether Authenticator.configuredFor
returns true or false) at all? Is there a way to invoke the optional
authenticator even when context.setUser(user) was never done in the first
authenticator?

On Wed, Jun 8, 2016 at 5:21 AM, Marek Posolda <mposolda at redhat.com> wrote:

> Currently the OPTIONAL means that authenticator is used just if it's
> configured for particular user ( Authenticator.configuredFor returns true
> for that user). In case of OTP, it means that OTP form is shown just if OTP
> is configured for particular user.
>
> It looks that OPTIONAL authenticator needs to return "requiresUser" with
> true, otherwise if it doesn't require user the error will be returned (even
> if authenticator is OPTIONAL).
>
> Marek
>
>
> On 07/06/16 17:29, Rashmi Singh wrote:
>
> From the keycloak documentation and
> <https://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html>
> https://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html
>
> it is not very clear to me what the OPTIONAL setting for an execution mean.
>
> For example, when we have the following:
>
> Forms Subflow - ALTERNATIVE
>            Username/Password Form - REQUIRED
>            OTP Password Form - OPTIONAL
>
>
>
> When can it enter the Optional OTP form? Do we need to add some code (some
> condition ?) in the UsernamePasswordAuthentication Code, so it enters the
> optional OTP form authenticator? Or something else? I am not so clear about
> the concept of this optional field and how to enter it. Can someone please
> explain this in detail?
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160608/114b53f6/attachment-0001.html 

From bburke at redhat.com  Wed Jun  8 14:25:53 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 8 Jun 2016 14:25:53 -0400
Subject: [keycloak-dev] Feedback
In-Reply-To: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
Message-ID: <8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>



On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
> Hi All,
>
> Asked Bill for some feedback about AuthZ docs [1] and would like to share with you.
>
> @Bill, my initial comments inline.
>
> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Sent: Wednesday, June 8, 2016 11:15:03 AM
>> Subject: Re: Feedback
>>
>> * Example is too complex.  Needs to be broken down and explained for
>> each policy that was created.
> OK. By "broken down" you mean using sub-topics (pages) or just sections on the same page ?
>
> The "Hello World" one should be fine because it is just a single policy example. The "Securing a Servlet Application" may have more details about each of those policies, will work on that. Or even just point to their respective documentation, as we also have doc for each policy type.
>
>> * Example should not use JSON import.  It should walk through screen
>> shots to explain how to set up things.
> The idea behind using JSON import is that it provides an easy and fast way to users get started. After all, you just need to copy&paste configuration (or obtain from examples dir) and import to KC. IMO, that makes the tutorial more easy to follow with focus on the main concepts being explained.
JSON is great for running an example, but not great for documentation.

> I'm trying to keep documentation about UI on each topic, so you can see how to use admin console to create/configure things.
>
>> * Need more screenshots throughout doc
> Probably related with your previous feedback. I'm going to take some more screenshots ....
>
>> * Is Resource Server->Client always a one-to-one thing?
> No, RS<->Client is not always a 1:1 mapping. Usually, they would be different entities, where the client is acting on behalf of the RO to access protected resources on a resource server. That is true for most API security use cases.
>
> However, an app may use both hats. For instance, monolithic JEE apps.
>
>> Maybe Authorization should move under clients tab?
> That is a good question. And my quick answer for that would be to keep it separated for now.
>
> I think changes like that may involve more discussions around UI design. For instance, today clients and resource servers are managed in the same space (Clients in left menu bar). As you know, clients (entities accessing a RS on behalf of an user) and RSs are different things and although they share a lot of things, I think we could have have them *visually* separated somehow.
>
> AuthZ includes more tabs and flows, so I don't think move under clients tab would be a good idea. I'm not a UX expert, there is probably a way to do what you want nicely ...
Maybe Resource Server is a misleading name?  Maybe it should be named a 
Resource Manager or Resource Catalogue?  What about having a Resources 
tab under Client that lists the "Resource Servers" attached to the 
client and the ability to add/remove Resource Servers for that client?  
Its just a different way to navigate.

>> * Looks like there is a bit of redundant config for adapters. How big is
>> authz at the adapter side?
>  From an adapter perspective, AuthZ code is pretty much straightforward and small. The redundant config you are talking about is probably the "client" property in keycloak-authz.json. So yes, it is.
>
> Today, authz code is basically provided by a Servlet Filter. See Policy Enforcers.

OIDC adapter provides:

* client id
* realm name
* realm public key
* auth server URL

I'm pretty sure the adapter config could be made available to the authz 
adapter.  It would allow you to reduce the number of steps to configure 
this stuff.

>> Maybe this code should be merged with our
>> adapters so config for user becomes simpler?
> Well, I was trying to avoid change adapters. At least for now.
>
> We can get those changes merged with our OIDC adapters, for sure. So I could move that *enforcer* property to a keycloak.json file.
>
> The question is if we should just leave that way for now and release this stuff. It is your call, if you want them merged I'll do it.

Across the board, for all of Keycloak, we need to put some thought into 
how to make things easier to configure with intuitive defaults, etc.  
For example, there has been some talk of having ZERO config at the 
adapter side except the realm URL and a client token.  Apps would then 
pull down all of their configuration from Keycloak.

>> Something to think about
>> and look into.  Really probably depends how many dependencies authz
>> brings in.
> There is no additional deps ...
>
>> * Need to unify scripting and SPI objects.  Authz should share SPI
>> objects (i.e. client IP address) with AuthenticationFlow SPI and other
>> things.  Looks like you might have duplicate things.
> Saw that you merged some scripting stuff to authentication flow recently. But I'm not sure about have both authc and authz sharing the same SPI right now.
>
> I don't think I'm replicating things.
You are at least replicating access to Client IP address.  We need to 
make sure that the variable names and variable references are consistent 
between Authentication Flow scripting and Authz Scripting.  We can't 
have a completely different dictionary.


From singhrasster at gmail.com  Wed Jun  8 15:04:24 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Wed, 8 Jun 2016 14:04:24 -0500
Subject: [keycloak-dev] Optional authenticator inside an alternative
 subflow, how and when is it invoked?
In-Reply-To: <CAJ0vL++OP4OF992J6FGpGNpA2BYwuavcw86EcVCf0CFL6xDZeQ@mail.gmail.com>
References: <CAJ0vL++gxxYXdjgoht0GLX2c5WFCUHumS8uUUndMmeTR7_ns3Q@mail.gmail.com>
	<5757F1B5.9060306@redhat.com>
	<CAJ0vL++OP4OF992J6FGpGNpA2BYwuavcw86EcVCf0CFL6xDZeQ@mail.gmail.com>
Message-ID: <CAJ0vL++YTwqgxCMT-NquWO8VVif+R2a_FOFGGMU5zO9o6z9tvw@mail.gmail.com>

OK, I am clear about this point now. It does enter the second optional
authenticator, so it is good now. Thank you

On Wed, Jun 8, 2016 at 10:43 AM, Rashmi Singh <singhrasster at gmail.com>
wrote:

> In general, if we have any two authenticators under ALTERNATIVE flow, the
> second being OPTIONAL, is the optional one invoked only when
> context.setUser(user) is set in the first authenticator? otherwise, the
> second OPTIONAL authenticator is never invoked (irrespective of whether Authenticator.configuredFor
> returns true or false) at all? Is there a way to invoke the optional
> authenticator even when context.setUser(user) was never done in the first
> authenticator?
>
> On Wed, Jun 8, 2016 at 5:21 AM, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Currently the OPTIONAL means that authenticator is used just if it's
>> configured for particular user ( Authenticator.configuredFor returns true
>> for that user). In case of OTP, it means that OTP form is shown just if OTP
>> is configured for particular user.
>>
>> It looks that OPTIONAL authenticator needs to return "requiresUser" with
>> true, otherwise if it doesn't require user the error will be returned (even
>> if authenticator is OPTIONAL).
>>
>> Marek
>>
>>
>> On 07/06/16 17:29, Rashmi Singh wrote:
>>
>> From the keycloak documentation and
>> <https://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html>
>> https://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html
>>
>> it is not very clear to me what the OPTIONAL setting for an execution
>> mean.
>>
>> For example, when we have the following:
>>
>> Forms Subflow - ALTERNATIVE
>>            Username/Password Form - REQUIRED
>>            OTP Password Form - OPTIONAL
>>
>>
>>
>> When can it enter the Optional OTP form? Do we need to add some code
>> (some condition ?) in the UsernamePasswordAuthentication Code, so it enters
>> the optional OTP form authenticator? Or something else? I am not so clear
>> about the concept of this optional field and how to enter it. Can someone
>> please explain this in detail?
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160608/87a87f0a/attachment.html 

From psilva at redhat.com  Wed Jun  8 15:12:10 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 8 Jun 2016 15:12:10 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
Message-ID: <1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, June 8, 2016 3:25:53 PM
> Subject: Re: Feedback
> 
> 
> 
> On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
> > Hi All,
> >
> > Asked Bill for some feedback about AuthZ docs [1] and would like to share
> > with you.
> >
> > @Bill, my initial comments inline.
> >
> > [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Sent: Wednesday, June 8, 2016 11:15:03 AM
> >> Subject: Re: Feedback
> >>
> >> * Example is too complex.  Needs to be broken down and explained for
> >> each policy that was created.
> > OK. By "broken down" you mean using sub-topics (pages) or just sections on
> > the same page ?
> >
> > The "Hello World" one should be fine because it is just a single policy
> > example. The "Securing a Servlet Application" may have more details about
> > each of those policies, will work on that. Or even just point to their
> > respective documentation, as we also have doc for each policy type.
> >
> >> * Example should not use JSON import.  It should walk through screen
> >> shots to explain how to set up things.
> > The idea behind using JSON import is that it provides an easy and fast way
> > to users get started. After all, you just need to copy&paste configuration
> > (or obtain from examples dir) and import to KC. IMO, that makes the
> > tutorial more easy to follow with focus on the main concepts being
> > explained.
> JSON is great for running an example, but not great for documentation.

OK. Changing ...

> 
> > I'm trying to keep documentation about UI on each topic, so you can see how
> > to use admin console to create/configure things.
> >
> >> * Need more screenshots throughout doc
> > Probably related with your previous feedback. I'm going to take some more
> > screenshots ....
> >
> >> * Is Resource Server->Client always a one-to-one thing?
> > No, RS<->Client is not always a 1:1 mapping. Usually, they would be
> > different entities, where the client is acting on behalf of the RO to
> > access protected resources on a resource server. That is true for most API
> > security use cases.
> >
> > However, an app may use both hats. For instance, monolithic JEE apps.
> >
> >> Maybe Authorization should move under clients tab?
> > That is a good question. And my quick answer for that would be to keep it
> > separated for now.
> >
> > I think changes like that may involve more discussions around UI design.
> > For instance, today clients and resource servers are managed in the same
> > space (Clients in left menu bar). As you know, clients (entities accessing
> > a RS on behalf of an user) and RSs are different things and although they
> > share a lot of things, I think we could have have them *visually*
> > separated somehow.
> >
> > AuthZ includes more tabs and flows, so I don't think move under clients tab
> > would be a good idea. I'm not a UX expert, there is probably a way to do
> > what you want nicely ...
> Maybe Resource Server is a misleading name?  Maybe it should be named a
> Resource Manager or Resource Catalogue?  What about having a Resources
> tab under Client that lists the "Resource Servers" attached to the
> client and the ability to add/remove Resource Servers for that client?
> Its just a different way to navigate.

Don't think Resource Server is a misleading name. It is a pretty well concept on OAuth2 world.

Maybe I can give a shot to your suggestion and move all AuthZ UIs to a "Resource Server" tab. Or even have all those AuthZ UI tabs as separated tabs. Will send you screenshots with the result.

[NOTE]
I think I misunderstood your original question about the 1:1 mapping between RS and Clients. My answer was based on a conceptual view of those entities, where RS and Client may represent or not the same entity.
>From a implementation view, RS and Client have 1:1 mapping.

> 
> >> * Looks like there is a bit of redundant config for adapters. How big is
> >> authz at the adapter side?
> >  From an adapter perspective, AuthZ code is pretty much straightforward and
> >  small. The redundant config you are talking about is probably the
> >  "client" property in keycloak-authz.json. So yes, it is.
> >
> > Today, authz code is basically provided by a Servlet Filter. See Policy
> > Enforcers.
> 
> OIDC adapter provides:
> 
> * client id
> * realm name
> * realm public key
> * auth server URL
> 
> I'm pretty sure the adapter config could be made available to the authz
> adapter.  It would allow you to reduce the number of steps to configure
> this stuff.

OK

> 
> >> Maybe this code should be merged with our
> >> adapters so config for user becomes simpler?
> > Well, I was trying to avoid change adapters. At least for now.
> >
> > We can get those changes merged with our OIDC adapters, for sure. So I
> > could move that *enforcer* property to a keycloak.json file.
> >
> > The question is if we should just leave that way for now and release this
> > stuff. It is your call, if you want them merged I'll do it.
> 
> Across the board, for all of Keycloak, we need to put some thought into
> how to make things easier to configure with intuitive defaults, etc.
> For example, there has been some talk of having ZERO config at the
> adapter side except the realm URL and a client token.  Apps would then
> pull down all of their configuration from Keycloak.

See, config is already minimal. Beside the keycloak-authz.json we discussed, you just need to change web.xml and jboss-deployment-structure.xml. The first is a necessary evil, but I can remove the latter.

> 
> >> Something to think about
> >> and look into.  Really probably depends how many dependencies authz
> >> brings in.
> > There is no additional deps ...
> >
> >> * Need to unify scripting and SPI objects.  Authz should share SPI
> >> objects (i.e. client IP address) with AuthenticationFlow SPI and other
> >> things.  Looks like you might have duplicate things.
> > Saw that you merged some scripting stuff to authentication flow recently.
> > But I'm not sure about have both authc and authz sharing the same SPI
> > right now.
> >
> > I don't think I'm replicating things.
> You are at least replicating access to Client IP address.  We need to
> make sure that the variable names and variable references are consistent
> between Authentication Flow scripting and Authz Scripting.  We can't
> have a completely different dictionary.

I agree. Do you mind if we postpone that to a second release ? So I can take a better look on that new scripting SPI and see how we can use it here ?

> 
> 

From bburke at redhat.com  Wed Jun  8 15:29:42 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 8 Jun 2016 15:29:42 -0400
Subject: [keycloak-dev] Feedback
In-Reply-To: <1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
	<1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
Message-ID: <4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>



On 6/8/16 3:12 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Wednesday, June 8, 2016 3:25:53 PM
>> Subject: Re: Feedback
>>
>>
>>
>> On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
>>> Hi All,
>>>
>>> Asked Bill for some feedback about AuthZ docs [1] and would like to share
>>> with you.
>>>
>>> @Bill, my initial comments inline.
>>>
>>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Sent: Wednesday, June 8, 2016 11:15:03 AM
>>>> Subject: Re: Feedback
>>>>
>>>> * Example is too complex.  Needs to be broken down and explained for
>>>> each policy that was created.
>>> OK. By "broken down" you mean using sub-topics (pages) or just sections on
>>> the same page ?
>>>
>>> The "Hello World" one should be fine because it is just a single policy
>>> example. The "Securing a Servlet Application" may have more details about
>>> each of those policies, will work on that. Or even just point to their
>>> respective documentation, as we also have doc for each policy type.
>>>
>>>> * Example should not use JSON import.  It should walk through screen
>>>> shots to explain how to set up things.
>>> The idea behind using JSON import is that it provides an easy and fast way
>>> to users get started. After all, you just need to copy&paste configuration
>>> (or obtain from examples dir) and import to KC. IMO, that makes the
>>> tutorial more easy to follow with focus on the main concepts being
>>> explained.
>> JSON is great for running an example, but not great for documentation.
> OK. Changing ...
>
>>> I'm trying to keep documentation about UI on each topic, so you can see how
>>> to use admin console to create/configure things.
>>>
>>>> * Need more screenshots throughout doc
>>> Probably related with your previous feedback. I'm going to take some more
>>> screenshots ....
>>>
>>>> * Is Resource Server->Client always a one-to-one thing?
>>> No, RS<->Client is not always a 1:1 mapping. Usually, they would be
>>> different entities, where the client is acting on behalf of the RO to
>>> access protected resources on a resource server. That is true for most API
>>> security use cases.
>>>
>>> However, an app may use both hats. For instance, monolithic JEE apps.
>>>
>>>> Maybe Authorization should move under clients tab?
>>> That is a good question. And my quick answer for that would be to keep it
>>> separated for now.
>>>
>>> I think changes like that may involve more discussions around UI design.
>>> For instance, today clients and resource servers are managed in the same
>>> space (Clients in left menu bar). As you know, clients (entities accessing
>>> a RS on behalf of an user) and RSs are different things and although they
>>> share a lot of things, I think we could have have them *visually*
>>> separated somehow.
>>>
>>> AuthZ includes more tabs and flows, so I don't think move under clients tab
>>> would be a good idea. I'm not a UX expert, there is probably a way to do
>>> what you want nicely ...
>> Maybe Resource Server is a misleading name?  Maybe it should be named a
>> Resource Manager or Resource Catalogue?  What about having a Resources
>> tab under Client that lists the "Resource Servers" attached to the
>> client and the ability to add/remove Resource Servers for that client?
>> Its just a different way to navigate.
> Don't think Resource Server is a misleading name. It is a pretty well concept on OAuth2 world.
>
> Maybe I can give a shot to your suggestion and move all AuthZ UIs to a "Resource Server" tab. Or even have all those AuthZ UI tabs as separated tabs. Will send you screenshots with the result.
>
> [NOTE]
> I think I misunderstood your original question about the 1:1 mapping between RS and Clients. My answer was based on a conceptual view of those entities, where RS and Client may represent or not the same entity.
>  From a implementation view, RS and Client have 1:1 mapping.

A Client can be associated with more than one Resource Server?

>
>> Across the board, for all of Keycloak, we need to put some thought into
>> how to make things easier to configure with intuitive defaults, etc.
>> For example, there has been some talk of having ZERO config at the
>> adapter side except the realm URL and a client token.  Apps would then
>> pull down all of their configuration from Keycloak.
> See, config is already minimal. Beside the keycloak-authz.json we discussed, you just need to change web.xml and jboss-deployment-structure.xml. The first is a necessary evil, but I can remove the latter.

Seems like if its all built into the same adapter, then there's a lot 
less configuration steps

All this doesn't need to be done for first release.  I'm just giving 
feedback :)

From psilva at redhat.com  Wed Jun  8 15:34:31 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 8 Jun 2016 15:34:31 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
	<1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
	<4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
Message-ID: <832580100.17065526.1465414471742.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, June 8, 2016 4:29:42 PM
> Subject: Re: Feedback
> 
> 
> 
> On 6/8/16 3:12 PM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak-dev"
> >> <keycloak-dev at lists.jboss.org>
> >> Sent: Wednesday, June 8, 2016 3:25:53 PM
> >> Subject: Re: Feedback
> >>
> >>
> >>
> >> On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
> >>> Hi All,
> >>>
> >>> Asked Bill for some feedback about AuthZ docs [1] and would like to share
> >>> with you.
> >>>
> >>> @Bill, my initial comments inline.
> >>>
> >>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Sent: Wednesday, June 8, 2016 11:15:03 AM
> >>>> Subject: Re: Feedback
> >>>>
> >>>> * Example is too complex.  Needs to be broken down and explained for
> >>>> each policy that was created.
> >>> OK. By "broken down" you mean using sub-topics (pages) or just sections
> >>> on
> >>> the same page ?
> >>>
> >>> The "Hello World" one should be fine because it is just a single policy
> >>> example. The "Securing a Servlet Application" may have more details about
> >>> each of those policies, will work on that. Or even just point to their
> >>> respective documentation, as we also have doc for each policy type.
> >>>
> >>>> * Example should not use JSON import.  It should walk through screen
> >>>> shots to explain how to set up things.
> >>> The idea behind using JSON import is that it provides an easy and fast
> >>> way
> >>> to users get started. After all, you just need to copy&paste
> >>> configuration
> >>> (or obtain from examples dir) and import to KC. IMO, that makes the
> >>> tutorial more easy to follow with focus on the main concepts being
> >>> explained.
> >> JSON is great for running an example, but not great for documentation.
> > OK. Changing ...
> >
> >>> I'm trying to keep documentation about UI on each topic, so you can see
> >>> how
> >>> to use admin console to create/configure things.
> >>>
> >>>> * Need more screenshots throughout doc
> >>> Probably related with your previous feedback. I'm going to take some more
> >>> screenshots ....
> >>>
> >>>> * Is Resource Server->Client always a one-to-one thing?
> >>> No, RS<->Client is not always a 1:1 mapping. Usually, they would be
> >>> different entities, where the client is acting on behalf of the RO to
> >>> access protected resources on a resource server. That is true for most
> >>> API
> >>> security use cases.
> >>>
> >>> However, an app may use both hats. For instance, monolithic JEE apps.
> >>>
> >>>> Maybe Authorization should move under clients tab?
> >>> That is a good question. And my quick answer for that would be to keep it
> >>> separated for now.
> >>>
> >>> I think changes like that may involve more discussions around UI design.
> >>> For instance, today clients and resource servers are managed in the same
> >>> space (Clients in left menu bar). As you know, clients (entities
> >>> accessing
> >>> a RS on behalf of an user) and RSs are different things and although they
> >>> share a lot of things, I think we could have have them *visually*
> >>> separated somehow.
> >>>
> >>> AuthZ includes more tabs and flows, so I don't think move under clients
> >>> tab
> >>> would be a good idea. I'm not a UX expert, there is probably a way to do
> >>> what you want nicely ...
> >> Maybe Resource Server is a misleading name?  Maybe it should be named a
> >> Resource Manager or Resource Catalogue?  What about having a Resources
> >> tab under Client that lists the "Resource Servers" attached to the
> >> client and the ability to add/remove Resource Servers for that client?
> >> Its just a different way to navigate.
> > Don't think Resource Server is a misleading name. It is a pretty well
> > concept on OAuth2 world.
> >
> > Maybe I can give a shot to your suggestion and move all AuthZ UIs to a
> > "Resource Server" tab. Or even have all those AuthZ UI tabs as separated
> > tabs. Will send you screenshots with the result.
> >
> > [NOTE]
> > I think I misunderstood your original question about the 1:1 mapping
> > between RS and Clients. My answer was based on a conceptual view of those
> > entities, where RS and Client may represent or not the same entity.
> >  From a implementation view, RS and Client have 1:1 mapping.
> 
> A Client can be associated with more than one Resource Server?

No, one-to-one. See https://keycloak.gitbooks.io/authorization-services-guide/content/topics/resource-server/create.html.

Will put screenshots there, as we discussed.

> 
> >
> >> Across the board, for all of Keycloak, we need to put some thought into
> >> how to make things easier to configure with intuitive defaults, etc.
> >> For example, there has been some talk of having ZERO config at the
> >> adapter side except the realm URL and a client token.  Apps would then
> >> pull down all of their configuration from Keycloak.
> > See, config is already minimal. Beside the keycloak-authz.json we
> > discussed, you just need to change web.xml and
> > jboss-deployment-structure.xml. The first is a necessary evil, but I can
> > remove the latter.
> 
> Seems like if its all built into the same adapter, then there's a lot
> less configuration steps
> 
> All this doesn't need to be done for first release.  I'm just giving
> feedback :)

God bless you

> 

From psilva at redhat.com  Wed Jun  8 17:44:50 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 8 Jun 2016 17:44:50 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <832580100.17065526.1465414471742.JavaMail.zimbra@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
	<1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
	<4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
	<832580100.17065526.1465414471742.JavaMail.zimbra@redhat.com>
Message-ID: <1937592999.17146463.1465422290750.JavaMail.zimbra@redhat.com>

Regarding adapter config, I'm going to quickly rewrite the AuthZ Client API. Currently, this API is based on ResteasyClient.

Will change it to be solely based on org.apache.httpcomponents:httpclient and keep even more lightweight. That should be enough to let me change current adapters to support authz config and keep config more simple.

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Wednesday, June 8, 2016 4:34:31 PM
Subject: Re: [keycloak-dev] Feedback

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, June 8, 2016 4:29:42 PM
> Subject: Re: Feedback
> 
> 
> 
> On 6/8/16 3:12 PM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak-dev"
> >> <keycloak-dev at lists.jboss.org>
> >> Sent: Wednesday, June 8, 2016 3:25:53 PM
> >> Subject: Re: Feedback
> >>
> >>
> >>
> >> On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
> >>> Hi All,
> >>>
> >>> Asked Bill for some feedback about AuthZ docs [1] and would like to share
> >>> with you.
> >>>
> >>> @Bill, my initial comments inline.
> >>>
> >>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Sent: Wednesday, June 8, 2016 11:15:03 AM
> >>>> Subject: Re: Feedback
> >>>>
> >>>> * Example is too complex.  Needs to be broken down and explained for
> >>>> each policy that was created.
> >>> OK. By "broken down" you mean using sub-topics (pages) or just sections
> >>> on
> >>> the same page ?
> >>>
> >>> The "Hello World" one should be fine because it is just a single policy
> >>> example. The "Securing a Servlet Application" may have more details about
> >>> each of those policies, will work on that. Or even just point to their
> >>> respective documentation, as we also have doc for each policy type.
> >>>
> >>>> * Example should not use JSON import.  It should walk through screen
> >>>> shots to explain how to set up things.
> >>> The idea behind using JSON import is that it provides an easy and fast
> >>> way
> >>> to users get started. After all, you just need to copy&paste
> >>> configuration
> >>> (or obtain from examples dir) and import to KC. IMO, that makes the
> >>> tutorial more easy to follow with focus on the main concepts being
> >>> explained.
> >> JSON is great for running an example, but not great for documentation.
> > OK. Changing ...
> >
> >>> I'm trying to keep documentation about UI on each topic, so you can see
> >>> how
> >>> to use admin console to create/configure things.
> >>>
> >>>> * Need more screenshots throughout doc
> >>> Probably related with your previous feedback. I'm going to take some more
> >>> screenshots ....
> >>>
> >>>> * Is Resource Server->Client always a one-to-one thing?
> >>> No, RS<->Client is not always a 1:1 mapping. Usually, they would be
> >>> different entities, where the client is acting on behalf of the RO to
> >>> access protected resources on a resource server. That is true for most
> >>> API
> >>> security use cases.
> >>>
> >>> However, an app may use both hats. For instance, monolithic JEE apps.
> >>>
> >>>> Maybe Authorization should move under clients tab?
> >>> That is a good question. And my quick answer for that would be to keep it
> >>> separated for now.
> >>>
> >>> I think changes like that may involve more discussions around UI design.
> >>> For instance, today clients and resource servers are managed in the same
> >>> space (Clients in left menu bar). As you know, clients (entities
> >>> accessing
> >>> a RS on behalf of an user) and RSs are different things and although they
> >>> share a lot of things, I think we could have have them *visually*
> >>> separated somehow.
> >>>
> >>> AuthZ includes more tabs and flows, so I don't think move under clients
> >>> tab
> >>> would be a good idea. I'm not a UX expert, there is probably a way to do
> >>> what you want nicely ...
> >> Maybe Resource Server is a misleading name?  Maybe it should be named a
> >> Resource Manager or Resource Catalogue?  What about having a Resources
> >> tab under Client that lists the "Resource Servers" attached to the
> >> client and the ability to add/remove Resource Servers for that client?
> >> Its just a different way to navigate.
> > Don't think Resource Server is a misleading name. It is a pretty well
> > concept on OAuth2 world.
> >
> > Maybe I can give a shot to your suggestion and move all AuthZ UIs to a
> > "Resource Server" tab. Or even have all those AuthZ UI tabs as separated
> > tabs. Will send you screenshots with the result.
> >
> > [NOTE]
> > I think I misunderstood your original question about the 1:1 mapping
> > between RS and Clients. My answer was based on a conceptual view of those
> > entities, where RS and Client may represent or not the same entity.
> >  From a implementation view, RS and Client have 1:1 mapping.
> 
> A Client can be associated with more than one Resource Server?

No, one-to-one. See https://keycloak.gitbooks.io/authorization-services-guide/content/topics/resource-server/create.html.

Will put screenshots there, as we discussed.

> 
> >
> >> Across the board, for all of Keycloak, we need to put some thought into
> >> how to make things easier to configure with intuitive defaults, etc.
> >> For example, there has been some talk of having ZERO config at the
> >> adapter side except the realm URL and a client token.  Apps would then
> >> pull down all of their configuration from Keycloak.
> > See, config is already minimal. Beside the keycloak-authz.json we
> > discussed, you just need to change web.xml and
> > jboss-deployment-structure.xml. The first is a necessary evil, but I can
> > remove the latter.
> 
> Seems like if its all built into the same adapter, then there's a lot
> less configuration steps
> 
> All this doesn't need to be done for first release.  I'm just giving
> feedback :)

God bless you

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

From singhrasster at gmail.com  Wed Jun  8 21:48:50 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Wed, 8 Jun 2016 20:48:50 -0500
Subject: [keycloak-dev] Optional authenticator inside an alternative
 subflow, how and when is it invoked?
In-Reply-To: <CAJ0vL++YTwqgxCMT-NquWO8VVif+R2a_FOFGGMU5zO9o6z9tvw@mail.gmail.com>
References: <CAJ0vL++gxxYXdjgoht0GLX2c5WFCUHumS8uUUndMmeTR7_ns3Q@mail.gmail.com>
	<5757F1B5.9060306@redhat.com>
	<CAJ0vL++OP4OF992J6FGpGNpA2BYwuavcw86EcVCf0CFL6xDZeQ@mail.gmail.com>
	<CAJ0vL++YTwqgxCMT-NquWO8VVif+R2a_FOFGGMU5zO9o6z9tvw@mail.gmail.com>
Message-ID: <CAJ0vL+Ls9+ODd=dBb_44QhAOuBu0+sohr7roTSUCZgjMTHMhng@mail.gmail.com>

I have one more question on this. I have my own implementation of two
authenticators now: Username Authenticator (REQUIRED) and OTP authenticator
(OPTIONAL) under an ALTERNATIVE subflow. The second optional authenticator
has Authenticator.configuredFor returns false (I have this because I do not
want this to be invoked only when the user is set in the context already).
Now, the second authenticator is invoked which is good. But, there is one
case in my usernamePassword Authenticator for which the optional
OTPAuthenticator should not be invoked. Can this be achieved? Other than
that case, OTP authenticator should be invoked as now. Can I stop this
second optional OTPAuthenticator from being invoked for a particular case
in my UsernamePassword authenticator?

On Wed, Jun 8, 2016 at 2:04 PM, Rashmi Singh <singhrasster at gmail.com> wrote:

> OK, I am clear about this point now. It does enter the second optional
> authenticator, so it is good now. Thank you
>
> On Wed, Jun 8, 2016 at 10:43 AM, Rashmi Singh <singhrasster at gmail.com>
> wrote:
>
>> In general, if we have any two authenticators under ALTERNATIVE flow, the
>> second being OPTIONAL, is the optional one invoked only when
>> context.setUser(user) is set in the first authenticator? otherwise, the
>> second OPTIONAL authenticator is never invoked (irrespective of whether Authenticator.configuredFor
>> returns true or false) at all? Is there a way to invoke the optional
>> authenticator even when context.setUser(user) was never done in the first
>> authenticator?
>>
>> On Wed, Jun 8, 2016 at 5:21 AM, Marek Posolda <mposolda at redhat.com>
>> wrote:
>>
>>> Currently the OPTIONAL means that authenticator is used just if it's
>>> configured for particular user ( Authenticator.configuredFor returns true
>>> for that user). In case of OTP, it means that OTP form is shown just if OTP
>>> is configured for particular user.
>>>
>>> It looks that OPTIONAL authenticator needs to return "requiresUser" with
>>> true, otherwise if it doesn't require user the error will be returned (even
>>> if authenticator is OPTIONAL).
>>>
>>> Marek
>>>
>>>
>>> On 07/06/16 17:29, Rashmi Singh wrote:
>>>
>>> From the keycloak documentation and
>>> <https://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html>
>>> https://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html
>>>
>>> it is not very clear to me what the OPTIONAL setting for an execution
>>> mean.
>>>
>>> For example, when we have the following:
>>>
>>> Forms Subflow - ALTERNATIVE
>>>            Username/Password Form - REQUIRED
>>>            OTP Password Form - OPTIONAL
>>>
>>>
>>>
>>> When can it enter the Optional OTP form? Do we need to add some code
>>> (some condition ?) in the UsernamePasswordAuthentication Code, so it enters
>>> the optional OTP form authenticator? Or something else? I am not so clear
>>> about the concept of this optional field and how to enter it. Can someone
>>> please explain this in detail?
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160608/d6bbd464/attachment.html 

From a.nekrasov at ftc.ru  Thu Jun  9 02:44:14 2016
From: a.nekrasov at ftc.ru (Nekrasov Aleksandr)
Date: Thu, 9 Jun 2016 06:44:14 +0000
Subject: [keycloak-dev] Verify access token when using SPI
Message-ID: <2a34f09b9e044ef6bc64294a1a0b34cb@nut-mbx-4.win.ftc.ru>

Hello everyone.

I am release my own provider to extend some user account actions and having trouble with token validation in it. I am explore rest example https://github.com/keycloak/keycloak/tree/master/examples/providers/rest , but can`t see how I can do it.

My scenario is next. Client app authenticate user use Direct Access Grant request to retrieve token. Next, I am sending request on my own resource with this token. Then I want to validate token and check user rights for allow access to my method in resource. What is true way to release it?

Nekrasov Aleksander,
Developer,
Center of Financial Techologies

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

From mposolda at redhat.com  Thu Jun  9 02:54:29 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 9 Jun 2016 08:54:29 +0200
Subject: [keycloak-dev] Optional authenticator inside an alternative
 subflow, how and when is it invoked?
In-Reply-To: <CAJ0vL+Ls9+ODd=dBb_44QhAOuBu0+sohr7roTSUCZgjMTHMhng@mail.gmail.com>
References: <CAJ0vL++gxxYXdjgoht0GLX2c5WFCUHumS8uUUndMmeTR7_ns3Q@mail.gmail.com>
	<5757F1B5.9060306@redhat.com>
	<CAJ0vL++OP4OF992J6FGpGNpA2BYwuavcw86EcVCf0CFL6xDZeQ@mail.gmail.com>
	<CAJ0vL++YTwqgxCMT-NquWO8VVif+R2a_FOFGGMU5zO9o6z9tvw@mail.gmail.com>
	<CAJ0vL+Ls9+ODd=dBb_44QhAOuBu0+sohr7roTSUCZgjMTHMhng@mail.gmail.com>
Message-ID: <575912A5.7050508@redhat.com>

For more complicated conditional workflows like this, you can always use 
clientSession notes and save/read the state from here. For example 
authenticator1 will call something like this if "particular case" happened:

clientSession.setNote("someNote", "particularCaseHappened");

And authenticator2 can then use something like this in the beginning of 
method "authenticate" :

if ("particularCaseHappened".equals(clientSession.getNote("someNote") {
     log.info("Ignoring this authenticator based on fact that 
'particular case' from authenticator1 happened");
     context.attempted();
     return;
}

Marek

On 09/06/16 03:48, Rashmi Singh wrote:
> I have one more question on this. I have my own implementation of two 
> authenticators now: Username Authenticator (REQUIRED) and OTP 
> authenticator (OPTIONAL) under an ALTERNATIVE subflow. The second 
> optional authenticator has Authenticator.configuredFor returns false 
> (I have this because I do not want this to be invoked only when the 
> user is set in the context already). Now, the second authenticator is 
> invoked which is good. But, there is one case in my usernamePassword 
> Authenticator for which the optional OTPAuthenticator should not be 
> invoked. Can this be achieved? Other than that case, OTP authenticator 
> should be invoked as now. Can I stop this second optional 
> OTPAuthenticator from being invoked for a particular case in my 
> UsernamePassword authenticator?
>
> On Wed, Jun 8, 2016 at 2:04 PM, Rashmi Singh <singhrasster at gmail.com 
> <mailto:singhrasster at gmail.com>> wrote:
>
>     OK, I am clear about this point now. It does enter the second
>     optional authenticator, so it is good now. Thank you
>
>     On Wed, Jun 8, 2016 at 10:43 AM, Rashmi Singh
>     <singhrasster at gmail.com <mailto:singhrasster at gmail.com>> wrote:
>
>         In general, if we have any two authenticators under
>         ALTERNATIVE flow, the second being OPTIONAL, is the optional
>         one invoked only when context.setUser(user) is set in the
>         first authenticator? otherwise, the second OPTIONAL
>         authenticator is never invoked (irrespective of whether
>         Authenticator.configuredFor returns true or false) at all? Is
>         there a way to invoke the optional authenticator even when
>         context.setUser(user) was never done in the first authenticator?
>
>         On Wed, Jun 8, 2016 at 5:21 AM, Marek Posolda
>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>
>             Currently the OPTIONAL means that authenticator is used
>             just if it's configured for particular user (
>             Authenticator.configuredFor returns true for that user).
>             In case of OTP, it means that OTP form is shown just if
>             OTP is configured for particular user.
>
>             It looks that OPTIONAL authenticator needs to return
>             "requiresUser" with true, otherwise if it doesn't require
>             user the error will be returned (even if authenticator is
>             OPTIONAL).
>
>             Marek
>
>
>             On 07/06/16 17:29, Rashmi Singh wrote:
>>             From the keycloak documentation and
>>             https://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html
>>
>>
>>             it is not very clear to me what the OPTIONAL setting for
>>             an execution mean.
>>
>>             For example, when we have the following:
>>
>>             Forms Subflow - ALTERNATIVE
>>                         Username/Password Form - REQUIRED
>>                         OTP Password Form - OPTIONAL
>>
>>
>>             When can it enter the Optional OTP form? Do we need to
>>             add some code (some condition ?) in the
>>             UsernamePasswordAuthentication Code, so it enters the
>>             optional OTP form authenticator? Or something else? I am
>>             not so clear about the concept of this optional field and
>>             how to enter it. Can someone please explain this in detail?
>>
>>
>>             _______________________________________________
>>             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
>
>
>
>

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

From velias at redhat.com  Thu Jun  9 06:42:06 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Thu, 9 Jun 2016 12:42:06 +0200
Subject: [keycloak-dev] Exception handling for own REST API - is it possible
 to register own javax.ws.rs.ext.ExceptionMapper?
Message-ID: <575947FE.7030808@redhat.com>

Hi,

I'm implementing my own REST endpoint using RealmResourceProvider and 
I'm thinking how to perform error handling (which is not covered in 
example).
Is it possible to register my javax.ws.rs.ext.ExceptionMapper subclass 
to handle my exceptions? I tried to add subclass of it annotated with 
javax.ws.rs.ext.Provider into my code but it is not used.
I get common error page with:

*Stack Trace*
org.jboss.resteasy.spi.UnhandledException: 
com.redhat.developer.keycloak.rest.InvalidParametersException: email 
param must be specified

Thansk in advance.

Vlastimil

-- 
Vlastimil Elias
Principal Software Engineer
Red Hat Developer | Engineering

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

From carreraariel at gmail.com  Thu Jun  9 11:59:26 2016
From: carreraariel at gmail.com (Ariel Carrera)
Date: Thu, 9 Jun 2016 12:59:26 -0300
Subject: [keycloak-dev] User Federation Provider Cache
Message-ID: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>

Hi Marek, Stian, Bill....

I have developed a custom user federation provider. I notice that Keycloak
create several User Federation Providers during a single authentication
flow callin KeycloakModelUtils.getFederationProviderInstance multiple
times...

To prevent create two or three user federation providers per request, I
need implement into my custom Federation Provider a logic for search an
instance of my custom provider into the Keycloak session and if not exists
then create a new one. So... there would be better do it into the method
KeycloakModelUtils.getFederationProviderInstance?

People that implements a custom user federation providers... Do people need
to create multiple instances per request of the same provider?


By the way, I have extended the keycloak SPI to perform use of infinispan
cache when a custom user provider try to validate a user or get some data
from a user federation provider during process. Maybe this could be useful
to other users... if you wants to add this spi, I can try to prepare a pull
request to you.


Thanks
-- 
Ariel Carrera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160609/33be6a58/attachment.html 

From carreraariel at gmail.com  Thu Jun  9 12:05:47 2016
From: carreraariel at gmail.com (Ariel Carrera)
Date: Thu, 9 Jun 2016 13:05:47 -0300
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
Message-ID: <CAFzO_6c+N46eh+x7i67g8fCEpCqu5AQmLJL_otZGcA2R-TVuiw@mail.gmail.com>

When I wrote:
"I have developed a custom user federation provider. I notice that Keycloak
create several User Federation Providers during a single authentication
flow callin KeycloakModelUtils.getFederationProviderInstance multiple
times..."
I tried to write:
"I have developed a custom user federation provider. I notice that Keycloak
creates several User Federation Providers during a single authentication
flow, calling to KeycloakModelUtils.getFederationProviderInstance multiple
times..."

2016-06-09 12:59 GMT-03:00 Ariel Carrera <carreraariel at gmail.com>:

> Hi Marek, Stian, Bill....
>
> I have developed a custom user federation provider. I notice that Keycloak
> create several User Federation Providers during a single authentication
> flow callin KeycloakModelUtils.getFederationProviderInstance multiple
> times...
>
> To prevent create two or three user federation providers per request, I
> need implement into my custom Federation Provider a logic for search an
> instance of my custom provider into the Keycloak session and if not exists
> then create a new one. So... there would be better do it into the method
> KeycloakModelUtils.getFederationProviderInstance?
>
> People that implements a custom user federation providers... Do people
> need to create multiple instances per request of the same provider?
>
>
> By the way, I have extended the keycloak SPI to perform use of infinispan
> cache when a custom user provider try to validate a user or get some data
> from a user federation provider during process. Maybe this could be useful
> to other users... if you wants to add this spi, I can try to prepare a pull
> request to you.
>
>
> Thanks
> --
> Ariel Carrera
>



-- 
Tat?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160609/df989695/attachment-0001.html 

From bburke at redhat.com  Thu Jun  9 13:54:51 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 9 Jun 2016 13:54:51 -0400
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
Message-ID: <1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>

We are planning to merge the UserFederationProvider and UserProvider 
SPIs into a new User Storage SPI.  I'm actually working on that right 
now and will be posting something soon.

Is creating a provider expensive for you for your implementation?


On 6/9/16 11:59 AM, Ariel Carrera wrote:
> Hi Marek, Stian, Bill....
>
> I have developed a custom user federation provider. I notice that 
> Keycloak create several User Federation Providers during a single 
> authentication flow callin 
> KeycloakModelUtils.getFederationProviderInstance multiple times...
>
> To prevent create two or three user federation providers per request, 
> I need implement into my custom Federation Provider a logic for search 
> an instance of my custom provider into the Keycloak session and if not 
> exists then create a new one. So... there would be better do it into 
> the method KeycloakModelUtils.getFederationProviderInstance?
>
> People that implements a custom user federation providers... Do people 
> need to create multiple instances per request of the same provider?
>
>
> By the way, I have extended the keycloak SPI to perform use of 
> infinispan cache when a custom user provider try to validate a user or 
> get some data from a user federation provider during process. Maybe 
> this could be useful to other users... if you wants to add this spi, I 
> can try to prepare a pull request to you.
>
>
> Thanks
> -- 
> Ariel Carrera
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From desk3016 at live.com  Thu Jun  9 16:46:35 2016
From: desk3016 at live.com (Eric Son 3016)
Date: Thu, 9 Jun 2016 13:46:35 -0700
Subject: [keycloak-dev] Exception when using JAXB in keycloak
Message-ID: <BAY172-W28F3E3DBA9FA342328B06BBE5F0@phx.gbl>

Hi, I was trying to use JAXB in the keycloak and I have got the ClassNotFoundException 

2016-06-09 20:19:40,514 INFO  [stdout] (default task-2) Failed to create marshalled xmlString: javax.xml.bind.JAXBException
2016-06-09 20:19:40,515 INFO  [stdout] (default task-2)  - with linked exception:
2016-06-09 20:19:40,515 INFO  [stdout] (default task-2) [java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory from [Module "deployment.keycloak-server.war:main" from Service Module Loader]]

when the code is doing
JAXBContext jaxbContext = JAXBContext.newInstance(Class A);

is it because of keycloak is using openJDK instead of oracle JDK? 

Since, on my eclipse, the project includes the JRE system library that has rt.jar containing com.sun.xml.internal.bind.v2.ContextFactory class 
and was able to compile the project with no issue but it only happens when keycloak war is deployed.

I borrow some idea from below link, (the same thing happens for com.sun.net.ssl.internal.ssl.provider with JRE system library's jsse.jar)
http://stackoverflow.com/questions/11289860/deploy-time-error-java-lang-noclassdeffounderror-com-sun-net-ssl-internal-ssl

basically, I created a jboss-deployment-structure.xml file into the WEB-INF/ and imported the system module dependency into module.xml under JBOSS_HOME\modules\system\layers\base\sun\jdk\main\ but it didn't help. 


Has anyone run into this issue? Any suggestion will be appreciated.

Thanks a lot!

Best Regards,

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

From carreraariel at gmail.com  Thu Jun  9 19:36:33 2016
From: carreraariel at gmail.com (Ariel Carrera)
Date: Thu, 9 Jun 2016 20:36:33 -0300
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
Message-ID: <CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>

There is not problem! :)
One more thing, I solved the problem of multiple "federation provider"
instances, adding this code to the DefaultKeycloakSession (and the method
definition in KeycloakSession interface):


> public <T extends Provider> void registerProvider(Class<T> clazz, Provider
> provider, String id) {
>         Integer hash = clazz.hashCode() + id.hashCode();
>         providers.put(hash, provider);
>     }


And into MyUserFederationProviderFactory.getInstance(session, model)
something like this:

public UserFederationProvider getInstance(KeycloakSession session,
> UserFederationProviderModel model){
> UserFederationProvider provider = (UserFederationProvider)
> session.getProvider(UserFederationProvider.class, model.getId());
> if (provider == null){
> lazyInit(session);
>                 provider = new MyUserFederationProvider(session, model,
> config, ......);
>
> ((KeycloakSession)session).registerProvider(UserFederationProvider.class,
> provider, model.getId());
> };
>         return provider;
>     }


After a few tests and debug it seems to work... creating, catching, and
closing provider instances as expected.


In future versions as you said, maybe would be better include a way to
instantiate a complex object/provider instead of doing

> ProviderFactory.create(KeycloakSession session)
> some kind of method like
> ProviderFactory.create(KeycloakSession session, Object... obj);

and the appropriate method into the KeycloakSession

> <T extends Provider> T getProvider(Class<T> clazz, Object... obj);
> <T extends Provider> T getProvider(Class<T> clazz, String id, Object...
> obj);


And why not a map into the keycloakSession to store some additional context
data to share between providers during same request? It's only a vague idea

Regards!

2016-06-09 17:14 GMT-03:00 Bill Burke <bburke at redhat.com>:

> Its gonna be awhile.  Its going to be difficult to make everything both
> backward compatible and cover all the current and future use cases we need
> to cover.  Listen on the dev list.  I should post some info soon on what
> the new impl will look like.
>
> On 6/9/16 3:57 PM, Ariel Carrera wrote:
>
> Yes Bill, exactly! I will waiting to test it Thanks!
>
> 2016-06-09 16:29 GMT-03:00 Bill Burke <bburke at redhat.com>:
>
>>
>>
>> On 6/9/16 2:52 PM, Ariel Carrera wrote:
>>
>>> Hi Bill, is a little expensive for me because I am creating a new entity
>>> manager to connect with a legacy database, and creating/enlisting a
>>> transaction per instance.
>>> For example in a simple flow case where a user needs to click "I forgot
>>> my password" link to recover the password, there is more than nine or ten
>>> instances created to do this. It's really not a big problem but I think
>>> that is not necessary and can be implemented like others spi providers
>>> catched into the keycloak session.
>>>
>>> This is good feedback.  We need a way to associate a provider, by name,
>> to the KeycloakSession.  Maybe we just need a way to associate anything
>> with the KeycloakSession period.
>>
>> In my case, another difficulty is synchronization between an old
>>> authentication system and keycloak implemented on demand (there is no
>>> full/partial syncrhonization because the legacy system is still working and
>>> need to work together for a while). Also I implemented synchronization
>>> support but at this moment it not used.
>>> Every time that keycloak needs to validate a user (isValid) recovered
>>> from the user storage or cache, a query to the legacy system is made. Added
>>> to this... I need to recover some attributes and roles changes produced on
>>> the legacy system.... so I decided to implement a "user federation cache"
>>> with a short term expiration to improve the performance with certain
>>> synchronization delay tolerance.
>>>
>>> In a few words I have: a custom User Federation Provider + on deman
>>> synchronization + a user Federation Provider Cache (my own cache SPI).
>>>
>>> Maybe an optional spi to obtain a custom container from infinispan could
>>> be a good choice to add to the new implementation and provide another one
>>> tool to do things with better performance.
>>>
>>> I think the new model might solve your caching needs.  There will be no
>> importing by default.  This means no synching, etc.  Keycloak will only
>> store metadata that your user store can't provide.  User Federation
>> Providers will work just as the default Keycloak user store and user cache.
>>
>>
>
>
> --
> Tat?
>
>
>


-- 
Tat?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160609/1180c511/attachment.html 

From psilva at redhat.com  Thu Jun  9 23:04:00 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 9 Jun 2016 23:04:00 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
	<1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
	<4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
Message-ID: <1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>

Bill,

Got the authz stuff working with the adapters. It was a puzzle but I think I have something.

Here are the most important changes:

* Added an authorization step into AuthenticatedActionsHandler, so I could perform the authorization checks there and decide whether the request can continue or not.
* Authorization checks are now in adapter-core and they are generic, so we can support the different adapters.
* Added a single keycloak-authz-client dependency to adapter-core. It provides a lightweight API for accessing authz services (see doc) and doesn't bring new dependencies, but only those already in use by adapter-core.
* Added an AuthorizationContext type to keycloak-core. It holds the authorization data and can be obtained from a KeycloakSecurityContext (it is marked as transient). Instances are set into KeycloakSecurityContext during the authorization  process, so the application can use it to check for permissions. In the future, it should allow us to bring the policy decision point more close to the policy enforcement point. I was already using this class, just moved to keycloak-core.
* I've discarded my own sub-types of AccessToken, they were redundant. The only difference between authz tokens and access tokens was a list of permissions. And the concept behind them is the same. I've added a "authorization" claim to AccessToken (null by default) from where permissions granted by the server can be obtained.
* Added a "policy-enforcer" configuration to the adapter config. With this option you can provide the different options to configure a policy enforcer.

As expected, adapter configuration is even more simple now, with less steps to get things done.

Do you have any consideration ? Would like to update the authz doc and getting started tutorials to reflect the config changes to adapters.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Wednesday, June 8, 2016 4:29:42 PM
Subject: Re: Feedback



On 6/8/16 3:12 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Wednesday, June 8, 2016 3:25:53 PM
>> Subject: Re: Feedback
>>
>>
>>
>> On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
>>> Hi All,
>>>
>>> Asked Bill for some feedback about AuthZ docs [1] and would like to share
>>> with you.
>>>
>>> @Bill, my initial comments inline.
>>>
>>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Sent: Wednesday, June 8, 2016 11:15:03 AM
>>>> Subject: Re: Feedback
>>>>
>>>> * Example is too complex.  Needs to be broken down and explained for
>>>> each policy that was created.
>>> OK. By "broken down" you mean using sub-topics (pages) or just sections on
>>> the same page ?
>>>
>>> The "Hello World" one should be fine because it is just a single policy
>>> example. The "Securing a Servlet Application" may have more details about
>>> each of those policies, will work on that. Or even just point to their
>>> respective documentation, as we also have doc for each policy type.
>>>
>>>> * Example should not use JSON import.  It should walk through screen
>>>> shots to explain how to set up things.
>>> The idea behind using JSON import is that it provides an easy and fast way
>>> to users get started. After all, you just need to copy&paste configuration
>>> (or obtain from examples dir) and import to KC. IMO, that makes the
>>> tutorial more easy to follow with focus on the main concepts being
>>> explained.
>> JSON is great for running an example, but not great for documentation.
> OK. Changing ...
>
>>> I'm trying to keep documentation about UI on each topic, so you can see how
>>> to use admin console to create/configure things.
>>>
>>>> * Need more screenshots throughout doc
>>> Probably related with your previous feedback. I'm going to take some more
>>> screenshots ....
>>>
>>>> * Is Resource Server->Client always a one-to-one thing?
>>> No, RS<->Client is not always a 1:1 mapping. Usually, they would be
>>> different entities, where the client is acting on behalf of the RO to
>>> access protected resources on a resource server. That is true for most API
>>> security use cases.
>>>
>>> However, an app may use both hats. For instance, monolithic JEE apps.
>>>
>>>> Maybe Authorization should move under clients tab?
>>> That is a good question. And my quick answer for that would be to keep it
>>> separated for now.
>>>
>>> I think changes like that may involve more discussions around UI design.
>>> For instance, today clients and resource servers are managed in the same
>>> space (Clients in left menu bar). As you know, clients (entities accessing
>>> a RS on behalf of an user) and RSs are different things and although they
>>> share a lot of things, I think we could have have them *visually*
>>> separated somehow.
>>>
>>> AuthZ includes more tabs and flows, so I don't think move under clients tab
>>> would be a good idea. I'm not a UX expert, there is probably a way to do
>>> what you want nicely ...
>> Maybe Resource Server is a misleading name?  Maybe it should be named a
>> Resource Manager or Resource Catalogue?  What about having a Resources
>> tab under Client that lists the "Resource Servers" attached to the
>> client and the ability to add/remove Resource Servers for that client?
>> Its just a different way to navigate.
> Don't think Resource Server is a misleading name. It is a pretty well concept on OAuth2 world.
>
> Maybe I can give a shot to your suggestion and move all AuthZ UIs to a "Resource Server" tab. Or even have all those AuthZ UI tabs as separated tabs. Will send you screenshots with the result.
>
> [NOTE]
> I think I misunderstood your original question about the 1:1 mapping between RS and Clients. My answer was based on a conceptual view of those entities, where RS and Client may represent or not the same entity.
>  From a implementation view, RS and Client have 1:1 mapping.

A Client can be associated with more than one Resource Server?

>
>> Across the board, for all of Keycloak, we need to put some thought into
>> how to make things easier to configure with intuitive defaults, etc.
>> For example, there has been some talk of having ZERO config at the
>> adapter side except the realm URL and a client token.  Apps would then
>> pull down all of their configuration from Keycloak.
> See, config is already minimal. Beside the keycloak-authz.json we discussed, you just need to change web.xml and jboss-deployment-structure.xml. The first is a necessary evil, but I can remove the latter.

Seems like if its all built into the same adapter, then there's a lot 
less configuration steps

All this doesn't need to be done for first release.  I'm just giving 
feedback :)

From bburke at redhat.com  Fri Jun 10 09:39:07 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jun 2016 09:39:07 -0400
Subject: [keycloak-dev] Feedback
In-Reply-To: <1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
	<1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
	<4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
	<1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>
Message-ID: <a77d412a-a62b-69e8-5eaf-bee704680041@redhat.com>



On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
> Bill,
>
> Got the authz stuff working with the adapters. It was a puzzle but I think I have something.
Yeah, its nasty.  Every servlet container handlers security just a bit 
differently than others so, its ugly.

> * I've discarded my own sub-types of AccessToken, they were redundant. The only difference between authz tokens and access tokens was a list of permissions. And the concept behind them is the same. I've added a "authorization" claim to AccessToken (null by default) from where permissions granted by the server can be obtained.
Is a claim better?  Or should AccessTokenResponse optionally contain the 
RPT?  Or optionally a query param for Implicit Flow?  Or have both?  I 
don't know.



From psilva at redhat.com  Fri Jun 10 10:59:37 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 10 Jun 2016 10:59:37 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <a77d412a-a62b-69e8-5eaf-bee704680041@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
	<1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
	<4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
	<1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>
	<a77d412a-a62b-69e8-5eaf-bee704680041@redhat.com>
Message-ID: <862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, June 10, 2016 10:39:07 AM
> Subject: Re: Feedback
> 
> 
> 
> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
> > Bill,
> >
> > Got the authz stuff working with the adapters. It was a puzzle but I think
> > I have something.
> Yeah, its nasty.  Every servlet container handlers security just a bit
> differently than others so, its ugly.
> 
> > * I've discarded my own sub-types of AccessToken, they were redundant. The
> > only difference between authz tokens and access tokens was a list of
> > permissions. And the concept behind them is the same. I've added a
> > "authorization" claim to AccessToken (null by default) from where
> > permissions granted by the server can be obtained.
> Is a claim better?  

To represent a RPT, I believe it is.

>Or should AccessTokenResponse optionally contain the RPT?

IMO, that would make things harder from a client perspective. See my next comments.  

> Or optionally a query param for Implicit Flow?  Or have both?  I
> don't know.

I think we have two different things here:

* How a RPT looks like
* How a RPT is obtained (the protocol in use)

In the first case, a RPT is just a special type of access token with authorization data on it. Where this data is a result of the evaluation of permissions and authorization policies associated with the resources being requested. Here, that claim represents this data. This is protocol agnostic.

The latter case is how you obtain that data, which is strongly associated with the protocol in use. What you said makes a lot of sense, we can issue this authorization data when doing any of the OAuth2 grant types. That can be specially useful when you want to obtain all permissions for an user at once when authenticating in KC, avoiding an additional call to the server in order to obtain authorization specific data. One way to achieve that would be a 
"Entitlement Protocol Mapper" that is capable of decorating an access token with the authorization data. Thus, transforming the access token into a RPT. See, the client just use the final access token without any additional treatment.

There are a lot of other features to implement around both UMA and Entitlement protocols. For instance, claims gathering or obligations. So the server can ask the client for additional information. Eg.: require a higher security level, etc. And for that, we must be able to obtain authz data separately.

> 
> 
> 

From bburke at redhat.com  Fri Jun 10 11:11:37 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jun 2016 11:11:37 -0400
Subject: [keycloak-dev] Feedback
In-Reply-To: <862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
	<1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
	<4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
	<1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>
	<a77d412a-a62b-69e8-5eaf-bee704680041@redhat.com>
	<862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>
Message-ID: <9ac0a941-666f-15cb-2ff3-8598eaa94660@redhat.com>



On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, June 10, 2016 10:39:07 AM
>> Subject: Re: Feedback
>>
>>
>>
>> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
>>> Bill,
>>>
>>> Got the authz stuff working with the adapters. It was a puzzle but I think
>>> I have something.
>> Yeah, its nasty.  Every servlet container handlers security just a bit
>> differently than others so, its ugly.
>>
>>> * I've discarded my own sub-types of AccessToken, they were redundant. The
>>> only difference between authz tokens and access tokens was a list of
>>> permissions. And the concept behind them is the same. I've added a
>>> "authorization" claim to AccessToken (null by default) from where
>>> permissions granted by the server can be obtained.
>> Is a claim better?
> To represent a RPT, I believe it is.
>
>> Or should AccessTokenResponse optionally contain the RPT?
> IMO, that would make things harder from a client perspective. See my next comments.
>
>> Or optionally a query param for Implicit Flow?  Or have both?  I
>> don't know.
> I think we have two different things here:
>
> * How a RPT looks like
> * How a RPT is obtained (the protocol in use)
>
> In the first case, a RPT is just a special type of access token with authorization data on it. Where this data is a result of the evaluation of permissions and authorization policies associated with the resources being requested. Here, that claim represents this data. This is protocol agnostic.
>
> The latter case is how you obtain that data, which is strongly associated with the protocol in use. What you said makes a lot of sense, we can issue this authorization data when doing any of the OAuth2 grant types. That can be specially useful when you want to obtain all permissions for an user at once when authenticating in KC, avoiding an additional call to the server in order to obtain authorization specific data. One way to achieve that would be a
> "Entitlement Protocol Mapper" that is capable of decorating an access token with the authorization data. Thus, transforming the access token into a RPT. See, the client just use the final access token without any additional treatment.
>
> There are a lot of other features to implement around both UMA and Entitlement protocols. For instance, claims gathering or obligations. So the server can ask the client for additional information. Eg.: require a higher security level, etc. And for that, we must be able to obtain authz data separately.

IIRC, there's a REST API right that allows a client to turn an access 
token into an RPT?  So, if Client A gets an access token, it can invoke 
on Service B.  Service B can pass the access token to Keycloak to obtain 
an RPT?

From psilva at redhat.com  Fri Jun 10 11:23:33 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 10 Jun 2016 11:23:33 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <9ac0a941-666f-15cb-2ff3-8598eaa94660@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
	<1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
	<4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
	<1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>
	<a77d412a-a62b-69e8-5eaf-bee704680041@redhat.com>
	<862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>
	<9ac0a941-666f-15cb-2ff3-8598eaa94660@redhat.com>
Message-ID: <1920717619.17938110.1465572213044.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, June 10, 2016 12:11:37 PM
> Subject: Re: Feedback
> 
> 
> 
> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Friday, June 10, 2016 10:39:07 AM
> >> Subject: Re: Feedback
> >>
> >>
> >>
> >> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
> >>> Bill,
> >>>
> >>> Got the authz stuff working with the adapters. It was a puzzle but I
> >>> think
> >>> I have something.
> >> Yeah, its nasty.  Every servlet container handlers security just a bit
> >> differently than others so, its ugly.
> >>
> >>> * I've discarded my own sub-types of AccessToken, they were redundant.
> >>> The
> >>> only difference between authz tokens and access tokens was a list of
> >>> permissions. And the concept behind them is the same. I've added a
> >>> "authorization" claim to AccessToken (null by default) from where
> >>> permissions granted by the server can be obtained.
> >> Is a claim better?
> > To represent a RPT, I believe it is.
> >
> >> Or should AccessTokenResponse optionally contain the RPT?
> > IMO, that would make things harder from a client perspective. See my next
> > comments.
> >
> >> Or optionally a query param for Implicit Flow?  Or have both?  I
> >> don't know.
> > I think we have two different things here:
> >
> > * How a RPT looks like
> > * How a RPT is obtained (the protocol in use)
> >
> > In the first case, a RPT is just a special type of access token with
> > authorization data on it. Where this data is a result of the evaluation of
> > permissions and authorization policies associated with the resources being
> > requested. Here, that claim represents this data. This is protocol
> > agnostic.
> >
> > The latter case is how you obtain that data, which is strongly associated
> > with the protocol in use. What you said makes a lot of sense, we can issue
> > this authorization data when doing any of the OAuth2 grant types. That can
> > be specially useful when you want to obtain all permissions for an user at
> > once when authenticating in KC, avoiding an additional call to the server
> > in order to obtain authorization specific data. One way to achieve that
> > would be a
> > "Entitlement Protocol Mapper" that is capable of decorating an access token
> > with the authorization data. Thus, transforming the access token into a
> > RPT. See, the client just use the final access token without any
> > additional treatment.
> >
> > There are a lot of other features to implement around both UMA and
> > Entitlement protocols. For instance, claims gathering or obligations. So
> > the server can ask the client for additional information. Eg.: require a
> > higher security level, etc. And for that, we must be able to obtain authz
> > data separately.
> 
> IIRC, there's a REST API right that allows a client to turn an access
> token into an RPT?  

Yes, that is what both Authorization and Entitlement API are meant for.

> So, if Client A gets an access token, it can invoke
> on Service B.  Service B can pass the access token to Keycloak to obtain
> an RPT?

Yes you can. The built-in policy enforcers (related with the changes I did to adapters) can operation in two modes:

* Bearer Token
* "Stateful" scenario (eg.: monolithic JEE apps)

In the first case, is up to the client to obtain and send the RPT with the necessary permissions to access protected resources on the resource server(Service B). Here you can use two protocols: UMA and Entitlement. You know UMA. Entitlement is just a more lightweight and 1-legged protocol based on some UMA concepts. It doesn't require permission tickets and stuff.

In the latter case, there is a specific policy enforcer that does exactly what you described. Obtaining a RPT transparently from a Keycloak server using the *Entitlement* API.

> 

From bburke at redhat.com  Fri Jun 10 11:43:51 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Jun 2016 11:43:51 -0400
Subject: [keycloak-dev] Feedback
In-Reply-To: <1920717619.17938110.1465572213044.JavaMail.zimbra@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<8d4a6320-b347-21f5-c070-d0fc917812c2@redhat.com>
	<1201145296.17057225.1465413130829.JavaMail.zimbra@redhat.com>
	<4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
	<1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>
	<a77d412a-a62b-69e8-5eaf-bee704680041@redhat.com>
	<862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>
	<9ac0a941-666f-15cb-2ff3-8598eaa94660@redhat.com>
	<1920717619.17938110.1465572213044.JavaMail.zimbra@redhat.com>
Message-ID: <573a2370-59f7-77ca-9544-acd47cfdc23e@redhat.com>



On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, June 10, 2016 12:11:37 PM
>> Subject: Re: Feedback
>>
>>
>>
>> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Friday, June 10, 2016 10:39:07 AM
>>>> Subject: Re: Feedback
>>>>
>>>>
>>>>
>>>> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
>>>>> Bill,
>>>>>
>>>>> Got the authz stuff working with the adapters. It was a puzzle but I
>>>>> think
>>>>> I have something.
>>>> Yeah, its nasty.  Every servlet container handlers security just a bit
>>>> differently than others so, its ugly.
>>>>
>>>>> * I've discarded my own sub-types of AccessToken, they were redundant.
>>>>> The
>>>>> only difference between authz tokens and access tokens was a list of
>>>>> permissions. And the concept behind them is the same. I've added a
>>>>> "authorization" claim to AccessToken (null by default) from where
>>>>> permissions granted by the server can be obtained.
>>>> Is a claim better?
>>> To represent a RPT, I believe it is.
>>>
>>>> Or should AccessTokenResponse optionally contain the RPT?
>>> IMO, that would make things harder from a client perspective. See my next
>>> comments.
>>>
>>>> Or optionally a query param for Implicit Flow?  Or have both?  I
>>>> don't know.
>>> I think we have two different things here:
>>>
>>> * How a RPT looks like
>>> * How a RPT is obtained (the protocol in use)
>>>
>>> In the first case, a RPT is just a special type of access token with
>>> authorization data on it. Where this data is a result of the evaluation of
>>> permissions and authorization policies associated with the resources being
>>> requested. Here, that claim represents this data. This is protocol
>>> agnostic.
>>>
>>> The latter case is how you obtain that data, which is strongly associated
>>> with the protocol in use. What you said makes a lot of sense, we can issue
>>> this authorization data when doing any of the OAuth2 grant types. That can
>>> be specially useful when you want to obtain all permissions for an user at
>>> once when authenticating in KC, avoiding an additional call to the server
>>> in order to obtain authorization specific data. One way to achieve that
>>> would be a
>>> "Entitlement Protocol Mapper" that is capable of decorating an access token
>>> with the authorization data. Thus, transforming the access token into a
>>> RPT. See, the client just use the final access token without any
>>> additional treatment.
>>>
>>> There are a lot of other features to implement around both UMA and
>>> Entitlement protocols. For instance, claims gathering or obligations. So
>>> the server can ask the client for additional information. Eg.: require a
>>> higher security level, etc. And for that, we must be able to obtain authz
>>> data separately.
>> IIRC, there's a REST API right that allows a client to turn an access
>> token into an RPT?
> Yes, that is what both Authorization and Entitlement API are meant for.
>
>> So, if Client A gets an access token, it can invoke
>> on Service B.  Service B can pass the access token to Keycloak to obtain
>> an RPT?
> Yes you can. The built-in policy enforcers (related with the changes I did to adapters) can operation in two modes:
>
> * Bearer Token
> * "Stateful" scenario (eg.: monolithic JEE apps)
>
> In the first case, is up to the client to obtain and send the RPT with the necessary permissions to access protected resources on the resource server(Service B). Here you can use two protocols: UMA and Entitlement. You know UMA. Entitlement is just a more lightweight and 1-legged protocol based on some UMA concepts. It doesn't require permission tickets and stuff.
>
> In the latter case, there is a specific policy enforcer that does exactly what you described. Obtaining a RPT transparently from a Keycloak server using the *Entitlement* API.
>
My only reasoning for wanting the option to include the RPT in the 
AccessTokenResponse was for performance reasons.  Obtaining an RPT could 
be obtained for free for a specific client by piggybacking on the OAuth 
protocol, but the access token could remain small/lightweight and not 
contain the RPT.  You'd still want to be able to include the RPT within 
the AT if so desired, but there might come a point when the AT becomes 
too fat.

All this isn't really important at this time though.  What's more 
important is releasing Authz soon.  I just foresese us wanting to 
provide different optimizations for different environments.

Bill




From psilva at redhat.com  Fri Jun 10 11:55:39 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 10 Jun 2016 11:55:39 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <573a2370-59f7-77ca-9544-acd47cfdc23e@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<4d63afab-b5a8-885c-b194-972ea934129b@redhat.com>
	<1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>
	<a77d412a-a62b-69e8-5eaf-bee704680041@redhat.com>
	<862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>
	<9ac0a941-666f-15cb-2ff3-8598eaa94660@redhat.com>
	<1920717619.17938110.1465572213044.JavaMail.zimbra@redhat.com>
	<573a2370-59f7-77ca-9544-acd47cfdc23e@redhat.com>
Message-ID: <1456138264.17954317.1465574139108.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, June 10, 2016 12:43:51 PM
> Subject: Re: Feedback
> 
> 
> 
> On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Friday, June 10, 2016 12:11:37 PM
> >> Subject: Re: Feedback
> >>
> >>
> >>
> >> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Friday, June 10, 2016 10:39:07 AM
> >>>> Subject: Re: Feedback
> >>>>
> >>>>
> >>>>
> >>>> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
> >>>>> Bill,
> >>>>>
> >>>>> Got the authz stuff working with the adapters. It was a puzzle but I
> >>>>> think
> >>>>> I have something.
> >>>> Yeah, its nasty.  Every servlet container handlers security just a bit
> >>>> differently than others so, its ugly.
> >>>>
> >>>>> * I've discarded my own sub-types of AccessToken, they were redundant.
> >>>>> The
> >>>>> only difference between authz tokens and access tokens was a list of
> >>>>> permissions. And the concept behind them is the same. I've added a
> >>>>> "authorization" claim to AccessToken (null by default) from where
> >>>>> permissions granted by the server can be obtained.
> >>>> Is a claim better?
> >>> To represent a RPT, I believe it is.
> >>>
> >>>> Or should AccessTokenResponse optionally contain the RPT?
> >>> IMO, that would make things harder from a client perspective. See my next
> >>> comments.
> >>>
> >>>> Or optionally a query param for Implicit Flow?  Or have both?  I
> >>>> don't know.
> >>> I think we have two different things here:
> >>>
> >>> * How a RPT looks like
> >>> * How a RPT is obtained (the protocol in use)
> >>>
> >>> In the first case, a RPT is just a special type of access token with
> >>> authorization data on it. Where this data is a result of the evaluation
> >>> of
> >>> permissions and authorization policies associated with the resources
> >>> being
> >>> requested. Here, that claim represents this data. This is protocol
> >>> agnostic.
> >>>
> >>> The latter case is how you obtain that data, which is strongly associated
> >>> with the protocol in use. What you said makes a lot of sense, we can
> >>> issue
> >>> this authorization data when doing any of the OAuth2 grant types. That
> >>> can
> >>> be specially useful when you want to obtain all permissions for an user
> >>> at
> >>> once when authenticating in KC, avoiding an additional call to the server
> >>> in order to obtain authorization specific data. One way to achieve that
> >>> would be a
> >>> "Entitlement Protocol Mapper" that is capable of decorating an access
> >>> token
> >>> with the authorization data. Thus, transforming the access token into a
> >>> RPT. See, the client just use the final access token without any
> >>> additional treatment.
> >>>
> >>> There are a lot of other features to implement around both UMA and
> >>> Entitlement protocols. For instance, claims gathering or obligations. So
> >>> the server can ask the client for additional information. Eg.: require a
> >>> higher security level, etc. And for that, we must be able to obtain authz
> >>> data separately.
> >> IIRC, there's a REST API right that allows a client to turn an access
> >> token into an RPT?
> > Yes, that is what both Authorization and Entitlement API are meant for.
> >
> >> So, if Client A gets an access token, it can invoke
> >> on Service B.  Service B can pass the access token to Keycloak to obtain
> >> an RPT?
> > Yes you can. The built-in policy enforcers (related with the changes I did
> > to adapters) can operation in two modes:
> >
> > * Bearer Token
> > * "Stateful" scenario (eg.: monolithic JEE apps)
> >
> > In the first case, is up to the client to obtain and send the RPT with the
> > necessary permissions to access protected resources on the resource
> > server(Service B). Here you can use two protocols: UMA and Entitlement.
> > You know UMA. Entitlement is just a more lightweight and 1-legged protocol
> > based on some UMA concepts. It doesn't require permission tickets and
> > stuff.
> >
> > In the latter case, there is a specific policy enforcer that does exactly
> > what you described. Obtaining a RPT transparently from a Keycloak server
> > using the *Entitlement* API.
> >
> My only reasoning for wanting the option to include the RPT in the
> AccessTokenResponse was for performance reasons.  Obtaining an RPT could
> be obtained for free for a specific client by piggybacking on the OAuth
> protocol, but the access token could remain small/lightweight and not
> contain the RPT.  You'd still want to be able to include the RPT within
> the AT if so desired, but there might come a point when the AT becomes
> too fat.
> 
> All this isn't really important at this time though.  What's more
> important is releasing Authz soon.  I just foresese us wanting to
> provide different optimizations for different environments.
> 
> Bill

+1. And that is the reason why I'm following this path now. So far, I was using a very specific token to hold authz data. But as you said, let's discuss about performance and optimizations at the appropriate time and release this stuff first. We can do a lot of things at this regard.

Regarding token size, during this work I did a research about this topic and there are interesting discussions on OAuth2-WG.

Thanks for all feedback, it was really important to improve things.

> 
> 
> 
> 

From sthorger at redhat.com  Mon Jun 13 02:56:30 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jun 2016 08:56:30 +0200
Subject: [keycloak-dev] Exception handling for own REST API - is it
 possible to register own javax.ws.rs.ext.ExceptionMapper?
In-Reply-To: <575947FE.7030808@redhat.com>
References: <575947FE.7030808@redhat.com>
Message-ID: <CAJgngAfpQnbEuX3fHO70f6s1eA0kd=Dzd7gUinz-pQ0g6A9Keg@mail.gmail.com>

Providers would also need to be registered in KeycloakApplication. We don't
support that at the moment at least. You could add try/catch to your code
and return an extension of WebApplicationException [1]. That way you can
define how the response should look like.

[1]
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/ErrorResponseException.java

On 9 June 2016 at 12:42, Vlastimil Elias <velias at redhat.com> wrote:

> Hi,
>
> I'm implementing my own REST endpoint using RealmResourceProvider and I'm
> thinking how to perform error handling (which is not covered in example).
> Is it possible to register my javax.ws.rs.ext.ExceptionMapper subclass to
> handle my exceptions? I tried to add subclass of it annotated with
> javax.ws.rs.ext.Provider into my code but it is not used.
> I get common error page with:
>
> *Stack Trace*
> org.jboss.resteasy.spi.UnhandledException:
> com.redhat.developer.keycloak.rest.InvalidParametersException: email param
> must be specified
>
> Thansk in advance.
>
> Vlastimil
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Red Hat Developer | Engineering
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160613/c30bc527/attachment.html 

From sthorger at redhat.com  Mon Jun 13 02:59:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jun 2016 08:59:43 +0200
Subject: [keycloak-dev] Exception when using JAXB in keycloak
In-Reply-To: <BAY172-W28F3E3DBA9FA342328B06BBE5F0@phx.gbl>
References: <BAY172-W28F3E3DBA9FA342328B06BBE5F0@phx.gbl>
Message-ID: <CAJgngAdmravixO0oMSnTm4wKw8gV9DJinbZsYKpVd1GVynr5=Q@mail.gmail.com>

Is this in a custom provider (what SPI?)? If so you should deploy it as a
module (see docs for details) and also do a Google search for what
dependency is needed.

On 9 June 2016 at 22:46, Eric Son 3016 <desk3016 at live.com> wrote:

> Hi, I was trying to use JAXB in the keycloak and I have got the
> ClassNotFoundException
>
> 2016-06-09 20:19:40,514 INFO  [stdout] (default task-2) Failed to create
> marshalled xmlString: javax.xml.bind.JAXBException
> 2016-06-09 20:19:40,515 INFO  [stdout] (default task-2)  - with linked
> exception:
> 2016-06-09 20:19:40,515 INFO  [stdout] (default task-2)
> [java.lang.ClassNotFoundException:
> com.sun.xml.internal.bind.v2.ContextFactory from [Module
> "deployment.keycloak-server.war:main" from Service Module Loader]]
>
> when the code is doing
> JAXBContext jaxbContext = JAXBContext.newInstance(Class A);
>
> is it because of keycloak is using openJDK instead of oracle JDK?
>
> Since, on my eclipse, the project includes the JRE system library that has
> rt.jar containing* com.sun.xml.internal.bind.v2.ContextFactory* class
> and was able to compile the project with no issue but it only happens when
> keycloak war is deployed.
>
> I borrow some idea from below link, (the same thing happens for*
> com.sun.net.ssl.internal.ssl.provider* with JRE system library's jsse.jar)
>
> http://stackoverflow.com/questions/11289860/deploy-time-error-java-lang-noclassdeffounderror-com-sun-net-ssl-internal-ssl
>
> basically, I created a jboss-deployment-structure.xml file into the
> WEB-INF/ and imported the system module dependency into module.xml under
> JBOSS_HOME\modules\system\layers\base\sun\jdk\main\ but it didn't help.
>
>
> Has anyone run into this issue? Any suggestion will be appreciated.
>
> Thanks a lot!
>
> Best Regards,
>
> WJ
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160613/6aa4a37c/attachment.html 

From mposolda at redhat.com  Mon Jun 13 03:39:48 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 13 Jun 2016 09:39:48 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
Message-ID: <575E6344.3000605@redhat.com>

We discussed some time ago how to ensure that UserFederationProvider 
lifecycle is properly tight to KeycloakSession 
http://lists.jboss.org/pipermail/keycloak-dev/2016-April/007123.html . 
The last we discussed was to add new method on KeycloakSession like:

<T extends Provider> T getProvider(Class<T> clazz, String id, String 
instanceId);

where instanceId is the state associated with the provider (in case of 
UserFederationProvider it will be DB ID of 
UserFederationProviderModelId). That way, the 
UserFederationProviderFactory.create can load the 
UserFederationProviderModel (assumption is that RealmModel is available 
in KeycloakContext, so UserFederationProviderFactory.create has access 
to RealmModel + providerDatabaseId to load it from DB).

In the thread, you can see that I've initially proposed something 
similar to your proposal, but it's a bit more complex though. Hopefully 
going "simple" way and adding just the method with "instanceId" String 
argument can solve the issue.

Marek

On 10/06/16 01:36, Ariel Carrera wrote:
> There is not problem! :)
> One more thing, I solved the problem of multiple "federation provider" 
> instances, adding this code to the DefaultKeycloakSession (and the 
> method definition in KeycloakSession interface):
>
>     public <T extends Provider> void registerProvider(Class<T> clazz,
>     Provider provider, String id) {
>             Integer hash = clazz.hashCode() + id.hashCode();
>             providers.put(hash, provider);
>         }
>
>
> And into MyUserFederationProviderFactory.getInstance(session, model) 
> something like this:
>
>     public UserFederationProvider getInstance(KeycloakSession session,
>     UserFederationProviderModel model){
>     UserFederationProvider provider = (UserFederationProvider)
>     session.getProvider(UserFederationProvider.class, model.getId());
>     if (provider == null){
>     lazyInit(session);
>         provider = new MyUserFederationProvider(session, model,
>     config, ......);
>     ((KeycloakSession)session).registerProvider(UserFederationProvider.class,
>     provider, model.getId());
>     };
>             return provider;
>         }
>
>
> After a few tests and debug it seems to work... creating, catching, 
> and closing provider instances as expected.
>
>
> In future versions as you said, maybe would be better include a way to 
> instantiate a complex object/provider instead of doing
>
>     ProviderFactory.create(KeycloakSession session)
>     some kind of method like
>     ProviderFactory.create(KeycloakSession session, Object... obj);
>
> and the appropriate method into the KeycloakSession
>
>     <T extends Provider> T getProvider(Class<T> clazz, Object... obj);
>     <T extends Provider> T getProvider(Class<T> clazz, String id,
>     Object... obj);
>
>
> And why not a map into the keycloakSession to store some additional 
> context data to share between providers during same request? It's only 
> a vague idea
>
> Regards!
>
> 2016-06-09 17:14 GMT-03:00 Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>>:
>
>     Its gonna be awhile.  Its going to be difficult to make everything
>     both backward compatible and cover all the current and future use
>     cases we need to cover.  Listen on the dev list.  I should post
>     some info soon on what the new impl will look like.
>
>
>     On 6/9/16 3:57 PM, Ariel Carrera wrote:
>>     Yes Bill, exactly! I will waiting to test it Thanks!
>>
>>     2016-06-09 16:29 GMT-03:00 Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>>:
>>
>>
>>
>>         On 6/9/16 2:52 PM, Ariel Carrera wrote:
>>
>>             Hi Bill, is a little expensive for me because I am
>>             creating a new entity manager to connect with a legacy
>>             database, and creating/enlisting a transaction per instance.
>>             For example in a simple flow case where a user needs to
>>             click "I forgot my password" link to recover the
>>             password, there is more than nine or ten instances
>>             created to do this. It's really not a big problem but I
>>             think that is not necessary and can be implemented like
>>             others spi providers catched into the keycloak session.
>>
>>         This is good feedback.  We need a way to associate a
>>         provider, by name, to the KeycloakSession.  Maybe we just
>>         need a way to associate anything with the KeycloakSession period.
>>
>>             In my case, another difficulty is synchronization between
>>             an old authentication system and keycloak implemented on
>>             demand (there is no full/partial syncrhonization because
>>             the legacy system is still working and need to work
>>             together for a while). Also I implemented synchronization
>>             support but at this moment it not used.
>>             Every time that keycloak needs to validate a user
>>             (isValid) recovered from the user storage or cache, a
>>             query to the legacy system is made. Added to this... I
>>             need to recover some attributes and roles changes
>>             produced on the legacy system.... so I decided to
>>             implement a "user federation cache" with a short term
>>             expiration to improve the performance with certain
>>             synchronization delay tolerance.
>>
>>             In a few words I have: a custom User Federation Provider
>>             + on deman synchronization + a user Federation Provider
>>             Cache (my own cache SPI).
>>
>>             Maybe an optional spi to obtain a custom container from
>>             infinispan could be a good choice to add to the new
>>             implementation and provide another one tool to do things
>>             with better performance.
>>
>>         I think the new model might solve your caching needs.  There
>>         will be no importing by default.  This means no synching,
>>         etc.  Keycloak will only store metadata that your user store
>>         can't provide.  User Federation Providers will work just as
>>         the default Keycloak user store and user cache.
>>
>>
>>
>>
>>     -- 
>>     Tat?
>
>
>
>
> -- 
> Tat?
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Mon Jun 13 04:19:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jun 2016 10:19:35 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <575E6344.3000605@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
Message-ID: <CAJgngAfOfJ2R7iZXqtxNsmHxa-jOLSpY=Rk+SEhT17M3D-FV-w@mail.gmail.com>

I've never been a fan of how creating user feds outside of the session was
done. It's a completely broken concept and has several flaws:

a) KeycloakSession doesn't manage instances - we have issues with both
multiple instances being created as well as instances not being closed.
b) The code that requires an instance needs to know how to create one
c) No way to create a custom way to configure/setup - the model approach
may work for some, but what if a custom provider wants to store config
differently

With that in mind this needs to be fix and not monkey patched.

When requesting an instance of a user federation it should be:

session.getProvider(UserFederationProvider.class, String instanceId)

That's it. It would then be up to the factory of figuring out how to
instantiate it, not the calling code.

On 13 June 2016 at 09:39, Marek Posolda <mposolda at redhat.com> wrote:

> We discussed some time ago how to ensure that UserFederationProvider
> lifecycle is properly tight to KeycloakSession
> http://lists.jboss.org/pipermail/keycloak-dev/2016-April/007123.html .
> The last we discussed was to add new method on KeycloakSession like:
>
> <T extends Provider> T getProvider(Class<T> clazz, String id, String
> instanceId);
>
> where instanceId is the state associated with the provider (in case of
> UserFederationProvider it will be DB ID of UserFederationProviderModelId).
> That way, the UserFederationProviderFactory.create can load the
> UserFederationProviderModel (assumption is that RealmModel is available in
> KeycloakContext, so UserFederationProviderFactory.create has access to
> RealmModel + providerDatabaseId to load it from DB).
>
> In the thread, you can see that I've initially proposed something similar
> to your proposal, but it's a bit more complex though. Hopefully going
> "simple" way and adding just the method with "instanceId" String argument
> can solve the issue.
>
> Marek
>
>
> On 10/06/16 01:36, Ariel Carrera wrote:
>
> There is not problem! :)
> One more thing, I solved the problem of multiple "federation provider"
> instances, adding this code to the DefaultKeycloakSession (and the method
> definition in KeycloakSession interface):
>
>
>> public <T extends Provider> void registerProvider(Class<T> clazz,
>> Provider provider, String id) {
>>         Integer hash = clazz.hashCode() + id.hashCode();
>>         providers.put(hash, provider);
>>     }
>
>
> And into MyUserFederationProviderFactory.getInstance(session, model)
> something like this:
>
> public UserFederationProvider getInstance(KeycloakSession session,
>> UserFederationProviderModel model){
>> UserFederationProvider provider = (UserFederationProvider)
>> session.getProvider(UserFederationProvider.class, model.getId());
>> if (provider == null){
>> lazyInit(session);
>>                 provider = new MyUserFederationProvider(session, model,
>> config, ......);
>>
>> ((KeycloakSession)session).registerProvider(UserFederationProvider.class,
>> provider, model.getId());
>> };
>>         return provider;
>>     }
>
>
> After a few tests and debug it seems to work... creating, catching, and
> closing provider instances as expected.
>
>
> In future versions as you said, maybe would be better include a way to
> instantiate a complex object/provider instead of doing
>
>> ProviderFactory.create(KeycloakSession session)
>> some kind of method like
>> ProviderFactory.create(KeycloakSession session, Object... obj);
>
> and the appropriate method into the KeycloakSession
>
>> <T extends Provider> T getProvider(Class<T> clazz, Object... obj);
>> <T extends Provider> T getProvider(Class<T> clazz, String id, Object...
>> obj);
>
>
> And why not a map into the keycloakSession to store some additional
> context data to share between providers during same request? It's only a
> vague idea
>
> Regards!
>
> 2016-06-09 17:14 GMT-03:00 Bill Burke <bburke at redhat.com>:
>
>> Its gonna be awhile.  Its going to be difficult to make everything both
>> backward compatible and cover all the current and future use cases we need
>> to cover.  Listen on the dev list.  I should post some info soon on what
>> the new impl will look like.
>>
>> On 6/9/16 3:57 PM, Ariel Carrera wrote:
>>
>> Yes Bill, exactly! I will waiting to test it Thanks!
>>
>> 2016-06-09 16:29 GMT-03:00 Bill Burke < <bburke at redhat.com>
>> bburke at redhat.com>:
>>
>>>
>>>
>>> On 6/9/16 2:52 PM, Ariel Carrera wrote:
>>>
>>>> Hi Bill, is a little expensive for me because I am creating a new
>>>> entity manager to connect with a legacy database, and creating/enlisting a
>>>> transaction per instance.
>>>> For example in a simple flow case where a user needs to click "I forgot
>>>> my password" link to recover the password, there is more than nine or ten
>>>> instances created to do this. It's really not a big problem but I think
>>>> that is not necessary and can be implemented like others spi providers
>>>> catched into the keycloak session.
>>>>
>>>> This is good feedback.  We need a way to associate a provider, by name,
>>> to the KeycloakSession.  Maybe we just need a way to associate anything
>>> with the KeycloakSession period.
>>>
>>> In my case, another difficulty is synchronization between an old
>>>> authentication system and keycloak implemented on demand (there is no
>>>> full/partial syncrhonization because the legacy system is still working and
>>>> need to work together for a while). Also I implemented synchronization
>>>> support but at this moment it not used.
>>>> Every time that keycloak needs to validate a user (isValid) recovered
>>>> from the user storage or cache, a query to the legacy system is made. Added
>>>> to this... I need to recover some attributes and roles changes produced on
>>>> the legacy system.... so I decided to implement a "user federation cache"
>>>> with a short term expiration to improve the performance with certain
>>>> synchronization delay tolerance.
>>>>
>>>> In a few words I have: a custom User Federation Provider + on deman
>>>> synchronization + a user Federation Provider Cache (my own cache SPI).
>>>>
>>>> Maybe an optional spi to obtain a custom container from infinispan
>>>> could be a good choice to add to the new implementation and provide another
>>>> one tool to do things with better performance.
>>>>
>>>> I think the new model might solve your caching needs.  There will be no
>>> importing by default.  This means no synching, etc.  Keycloak will only
>>> store metadata that your user store can't provide.  User Federation
>>> Providers will work just as the default Keycloak user store and user cache.
>>>
>>>
>>
>>
>> --
>> Tat?
>>
>>
>>
>
>
> --
> Tat?
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160613/079aae9d/attachment.html 

From velias at redhat.com  Mon Jun 13 04:33:18 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Mon, 13 Jun 2016 10:33:18 +0200
Subject: [keycloak-dev] Exception handling for own REST API - is it
 possible to register own javax.ws.rs.ext.ExceptionMapper?
In-Reply-To: <CAJgngAfpQnbEuX3fHO70f6s1eA0kd=Dzd7gUinz-pQ0g6A9Keg@mail.gmail.com>
References: <575947FE.7030808@redhat.com>
	<CAJgngAfpQnbEuX3fHO70f6s1eA0kd=Dzd7gUinz-pQ0g6A9Keg@mail.gmail.com>
Message-ID: <575E6FCE.6070301@redhat.com>

Thanks, looks good. Maybe your REST example should be extended to 
contain example of error handling using this exception.

Cheers

Vlastimil


On 13.6.2016 08:56, Stian Thorgersen wrote:
> Providers would also need to be registered in KeycloakApplication. We 
> don't support that at the moment at least. You could add try/catch to 
> your code and return an extension of WebApplicationException [1]. That 
> way you can define how the response should look like.
>
> [1] 
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/ErrorResponseException.java
>
> On 9 June 2016 at 12:42, Vlastimil Elias <velias at redhat.com 
> <mailto:velias at redhat.com>> wrote:
>
>     Hi,
>
>     I'm implementing my own REST endpoint using RealmResourceProvider
>     and I'm thinking how to perform error handling (which is not
>     covered in example).
>     Is it possible to register my javax.ws.rs.ext.ExceptionMapper
>     subclass to handle my exceptions? I tried to add subclass of it
>     annotated with javax.ws.rs.ext.Provider into my code but it is not
>     used.
>     I get common error page with:
>
>     *Stack Trace*
>     org.jboss.resteasy.spi.UnhandledException:
>     com.redhat.developer.keycloak.rest.InvalidParametersException:
>     email param must be specified
>
>     Thansk in advance.
>
>     Vlastimil
>
>     -- 
>     Vlastimil Elias
>     Principal Software Engineer
>     Red Hat Developer | Engineering
>
>
>     _______________________________________________
>     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
>
>

-- 
Vlastimil Elias
Principal Software Engineer
Red Hat Developer | Engineering

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

From bburke at redhat.com  Mon Jun 13 08:56:34 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Jun 2016 08:56:34 -0400
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <575E6344.3000605@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
Message-ID: <96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>

I'm working on a new SPI right now.  Here is my notebad to capture how 
things work, issues weed to consider, and problems we have to solve:

https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI


On 6/13/16 3:39 AM, Marek Posolda wrote:
> We discussed some time ago how to ensure that UserFederationProvider 
> lifecycle is properly tight to KeycloakSession 
> http://lists.jboss.org/pipermail/keycloak-dev/2016-April/007123.html . 
> The last we discussed was to add new method on KeycloakSession like:
>
> <T extends Provider> T getProvider(Class<T> clazz, String id, String 
> instanceId);
>
> where instanceId is the state associated with the provider (in case of 
> UserFederationProvider it will be DB ID of 
> UserFederationProviderModelId). That way, the 
> UserFederationProviderFactory.create can load the 
> UserFederationProviderModel (assumption is that RealmModel is 
> available in KeycloakContext, so UserFederationProviderFactory.create 
> has access to RealmModel + providerDatabaseId to load it from DB).
>
> In the thread, you can see that I've initially proposed something 
> similar to your proposal, but it's a bit more complex though. 
> Hopefully going "simple" way and adding just the method with 
> "instanceId" String argument can solve the issue.
>
> Marek
>
> On 10/06/16 01:36, Ariel Carrera wrote:
>> There is not problem! :)
>> One more thing, I solved the problem of multiple "federation 
>> provider" instances, adding this code to the DefaultKeycloakSession 
>> (and the method definition in KeycloakSession interface):
>>
>>     public <T extends Provider> void registerProvider(Class<T> clazz,
>>     Provider provider, String id) {
>>             Integer hash = clazz.hashCode() + id.hashCode();
>>             providers.put(hash, provider);
>>         }
>>
>>
>> And into MyUserFederationProviderFactory.getInstance(session, model) 
>> something like this:
>>
>>     public UserFederationProvider getInstance(KeycloakSession
>>     session, UserFederationProviderModel model){
>>     UserFederationProvider provider = (UserFederationProvider)
>>     session.getProvider(UserFederationProvider.class, model.getId());
>>     if (provider == null){
>>     lazyInit(session);
>>           provider = new MyUserFederationProvider(session, model,
>>     config, ......);
>>     ((KeycloakSession)session).registerProvider(UserFederationProvider.class,
>>     provider, model.getId());
>>     };
>>             return provider;
>>         }
>>
>>
>> After a few tests and debug it seems to work... creating, catching, 
>> and closing provider instances as expected.
>>
>>
>> In future versions as you said, maybe would be better include a way 
>> to instantiate a complex object/provider instead of doing
>>
>>     ProviderFactory.create(KeycloakSession session)
>>     some kind of method like
>>     ProviderFactory.create(KeycloakSession session, Object... obj);
>>
>> and the appropriate method into the KeycloakSession
>>
>>     <T extends Provider> T getProvider(Class<T> clazz, Object... obj);
>>     <T extends Provider> T getProvider(Class<T> clazz, String id,
>>     Object... obj);
>>
>>
>> And why not a map into the keycloakSession to store some additional 
>> context data to share between providers during same request? It's 
>> only a vague idea
>>
>> Regards!
>>
>> 2016-06-09 17:14 GMT-03:00 Bill Burke <bburke at redhat.com 
>> <mailto:bburke at redhat.com>>:
>>
>>     Its gonna be awhile.  Its going to be difficult to make
>>     everything both backward compatible and cover all the current and
>>     future use cases we need to cover.  Listen on the dev list.  I
>>     should post some info soon on what the new impl will look like.
>>
>>
>>     On 6/9/16 3:57 PM, Ariel Carrera wrote:
>>>     Yes Bill, exactly! I will waiting to test it Thanks!
>>>
>>>     2016-06-09 16:29 GMT-03:00 Bill Burke <bburke at redhat.com>:
>>>
>>>
>>>
>>>         On 6/9/16 2:52 PM, Ariel Carrera wrote:
>>>
>>>             Hi Bill, is a little expensive for me because I am
>>>             creating a new entity manager to connect with a legacy
>>>             database, and creating/enlisting a transaction per instance.
>>>             For example in a simple flow case where a user needs to
>>>             click "I forgot my password" link to recover the
>>>             password, there is more than nine or ten instances
>>>             created to do this. It's really not a big problem but I
>>>             think that is not necessary and can be implemented like
>>>             others spi providers catched into the keycloak session.
>>>
>>>         This is good feedback.  We need a way to associate a
>>>         provider, by name, to the KeycloakSession.  Maybe we just
>>>         need a way to associate anything with the KeycloakSession
>>>         period.
>>>
>>>             In my case, another difficulty is synchronization
>>>             between an old authentication system and keycloak
>>>             implemented on demand (there is no full/partial
>>>             syncrhonization because the legacy system is still
>>>             working and need to work together for a while). Also I
>>>             implemented synchronization support but at this moment
>>>             it not used.
>>>             Every time that keycloak needs to validate a user
>>>             (isValid) recovered from the user storage or cache, a
>>>             query to the legacy system is made. Added to this... I
>>>             need to recover some attributes and roles changes
>>>             produced on the legacy system.... so I decided to
>>>             implement a "user federation cache" with a short term
>>>             expiration to improve the performance with certain
>>>             synchronization delay tolerance.
>>>
>>>             In a few words I have: a custom User Federation Provider
>>>             + on deman synchronization + a user Federation Provider
>>>             Cache (my own cache SPI).
>>>
>>>             Maybe an optional spi to obtain a custom container from
>>>             infinispan could be a good choice to add to the new
>>>             implementation and provide another one tool to do things
>>>             with better performance.
>>>
>>>         I think the new model might solve your caching needs.  There
>>>         will be no importing by default.  This means no synching,
>>>         etc.  Keycloak will only store metadata that your user store
>>>         can't provide.  User Federation Providers will work just as
>>>         the default Keycloak user store and user cache.
>>>
>>>
>>>
>>>
>>>     -- 
>>>     Tat?
>>
>>
>>
>>
>> -- 
>> Tat?
>>
>>
>> _______________________________________________
>> 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

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

From bburke at redhat.com  Mon Jun 13 09:06:12 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Jun 2016 09:06:12 -0400
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <CAJgngAfOfJ2R7iZXqtxNsmHxa-jOLSpY=Rk+SEhT17M3D-FV-w@mail.gmail.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<CAJgngAfOfJ2R7iZXqtxNsmHxa-jOLSpY=Rk+SEhT17M3D-FV-w@mail.gmail.com>
Message-ID: <85ec7a78-53ee-697c-80f5-7bf426c31b12@redhat.com>



On 6/13/16 4:19 AM, Stian Thorgersen wrote:
> I've never been a fan of how creating user feds outside of the session 
> was done. It's a completely broken concept and has several flaws:
>
> a) KeycloakSession doesn't manage instances - we have issues with both 
> multiple instances being created as well as instances not being closed.
> b) The code that requires an instance needs to know how to create one
> c) No way to create a custom way to configure/setup - the model 
> approach may work for some, but what if a custom provider wants to 
> store config differently
>
> With that in mind this needs to be fix and not monkey patched.
>
> When requesting an instance of a user federation it should be:
>
> session.getProvider(UserFederationProvider.class, String instanceId)
>



> That's it. It would then be up to the factory of figuring out how to 
> instantiate it, not the calling code.
>
A user fed provider is often a generic thing that can be configured 
multiple times for multiple different stores (i.e. LDAP).  So, the model 
is a must.  We don't want people configuring fed providers within 
keycloak-server.json

Model will be used by most (all) providers so it needs to be a parameter 
for creation.  This generic getProvider() method on KeycloakSession just 
doesn't fit for most situations.  Most mappers fall into this category 
too.  I have thought about defining a generic ConfigurationModel and 
datastore that would be used by everything (mappers, fed providers, etc.)

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

From sthorger at redhat.com  Mon Jun 13 09:13:13 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jun 2016 15:13:13 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <85ec7a78-53ee-697c-80f5-7bf426c31b12@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<CAJgngAfOfJ2R7iZXqtxNsmHxa-jOLSpY=Rk+SEhT17M3D-FV-w@mail.gmail.com>
	<85ec7a78-53ee-697c-80f5-7bf426c31b12@redhat.com>
Message-ID: <CAJgngAd28j_AuMk8pjSd-uSJ0M+765SkPUGBwmEUVASzgHon+g@mail.gmail.com>

On 13 June 2016 at 15:06, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 6/13/16 4:19 AM, Stian Thorgersen wrote:
>
> I've never been a fan of how creating user feds outside of the session was
> done. It's a completely broken concept and has several flaws:
>
> a) KeycloakSession doesn't manage instances - we have issues with both
> multiple instances being created as well as instances not being closed.
> b) The code that requires an instance needs to know how to create one
> c) No way to create a custom way to configure/setup - the model approach
> may work for some, but what if a custom provider wants to store config
> differently
>
> With that in mind this needs to be fix and not monkey patched.
>
> When requesting an instance of a user federation it should be:
>
> session.getProvider(UserFederationProvider.class, String instanceId)
>
>
>
>
> That's it. It would then be up to the factory of figuring out how to
> instantiate it, not the calling code.
>
> A user fed provider is often a generic thing that can be configured
> multiple times for multiple different stores (i.e. LDAP).  So, the model is
> a must.  We don't want people configuring fed providers within
> keycloak-server.json
>
> Model will be used by most (all) providers so it needs to be a parameter
> for creation.  This generic getProvider() method on KeycloakSession just
> doesn't fit for most situations.  Most mappers fall into this category
> too.  I have thought about defining a generic ConfigurationModel and
> datastore that would be used by everything (mappers, fed providers, etc.)
>

Yes, I know. Please read the thread me and Marek and when we discussed
this. This really has to be sorted out otherwise we'll continue to have
issues with it.


>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160613/32992723/attachment.html 

From bburke at redhat.com  Mon Jun 13 10:00:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Jun 2016 10:00:49 -0400
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <CAJgngAd28j_AuMk8pjSd-uSJ0M+765SkPUGBwmEUVASzgHon+g@mail.gmail.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<CAJgngAfOfJ2R7iZXqtxNsmHxa-jOLSpY=Rk+SEhT17M3D-FV-w@mail.gmail.com>
	<85ec7a78-53ee-697c-80f5-7bf426c31b12@redhat.com>
	<CAJgngAd28j_AuMk8pjSd-uSJ0M+765SkPUGBwmEUVASzgHon+g@mail.gmail.com>
Message-ID: <cb1480a2-c180-9b97-f8df-b5a67d716d65@redhat.com>



On 6/13/16 9:13 AM, Stian Thorgersen wrote:
>
>
> On 13 June 2016 at 15:06, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 6/13/16 4:19 AM, Stian Thorgersen wrote:
>>     I've never been a fan of how creating user feds outside of the
>>     session was done. It's a completely broken concept and has
>>     several flaws:
>>
>>     a) KeycloakSession doesn't manage instances - we have issues with
>>     both multiple instances being created as well as instances not
>>     being closed.
>>     b) The code that requires an instance needs to know how to create one
>>     c) No way to create a custom way to configure/setup - the model
>>     approach may work for some, but what if a custom provider wants
>>     to store config differently
>>
>>     With that in mind this needs to be fix and not monkey patched.
>>
>>     When requesting an instance of a user federation it should be:
>>
>>     session.getProvider(UserFederationProvider.class, String instanceId)
>>
>
>
>
>>     That's it. It would then be up to the factory of figuring out how
>>     to instantiate it, not the calling code.
>>
>     A user fed provider is often a generic thing that can be
>     configured multiple times for multiple different stores (i.e.
>     LDAP).  So, the model is a must. We don't want people configuring
>     fed providers within keycloak-server.json
>
>     Model will be used by most (all) providers so it needs to be a
>     parameter for creation.  This generic getProvider() method on
>     KeycloakSession just doesn't fit for most situations.  Most
>     mappers fall into this category too.  I have thought about
>     defining a generic ConfigurationModel and datastore that would be
>     used by everything (mappers, fed providers, etc.)
>
>
> Yes, I know. Please read the thread me and Marek and when we discussed 
> this. This really has to be sorted out otherwise we'll continue to 
> have issues with it.

I read it.  Summary is that you need to be able to associate one 
instance per session and the ability for it to be closed when session 
ends.  As long as we don't think some implementation will want an 
instance per method call on the provider, then all this can probably be 
done automatically.

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

From sthorger at redhat.com  Mon Jun 13 10:04:06 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jun 2016 16:04:06 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <cb1480a2-c180-9b97-f8df-b5a67d716d65@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<CAJgngAfOfJ2R7iZXqtxNsmHxa-jOLSpY=Rk+SEhT17M3D-FV-w@mail.gmail.com>
	<85ec7a78-53ee-697c-80f5-7bf426c31b12@redhat.com>
	<CAJgngAd28j_AuMk8pjSd-uSJ0M+765SkPUGBwmEUVASzgHon+g@mail.gmail.com>
	<cb1480a2-c180-9b97-f8df-b5a67d716d65@redhat.com>
Message-ID: <CAJgngAcU2OLzhZ4s2VuSOTYxoJyJ2_+JB04jVgWVyGHKF234kA@mail.gmail.com>

On 13 June 2016 at 16:00, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 6/13/16 9:13 AM, Stian Thorgersen wrote:
>
>
>
> On 13 June 2016 at 15:06, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 6/13/16 4:19 AM, Stian Thorgersen wrote:
>>
>> I've never been a fan of how creating user feds outside of the session
>> was done. It's a completely broken concept and has several flaws:
>>
>> a) KeycloakSession doesn't manage instances - we have issues with both
>> multiple instances being created as well as instances not being closed.
>> b) The code that requires an instance needs to know how to create one
>> c) No way to create a custom way to configure/setup - the model approach
>> may work for some, but what if a custom provider wants to store config
>> differently
>>
>> With that in mind this needs to be fix and not monkey patched.
>>
>> When requesting an instance of a user federation it should be:
>>
>> session.getProvider(UserFederationProvider.class, String instanceId)
>>
>>
>>
>>
>> That's it. It would then be up to the factory of figuring out how to
>> instantiate it, not the calling code.
>>
>> A user fed provider is often a generic thing that can be configured
>> multiple times for multiple different stores (i.e. LDAP).  So, the model is
>> a must.  We don't want people configuring fed providers within
>> keycloak-server.json
>>
>> Model will be used by most (all) providers so it needs to be a parameter
>> for creation.  This generic getProvider() method on KeycloakSession just
>> doesn't fit for most situations.  Most mappers fall into this category
>> too.  I have thought about defining a generic ConfigurationModel and
>> datastore that would be used by everything (mappers, fed providers, etc.)
>>
>
> Yes, I know. Please read the thread me and Marek and when we discussed
> this. This really has to be sorted out otherwise we'll continue to have
> issues with it.
>
>
> I read it.  Summary is that you need to be able to associate one instance
> per session and the ability for it to be closed when session ends.  As long
> as we don't think some implementation will want an instance per method call
> on the provider, then all this can probably be done automatically.
>

Another thing to add is that the construction of the instances should be up
to the factory, not the caller. This allows the factory to retrieve the
config (model) from the realm for that particular instance. Alternatively a
factory can also pull the config from elsewhere if it wants to. It should
not be required by calling code to know how to construct the instance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160613/10e09e89/attachment.html 

From psilva at redhat.com  Mon Jun 13 13:16:26 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 13 Jun 2016 13:16:26 -0400 (EDT)
Subject: [keycloak-dev] Add roles to a client template
In-Reply-To: <169325331.18572202.1465835533670.JavaMail.zimbra@redhat.com>
Message-ID: <2058784677.18590546.1465838186636.JavaMail.zimbra@redhat.com>

Is it possible to add client roles to a client template ? Would like to provide a template with some default roles/scopes.

Regards.
Pedro Igor

From mitya at cargosoft.ru  Mon Jun 13 14:14:25 2016
From: mitya at cargosoft.ru (Mitya)
Date: Mon, 13 Jun 2016 21:14:25 +0300
Subject: [keycloak-dev] Support for arbitrary byte arrays as HOTP keys
Message-ID: <1465841665.12548.24.camel@cargosoft.ru>

The current KeyCloak HOTP implementation assumes that a HOTP key (aka
seed, aka initialization vector) is stored as string, and thus contains
only printable characters. However, the HOTP standard (RFC 4226)
doesn't impose any restrictions on key material; any arbitrary byte
array is acceptable.

Moreover, many hardware HOTP tokens are pre-programmed at the factory,
and do contain non-printable seeds. Even though KeyCloak doesn't
support hardware tokens out of the box, developers could implement it
by extending KeyCloak and employing existing algorithms. Unfortunately,
the existing convention (to store HOTP seeds as printable strings)
makes this impossible.

For the "password" credential type, the "value" field is already stored
as Base64. I think "hotp" credentials could also be stored as Base64 or
hex; another option would be to store the "value" field as BLOB (like
it's already done for the "salt" field).

I think I could produce a PR for this, I only need to know which
scenario is preferred.

Cheers,
Mitya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160613/25660307/attachment.html 

From sthorger at redhat.com  Mon Jun 13 14:20:37 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Jun 2016 20:20:37 +0200
Subject: [keycloak-dev] Add roles to a client template
In-Reply-To: <2058784677.18590546.1465838186636.JavaMail.zimbra@redhat.com>
References: <169325331.18572202.1465835533670.JavaMail.zimbra@redhat.com>
	<2058784677.18590546.1465838186636.JavaMail.zimbra@redhat.com>
Message-ID: <CAJgngAfNGn=0HLb0ObfhWRv1ZWYidYKnQF-Rp92KF=HK0deA7Q@mail.gmail.com>

Client templates can only store roles and scope. Not sure it makes sense to
add client roles, especially not since we're planning on introducing role
namespaces in the future and that could conflict with the design around
that.

Can you elaborate on the use-case?

On 13 June 2016 at 19:16, Pedro Igor Silva <psilva at redhat.com> wrote:

> Is it possible to add client roles to a client template ? Would like to
> provide a template with some default roles/scopes.
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160613/c2111678/attachment.html 

From psilva at redhat.com  Mon Jun 13 15:44:34 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 13 Jun 2016 15:44:34 -0400 (EDT)
Subject: [keycloak-dev] Add roles to a client template
In-Reply-To: <CAJgngAfNGn=0HLb0ObfhWRv1ZWYidYKnQF-Rp92KF=HK0deA7Q@mail.gmail.com>
References: <169325331.18572202.1465835533670.JavaMail.zimbra@redhat.com>
	<2058784677.18590546.1465838186636.JavaMail.zimbra@redhat.com>
	<CAJgngAfNGn=0HLb0ObfhWRv1ZWYidYKnQF-Rp92KF=HK0deA7Q@mail.gmail.com>
Message-ID: <307069035.18631231.1465847074943.JavaMail.zimbra@redhat.com>

It is related with some simplifications to authz services configuration.

In order to enable fine-grained authz, clients should be granted with specific roles to gain access to authz services. In some cases, users must consent access to his authorization data by third-party apps.

When consenting access to his authorization data, the user is actually consenting to a third-party app access to the protected resources at a specific resource server. In this case, a client role can be used to specify just that. Eg.: on the consent page you'll see a "uma_authorization in client-application-A"

I can also use realm roles to achieve the same result, but that would not be specific to a resource server/client-app. Although still a valid setup if the user wants so.

What I want to do is just create a template with these roles. I was expecting that the template could help me to avoid creating and assigning these roles manually.

This is not a blocker. As I said, realm roles can also be used to achieve the same results.

----- Original Message -----
From: "Stian Thorgersen" <sthorger at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Monday, June 13, 2016 3:20:37 PM
Subject: Re: [keycloak-dev] Add roles to a client template

Client templates can only store roles and scope. Not sure it makes sense to
add client roles, especially not since we're planning on introducing role
namespaces in the future and that could conflict with the design around
that.

Can you elaborate on the use-case?

On 13 June 2016 at 19:16, Pedro Igor Silva <psilva at redhat.com> wrote:

> Is it possible to add client roles to a client template ? Would like to
> provide a template with some default roles/scopes.
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Mon Jun 13 17:52:40 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 13 Jun 2016 17:52:40 -0400 (EDT)
Subject: [keycloak-dev] Add roles to a client template
In-Reply-To: <307069035.18631231.1465847074943.JavaMail.zimbra@redhat.com>
References: <169325331.18572202.1465835533670.JavaMail.zimbra@redhat.com>
	<2058784677.18590546.1465838186636.JavaMail.zimbra@redhat.com>
	<CAJgngAfNGn=0HLb0ObfhWRv1ZWYidYKnQF-Rp92KF=HK0deA7Q@mail.gmail.com>
	<307069035.18631231.1465847074943.JavaMail.zimbra@redhat.com>
Message-ID: <1213865699.18663118.1465854760408.JavaMail.zimbra@redhat.com>

Btw, is there any way to specify the entity (client or user) to which a default role should be applied ?

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: stian at redhat.com
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Monday, June 13, 2016 4:44:34 PM
Subject: Re: [keycloak-dev] Add roles to a client template

It is related with some simplifications to authz services configuration.

In order to enable fine-grained authz, clients should be granted with specific roles to gain access to authz services. In some cases, users must consent access to his authorization data by third-party apps.

When consenting access to his authorization data, the user is actually consenting to a third-party app access to the protected resources at a specific resource server. In this case, a client role can be used to specify just that. Eg.: on the consent page you'll see a "uma_authorization in client-application-A"

I can also use realm roles to achieve the same result, but that would not be specific to a resource server/client-app. Although still a valid setup if the user wants so.

What I want to do is just create a template with these roles. I was expecting that the template could help me to avoid creating and assigning these roles manually.

This is not a blocker. As I said, realm roles can also be used to achieve the same results.

----- Original Message -----
From: "Stian Thorgersen" <sthorger at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Monday, June 13, 2016 3:20:37 PM
Subject: Re: [keycloak-dev] Add roles to a client template

Client templates can only store roles and scope. Not sure it makes sense to
add client roles, especially not since we're planning on introducing role
namespaces in the future and that could conflict with the design around
that.

Can you elaborate on the use-case?

On 13 June 2016 at 19:16, Pedro Igor Silva <psilva at redhat.com> wrote:

> Is it possible to add client roles to a client template ? Would like to
> provide a template with some default roles/scopes.
>
> Regards.
> Pedro Igor
> _______________________________________________
> 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  Tue Jun 14 05:18:32 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 14 Jun 2016 11:18:32 +0200
Subject: [keycloak-dev] Add roles to a client template
In-Reply-To: <1213865699.18663118.1465854760408.JavaMail.zimbra@redhat.com>
References: <169325331.18572202.1465835533670.JavaMail.zimbra@redhat.com>
	<2058784677.18590546.1465838186636.JavaMail.zimbra@redhat.com>
	<CAJgngAfNGn=0HLb0ObfhWRv1ZWYidYKnQF-Rp92KF=HK0deA7Q@mail.gmail.com>
	<307069035.18631231.1465847074943.JavaMail.zimbra@redhat.com>
	<1213865699.18663118.1465854760408.JavaMail.zimbra@redhat.com>
Message-ID: <575FCBE8.60902@redhat.com>

Hey Pedro,

the default roles are always automatically added to all newly created 
users. They are not added to scopes of newly created clients (clients 
have "Full scope allowed" by default anyway). To achieve something like 
default scope, you can maybe add the roles to scope of some client 
template and then add this client template to your client. The client 
will then inherit all scopes. Is it something you meant?

Marek

On 13/06/16 23:52, Pedro Igor Silva wrote:
> Btw, is there any way to specify the entity (client or user) to which a default role should be applied ?
>
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: stian at redhat.com
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, June 13, 2016 4:44:34 PM
> Subject: Re: [keycloak-dev] Add roles to a client template
>
> It is related with some simplifications to authz services configuration.
>
> In order to enable fine-grained authz, clients should be granted with specific roles to gain access to authz services. In some cases, users must consent access to his authorization data by third-party apps.
>
> When consenting access to his authorization data, the user is actually consenting to a third-party app access to the protected resources at a specific resource server. In this case, a client role can be used to specify just that. Eg.: on the consent page you'll see a "uma_authorization in client-application-A"
>
> I can also use realm roles to achieve the same result, but that would not be specific to a resource server/client-app. Although still a valid setup if the user wants so.
>
> What I want to do is just create a template with these roles. I was expecting that the template could help me to avoid creating and assigning these roles manually.
>
> This is not a blocker. As I said, realm roles can also be used to achieve the same results.
>
> ----- Original Message -----
> From: "Stian Thorgersen" <sthorger at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, June 13, 2016 3:20:37 PM
> Subject: Re: [keycloak-dev] Add roles to a client template
>
> Client templates can only store roles and scope. Not sure it makes sense to
> add client roles, especially not since we're planning on introducing role
> namespaces in the future and that could conflict with the design around
> that.
>
> Can you elaborate on the use-case?
>
> On 13 June 2016 at 19:16, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Is it possible to add client roles to a client template ? Would like to
>> provide a template with some default roles/scopes.
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> 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 mitya at cargosoft.ru  Tue Jun 14 05:47:53 2016
From: mitya at cargosoft.ru (Mitya)
Date: Tue, 14 Jun 2016 12:47:53 +0300
Subject: [keycloak-dev] Extending admin theme with scripts
Message-ID: <1465897673.4620.7.camel@cargosoft.ru>

Hi,

Extensibility is definitely one of KeyCloak killer features, including
the ability to extend and modify admin console behavior. Unfortunately,
at the moment admin themes couldn't be extended with custom scripts,
contrary to what is stated in the docs.

The issue has been known for months:
https://issues.jboss.org/browse/KEYCLOAK-3052
https://github.com/pedroigor/keycloak-authz/issues/26

?I've created a pull request,?though the fix is trivial and could be
reimplemented directly.
https://github.com/keycloak/keycloak/pull/2933

Cheers,
Mitya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160614/3e1d405f/attachment.html 

From mitya at cargosoft.ru  Tue Jun 14 06:13:38 2016
From: mitya at cargosoft.ru (Mitya)
Date: Tue, 14 Jun 2016 13:13:38 +0300
Subject: [keycloak-dev] Russian localization
In-Reply-To: <814aec0ea038434e983b95c26ccfe311@nut-mbx-4.win.ftc.ru>
References: <9ce77698dcf74c24b366d80333249d85@nut-mbx-4.win.ftc.ru>
	<CAJgngAcT5AR8yuZY7Dh84Fa81GM1O=Or_h00UdV9Rh6_LD-R=w@mail.gmail.com>
	<814aec0ea038434e983b95c26ccfe311@nut-mbx-4.win.ftc.ru>
Message-ID: <1465899218.4620.11.camel@cargosoft.ru>

Aleksander, great news! This is something we were planning ourselves.
Thank you for your effort!
Stian, I think I'll be able to help to maintain and update Russian
translation, as well as perform some peer review.
Cheers,
Mitya
> Yes, I will trying to update it, when it necessary.
> ?
> From: Stian Thorgersen [mailto:sthorger at redhat.com]?
> Sent: Wednesday, June 08, 2016 10:53 AM
> To: ???????? ????????? ?????????
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Russian localization
> ?
> We would welcome a contribution for Russian. However, we are not able
> to maintain this translation ourselves. Would you be able to maintain
> it and update it when it's needed?
> 
> 
> ?
> On 8 June 2016 at 06:36, Nekrasov Aleksandr <a.nekrasov at ftc.ru>
> wrote:
> Hi all,
> ?
> I have translated all base theme message resources to russian
> language and want to create PR.
> I believe, it will be good, if keycloak will be supports russian
> locale. How do you think?
> ?
> Nekrasov Aleksander,
> Developer,
> Center of Financial Techologies
> ?
> 
> 
> 
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160614/aa254e9e/attachment-0001.html 

From sthorger at redhat.com  Tue Jun 14 07:04:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 14 Jun 2016 13:04:09 +0200
Subject: [keycloak-dev] Russian localization
In-Reply-To: <1465899218.4620.11.camel@cargosoft.ru>
References: <9ce77698dcf74c24b366d80333249d85@nut-mbx-4.win.ftc.ru>
	<CAJgngAcT5AR8yuZY7Dh84Fa81GM1O=Or_h00UdV9Rh6_LD-R=w@mail.gmail.com>
	<814aec0ea038434e983b95c26ccfe311@nut-mbx-4.win.ftc.ru>
	<1465899218.4620.11.camel@cargosoft.ru>
Message-ID: <CAJgngAc6LQab7x9vK7uHnreR7d_-FM7XJb_vCcQSE0_X1RcVaw@mail.gmail.com>

Great, you can help already by sanity checking the PR :)

On 14 June 2016 at 12:13, Mitya <mitya at cargosoft.ru> wrote:

> Aleksander, great news! This is something we were planning ourselves.
> Thank you for your effort!
>
> Stian, I think I'll be able to help to maintain and update Russian
> translation, as well as perform some peer review.
>
> Cheers,
> Mitya
>
>
> Yes, I will trying to update it, when it necessary.
>
>
>
> *From:* Stian Thorgersen [mailto:sthorger at redhat.com]
> *Sent:* Wednesday, June 08, 2016 10:53 AM
> *To:* ???????? ????????? ?????????
> *Cc:* keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Russian localization
>
>
>
> We would welcome a contribution for Russian. However, we are not able to
> maintain this translation ourselves. Would you be able to maintain it and
> update it when it's needed?
>
>
>
> On 8 June 2016 at 06:36, Nekrasov Aleksandr <a.nekrasov at ftc.ru> wrote:
>
> Hi all,
>
>
>
> I have translated all base theme message resources to russian language and
> want to create PR.
>
> I believe, it will be good, if keycloak will be supports russian locale.
> How do you think?
>
>
>
> Nekrasov Aleksander,
>
> Developer,
>
> Center of Financial Techologies
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160614/8ff22dae/attachment.html 

From psilva at redhat.com  Tue Jun 14 07:54:59 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 14 Jun 2016 07:54:59 -0400 (EDT)
Subject: [keycloak-dev] Add roles to a client template
In-Reply-To: <575FCBE8.60902@redhat.com>
References: <169325331.18572202.1465835533670.JavaMail.zimbra@redhat.com>
	<2058784677.18590546.1465838186636.JavaMail.zimbra@redhat.com>
	<CAJgngAfNGn=0HLb0ObfhWRv1ZWYidYKnQF-Rp92KF=HK0deA7Q@mail.gmail.com>
	<307069035.18631231.1465847074943.JavaMail.zimbra@redhat.com>
	<1213865699.18663118.1465854760408.JavaMail.zimbra@redhat.com>
	<575FCBE8.60902@redhat.com>
Message-ID: <1247474654.18783481.1465905299185.JavaMail.zimbra@redhat.com>

Hey Marek,

    When I define a role as default it is also added to the client "Effective Roles", not only to users.

    What I'm doing right now is pretty much what you described, have some realm roles and add them to the scopes of a client template. I was just trying to avoid keeping these roles at the realm level and provide a default configuration where the roles are specific for a client. Which makes more sense.

    Basically, I have three scopes:

    * uma_protection, that should be mapped to client applications acting as resource servers, only.
    * uma_authorization and kc_entitlement, that should be mapped to users as a client role for a given client app acting as a resource server. Ideally.

    In an ideal world (for privacy reasons), when you try to access a protected resource that is protected with our authz stuff, the user must consent access to his authorization data. So you may have a consent page saying "Third-party wants access to uma_authorization/kc_entitlement in Resource Server".

    As I said, global roles can also be used here, but they are not specific to a client and may not represent clearly the scope of access the user is actually consenting.

Thanks

----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>, stian at redhat.com
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Tuesday, June 14, 2016 6:18:32 AM
Subject: Re: [keycloak-dev] Add roles to a client template

Hey Pedro,

the default roles are always automatically added to all newly created 
users. They are not added to scopes of newly created clients (clients 
have "Full scope allowed" by default anyway). To achieve something like 
default scope, you can maybe add the roles to scope of some client 
template and then add this client template to your client. The client 
will then inherit all scopes. Is it something you meant?

Marek

On 13/06/16 23:52, Pedro Igor Silva wrote:
> Btw, is there any way to specify the entity (client or user) to which a default role should be applied ?
>
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: stian at redhat.com
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, June 13, 2016 4:44:34 PM
> Subject: Re: [keycloak-dev] Add roles to a client template
>
> It is related with some simplifications to authz services configuration.
>
> In order to enable fine-grained authz, clients should be granted with specific roles to gain access to authz services. In some cases, users must consent access to his authorization data by third-party apps.
>
> When consenting access to his authorization data, the user is actually consenting to a third-party app access to the protected resources at a specific resource server. In this case, a client role can be used to specify just that. Eg.: on the consent page you'll see a "uma_authorization in client-application-A"
>
> I can also use realm roles to achieve the same result, but that would not be specific to a resource server/client-app. Although still a valid setup if the user wants so.
>
> What I want to do is just create a template with these roles. I was expecting that the template could help me to avoid creating and assigning these roles manually.
>
> This is not a blocker. As I said, realm roles can also be used to achieve the same results.
>
> ----- Original Message -----
> From: "Stian Thorgersen" <sthorger at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, June 13, 2016 3:20:37 PM
> Subject: Re: [keycloak-dev] Add roles to a client template
>
> Client templates can only store roles and scope. Not sure it makes sense to
> add client roles, especially not since we're planning on introducing role
> namespaces in the future and that could conflict with the design around
> that.
>
> Can you elaborate on the use-case?
>
> On 13 June 2016 at 19:16, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Is it possible to add client roles to a client template ? Would like to
>> provide a template with some default roles/scopes.
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> 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 a.nekrasov at ftc.ru  Tue Jun 14 08:54:57 2016
From: a.nekrasov at ftc.ru (Nekrasov Aleksandr)
Date: Tue, 14 Jun 2016 12:54:57 +0000
Subject: [keycloak-dev] Reset Password changes complete needs review
Message-ID: <fb9ff4626a81430b9883334b05a0901b@nut-mbx-4.win.ftc.ru>

Hi!
My case is next: We have mobile project, which has no website. For some politics we cannot use any web forms for this project ( Keycloak forms too ) and app interact only with our rest service. When user reset credentials, he should receive email with some OTP code ( not link ) to enter it into mobile app.
Another reason why not link is that user must stay in mobile app context.
App context ( three steps flow):

1.       User click "forgot password", enter email and click next

2.       User see "enter reset code here" and paste here from email then click next

3.       User enter new password, click "save" and can work with app

Link breaks this scenario and adds one more context. And user should open it through browser. How the user can trust it? Its more difficult for the users for this case.


I prefer, if EmailTemplateProvider.sendPasswordReset method would have additional configurable OTP parameter. And using my own templates I can send to user OTP, link, or both.


Discussion starts here: http://lists.jboss.org/pipermail/keycloak-dev/2015-August/005092.html

Nekrasov Aleksander,
Developer,
Center of Financial Techologies

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

From sthorger at redhat.com  Wed Jun 15 02:18:37 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 15 Jun 2016 08:18:37 +0200
Subject: [keycloak-dev] Add roles to a client template
In-Reply-To: <1247474654.18783481.1465905299185.JavaMail.zimbra@redhat.com>
References: <169325331.18572202.1465835533670.JavaMail.zimbra@redhat.com>
	<2058784677.18590546.1465838186636.JavaMail.zimbra@redhat.com>
	<CAJgngAfNGn=0HLb0ObfhWRv1ZWYidYKnQF-Rp92KF=HK0deA7Q@mail.gmail.com>
	<307069035.18631231.1465847074943.JavaMail.zimbra@redhat.com>
	<1213865699.18663118.1465854760408.JavaMail.zimbra@redhat.com>
	<575FCBE8.60902@redhat.com>
	<1247474654.18783481.1465905299185.JavaMail.zimbra@redhat.com>
Message-ID: <CAJgngAeDBB=h0DJqFmG-Sf3XEmGMbgxOr=qTDzggA+4Ae=FRqA@mail.gmail.com>

I'm pretty sure client templates are not the way to go here. Not even sure
roles are the way to go.

What's does the uma_protection role do?
Why uma_authorization and kc_entitlement? What's the difference between the
two?

Giving access to this information is that even something a user should be
granting? Is it not an admin thing to do?



On 14 June 2016 at 13:54, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hey Marek,
>
>     When I define a role as default it is also added to the client
> "Effective Roles", not only to users.
>
>     What I'm doing right now is pretty much what you described, have some
> realm roles and add them to the scopes of a client template. I was just
> trying to avoid keeping these roles at the realm level and provide a
> default configuration where the roles are specific for a client. Which
> makes more sense.
>
>     Basically, I have three scopes:
>
>     * uma_protection, that should be mapped to client applications acting
> as resource servers, only.
>     * uma_authorization and kc_entitlement, that should be mapped to users
> as a client role for a given client app acting as a resource server.
> Ideally.
>
>     In an ideal world (for privacy reasons), when you try to access a
> protected resource that is protected with our authz stuff, the user must
> consent access to his authorization data. So you may have a consent page
> saying "Third-party wants access to uma_authorization/kc_entitlement in
> Resource Server".
>
>     As I said, global roles can also be used here, but they are not
> specific to a client and may not represent clearly the scope of access the
> user is actually consenting.
>
> Thanks
>
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, stian at redhat.com
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, June 14, 2016 6:18:32 AM
> Subject: Re: [keycloak-dev] Add roles to a client template
>
> Hey Pedro,
>
> the default roles are always automatically added to all newly created
> users. They are not added to scopes of newly created clients (clients
> have "Full scope allowed" by default anyway). To achieve something like
> default scope, you can maybe add the roles to scope of some client
> template and then add this client template to your client. The client
> will then inherit all scopes. Is it something you meant?
>
> Marek
>
> On 13/06/16 23:52, Pedro Igor Silva wrote:
> > Btw, is there any way to specify the entity (client or user) to which a
> default role should be applied ?
> >
> > ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: stian at redhat.com
> > Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> > Sent: Monday, June 13, 2016 4:44:34 PM
> > Subject: Re: [keycloak-dev] Add roles to a client template
> >
> > It is related with some simplifications to authz services configuration.
> >
> > In order to enable fine-grained authz, clients should be granted with
> specific roles to gain access to authz services. In some cases, users must
> consent access to his authorization data by third-party apps.
> >
> > When consenting access to his authorization data, the user is actually
> consenting to a third-party app access to the protected resources at a
> specific resource server. In this case, a client role can be used to
> specify just that. Eg.: on the consent page you'll see a "uma_authorization
> in client-application-A"
> >
> > I can also use realm roles to achieve the same result, but that would
> not be specific to a resource server/client-app. Although still a valid
> setup if the user wants so.
> >
> > What I want to do is just create a template with these roles. I was
> expecting that the template could help me to avoid creating and assigning
> these roles manually.
> >
> > This is not a blocker. As I said, realm roles can also be used to
> achieve the same results.
> >
> > ----- Original Message -----
> > From: "Stian Thorgersen" <sthorger at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> > Sent: Monday, June 13, 2016 3:20:37 PM
> > Subject: Re: [keycloak-dev] Add roles to a client template
> >
> > Client templates can only store roles and scope. Not sure it makes sense
> to
> > add client roles, especially not since we're planning on introducing role
> > namespaces in the future and that could conflict with the design around
> > that.
> >
> > Can you elaborate on the use-case?
> >
> > On 13 June 2016 at 19:16, Pedro Igor Silva <psilva at redhat.com> wrote:
> >
> >> Is it possible to add client roles to a client template ? Would like to
> >> provide a template with some default roles/scopes.
> >>
> >> Regards.
> >> Pedro Igor
> >> _______________________________________________
> >> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160615/ba63d065/attachment.html 

From mposolda at redhat.com  Wed Jun 15 04:47:46 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 15 Jun 2016 10:47:46 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
Message-ID: <57611632.9080300@redhat.com>

Hi Bill,

few notes from me. I am mostly adding the scenarios, which will be good 
to support/improve or which we should still keep supporting after 
refactoring IMO. Sorry for bit longer email :)

Note: When I talk "LDAP", I usually mean "LDAP or any other 3rd party 
federation storage"


Persistent vs. Transient modes
----------------------------------------

I think we should still keep some support for "persistent" mode (the 
case when user is imported to Keycloak local DB).

Assuming the scenario:
- john is imported from LDAP with "unsynced" mode
- john changes his password in account management. LDAP is unsynced 
(read-only), so the password needs to be changed in Keycloak storage
- After server restart, john should have set the new password, not the 
old one from LDAP. Hence the only possibility seems to keep support for 
"import" this user into Keycloak DB and have user persistent.

The similar situation applies for any update of user, which can't be 
saved back to LDAP (either because LDAP is read-only or because it 
doesn't support store the keycloak metadata like social links, consents, 
required actions etc)

Regarding this, I am thinking about possible import modes like:
1) Persistent : User attributes from LDAP are imported into Keycloak DB 
(same behaviour like now)

2) Transient : User attributes from LDAP are not imported into Keycloak 
DB, but just cached locally. Any updates of the user are either dropped 
after server restart or disallowed. For example: Maybe consents can be 
just dropped, but some other things like requiredRoles should be rather 
disallowed to change? For example if admin adds some requiredAction to 
user "john", the requiredAction shouldn't disappear after server 
restart. This would be a security hole IMO. So in that case, if admin 
tries to manually add requiredAction to such user, the exception will be 
thrown so admin is aware that this is not supported. Anyway, for support 
any writing to cache, the cache will need to be replicated though (for 
example: user consent saved into cache on node1 should be visible on 
node2 as well).

3) Hybrid : LDAP user is not imported into Keycloak DB immediatelly. 
They are imported "on-demand" after user is updated and the update can't 
be saved to LDAP


Caching
-----------

I hope new SPI will allow us more flexibility to support various 
scenarios. It will be good to support at least those IMO:

1) Keep the option we have now (LDAP user data are always read from 
"online" LDAP, but other user data are cached, so no need to read them 
from Keycloak DB)

2) Option to allow support for caching of LDAP data even if mode is 
"persistent" . I want LDAP users imported into Keycloak DB, but still I 
don't want to always "validate" user in LDAP during each request like 
it's now. This will be good for people, who prefer performance rather 
then always seeing latest LDAP data.

3) I agree that will be cool to support different expiration time based 
if it's LDAP user or just Keycloak-local user. Infinispan allows it 
though with something like : cache.put("ldapuser", ldapUser, 60, 
TimeUnit.SECONDS);



Transactions and 3rd party updates
-----------------------------------------------

- Will be good to improve registration of user to LDAP. Ideally during 
registration new user to LDAP, we should allow to send all data at once. 
(currently UserFederationProvider.register supports sending just 
username). Also we should allow to specify if register to 3rd party 
provider should be done *before* or *after* the registration to Keycloak 
local DB. For details, see https://issues.jboss.org/browse/KEYCLOAK-1075 
and all the comments from users...

- Also updating user should be ideally at once. For example if you call:
user.setFirstName("john");
user.setLastName("Doe");
user.setEmail("john at email.cz");

we shouldn't have 3 update calls to LDAP, but just one. Maybe we can 
address this with transaction abstraction? I've already did something 
for LDAP provider (see TxAwareLDAPUserModelDelegate ), however will be 
good to provide something more generic for user storage SPI. Then when 
KeycloakTransactionManager.commit is called, the data are send to 
federation storage


Sync users
--------------
We should still keep the option to sync users into Keycloak DB as we 
have now. Note some persistent storages like LDAP are limited with 
pagination. So the easiest possibility for some admins is just to sync 
users, so they can easily search them in admin console.


Proxy yes/no?
------------------

As we discussed in F2F, the proxy is maybe a bit complicated pattern, 
but it's very flexible. It allows to proxy/override exactly just the 
methods you want (for example: add UPDATE_PASSWORD requiredAction to 
user if ActiveDirectory password is expired. Add group mappings or role 
mappings dynamically etc)

Marek

On 13/06/16 14:56, Bill Burke wrote:
>
> I'm working on a new SPI right now.  Here is my notebad to capture how 
> things work, issues weed to consider, and problems we have to solve:
>
> https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI
>
>
> On 6/13/16 3:39 AM, Marek Posolda wrote:
>> We discussed some time ago how to ensure that UserFederationProvider 
>> lifecycle is properly tight to KeycloakSession 
>> http://lists.jboss.org/pipermail/keycloak-dev/2016-April/007123.html 
>> . The last we discussed was to add new method on KeycloakSession like:
>>
>> <T extends Provider> T getProvider(Class<T> clazz, String id, String 
>> instanceId);
>>
>> where instanceId is the state associated with the provider (in case 
>> of UserFederationProvider it will be DB ID of 
>> UserFederationProviderModelId). That way, the 
>> UserFederationProviderFactory.create can load the 
>> UserFederationProviderModel (assumption is that RealmModel is 
>> available in KeycloakContext, so UserFederationProviderFactory.create 
>> has access to RealmModel + providerDatabaseId to load it from DB).
>>
>> In the thread, you can see that I've initially proposed something 
>> similar to your proposal, but it's a bit more complex though. 
>> Hopefully going "simple" way and adding just the method with 
>> "instanceId" String argument can solve the issue.
>>
>> Marek
>>
>> On 10/06/16 01:36, Ariel Carrera wrote:
>>> There is not problem! :)
>>> One more thing, I solved the problem of multiple "federation 
>>> provider" instances, adding this code to the DefaultKeycloakSession 
>>> (and the method definition in KeycloakSession interface):
>>>
>>>     public <T extends Provider> void registerProvider(Class<T>
>>>     clazz, Provider provider, String id) {
>>>             Integer hash = clazz.hashCode() + id.hashCode();
>>>             providers.put(hash, provider);
>>>         }
>>>
>>>
>>> And into MyUserFederationProviderFactory.getInstance(session, model) 
>>> something like this:
>>>
>>>     public UserFederationProvider getInstance(KeycloakSession
>>>     session, UserFederationProviderModel model){
>>>     UserFederationProvider provider = (UserFederationProvider)
>>>     session.getProvider(UserFederationProvider.class, model.getId());
>>>     if (provider == null){
>>>     lazyInit(session);
>>>             provider = new MyUserFederationProvider(session, model,
>>>     config, ......);
>>>     ((KeycloakSession)session).registerProvider(UserFederationProvider.class,
>>>     provider, model.getId());
>>>     };
>>>             return provider;
>>>         }
>>>
>>>
>>> After a few tests and debug it seems to work... creating, catching, 
>>> and closing provider instances as expected.
>>>
>>>
>>> In future versions as you said, maybe would be better include a way 
>>> to instantiate a complex object/provider instead of doing
>>>
>>>     ProviderFactory.create(KeycloakSession session)
>>>     some kind of method like
>>>     ProviderFactory.create(KeycloakSession session, Object... obj);
>>>
>>> and the appropriate method into the KeycloakSession
>>>
>>>     <T extends Provider> T getProvider(Class<T> clazz, Object... obj);
>>>     <T extends Provider> T getProvider(Class<T> clazz, String id,
>>>     Object... obj);
>>>
>>>
>>> And why not a map into the keycloakSession to store some additional 
>>> context data to share between providers during same request? It's 
>>> only a vague idea
>>>
>>> Regards!
>>>
>>> 2016-06-09 17:14 GMT-03:00 Bill Burke <bburke at redhat.com 
>>> <mailto:bburke at redhat.com>>:
>>>
>>>     Its gonna be awhile.  Its going to be difficult to make
>>>     everything both backward compatible and cover all the current
>>>     and future use cases we need to cover.  Listen on the dev list. 
>>>     I should post some info soon on what the new impl will look like.
>>>
>>>
>>>     On 6/9/16 3:57 PM, Ariel Carrera wrote:
>>>>     Yes Bill, exactly! I will waiting to test it Thanks!
>>>>
>>>>     2016-06-09 16:29 GMT-03:00 Bill Burke <bburke at redhat.com>:
>>>>
>>>>
>>>>
>>>>         On 6/9/16 2:52 PM, Ariel Carrera wrote:
>>>>
>>>>             Hi Bill, is a little expensive for me because I am
>>>>             creating a new entity manager to connect with a legacy
>>>>             database, and creating/enlisting a transaction per
>>>>             instance.
>>>>             For example in a simple flow case where a user needs to
>>>>             click "I forgot my password" link to recover the
>>>>             password, there is more than nine or ten instances
>>>>             created to do this. It's really not a big problem but I
>>>>             think that is not necessary and can be implemented like
>>>>             others spi providers catched into the keycloak session.
>>>>
>>>>         This is good feedback.  We need a way to associate a
>>>>         provider, by name, to the KeycloakSession.  Maybe we just
>>>>         need a way to associate anything with the KeycloakSession
>>>>         period.
>>>>
>>>>             In my case, another difficulty is synchronization
>>>>             between an old authentication system and keycloak
>>>>             implemented on demand (there is no full/partial
>>>>             syncrhonization because the legacy system is still
>>>>             working and need to work together for a while). Also I
>>>>             implemented synchronization support but at this moment
>>>>             it not used.
>>>>             Every time that keycloak needs to validate a user
>>>>             (isValid) recovered from the user storage or cache, a
>>>>             query to the legacy system is made. Added to this... I
>>>>             need to recover some attributes and roles changes
>>>>             produced on the legacy system.... so I decided to
>>>>             implement a "user federation cache" with a short term
>>>>             expiration to improve the performance with certain
>>>>             synchronization delay tolerance.
>>>>
>>>>             In a few words I have: a custom User Federation
>>>>             Provider + on deman synchronization + a user Federation
>>>>             Provider Cache (my own cache SPI).
>>>>
>>>>             Maybe an optional spi to obtain a custom container from
>>>>             infinispan could be a good choice to add to the new
>>>>             implementation and provide another one tool to do
>>>>             things with better performance.
>>>>
>>>>         I think the new model might solve your caching needs. 
>>>>         There will be no importing by default.  This means no
>>>>         synching, etc.  Keycloak will only store metadata that your
>>>>         user store can't provide.  User Federation Providers will
>>>>         work just as the default Keycloak user store and user cache.
>>>>
>>>>
>>>>
>>>>
>>>>     -- 
>>>>     Tat?
>>>
>>>
>>>
>>>
>>> -- 
>>> Tat?
>>>
>>>
>>> _______________________________________________
>>> 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

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

From sthorger at redhat.com  Wed Jun 15 07:07:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 15 Jun 2016 13:07:19 +0200
Subject: [keycloak-dev] Support for arbitrary byte arrays as HOTP keys
In-Reply-To: <1465841665.12548.24.camel@cargosoft.ru>
References: <1465841665.12548.24.camel@cargosoft.ru>
Message-ID: <CAJgngAfORA-sqdD9aPVk8DTEK3faXY3fgsHXXgJ6Tr59RnjHYg@mail.gmail.com>

I'm not quite following the problem. You can encode the secret/key
using Base32. In fact this Keycloak already stores the secret as a Base32
encoded string. We don't strictly support hardware tokens at the moment as
there's no way to specify the secret, but you can probably do that through
the admin endpoints.

On 13 June 2016 at 20:14, Mitya <mitya at cargosoft.ru> wrote:

> The current KeyCloak HOTP implementation assumes that a HOTP key (aka
> seed, aka initialization vector) is stored as string, and thus contains
> only printable characters. However, the HOTP standard (RFC 4226)
> doesn't impose any restrictions on key material; any arbitrary byte
> array is acceptable.
>
> Moreover, many hardware HOTP tokens are pre-programmed at the factory,
> and do contain non-printable seeds. Even though KeyCloak doesn't
> support hardware tokens out of the box, developers could implement it
> by extending KeyCloak and employing existing algorithms. Unfortunately,
> the existing convention (to store HOTP seeds as printable strings)
> makes this impossible.
>
> For the "password" credential type, the "value" field is already stored
> as Base64. I think "hotp" credentials could also be stored as Base64 or
> hex; another option would be to store the "value" field as BLOB (like
> it's already done for the "salt" field).
>
> I think I could produce a PR for this, I only need to know which
> scenario is preferred.
>
> Cheers,
> Mitya
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160615/6ad9a837/attachment.html 

From psilva at redhat.com  Wed Jun 15 07:58:56 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 15 Jun 2016 07:58:56 -0400 (EDT)
Subject: [keycloak-dev] Add roles to a client template
In-Reply-To: <CAJgngAeDBB=h0DJqFmG-Sf3XEmGMbgxOr=qTDzggA+4Ae=FRqA@mail.gmail.com>
References: <169325331.18572202.1465835533670.JavaMail.zimbra@redhat.com>
	<2058784677.18590546.1465838186636.JavaMail.zimbra@redhat.com>
	<CAJgngAfNGn=0HLb0ObfhWRv1ZWYidYKnQF-Rp92KF=HK0deA7Q@mail.gmail.com>
	<307069035.18631231.1465847074943.JavaMail.zimbra@redhat.com>
	<1213865699.18663118.1465854760408.JavaMail.zimbra@redhat.com>
	<575FCBE8.60902@redhat.com>
	<1247474654.18783481.1465905299185.JavaMail.zimbra@redhat.com>
	<CAJgngAeDBB=h0DJqFmG-Sf3XEmGMbgxOr=qTDzggA+4Ae=FRqA@mail.gmail.com>
Message-ID: <373105168.19261810.1465991936114.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <sthorger at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, June 15, 2016 3:18:37 AM
> Subject: Re: [keycloak-dev] Add roles to a client template
> 
> I'm pretty sure client templates are not the way to go here. Not even sure
> roles are the way to go.
> 
> What's does the uma_protection role do?

https://keycloak.gitbooks.io/authorization-services-guide/content/topics/service/protection/protection-api.html

> Why uma_authorization and kc_entitlement? What's the difference between the
> two?

Authorization API
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/service/authorization/authorization-api.html

Entitlement API
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/service/entitlement/entitlement-api.html

Architecture Overview
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/overview/architecture.html

> 
> Giving access to this information is that even something a user should be
> granting? Is it not an admin thing to do?
> 
> 
> 
> On 14 June 2016 at 13:54, Pedro Igor Silva <psilva at redhat.com> wrote:
> 
> > Hey Marek,
> >
> >     When I define a role as default it is also added to the client
> > "Effective Roles", not only to users.
> >
> >     What I'm doing right now is pretty much what you described, have some
> > realm roles and add them to the scopes of a client template. I was just
> > trying to avoid keeping these roles at the realm level and provide a
> > default configuration where the roles are specific for a client. Which
> > makes more sense.
> >
> >     Basically, I have three scopes:
> >
> >     * uma_protection, that should be mapped to client applications acting
> > as resource servers, only.
> >     * uma_authorization and kc_entitlement, that should be mapped to users
> > as a client role for a given client app acting as a resource server.
> > Ideally.
> >
> >     In an ideal world (for privacy reasons), when you try to access a
> > protected resource that is protected with our authz stuff, the user must
> > consent access to his authorization data. So you may have a consent page
> > saying "Third-party wants access to uma_authorization/kc_entitlement in
> > Resource Server".
> >
> >     As I said, global roles can also be used here, but they are not
> > specific to a client and may not represent clearly the scope of access the
> > user is actually consenting.
> >
> > Thanks
> >
> > ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>, stian at redhat.com
> > Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, June 14, 2016 6:18:32 AM
> > Subject: Re: [keycloak-dev] Add roles to a client template
> >
> > Hey Pedro,
> >
> > the default roles are always automatically added to all newly created
> > users. They are not added to scopes of newly created clients (clients
> > have "Full scope allowed" by default anyway). To achieve something like
> > default scope, you can maybe add the roles to scope of some client
> > template and then add this client template to your client. The client
> > will then inherit all scopes. Is it something you meant?
> >
> > Marek
> >
> > On 13/06/16 23:52, Pedro Igor Silva wrote:
> > > Btw, is there any way to specify the entity (client or user) to which a
> > default role should be applied ?
> > >
> > > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: stian at redhat.com
> > > Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Monday, June 13, 2016 4:44:34 PM
> > > Subject: Re: [keycloak-dev] Add roles to a client template
> > >
> > > It is related with some simplifications to authz services configuration.
> > >
> > > In order to enable fine-grained authz, clients should be granted with
> > specific roles to gain access to authz services. In some cases, users must
> > consent access to his authorization data by third-party apps.
> > >
> > > When consenting access to his authorization data, the user is actually
> > consenting to a third-party app access to the protected resources at a
> > specific resource server. In this case, a client role can be used to
> > specify just that. Eg.: on the consent page you'll see a "uma_authorization
> > in client-application-A"
> > >
> > > I can also use realm roles to achieve the same result, but that would
> > not be specific to a resource server/client-app. Although still a valid
> > setup if the user wants so.
> > >
> > > What I want to do is just create a template with these roles. I was
> > expecting that the template could help me to avoid creating and assigning
> > these roles manually.
> > >
> > > This is not a blocker. As I said, realm roles can also be used to
> > achieve the same results.
> > >
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <sthorger at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Monday, June 13, 2016 3:20:37 PM
> > > Subject: Re: [keycloak-dev] Add roles to a client template
> > >
> > > Client templates can only store roles and scope. Not sure it makes sense
> > to
> > > add client roles, especially not since we're planning on introducing role
> > > namespaces in the future and that could conflict with the design around
> > > that.
> > >
> > > Can you elaborate on the use-case?
> > >
> > > On 13 June 2016 at 19:16, Pedro Igor Silva <psilva at redhat.com> wrote:
> > >
> > >> Is it possible to add client roles to a client template ? Would like to
> > >> provide a template with some default roles/scopes.
> > >>
> > >> Regards.
> > >> Pedro Igor
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> 

From psilva at redhat.com  Wed Jun 15 08:03:32 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 15 Jun 2016 08:03:32 -0400 (EDT)
Subject: [keycloak-dev] Add roles to a client template
In-Reply-To: <373105168.19261810.1465991936114.JavaMail.zimbra@redhat.com>
References: <169325331.18572202.1465835533670.JavaMail.zimbra@redhat.com>
	<CAJgngAfNGn=0HLb0ObfhWRv1ZWYidYKnQF-Rp92KF=HK0deA7Q@mail.gmail.com>
	<307069035.18631231.1465847074943.JavaMail.zimbra@redhat.com>
	<1213865699.18663118.1465854760408.JavaMail.zimbra@redhat.com>
	<575FCBE8.60902@redhat.com>
	<1247474654.18783481.1465905299185.JavaMail.zimbra@redhat.com>
	<CAJgngAeDBB=h0DJqFmG-Sf3XEmGMbgxOr=qTDzggA+4Ae=FRqA@mail.gmail.com>
	<373105168.19261810.1465991936114.JavaMail.zimbra@redhat.com>
Message-ID: <2097965237.19262958.1465992212576.JavaMail.zimbra@redhat.com>

Btw, I'm reviewing the kc_entitlement role in order to make the Entitlement API the default authz protocol and make configuration more simple.

So, I'm probably going to remove that role ....

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: stian at redhat.com
Cc: "Marek Posolda" <mposolda at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Wednesday, June 15, 2016 8:58:56 AM
Subject: Re: [keycloak-dev] Add roles to a client template

----- Original Message -----
> From: "Stian Thorgersen" <sthorger at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, June 15, 2016 3:18:37 AM
> Subject: Re: [keycloak-dev] Add roles to a client template
> 
> I'm pretty sure client templates are not the way to go here. Not even sure
> roles are the way to go.
> 
> What's does the uma_protection role do?

https://keycloak.gitbooks.io/authorization-services-guide/content/topics/service/protection/protection-api.html

> Why uma_authorization and kc_entitlement? What's the difference between the
> two?

Authorization API
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/service/authorization/authorization-api.html

Entitlement API
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/service/entitlement/entitlement-api.html

Architecture Overview
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/overview/architecture.html

> 
> Giving access to this information is that even something a user should be
> granting? Is it not an admin thing to do?
> 
> 
> 
> On 14 June 2016 at 13:54, Pedro Igor Silva <psilva at redhat.com> wrote:
> 
> > Hey Marek,
> >
> >     When I define a role as default it is also added to the client
> > "Effective Roles", not only to users.
> >
> >     What I'm doing right now is pretty much what you described, have some
> > realm roles and add them to the scopes of a client template. I was just
> > trying to avoid keeping these roles at the realm level and provide a
> > default configuration where the roles are specific for a client. Which
> > makes more sense.
> >
> >     Basically, I have three scopes:
> >
> >     * uma_protection, that should be mapped to client applications acting
> > as resource servers, only.
> >     * uma_authorization and kc_entitlement, that should be mapped to users
> > as a client role for a given client app acting as a resource server.
> > Ideally.
> >
> >     In an ideal world (for privacy reasons), when you try to access a
> > protected resource that is protected with our authz stuff, the user must
> > consent access to his authorization data. So you may have a consent page
> > saying "Third-party wants access to uma_authorization/kc_entitlement in
> > Resource Server".
> >
> >     As I said, global roles can also be used here, but they are not
> > specific to a client and may not represent clearly the scope of access the
> > user is actually consenting.
> >
> > Thanks
> >
> > ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>, stian at redhat.com
> > Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, June 14, 2016 6:18:32 AM
> > Subject: Re: [keycloak-dev] Add roles to a client template
> >
> > Hey Pedro,
> >
> > the default roles are always automatically added to all newly created
> > users. They are not added to scopes of newly created clients (clients
> > have "Full scope allowed" by default anyway). To achieve something like
> > default scope, you can maybe add the roles to scope of some client
> > template and then add this client template to your client. The client
> > will then inherit all scopes. Is it something you meant?
> >
> > Marek
> >
> > On 13/06/16 23:52, Pedro Igor Silva wrote:
> > > Btw, is there any way to specify the entity (client or user) to which a
> > default role should be applied ?
> > >
> > > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: stian at redhat.com
> > > Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Monday, June 13, 2016 4:44:34 PM
> > > Subject: Re: [keycloak-dev] Add roles to a client template
> > >
> > > It is related with some simplifications to authz services configuration.
> > >
> > > In order to enable fine-grained authz, clients should be granted with
> > specific roles to gain access to authz services. In some cases, users must
> > consent access to his authorization data by third-party apps.
> > >
> > > When consenting access to his authorization data, the user is actually
> > consenting to a third-party app access to the protected resources at a
> > specific resource server. In this case, a client role can be used to
> > specify just that. Eg.: on the consent page you'll see a "uma_authorization
> > in client-application-A"
> > >
> > > I can also use realm roles to achieve the same result, but that would
> > not be specific to a resource server/client-app. Although still a valid
> > setup if the user wants so.
> > >
> > > What I want to do is just create a template with these roles. I was
> > expecting that the template could help me to avoid creating and assigning
> > these roles manually.
> > >
> > > This is not a blocker. As I said, realm roles can also be used to
> > achieve the same results.
> > >
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <sthorger at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Monday, June 13, 2016 3:20:37 PM
> > > Subject: Re: [keycloak-dev] Add roles to a client template
> > >
> > > Client templates can only store roles and scope. Not sure it makes sense
> > to
> > > add client roles, especially not since we're planning on introducing role
> > > namespaces in the future and that could conflict with the design around
> > > that.
> > >
> > > Can you elaborate on the use-case?
> > >
> > > On 13 June 2016 at 19:16, Pedro Igor Silva <psilva at redhat.com> wrote:
> > >
> > >> Is it possible to add client roles to a client template ? Would like to
> > >> provide a template with some default roles/scopes.
> > >>
> > >> Regards.
> > >> Pedro Igor
> > >> _______________________________________________
> > >> 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 mitya at cargosoft.ru  Wed Jun 15 10:46:07 2016
From: mitya at cargosoft.ru (Mitya)
Date: Wed, 15 Jun 2016 17:46:07 +0300
Subject: [keycloak-dev] Support for arbitrary byte arrays as HOTP keys
In-Reply-To: <CAJgngAfORA-sqdD9aPVk8DTEK3faXY3fgsHXXgJ6Tr59RnjHYg@mail.gmail.com>
References: <1465841665.12548.24.camel@cargosoft.ru>
	<CAJgngAfORA-sqdD9aPVk8DTEK3faXY3fgsHXXgJ6Tr59RnjHYg@mail.gmail.com>
Message-ID: <1466001967.4357.17.camel@cargosoft.ru>

> I'm not quite following the problem. You can encode the secret/key
> using?Base32. In fact this Keycloak already stores the secret as
> a?Base32 encoded string. We don't strictly support hardware tokens at
> the moment as there's no way to specify the secret, but you can
> probably do that through the admin endpoints.
Yep, I've already done it (via custom realm resources, since there is
no SPI for custom *admin* resources yet).
To be accurate: KeyCloak *stores* HOTP secrets as plain strings, but
transfers them to phones as Base32. For example:
s7hAVBHOOPvAnTa3w4mh - this is what is stored in the database (plain
string)
OM3W QQKW IJEE 6T2Q OZAW 4VDB GN3T I3LI - this is printed out to be
entered into FreeOTP / Google Authenticator
When authenticating, the plain string is converted to bytes and used as
a secret for HmacOTP. Since storage type is String/VARCHAR, such a
secret is limited to printable characters.
My intention was to use the KeyCloak's standard HOTP authenticator to
validate OTPs generated by hardware tokens. Unfortunately, tokens that
I'm?working with (namely Aladdin eToken PASS) are programmed with seeds
that contain arbitrary bytes, and therefore they cannot be stored into
Credential's "value" field.
But now it turns out that I'll have to implement custom authenticator
either way. Thus, I'll just store seeds as hex string and decode them
in my authenticator before calling HmacOTP. I'll probably use different
credential type, ex., "hotp+", in order not to mess up with KeyCloak
OTP.
By the way, do you think having a SPI for credential types could be a
good idea (custom/proprietary OTP algorithms; custom storage format,
like in my case)? At the moment, all the supported credential types
(password, HOTP/TOTP etc.) are hardcoded
into?org.keycloak.models.utils.CredentialValidation. If we had a SPI,
it would become possible to add new types without modifying KeyCloak
code - and all the code that
uses?context.getSession().users().validCredentials(...) could make use
of new credential types.
Cheers,
Mitya

> On 13 June 2016 at 20:14, Mitya > <mitya at cargosoft.ru>>  wrote:
> > The current KeyCloak HOTP implementation assumes that a HOTP key (aka
> > seed, aka initialization vector) is stored as string, and thus contains
> > only printable characters. However, the HOTP standard (RFC 4226)
> > doesn't impose any restrictions on key material; any arbitrary byte
> > array is acceptable.
> > > > Moreover, many hardware HOTP tokens are pre-programmed at the factory,
> > and do contain non-printable seeds. Even though KeyCloak doesn't
> > support hardware tokens out of the box, developers could implement it
> > by extending KeyCloak and employing existing algorithms. Unfortunately,
> > the existing convention (to store HOTP seeds as printable strings)
> > makes this impossible.
> > > > For the "password" credential type, the "value" field is already stored
> > as Base64. I think "hotp" credentials could also be stored as Base64 or
> > hex; another option would be to store the "value" field as BLOB (like
> > it's already done for the "salt" field).
> > > > I think I could produce a PR for this, I only need to know which
> > scenario is preferred.
> > > > Cheers,
> > Mitya
> > 

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

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

From shaun.willows at iblocks.co.uk  Wed Jun 15 11:31:04 2016
From: shaun.willows at iblocks.co.uk (Shaun Willows)
Date: Wed, 15 Jun 2016 15:31:04 +0000
Subject: [keycloak-dev] Help regarding Picketlink Feature Migration
Message-ID: <4F0A68C4564FBB40A9AD1ACB5C350CC1034B201FD0@AD-IB-WIN01.iblocks.co.uk>

We are evaluating security frameworks for new application(s) within our organisation. Picketlink provides a number of features that are desirable to us as an organisation. However, as I understand, Picketlink is being migrated into Keycloak, and this process started in March 2015. Is it possible to provide any updates regarding the migration of the following features:

*         Picketlink's Java EE integration (particularly its integration with the DeltaSpike security interceptor) is especially useful to us. Will Keycloak provide similar CDI / Java EE integration? The FAQ at http://picketlink.org/keycloak-merge-faq/ indicates that this was planned to be the case, but I cannot see any progress on this issue in the Keycloak Github or JIRA.

*         Picketlink's IDM capabilities included a JPA IDM and the ability to easily create new IDMs. How can this be achieved in Keycloak?

*         Picketlink's capability to provide custom authenticators and token providers is also useful to us. How can this be achieved in Keycloak?

I appreciate the need to consolidate projects within Red Hat, however as Picketlink is not being actively developed and there is no clear migration path from Picketlink to Keycloak for a number of features, users of both frameworks are left with no interim solution.

Thanks for any help in this regard

Shaun Willows

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

From bburke at redhat.com  Wed Jun 15 11:33:01 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Jun 2016 11:33:01 -0400
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <57611632.9080300@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
Message-ID: <01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>

This redesign is quite complex as you have to take a lot of variables 
into account.  I also am trying to make things backward compatible and 
have the new SPI co-exist with the old.  Just remember though, the 
biggest reason for this rewrite is to AVOID IMPORTING!

Here's what I'm currently doing:

Federated Data
--------------
There will be a built-in federated user data service.  It exists to 
store additional data about a user, for example:

public interface UserAttributeFederatedStorage {
     void setSingleAttribute(RealmModel realm, UserModel user, String 
name, String value);
     void setAttribute(RealmModel realm, UserModel user, String name, 
List<String> values);
     void removeAttribute(RealmModel realm, UserModel user, String name);
     MultivaluedHashMap<String, String> getAttributes(RealmModel realm, 
UserModel user);
}

There will be federated storage options for all data.

User Storage Provider SPI
-----------------
Current UserProvider is going to be split up into smaller interface. 
SPI will remain the same though.  There is going to be a 
UserStorageProvider SPI.  Instances can implement one or more of the 
smaller UserProvider interfaces.

User Storage Provider instances will be returning UserModel instances. 
This means providers will be responsible for implementing some sort of 
UserAdapter implementation.  These custom UserAdapters will be 
responsible for interacting with the Federated Data Store and their 
custom storage:  Merging data between i.e. LDAP and the Federated 
Storage, managing which store stores what data, managing what data lives 
where.  Going to provide a helper abstract UserAdapter class that helps 
managing this data.

There will be a UserStorageManager class that implements all 
UserProvider instances.  Our caching layer will delegate to that instead 
of the actual storage provider.  The UserStorageManager will work 
similarly to UserFederationManager.  So, it would work like this:

1. session.users().getUserByUsername(realm, username)
2. User cache looks in cache, doesn't find it,
3. UserStorageManager.getUserByUsername()
4. UserStorageManager iterates all UserStorageProviders looking to see 
which one offers session.users().getUserByUsername() and invoke it.
5. LDAP.getUserByUsername()
6. LDAP finds the user, creates a UserAdapter, returns it.
7. User cache gets the UserModel returned by LDAP, it caches exactly 
like it is implemented now.  The LDAP UserAdapter, is responsible for 
pulling data and merging it from LDAP store and Federation Store.

User ids are an URN

"f:" + providerId + ":" + provider-user-metadata

UserStorageManager.getUserById() will parse the ID and call directly on 
the UserStorageProvider that initially loaded the user.

Updates are invoked directly on UserModel class.  LDAP UserAdapter will 
be responsible for figuring out what data is stored/updated in LDAP and 
what should be stored in Federated Storage.

More comments follow:


On 6/15/16 4:47 AM, Marek Posolda wrote:
> Hi Bill,
>
> few notes from me. I am mostly adding the scenarios, which will be good
> to support/improve or which we should still keep supporting after
> refactoring IMO. Sorry for bit longer email :)
>
> Note: When I talk "LDAP", I usually mean "LDAP or any other 3rd party
> federation storage"
>
>
> Persistent vs. Transient modes
> ----------------------------------------
>
> I think we should still keep some support for "persistent" mode (the
> case when user is imported to Keycloak local DB).
>

I want to get rid of import and only have it as an option for Brokering 
or for transient users (users that can't be looked up from a store out 
of band).  The LDAP adapter will be responsible for knowing what data is 
stored in LDAP and what data is stored in the Federated Store, so there 
is no need to "import"


> Assuming the scenario:
> - john is imported from LDAP with "unsynced" mode
> - john changes his password in account management. LDAP is unsynced
> (read-only), so the password needs to be changed in Keycloak storage
> - After server restart, john should have set the new password, not the
> old one from LDAP. Hence the only possibility seems to keep support for
> "import" this user into Keycloak DB and have user persistent.
>
> The similar situation applies for any update of user, which can't be
> saved back to LDAP (either because LDAP is read-only or because it
> doesn't support store the keycloak metadata like social links, consents,
> required actions etc)
>
> Regarding this, I am thinking about possible import modes like:
> 1) Persistent : User attributes from LDAP are imported into Keycloak DB
> (same behaviour like now)
>

No more importing.

> 2) Transient : User attributes from LDAP are not imported into Keycloak
> DB, but just cached locally. Any updates of the user are either dropped
> after server restart or disallowed. For example: Maybe consents can be
> just dropped, but some other things like requiredRoles should be rather
> disallowed to change? For example if admin adds some requiredAction to
> user "john", the requiredAction shouldn't disappear after server
> restart. This would be a security hole IMO. So in that case, if admin
> tries to manually add requiredAction to such user, the exception will be
> thrown so admin is aware that this is not supported. Anyway, for support
> any writing to cache, the cache will need to be replicated though (for
> example: user consent saved into cache on node1 should be visible on
> node2 as well).
>


> 3) Hybrid : LDAP user is not imported into Keycloak DB immediatelly.
> They are imported "on-demand" after user is updated and the update can't
> be saved to LDAP
>

No more on-demand loading of data.  IIRC, we discussed this in Brno. 
LDAP users will be cached in the same way JPA Users currently are.



>
> Caching
> -----------
>
> I hope new SPI will allow us more flexibility to support various
> scenarios. It will be good to support at least those IMO:
>

See above.  LDAP users will be cached in same way JPA Users currently are.

> 3) I agree that will be cool to support different expiration time based
> if it's LDAP user or just Keycloak-local user. Infinispan allows it
> though with something like : cache.put("ldapuser", ldapUser, 60,
> TimeUnit.SECONDS);
>

I think this will be an option that we will want to support.

>
>
> Transactions and 3rd party updates
> -----------------------------------------------
>
> - Will be good to improve registration of user to LDAP. Ideally during
> registration new user to LDAP, we should allow to send all data at once.
> (currently UserFederationProvider.register supports sending just
> username). Also we should allow to specify if register to 3rd party
> provider should be done *before* or *after* the registration to Keycloak
> local DB. For details, see https://issues.jboss.org/browse/KEYCLOAK-1075
> and all the comments from users...
>
> - Also updating user should be ideally at once. For example if you call:
> user.setFirstName("john");
> user.setLastName("Doe");
> user.setEmail("john at email.cz");
>
> we shouldn't have 3 update calls to LDAP, but just one. Maybe we can
> address this with transaction abstraction? I've already did something
> for LDAP provider (see TxAwareLDAPUserModelDelegate ), however will be
> good to provide something more generic for user storage SPI. Then when
> KeycloakTransactionManager.commit is called, the data are send to
> federation storage
>

This would be an implementation detail.  Similar to JPA Users, the LDAP 
UserAdapter will be remembered per session.  The LDAP adapter could 
queue up updates then at commit time flush them all.

Maybe you should consider writing an LDAP version of JPA?  ;-)  Probably 
a lot of code could be borrowed from PL IDM API.



>
> Sync users
> --------------
> We should still keep the option to sync users into Keycloak DB as we
> have now. Note some persistent storages like LDAP are limited with
> pagination. So the easiest possibility for some admins is just to sync
> users, so they can easily search them in admin console.
>
Doing a full import just to support pagination is overkill.  I'm 
guessing that a lot of deployments will not manage users through the 
Keycload admin console.  We can offer a manual a Sync SPI that providers 
can implement.




>
> Proxy yes/no?
> ------------------
>

Proxy yes, but it won't work the same.  See above.

Bill

From bburke at redhat.com  Wed Jun 15 11:40:14 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Jun 2016 11:40:14 -0400
Subject: [keycloak-dev] Help regarding Picketlink Feature Migration
In-Reply-To: <4F0A68C4564FBB40A9AD1ACB5C350CC1034B201FD0@AD-IB-WIN01.iblocks.co.uk>
References: <4F0A68C4564FBB40A9AD1ACB5C350CC1034B201FD0@AD-IB-WIN01.iblocks.co.uk>
Message-ID: <a238c9b5-149c-c0d5-103b-2d821357fbb6@redhat.com>

We are getting out of the role-your-own IDP business and instead, 
providing an actual IDP.  This means no more PL IDM API.  The majority 
of our efforts have been focused at the IDP side, and not the SP side. 
We hope to eventually have some of the useful annotations like in PL's 
Java EE integration but we haven't had the cycles to do it.  The IDP 
(Keycloak) does have custom authenticator SPI.  It also has a custom 
user federation SPI.  It has LDAP support out of the box too.

On 6/15/16 11:31 AM, Shaun Willows wrote:
> We are evaluating security frameworks for new application(s) within our
> organisation. Picketlink provides a number of features that are
> desirable to us as an organisation. However, as I understand, Picketlink
> is being migrated into Keycloak, and this process started in March 2015.
> Is it possible to provide any updates regarding the migration of the
> following features:
>
> ?         Picketlink?s Java EE integration (particularly its integration
> with the DeltaSpike security interceptor) is especially useful to us.
> Will Keycloak provide similar CDI / Java EE integration? The FAQ at
> http://picketlink.org/keycloak-merge-faq/ indicates that this was
> planned to be the case, but I cannot see any progress on this issue in
> the Keycloak Github or JIRA.
>
> ?         Picketlink?s IDM capabilities included a JPA IDM and the
> ability to easily create new IDMs. How can this be achieved in Keycloak?
>
> ?         Picketlink?s capability to provide custom authenticators and
> token providers is also useful to us. How can this be achieved in Keycloak?
>
>
>
> I appreciate the need to consolidate projects within Red Hat, however as
> Picketlink is not being actively developed and there is no clear
> migration path from Picketlink to Keycloak for a number of features,
> users of both frameworks are left with no interim solution.
>
>
>
> Thanks for any help in this regard
>
>
>
> Shaun Willows
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From brooks.isoldi at traversed.com  Wed Jun 15 13:10:43 2016
From: brooks.isoldi at traversed.com (Brooks Isoldi)
Date: Wed, 15 Jun 2016 13:10:43 -0400
Subject: [keycloak-dev] Disappearing Keycloak deployment
In-Reply-To: <5755E64D.1090809@redhat.com>
References: <5751E0E9.7030708@traversed.com>
	<CAJgngAeOLUsEmhnvE4XtmeiZ+ns1iy7006hN33UoJsvv+zanmw@mail.gmail.com>
	<57558E2B.1010307@traversed.com>
	<CAJgngAeVwuGyWf_2FUNemjA_42Q4GCgiTyaPRWiUZt9om5kbEw@mail.gmail.com>
	<5755BECD.2060801@traversed.com> <5755D663.1050800@traversed.com>
	<5755DE4A.2060004@redhat.com> <5755E345.6040703@traversed.com>
	<5755E64D.1090809@redhat.com>
Message-ID: <57618C13.4060806@traversed.com>

Stian,

To follow up to this issue, we deployed Keycloak alone and restarted 
wildfly a number of times in different ways (sudo service wildfly 
restart / stop, CLI) and could not reproduce this.  It seems that the 
only way we could (unreliably) reproduce this issue is if there is 
another application deployed to Wildfly.  Not sure at all why it would 
happen with another application there, but we'll proceed with KC on its 
own instance.

Thanks.



-Brooks

On 06/06/2016 05:08 PM, Stan Silvert wrote:
> On 6/6/2016 4:55 PM, Brooks Isoldi wrote:
>> We will give it a shot and try to reproduce with just the 
>> keycloak-server.war file alone.
>>
>> Meanwhile, can you give some instruction on how to tie my application 
>> into the Keycloak authentication?  The manual says to drop the 
>> following into the web.xml file:
>>
>>     <login-config>
>>         <auth-method>KEYCLOAK</auth-method>
>>         <realm-name>app-name</realm-name>
>>     </login-config>
> You will still need the auth-method.
>>
>> I assume that will not work if keycloak resides on a totally separate 
>> server...Or will that be taken care of by the "auth-server-url" in 
>> the keycloak.json file?
> See the section on how to use the WildFly adapter for your 
> application/client. 
> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#jboss-adapter
>>
>> Thanks.
>>
>>
>>
>>
>> On 06/06/2016 04:34 PM, Stan Silvert wrote:
>>> We strongly, strongly, strongly discourage application deployment on 
>>> the Keycloak server. In fact, we might soon be taking steps keep 
>>> people from doing that.
>>>
>>> Can you re-create the problem with the Keycloak server alone?
>>>
>>> On 6/6/2016 4:00 PM, Brooks Isoldi wrote:
>>>> Stian,
>>>>
>>>> I apologize, by "non-JEE" application, I meant only that it does 
>>>> not rely on standalone-full.xml.  We're using only standalone.xml 
>>>> for the application deployed to the keycloak wildfly server.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>>
>>>> On 06/06/2016 02:19 PM, Brooks Isoldi wrote:
>>>>> Bill,
>>>>>
>>>>> We do not see the war being redeployed upon startup.
>>>>>
>>>>>
>>>>> Stian,
>>>>>
>>>>> We are deploying a non-JEE application to the Keycloak Wildfly 
>>>>> instance and our initial setup process includes the following 
>>>>> commands:
>>>>>
>>>>>
>>>>> sudo ./jboss-cli.sh -c <<EOF
>>>>> module add --name=org.postgres 
>>>>> --resources=${KEYCLOAK_INSTALL_DIR}/${JDBC_FILENAME} 
>>>>> --dependencies=javax.api,javax.transaction.api
>>>>> /subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver)
>>>>> data-source add --jndi-name=java:/PostgresDS --name=PostgrePool 
>>>>> --connection-url=jdbc:postgresql://${POSTGRES_SERVER_URL} 
>>>>> --driver-name=postgres --user-name=<<USERNAME>> 
>>>>> --password=<<PASSWORD>>
>>>>> /core-service=management/security-realm=ApplicationRealm/server-identity=ssl/:add(keystore-path=keystore.jks, 
>>>>> keystore-relative-to=jboss.server.config.dir, 
>>>>> keystore-password=<<PASSWORD>>, alias=keystore, 
>>>>> key-password=<<PASSWORD>>)
>>>>> EOF
>>>>>
>>>>> sleep 10
>>>>>
>>>>> sudo service wildfly restart
>>>>>
>>>>> sleep 10
>>>>>
>>>>> sudo ./jboss-cli.sh -c <<EOF
>>>>> /subsystem=undertow/server=default-server/https-listener=https/:add(socket-binding=https, 
>>>>> security-realm=ApplicationRealm)
>>>>> EOF
>>>>>
>>>>> sleep 10
>>>>>
>>>>> sudo service wildfly restart
>>>>>
>>>>> sleep 10
>>>>>
>>>>> cd ${KEYCLOAK_INSTALL_DIR}/bin
>>>>> sudo ./jboss-cli.sh -c --file=adapter-install.cli
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 06/06/2016 01:18 PM, Stian Thorgersen wrote:
>>>>>> Do you modify the standalone distribution in any way? Do you 
>>>>>> deploy applications to it? Anything else that you do to it that 
>>>>>> could affect this?
>>>>>>
>>>>>> On 6 June 2016 at 16:52, Brooks Isoldi 
>>>>>> <brooks.isoldi at traversed.com 
>>>>>> <mailto:brooks.isoldi at traversed.com>> wrote:
>>>>>>
>>>>>>     I'm using the standalone distribution of 1.9.4.Final.
>>>>>>
>>>>>>     We have had this issue after executing "sudo service wildfly
>>>>>>     restart" on command line.  We've also had it happen after
>>>>>>     starting Keycloak by simply running
>>>>>>     ./$JBOSS_HOME/bin/standalone.sh and after it starts up,
>>>>>>     hitting cntrl-c. Additionally, we think it happened once
>>>>>>     while running shutdown --restart=true within the JBOSS CLI.
>>>>>>
>>>>>>     This has happened numerous times now, however we have not
>>>>>>     been able to create a reliable reproduction procedure.  I
>>>>>>     don't have logs to share right now, however I have seen in
>>>>>>     the server.log references to keycloak-server.war being
>>>>>>     undeployed.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On 06/06/2016 02:00 AM, Stian Thorgersen wrote:
>>>>>>>     What version of Keycloak and what distribution (standalone,
>>>>>>>     overlay or demo) do you use?
>>>>>>>
>>>>>>>     On 3 June 2016 at 21:56, Brooks Isoldi
>>>>>>>     <brooks.isoldi at traversed.com> wrote:
>>>>>>>
>>>>>>>         I've configured Keycloak as a service on Ubuntu 14.04
>>>>>>>         and I'm finding
>>>>>>>         that terminating and restarting the Wildfly service
>>>>>>>         (sudo service
>>>>>>>         wildfly restart) sometimes results in the
>>>>>>>         keycloak-server.war being
>>>>>>>         undeployed and removed.
>>>>>>>
>>>>>>>         Other times it happens by restarting from within the CLI.
>>>>>>>
>>>>>>>         How do I restart Wildfly without terminating Keycloak?
>>>>>>>
>>>>>>>         Thank you.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>         -Brooks
>>>>>>>         _______________________________________________
>>>>>>>         keycloak-dev mailing list
>>>>>>>         keycloak-dev at lists.jboss.org
>>>>>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     keycloak-dev mailing list
>>>>>>     keycloak-dev at lists.jboss.org
>>>>>>     <mailto:keycloak-dev at lists.jboss.org>
>>>>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

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

From tomas at intrahouse.com  Wed Jun 15 16:16:59 2016
From: tomas at intrahouse.com (=?UTF-8?B?VG9tw6FzIEdhcmPDrWE=?=)
Date: Wed, 15 Jun 2016 21:16:59 +0100
Subject: [keycloak-dev] Verify access token when using SPI
Message-ID: <CALgk1PLgMOp=Ou6w=LkO4kaDuFm_re0cm8JwMkbS-mej4m0pCw@mail.gmail.com>

Look here, lines 197-200 and you'll find your answer:
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/IdentityBrokerService.java

Most of the arguments for the constructor of the authenticateBearerToken
method are injected each time the IdentityBrokerService is instantiated,
line 225 here:
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/RealmsResource.java

-- 


*Tom?s Garc?a P?rez*

*Software Developer*

*Intrahouse*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160615/d5ce9d00/attachment.html 

From psilva at redhat.com  Wed Jun 15 17:06:35 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 15 Jun 2016 17:06:35 -0400 (EDT)
Subject: [keycloak-dev] OIDC and SCIM
In-Reply-To: <985819362.19676255.1466024710120.JavaMail.zimbra@redhat.com>
Message-ID: <478629873.19676713.1466024795976.JavaMail.zimbra@redhat.com>

There are some initial discussions going on at OpenID Connect WG about SCIM.

Probably something to start tracking ....

Regards.
Pedro Igor

From desk3016 at live.com  Wed Jun 15 22:26:11 2016
From: desk3016 at live.com (Eric Son 3016)
Date: Wed, 15 Jun 2016 19:26:11 -0700
Subject: [keycloak-dev] Config File for token validator endpoints url in
 keycloak?
In-Reply-To: <CAJgngAfuNHQ=uyGyq1TRUkvdi18MBbtos4vunTJaGP8qC7QwKQ@mail.gmail.com>
References: <BAY172-W32E76D10F741212ED00495BE590@phx.gbl>,
	<CAJgngAfuNHQ=uyGyq1TRUkvdi18MBbtos4vunTJaGP8qC7QwKQ@mail.gmail.com>
Message-ID: <BAY172-W292404F2181595C1DCC85CBE560@phx.gbl>






Hi Stian,
For elaborating previous question, I am creating a authentication provider, which needs to
call an external API. The payloads needs be encrypted with a key before calling
the API. 
I want API URL and Path of the Key to be configurable, so that Ops
team can tweak that based on each environment. 
I?ll be using KeyCloak in
multi-tenant environment, so rather than configuring it at authenticator level
for each relam, we want to configure these settings at system level.

 

I came across this link http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html#d4e559
which shows how you can pass configuration to providers. 
I tried to do the same
thing for my authentication provider but that didn?t work. Not Sure if it
matters but I am using KeyCloak version 1.9.3.

 

This is what I put in keycloak-server.json. Here
?xyz-username-password-authenticator? is my provider ID. 

 

"authentication": {

                               
"xyz-username-password-authenticator": {

                                               
"tvUrl": "https://192.168.0.11/TokenValidator/TokenValidator.asmx"

                               
}

               
}

I also tried it by putting following configuration i.e. by
removing the ?authentication? element from above config.

 

"xyz-username-password-authenticator":
{

"tvUrl":
"https://192.168.0.11/TokenValidator/TokenValidator.asmx"

               
}

 

Can you please guide me how can I pass these configurations
to my authentication providers?
Thanks!
Best Regards,
WJ



Date: Mon, 6 Jun 2016 08:00:07 +0200
Subject: Re: [keycloak-dev] Config File for token validator endpoints url in keycloak?
From: sthorger at redhat.com
To: desk3016 at live.com
CC: keycloak-dev at lists.jboss.org

Please elaborate on what your use-case is.
On 3 June 2016 at 19:09, Eric Son 3016 <desk3016 at live.com> wrote:



Hi, 

I would like to use external token validator with the keycloak.
 Is there any existing configuration file for storing token validator API endpoints url and its public key info?
I want to set them up in "System level" rather than the "Execution level" in the code.

Thanks for the help!

Best Regards,

WJ

 		 	   		  

_______________________________________________

keycloak-dev mailing list

keycloak-dev at lists.jboss.org

https://lists.jboss.org/mailman/listinfo/keycloak-dev


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

From sthorger at redhat.com  Wed Jun 15 22:57:59 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 16 Jun 2016 04:57:59 +0200
Subject: [keycloak-dev] Config File for token validator endpoints url in
	keycloak?
In-Reply-To: <BAY172-W292404F2181595C1DCC85CBE560@phx.gbl>
References: <BAY172-W32E76D10F741212ED00495BE590@phx.gbl>
	<CAJgngAfuNHQ=uyGyq1TRUkvdi18MBbtos4vunTJaGP8qC7QwKQ@mail.gmail.com>
	<BAY172-W292404F2181595C1DCC85CBE560@phx.gbl>
Message-ID: <CAJgngAdjNWP09LdAs_CEzUWO+LdLAA=YD-eoi_VkZRL49R7sqg@mail.gmail.com>

The SPI is called "authenticator", not "authentication", so it should be:

"authenticator": {

                                "xyz-username-password-authenticator": {

                                                "tvUrl": "
https://192.168.0.11/TokenValidator/TokenValidator.asmx"

                                }

                }


Assuming "xyz-username-password-authenticator" is what's returned by your
factories getId method.

On 16 June 2016 at 04:26, Eric Son 3016 <desk3016 at live.com> wrote:

> Hi Stian,
>
>
> For elaborating previous question, I am creating a authentication
> provider, which needs to call an external API.
>
> The payloads needs be encrypted with a key before calling the API.
>
>
> I want API URL and Path of the Key to be configurable, so that Ops team
> can tweak that based on each environment.
>
>
> I?ll be using KeyCloak in multi-tenant environment, so rather than
> configuring it at authenticator level for each relam, we want to configure
> these settings at system level.
>
>
>
> I came across this link
> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html#d4e559
> which shows how you can pass configuration to providers.
>
>
> I tried to do the same thing for my authentication provider but that
> didn?t work. Not Sure if it matters but I am using KeyCloak version 1.9.3.
>
>
>
> This is what I put in keycloak-server.json. Here
> ?xyz-username-password-authenticator? is my provider ID.
>
>
>
> "authentication": {
>
>                                 "xyz-username-password-authenticator": {
>
>                                                 "tvUrl": "
> https://192.168.0.11/TokenValidator/TokenValidator.asmx"
>
>                                 }
>
>                 }
>
> I also tried it by putting following configuration i.e. by removing the
> ?authentication? element from above config.
>
>
>
> "xyz-username-password-authenticator": {
>
> "tvUrl": "https://192.168.0.11/TokenValidator/TokenValidator.asmx"
>
>                 }
>
>
>
> Can you please guide me how can I pass these configurations to my
> authentication providers?
>
>
> Thanks!
>
>
> Best Regards,
>
>
> WJ
>
>
> ------------------------------
> Date: Mon, 6 Jun 2016 08:00:07 +0200
> Subject: Re: [keycloak-dev] Config File for token validator endpoints url
> in keycloak?
> From: sthorger at redhat.com
> To: desk3016 at live.com
> CC: keycloak-dev at lists.jboss.org
>
>
> Please elaborate on what your use-case is.
>
> On 3 June 2016 at 19:09, Eric Son 3016 <desk3016 at live.com> wrote:
>
> Hi,
>
> I would like to use external token validator with the keycloak.
>  Is there any existing configuration file for storing token validator API
> endpoints url and its public key info?
> I want to set them up in "System level" rather than the "Execution level"
> in the code.
>
> Thanks for the help!
>
> Best Regards,
>
> WJ
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160616/2c2f2e62/attachment.html 

From sthorger at redhat.com  Wed Jun 15 23:02:37 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 16 Jun 2016 05:02:37 +0200
Subject: [keycloak-dev] Support for arbitrary byte arrays as HOTP keys
In-Reply-To: <1466001967.4357.17.camel@cargosoft.ru>
References: <1465841665.12548.24.camel@cargosoft.ru>
	<CAJgngAfORA-sqdD9aPVk8DTEK3faXY3fgsHXXgJ6Tr59RnjHYg@mail.gmail.com>
	<1466001967.4357.17.camel@cargosoft.ru>
Message-ID: <CAJgngAcToun_3chP6+1dKE2f_V5U1HFx7914=hjtp_XQQF6zeQ@mail.gmail.com>

We already have an SPI for authenticators, which allows you to create
custom authenticators without modifying Keycloak code. The code
in validCredentials pre-dates the authenticator SPI.

On 15 June 2016 at 16:46, Mitya <mitya at cargosoft.ru> wrote:

> I'm not quite following the problem. You can encode the secret/key
> using Base32. In fact this Keycloak already stores the secret as a Base32
> encoded string. We don't strictly support hardware tokens at the moment as
> there's no way to specify the secret, but you can probably do that through
> the admin endpoints.
>
>
> Yep, I've already done it (via custom realm resources, since there is no
> SPI for custom *admin* resources yet).
>
> To be accurate: KeyCloak *stores* HOTP secrets as plain strings, but
> transfers them to phones as Base32. For example:
>
> s7hAVBHOOPvAnTa3w4mh - this is what is stored in the database (plain
> string)
> OM3W QQKW IJEE 6T2Q OZAW 4VDB GN3T I3LI - this is printed out to be
> entered into FreeOTP / Google Authenticator
>
> When authenticating, the plain string is converted to bytes and used as a
> secret for HmacOTP. Since storage type is String/VARCHAR, such a secret is
> limited to printable characters.
>
> My intention was to use the KeyCloak's standard HOTP authenticator to
> validate OTPs generated by hardware tokens. Unfortunately, tokens that
> I'm working with (namely Aladdin eToken PASS) are programmed with seeds
> that contain arbitrary bytes, and therefore they cannot be stored into
> Credential's "value" field.
>
> But now it turns out that I'll have to implement custom authenticator
> either way. Thus, I'll just store seeds as hex string and decode them in my
> authenticator before calling HmacOTP. I'll probably use different
> credential type, ex., "hotp+", in order not to mess up with KeyCloak OTP.
>
> By the way, do you think having a SPI for credential types could be a good
> idea (custom/proprietary OTP algorithms; custom storage format, like in my
> case)? At the moment, all the supported credential types (password,
> HOTP/TOTP etc.) are hardcoded
> into org.keycloak.models.utils.CredentialValidation. If we had a SPI, it
> would become possible to add new types without modifying KeyCloak code -
> and all the code that
> uses context.getSession().users().validCredentials(...) could make use of
> new credential types.
>
> Cheers,
> Mitya
>
>
> On 13 June 2016 at 20:14, Mitya <mitya at cargosoft.ru> wrote:
>
> The current KeyCloak HOTP implementation assumes that a HOTP key (aka
> seed, aka initialization vector) is stored as string, and thus contains
> only printable characters. However, the HOTP standard (RFC 4226)
> doesn't impose any restrictions on key material; any arbitrary byte
> array is acceptable.
>
> Moreover, many hardware HOTP tokens are pre-programmed at the factory,
> and do contain non-printable seeds. Even though KeyCloak doesn't
> support hardware tokens out of the box, developers could implement it
> by extending KeyCloak and employing existing algorithms. Unfortunately,
> the existing convention (to store HOTP seeds as printable strings)
> makes this impossible.
>
> For the "password" credential type, the "value" field is already stored
> as Base64. I think "hotp" credentials could also be stored as Base64 or
> hex; another option would be to store the "value" field as BLOB (like
> it's already done for the "salt" field).
>
> I think I could produce a PR for this, I only need to know which
> scenario is preferred.
>
> Cheers,
> Mitya
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160616/39e9f202/attachment.html 

From sthorger at redhat.com  Thu Jun 16 02:44:05 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 16 Jun 2016 08:44:05 +0200
Subject: [keycloak-dev] Narrowed down event subjects for AdminEvents
In-Reply-To: <CAK-7U1i8fCbfU83RxQk9pMr7k5_dxZs1oLys3X73Gse2gaRVXg@mail.gmail.com>
References: <CAK-7U1i8fCbfU83RxQk9pMr7k5_dxZs1oLys3X73Gse2gaRVXg@mail.gmail.com>
Message-ID: <CAJgngAfeL4rQyoHuKztQndjrv4OvrSGTY0cAM=OUAS-=rSCQPQ@mail.gmail.com>

Sounds good to me

On 7 June 2016 at 11:22, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello Group,
>
> when writing custom EventListeners for propagating Keycloak Events to
> inform downstream systems
> of any user related changes one also needs to consider events that are
> caused by admins, e.g. AdminEvent.
>
> Examples are the grant / revoke of a role, group membership changes
> (derived roles) or user account changes
> performed by an admin user.
>
> Currently it is not possible to differentiate those admin events when
> looking at the AdminEvent object
> without actually parsing / inspecting the representation. This makes it
> rather complicated to correctly react
> specfic ways for an AdminEvent, e.g. on a Role Membership change, detect
> and resolve the new role, the user involved and propagate that to the
> downstream systems.
>
> With https://issues.jboss.org/browse/KEYCLOAK-2961 I tried a simple
> workround by adding the
> actual realm resource paths to the AdminEvent objekt which allows me to
> deduce what actually happend.
>
> Since the associated PR (https://github.com/keycloak/keycloak/pull/2774)
> was rejected I think a better solution would be to add dedicated "Event
> Subject" Information to the AdminEvents.
>
> Marek agreed that this would be a good idea in the PR discussion.
>
> Subjects could be an enum with "ROLE", "USER/ACCOUNT", "GROUP", however
> for ROLE one would need to differentiate between REALM_ROLE / CLIENT_ROLE
> (for proper lookup) and ROLE creation and ROLE_ASSIGNEMNT, same with GROUP.
>
> Together with the AdminEvent#OperationType one could deduce what
> happended, e.g.:
> Event Subject: ROLE_ASSIGNMENT
> Event OperationType: CREATE
> -> role was granted
>
> Event Subject: ROLE_ASSIGNMENT
> Event OperationType: DELETE
> -> role was revoked
>
> It would be great if the event would carry some narrowed context
> information (OperationContext?),
> e.g. in case of a CLIENT_ROLE ROLE_ASSIGNMENT: clientId, roleId, userId
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160616/01f9b4fc/attachment-0001.html 

From sthorger at redhat.com  Thu Jun 16 02:52:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 16 Jun 2016 08:52:24 +0200
Subject: [keycloak-dev] Proof of Concept for User Activity Dashboard
In-Reply-To: <CAK-7U1g-f8-OiEt6_2aJD8PP49OJZar9rQz8MyJpwopp0CY6kw@mail.gmail.com>
References: <CAK-7U1jeqDDaRRtfp_PpEpGveW0ntNm3FSFbdckZ3YeQFuhdZg@mail.gmail.com>
	<a671ed72-49fb-ac74-b65a-02bd323c767a@redhat.com>
	<CAK-7U1g-f8-OiEt6_2aJD8PP49OJZar9rQz8MyJpwopp0CY6kw@mail.gmail.com>
Message-ID: <CAJgngAc3M2SHaD-dkAuyv9uisk99W1sKoY-EBu2L_C+dF+tZXw@mail.gmail.com>

On 31 May 2016 at 19:42, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello Bill,
>
> I didn't say that using JPA to store event data would lead to bad
> performance :-)
> it's just that querying and aggregating event data via JPA(QL) is a pain
> ...
> and I didn't want to potentially pull 100k+ events into memory to compute
> the stats in Java.
>
> I wanted to keep the processing in the Keycloak JVM as low as possible to
> not risk any
> OOME scenarios (though one could also use batch fetching here...).
>
> That's the reason why I used a view that uses database specific means to
> do so.
>
> With that said recording events with JPA is fine IMHO - though it could be
> done asynchronously in the background.
> My current approach for computing stats only relies on the already stored
> event_entity data,
> which of course needs to be persisted then - currently I don't need to
> store anything.
>
> But since the event_entity data can be deleted I'd proposed to
> periodically compute
> aggregates based on those when a day is over. It could then compute stuff
> like:
>
> * totalUserCount                 - how many users do we have in the realm?
> * totalLoginCount                - how many users did login on that
> particular day?
> * totalLoginFailedCount          - how many logins failed on that day?
> * totalLoginBlockedCount         - how many failed logins lead to blocked
> accounts?
> * totalRegisterCount             - how many users did register on that day?
> * totalAbortedRegistrationsCount - how many users abandonned the
> registration?
> - per realm per day.
>

That sounds like a much better approach. Actually it could run every N
minutes with the timer provider. If it only fetches the last N minutes of
events it's not going to be a huge query, but probably still worth doing it
in batches (1K max at the time or something?).

One issue here is that the timer is currently executed on all nodes, while
this particular one should only run on one node.


>
> Similar stats could also be held by each keycloak instance in-memory and
> shared via infinispan.
> Those stats could then also periodically aggregated (every 5 mins) to give
> information near real-time.
>

Not sure that's necessary. Having the timer run periodically should be
sufficient. It should definitively be a secondary requirement and possible
to disable.


>
> Regarding the rare usage of this info I'd argue that the dashboard should
> actually be the first
> page that an administrator sees when logging in to Keycloak (after initial
> setup of course) -
> I think it gives you a lot more than just a few stats - e.g. the
> possibility to login
> see patterns and identify potential problems this probably consulted
> multiple times a day by multiple
> people - especially if one uses a lot of different tenants.
>

I agree it should be the main page, but thousands of users could be
logging-in a second, while only one or two admins login to the admin
console a day. So compared to logins, it's rare.


>
> Cheers,
> Thomas
>
> 2016-05-31 6:15 GMT+02:00 Bill Burke <bburke at redhat.com>:
>
>> I didn't read whole thread on this:  Having a JPA event store would be
>> bad performance?  Isn't there more than one even per login?  That means
>> multiple DB inserts per login just to gather stats.  Stats that would be
>> looked at rarely (once a day?  once a week?  once a month?)  Just something
>> to think about.
>>
>> On 5/29/16 4:52 PM, Thomas Darimont wrote:
>>
>> Hello group,
>>
>> a few months ago I raised the feature request "Activity dashboard" in the
>> Keycloak JIRA.
>> https://issues.jboss.org/browse/KEYCLOAK-1840
>>
>> This weekend I gave this a spin and I think I got pretty far with it,
>> see attached annotated screenshot.
>>
>> The idea was to leverage the information from the stored event data
>> to compute some Keycloak usage statistics over time.
>> My current prototype supports JPA (user / event) storage provider
>> and works with postgresql but could be adapted to other databases
>> including MongoDB.
>>
>> Since I need to compute the usage statistics based on the event data,
>> events need to be stored and some views (3) need to be defined to
>> make the data accessible from JPA in a generic fashion.
>>
>> Since the queries are quite complex I wanted to keep them out
>> of the code and therefore used named native queries via orm.xml.
>> The actual queries use some database specific date/time functions
>> that I wanted to keep out of the code - thus I created views
>> that could be adapted for each database and provisioned via liquibase.
>>
>> The view definitions can be found here:
>> https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e
>>
>> For MongoDB one could define appropriate aggregation framework pipelines
>> to express the same query logic.
>>
>> I basically exposed the data from those views per realm via a newly
>> introduced AnalyticsProvider interface that is accessible via
>> KeycloakSession.
>>
>> Data from this AnalyticsProvider is then exposed as a REST resource
>> called "DashboardResource".
>> Data from this REST endpoint is then consumed by the admin frontend in a
>> new section
>> called "dashboard".
>>
>> In the frontend I used basic patternfly components, e.g.: cards & tables:
>> https://rawgit.com/patternfly/patternfly/master/tests/cards.html
>>
>> For the heatmap I used http://cal-heatmap.com/#start which is based on
>> d3js.
>> There is also an angularjs directive that could be used as well.
>> https://github.com/shekhargulati/angular-cal-heatmap-directive
>>
>> The current hacky code can be found here.:
>>
>> https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dashboard
>>
>> The relevant commit is:
>>
>> https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2ddbaf27961f2a852203
>>
>> The code still needs a decent amount of polishing but I wanted to share
>> this with
>> you guys first to see if this could make it into Keycloak at some point.
>>
>> Cheers,
>> Thomas
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160616/89dab3e6/attachment.html 

From mposolda at redhat.com  Thu Jun 16 05:23:28 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 16 Jun 2016 11:23:28 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
Message-ID: <57627010.4010003@redhat.com>

On 15/06/16 17:33, Bill Burke wrote:
> This redesign is quite complex as you have to take a lot of variables 
> into account.  I also am trying to make things backward compatible and 
> have the new SPI co-exist with the old. Just remember though, the 
> biggest reason for this rewrite is to AVOID IMPORTING!
>
> Here's what I'm currently doing:
>
> Federated Data
> --------------
> There will be a built-in federated user data service.  It exists to 
> store additional data about a user, for example:
>
> public interface UserAttributeFederatedStorage {
>     void setSingleAttribute(RealmModel realm, UserModel user, String 
> name, String value);
>     void setAttribute(RealmModel realm, UserModel user, String name, 
> List<String> values);
>     void removeAttribute(RealmModel realm, UserModel user, String name);
>     MultivaluedHashMap<String, String> getAttributes(RealmModel realm, 
> UserModel user);
> }
>
> There will be federated storage options for all data.
>
> User Storage Provider SPI
> -----------------
> Current UserProvider is going to be split up into smaller interface. 
> SPI will remain the same though.  There is going to be a 
> UserStorageProvider SPI.  Instances can implement one or more of the 
> smaller UserProvider interfaces.
>
> User Storage Provider instances will be returning UserModel instances. 
> This means providers will be responsible for implementing some sort of 
> UserAdapter implementation.  These custom UserAdapters will be 
> responsible for interacting with the Federated Data Store and their 
> custom storage:  Merging data between i.e. LDAP and the Federated 
> Storage, managing which store stores what data, managing what data 
> lives where.  Going to provide a helper abstract UserAdapter class 
> that helps managing this data.
Ok. Am I understand correctly that "smaller" providers are not limited 
to be either fully-LDAP based or fully-localDB based? For example I want 
"attribute-a" of user "john" to be stored in LDAP, however "attribute-b" 
of same user will be stored in local DB. From what you wrote, I assume 
it will work as UserAdapter can delegate to other store if it doesn't 
find "attribute-b" in LDAP?


Adding again the scenario with requiredActions, which we currently 
support and which we briefly discussed on F2F. I am adding it just to 
ensure that we won't loose the support for this :)
- Password in MSAD is expired
- Keycloak reads some corresponding attribute from MSAD and it sets 
UPDATE_PASSWORD requiredAction on the user based on it
- Keycloak asks user to update password and this is then propagated to MSAD

In other words, just the UPDATE_PASSWORD requiredAction is handled by 
MSAD, but all the other required actions need to be handled by Keycloak 
local DB.


>
> There will be a UserStorageManager class that implements all 
> UserProvider instances.  Our caching layer will delegate to that 
> instead of the actual storage provider.  The UserStorageManager will 
> work similarly to UserFederationManager.  So, it would work like this:
>
> 1. session.users().getUserByUsername(realm, username)
> 2. User cache looks in cache, doesn't find it,
> 3. UserStorageManager.getUserByUsername()
> 4. UserStorageManager iterates all UserStorageProviders looking to see 
> which one offers session.users().getUserByUsername() and invoke it.
> 5. LDAP.getUserByUsername()
> 6. LDAP finds the user, creates a UserAdapter, returns it.
> 7. User cache gets the UserModel returned by LDAP, it caches exactly 
> like it is implemented now.  The LDAP UserAdapter, is responsible for 
> pulling data and merging it from LDAP store and Federation Store.
>
> User ids are an URN
>
> "f:" + providerId + ":" + provider-user-metadata
>
> UserStorageManager.getUserById() will parse the ID and call directly 
> on the UserStorageProvider that initially loaded the user.
>
> Updates are invoked directly on UserModel class.  LDAP UserAdapter 
> will be responsible for figuring out what data is stored/updated in 
> LDAP and what should be stored in Federated Storage.
>
> More comments follow:
>
>
> On 6/15/16 4:47 AM, Marek Posolda wrote:
>> Hi Bill,
>>
>> few notes from me. I am mostly adding the scenarios, which will be good
>> to support/improve or which we should still keep supporting after
>> refactoring IMO. Sorry for bit longer email :)
>>
>> Note: When I talk "LDAP", I usually mean "LDAP or any other 3rd party
>> federation storage"
>>
>>
>> Persistent vs. Transient modes
>> ----------------------------------------
>>
>> I think we should still keep some support for "persistent" mode (the
>> case when user is imported to Keycloak local DB).
>>
>
> I want to get rid of import and only have it as an option for 
> Brokering or for transient users (users that can't be looked up from a 
> store out of band).  The LDAP adapter will be responsible for knowing 
> what data is stored in LDAP and what data is stored in the Federated 
> Store, so there is no need to "import"
Ok, so LDAP data are not imported, however the non-LDAP data (or 
overwritten data) are read from local store right? So we still support 
the scenario with overwriting data (unsynced mode) like this?

- User from LDAP authenticates and his pasword is verified against LDAP
- User changes his password, but LDAP is read-only, so new password 
needs to be written to local DB
- User authenticates again, but now his password needs to be verified 
against local DB

>
>
>> Assuming the scenario:
>> - john is imported from LDAP with "unsynced" mode
>> - john changes his password in account management. LDAP is unsynced
>> (read-only), so the password needs to be changed in Keycloak storage
>> - After server restart, john should have set the new password, not the
>> old one from LDAP. Hence the only possibility seems to keep support for
>> "import" this user into Keycloak DB and have user persistent.
>>
>> The similar situation applies for any update of user, which can't be
>> saved back to LDAP (either because LDAP is read-only or because it
>> doesn't support store the keycloak metadata like social links, consents,
>> required actions etc)
>>
>> Regarding this, I am thinking about possible import modes like:
>> 1) Persistent : User attributes from LDAP are imported into Keycloak DB
>> (same behaviour like now)
>>
>
> No more importing.
>
>> 2) Transient : User attributes from LDAP are not imported into Keycloak
>> DB, but just cached locally. Any updates of the user are either dropped
>> after server restart or disallowed. For example: Maybe consents can be
>> just dropped, but some other things like requiredRoles should be rather
>> disallowed to change? For example if admin adds some requiredAction to
>> user "john", the requiredAction shouldn't disappear after server
>> restart. This would be a security hole IMO. So in that case, if admin
>> tries to manually add requiredAction to such user, the exception will be
>> thrown so admin is aware that this is not supported. Anyway, for support
>> any writing to cache, the cache will need to be replicated though (for
>> example: user consent saved into cache on node1 should be visible on
>> node2 as well).
>>
>
>
>> 3) Hybrid : LDAP user is not imported into Keycloak DB immediatelly.
>> They are imported "on-demand" after user is updated and the update can't
>> be saved to LDAP
>>
>
> No more on-demand loading of data.  IIRC, we discussed this in Brno. 
> LDAP users will be cached in the same way JPA Users currently are.
>
>
>
>>
>> Caching
>> -----------
>>
>> I hope new SPI will allow us more flexibility to support various
>> scenarios. It will be good to support at least those IMO:
>>
>
> See above.  LDAP users will be cached in same way JPA Users currently 
> are.
So if I understand correctly,we will loose the option (1), which we 
currently support like:

LDAP user data are always read from "online" LDAP in every request, but 
all other user data are cached, so no need to read them from local 
Keycloak DB (even for many hours).

In other words, we will have option to use different expiration times 
(ie. LDAP user is expired from cache every 5 minutes, when fully-local 
user is expired every 2 hours), however you will need to read each 5 
minutes all the data of user "john" from both LDAP and local-db, right?

However loosing this one is probably not so big issue....
>
>> 3) I agree that will be cool to support different expiration time based
>> if it's LDAP user or just Keycloak-local user. Infinispan allows it
>> though with something like : cache.put("ldapuser", ldapUser, 60,
>> TimeUnit.SECONDS);
>>
>
> I think this will be an option that we will want to support.
>
>>
>>
>> Transactions and 3rd party updates
>> -----------------------------------------------
>>
>> - Will be good to improve registration of user to LDAP. Ideally during
>> registration new user to LDAP, we should allow to send all data at once.
>> (currently UserFederationProvider.register supports sending just
>> username). Also we should allow to specify if register to 3rd party
>> provider should be done *before* or *after* the registration to Keycloak
>> local DB. For details, see https://issues.jboss.org/browse/KEYCLOAK-1075
>> and all the comments from users...
>>
>> - Also updating user should be ideally at once. For example if you call:
>> user.setFirstName("john");
>> user.setLastName("Doe");
>> user.setEmail("john at email.cz");
>>
>> we shouldn't have 3 update calls to LDAP, but just one. Maybe we can
>> address this with transaction abstraction? I've already did something
>> for LDAP provider (see TxAwareLDAPUserModelDelegate ), however will be
>> good to provide something more generic for user storage SPI. Then when
>> KeycloakTransactionManager.commit is called, the data are send to
>> federation storage
>>
>
> This would be an implementation detail.  Similar to JPA Users, the 
> LDAP UserAdapter will be remembered per session.  The LDAP adapter 
> could queue up updates then at commit time flush them all.
>
> Maybe you should consider writing an LDAP version of JPA?  ;-) 
> Probably a lot of code could be borrowed from PL IDM API.
I've wrote already something similar for Mongo ;) Also I already 
addressed the multiple-updates issue for LDAP (see above). However this 
one is mainly issue for 3rd party providers rather than for LDAP 
provider. Especially since 3rd party provider may have some validations 
for some attributes.


For example consider this scenario, which can happen in current 
implementation:

UserModel john = session.users().addUser(realm, "john");
john.setEmail("john at email.org");

All of this happens during "addUser" call:

- User "john" is saved to local-db
- SomeUserFederationProvider.register calls the registration request to 
3rd party federation storage. User "john" is saved in 3rd party storage now.

Then john.setEmail is invoked
- There is request to 3rd party federation storage to update email.
- 3rd party storage refuse to save the email because there is already an 
existing user with email "john at email.org" . So it sends back the 
validation error. Now keycloak can rollback the transaction, however 
user "john" was already registered in 3rd party federation storage from 
previous "register" call -> FAIL

So now you need to manually remove the user from 3rd party storage, 
which is dirty hack. There are other possible hacks to address this. For 
example someone "postpone" the registration in "register" method by 
adding some helper attributes and sends the registration request later 
when all the attributes are set. I suggest to read the comments in 
https://issues.jboss.org/browse/KEYCLOAK-1075 for details.

IMO the proper solution is to ensure that "register" request to 3rd 
party is postponed until the transaction.commit when user is filled with 
all the attributes. Similarly update should be done just once. IMO we 
should provide something at SPI level to simplify this scenario.

I understand that main motivation for you is to avoid "imports", however 
since we are refactoring anyway, we should try to address other SPI 
limitations too. And IMO this one is pretty bad and worth improve ;)
>
>
>
>>
>> Sync users
>> --------------
>> We should still keep the option to sync users into Keycloak DB as we
>> have now. Note some persistent storages like LDAP are limited with
>> pagination. So the easiest possibility for some admins is just to sync
>> users, so they can easily search them in admin console.
>>
> Doing a full import just to support pagination is overkill.  I'm 
> guessing that a lot of deployments will not manage users through the 
> Keycload admin console.  We can offer a manual a Sync SPI that 
> providers can implement.
Maybe it's overkill for 90% of deployments, but remaining 10% want to 
see all LDAP users in admin console immediatelly and hence want to sync 
them? IMO it's always good to have SPI flexible so it can easily support 
all the possible requirements. However I understand that it's not always 
possible...

Marek
>
>
>
>
>>
>> Proxy yes/no?
>> ------------------
>>
>
> Proxy yes, but it won't work the same.  See above.
>
> Bill


From bburke at redhat.com  Thu Jun 16 10:38:01 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 16 Jun 2016 10:38:01 -0400
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <57627010.4010003@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
Message-ID: <889fa832-c988-948c-2842-5348922f07dc@redhat.com>



On 6/16/16 5:23 AM, Marek Posolda wrote:
> On 15/06/16 17:33, Bill Burke wrote:
>> This redesign is quite complex as you have to take a lot of variables
>> into account.  I also am trying to make things backward compatible and
>> have the new SPI co-exist with the old. Just remember though, the
>> biggest reason for this rewrite is to AVOID IMPORTING!
>>
>> Here's what I'm currently doing:
>>
>> Federated Data
>> --------------
>> There will be a built-in federated user data service.  It exists to
>> store additional data about a user, for example:
>>
>> public interface UserAttributeFederatedStorage {
>>     void setSingleAttribute(RealmModel realm, UserModel user, String
>> name, String value);
>>     void setAttribute(RealmModel realm, UserModel user, String name,
>> List<String> values);
>>     void removeAttribute(RealmModel realm, UserModel user, String name);
>>     MultivaluedHashMap<String, String> getAttributes(RealmModel realm,
>> UserModel user);
>> }
>>
>> There will be federated storage options for all data.
>>
>> User Storage Provider SPI
>> -----------------
>> Current UserProvider is going to be split up into smaller interface.
>> SPI will remain the same though.  There is going to be a
>> UserStorageProvider SPI.  Instances can implement one or more of the
>> smaller UserProvider interfaces.
>>
>> User Storage Provider instances will be returning UserModel instances.
>> This means providers will be responsible for implementing some sort of
>> UserAdapter implementation.  These custom UserAdapters will be
>> responsible for interacting with the Federated Data Store and their
>> custom storage:  Merging data between i.e. LDAP and the Federated
>> Storage, managing which store stores what data, managing what data
>> lives where.  Going to provide a helper abstract UserAdapter class
>> that helps managing this data.
> Ok. Am I understand correctly that "smaller" providers are not limited
> to be either fully-LDAP based or fully-localDB based? For example I want
> "attribute-a" of user "john" to be stored in LDAP, however "attribute-b"
> of same user will be stored in local DB. From what you wrote, I assume
> it will work as UserAdapter can delegate to other store if it doesn't
> find "attribute-b" in LDAP?
>
>
> Adding again the scenario with requiredActions, which we currently
> support and which we briefly discussed on F2F. I am adding it just to
> ensure that we won't loose the support for this :)
> - Password in MSAD is expired
> - Keycloak reads some corresponding attribute from MSAD and it sets
> UPDATE_PASSWORD requiredAction on the user based on it
> - Keycloak asks user to update password and this is then propagated to MSAD
>
> In other words, just the UPDATE_PASSWORD requiredAction is handled by
> MSAD, but all the other required actions need to be handled by Keycloak
> local DB.
>

Yes that will work.  Because the provider is providing the UserAdapter, 
it has control over how things are pulled together.  I also intend to 
eventually allow federated-federated-storage.  So, you could lookup from 
LDAP, but gather attributes/role-mappings/etc. from another LDAP store, 
Keycloak, or other places.

>>>
>>> Persistent vs. Transient modes
>>> ----------------------------------------
>>>
>>> I think we should still keep some support for "persistent" mode (the
>>> case when user is imported to Keycloak local DB).
>>>
>>
>> I want to get rid of import and only have it as an option for
>> Brokering or for transient users (users that can't be looked up from a
>> store out of band).  The LDAP adapter will be responsible for knowing
>> what data is stored in LDAP and what data is stored in the Federated
>> Store, so there is no need to "import"
> Ok, so LDAP data are not imported, however the non-LDAP data (or
> overwritten data) are read from local store right? So we still support
> the scenario with overwriting data (unsynced mode) like this?
>
> - User from LDAP authenticates and his pasword is verified against LDAP
> - User changes his password, but LDAP is read-only, so new password
> needs to be written to local DB
> - User authenticates again, but now his password needs to be verified
> against local DB
>

We can provide some default behavior from the UserAdatper helper 
abstract class, but the provider is accountable for merging data.

>>>
>>> Caching
>>> -----------
>>>
>>> I hope new SPI will allow us more flexibility to support various
>>> scenarios. It will be good to support at least those IMO:
>>>
>>
>> See above.  LDAP users will be cached in same way JPA Users currently
>> are.
> So if I understand correctly,we will loose the option (1), which we
> currently support like:
>
> LDAP user data are always read from "online" LDAP in every request, but
> all other user data are cached, so no need to read them from local
> Keycloak DB (even for many hours).
>

Yeah, no more on-demand.  Either you cache or you don't.

> In other words, we will have option to use different expiration times
> (ie. LDAP user is expired from cache every 5 minutes, when fully-local
> user is expired every 2 hours), however you will need to read each 5
> minutes all the data of user "john" from both LDAP and local-db, right?
>
> However loosing this one is probably not so big issue....

The user cache will see one UserModel and load from there.  So, it 
caches LDAP and any other federated storage for the user that the 
UserModel provides.



>>
>>> 3) I agree that will be cool to support different expiration time based
>>> if it's LDAP user or just Keycloak-local user. Infinispan allows it
>>> though with something like : cache.put("ldapuser", ldapUser, 60,
>>> TimeUnit.SECONDS);
>>>
>>
>> I think this will be an option that we will want to support.
>>
>>>
>>>
>>> Transactions and 3rd party updates
>>> -----------------------------------------------
>>>
>>> - Will be good to improve registration of user to LDAP. Ideally during
>>> registration new user to LDAP, we should allow to send all data at once.
>>> (currently UserFederationProvider.register supports sending just
>>> username). Also we should allow to specify if register to 3rd party
>>> provider should be done *before* or *after* the registration to Keycloak
>>> local DB. For details, see https://issues.jboss.org/browse/KEYCLOAK-1075
>>> and all the comments from users...
>>>
>>> - Also updating user should be ideally at once. For example if you call:
>>> user.setFirstName("john");
>>> user.setLastName("Doe");
>>> user.setEmail("john at email.cz");
>>>
>>> we shouldn't have 3 update calls to LDAP, but just one. Maybe we can
>>> address this with transaction abstraction? I've already did something
>>> for LDAP provider (see TxAwareLDAPUserModelDelegate ), however will be
>>> good to provide something more generic for user storage SPI. Then when
>>> KeycloakTransactionManager.commit is called, the data are send to
>>> federation storage
>>>
>>
>> This would be an implementation detail.  Similar to JPA Users, the
>> LDAP UserAdapter will be remembered per session.  The LDAP adapter
>> could queue up updates then at commit time flush them all.
>>
>> Maybe you should consider writing an LDAP version of JPA?  ;-)
>> Probably a lot of code could be borrowed from PL IDM API.
> I've wrote already something similar for Mongo ;) Also I already
> addressed the multiple-updates issue for LDAP (see above). However this
> one is mainly issue for 3rd party providers rather than for LDAP
> provider. Especially since 3rd party provider may have some validations
> for some attributes.
>
>
> For example consider this scenario, which can happen in current
> implementation:
>
> UserModel john = session.users().addUser(realm, "john");
> john.setEmail("john at email.org");
>
> All of this happens during "addUser" call:
>
> - User "john" is saved to local-db
> - SomeUserFederationProvider.register calls the registration request to
> 3rd party federation storage. User "john" is saved in 3rd party storage
> now.
>
> Then john.setEmail is invoked
> - There is request to 3rd party federation storage to update email.
> - 3rd party storage refuse to save the email because there is already an
> existing user with email "john at email.org" . So it sends back the
> validation error. Now keycloak can rollback the transaction, however
> user "john" was already registered in 3rd party federation storage from
> previous "register" call -> FAIL
>
> So now you need to manually remove the user from 3rd party storage,
> which is dirty hack. There are other possible hacks to address this. For
> example someone "postpone" the registration in "register" method by
> adding some helper attributes and sends the registration request later
> when all the attributes are set. I suggest to read the comments in
> https://issues.jboss.org/browse/KEYCLOAK-1075 for details.
>
> IMO the proper solution is to ensure that "register" request to 3rd
> party is postponed until the transaction.commit when user is filled with
> all the attributes. Similarly update should be done just once. IMO we
> should provide something at SPI level to simplify this scenario.
>

We already have a KeycloakTransaction you can register with.

> I understand that main motivation for you is to avoid "imports", however
> since we are refactoring anyway, we should try to address other SPI
> limitations too. And IMO this one is pretty bad and worth improve ;)

So, have a method addUser(RealmModel realm, UserEntity user)?

>>
>>
>>
>>>
>>> Sync users
>>> --------------
>>> We should still keep the option to sync users into Keycloak DB as we
>>> have now. Note some persistent storages like LDAP are limited with
>>> pagination. So the easiest possibility for some admins is just to sync
>>> users, so they can easily search them in admin console.
>>>
>> Doing a full import just to support pagination is overkill.  I'm
>> guessing that a lot of deployments will not manage users through the
>> Keycload admin console.  We can offer a manual a Sync SPI that
>> providers can implement.
> Maybe it's overkill for 90% of deployments, but remaining 10% want to
> see all LDAP users in admin console immediatelly and hence want to sync
> them? IMO it's always good to have SPI flexible so it can easily support
> all the possible requirements. However I understand that it's not always
> possible...
>

This is only an issue for large query result sets where you want to do 
pagination.  IIRC, we couldn't figure out a way to do this in a scalable 
manner without imports.


From desk3016 at live.com  Thu Jun 16 12:01:29 2016
From: desk3016 at live.com (Eric Son 3016)
Date: Thu, 16 Jun 2016 09:01:29 -0700
Subject: [keycloak-dev] Config File for token validator endpoints url in
 keycloak?
In-Reply-To: <CAJgngAdjNWP09LdAs_CEzUWO+LdLAA=YD-eoi_VkZRL49R7sqg@mail.gmail.com>
References: <BAY172-W32E76D10F741212ED00495BE590@phx.gbl>,
	<CAJgngAfuNHQ=uyGyq1TRUkvdi18MBbtos4vunTJaGP8qC7QwKQ@mail.gmail.com>,
	<BAY172-W292404F2181595C1DCC85CBE560@phx.gbl>,
	<CAJgngAdjNWP09LdAs_CEzUWO+LdLAA=YD-eoi_VkZRL49R7sqg@mail.gmail.com>
Message-ID: <BAY172-W358F9DADF6579FEFE9DCC4BE560@phx.gbl>



Hi Stian,
Based on your response, I
changed the configuration to this. But in authenticator, I am not able to
access this config. 
Am I missing something? 



               
"authenticator": {

                               
"xyz-username-password-authenticator": {

                                               
"tvUrl": "https://192.168.0.11/TokenValidator/TokenValidator.asmx",

                                               


                               
}

               
}

 

Here is my authenticator
provider ID and provider configurations, Btw I can see this configuration in
the console with empty value. 



    public static final String PROVIDER_ID = "xyz-username-password-authenticator";

    public String getId() {

        return PROVIDER_ID;

    }

 

    private static final
List<ProviderConfigProperty> configProperties = new
ArrayList<ProviderConfigProperty>();

 

    static {

       
ProviderConfigProperty property;

        property = new
ProviderConfigProperty();

        property.setName("tvUrl");

        property.setLabel("Token
Validator URL");

        property.setType(ProviderConfigProperty.STRING_TYPE);

        property.setHelpText("Token
Validator URL.");

        configProperties.add(property);

    }
In my authenticator, I am
accessing config like this, but it doesn?t have value for this config.


       if(context.getAuthenticatorConfig().getConfig()
!= null) {

             
for (String key : context.getAuthenticatorConfig().getConfig().keySet())
{

      
              log.info("Config Key:
" +
key + ", Value:
" +
context.getAuthenticatorConfig().getConfig().get(key));

             
}

       }


Did you see what I have missed, any? Thanks!

Best Regards,WJ



Date: Thu, 16 Jun 2016 04:57:59 +0200
Subject: Re: [keycloak-dev] Config File for token validator endpoints url in keycloak?
From: sthorger at redhat.com
To: desk3016 at live.com
CC: keycloak-dev at lists.jboss.org

The SPI is called "authenticator", not "authentication", so it should be:
"authenticator": {                                "xyz-username-password-authenticator": {                                                "tvUrl": "https://192.168.0.11/TokenValidator/TokenValidator.asmx"                                }                }
Assuming "xyz-username-password-authenticator" is what's returned by your factories getId method.
On 16 June 2016 at 04:26, Eric Son 3016 <desk3016 at live.com> wrote:








Hi Stian,
For elaborating previous question, I am creating a authentication provider, which needs to
call an external API. The payloads needs be encrypted with a key before calling
the API. 
I want API URL and Path of the Key to be configurable, so that Ops
team can tweak that based on each environment. 
I?ll be using KeyCloak in
multi-tenant environment, so rather than configuring it at authenticator level
for each relam, we want to configure these settings at system level.

 

I came across this link http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html#d4e559
which shows how you can pass configuration to providers. 
I tried to do the same
thing for my authentication provider but that didn?t work. Not Sure if it
matters but I am using KeyCloak version 1.9.3.

 

This is what I put in keycloak-server.json. Here
?xyz-username-password-authenticator? is my provider ID. 

 

"authentication": {

                               
"xyz-username-password-authenticator": {

                                               
"tvUrl": "https://192.168.0.11/TokenValidator/TokenValidator.asmx"

                               
}

               
}

I also tried it by putting following configuration i.e. by
removing the ?authentication? element from above config.

 

"xyz-username-password-authenticator":
{

"tvUrl":
"https://192.168.0.11/TokenValidator/TokenValidator.asmx"

               
}

 

Can you please guide me how can I pass these configurations
to my authentication providers?
Thanks!
Best Regards,
WJ



Date: Mon, 6 Jun 2016 08:00:07 +0200
Subject: Re: [keycloak-dev] Config File for token validator endpoints url in keycloak?
From: sthorger at redhat.com
To: desk3016 at live.com
CC: keycloak-dev at lists.jboss.org

Please elaborate on what your use-case is.
On 3 June 2016 at 19:09, Eric Son 3016 <desk3016 at live.com> wrote:



Hi, 

I would like to use external token validator with the keycloak.
 Is there any existing configuration file for storing token validator API endpoints url and its public key info?
I want to set them up in "System level" rather than the "Execution level" in the code.

Thanks for the help!

Best Regards,

WJ

 		 	   		  

_______________________________________________

keycloak-dev mailing list

keycloak-dev at lists.jboss.org

https://lists.jboss.org/mailman/listinfo/keycloak-dev


 		 	   		  

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

From psilva at redhat.com  Thu Jun 16 13:12:36 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 16 Jun 2016 13:12:36 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <1456138264.17954317.1465574139108.JavaMail.zimbra@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>
	<a77d412a-a62b-69e8-5eaf-bee704680041@redhat.com>
	<862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>
	<9ac0a941-666f-15cb-2ff3-8598eaa94660@redhat.com>
	<1920717619.17938110.1465572213044.JavaMail.zimbra@redhat.com>
	<573a2370-59f7-77ca-9544-acd47cfdc23e@redhat.com>
	<1456138264.17954317.1465574139108.JavaMail.zimbra@redhat.com>
Message-ID: <329467153.20332400.1466097156190.JavaMail.zimbra@redhat.com>

Hi All,

   After reviewing somethings based on the feedback from Bill and Stian, I've updated both code and docs [1] to reflect what we have discussed.

   In a nutshell, I think UX is much better now. With less steps to get things done and in some cases with a default configuration to quickly get started with authorization services.

   Special attention to the "Managing Resource Server" [2] section. There you'll understand the main changes that made things more simple.

   I'll be working with some getting started tutorials, I think they will be very simple and easy to follow now.

   Please, let me know your thoughts.

[1] https://keycloak.gitbooks.io/authorization-services-guide/content/
[2] https://keycloak.gitbooks.io/authorization-services-guide/content/topics/resource-server/overview.html
   

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Friday, June 10, 2016 12:55:39 PM
Subject: Re: [keycloak-dev] Feedback

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, June 10, 2016 12:43:51 PM
> Subject: Re: Feedback
> 
> 
> 
> On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Friday, June 10, 2016 12:11:37 PM
> >> Subject: Re: Feedback
> >>
> >>
> >>
> >> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Friday, June 10, 2016 10:39:07 AM
> >>>> Subject: Re: Feedback
> >>>>
> >>>>
> >>>>
> >>>> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
> >>>>> Bill,
> >>>>>
> >>>>> Got the authz stuff working with the adapters. It was a puzzle but I
> >>>>> think
> >>>>> I have something.
> >>>> Yeah, its nasty.  Every servlet container handlers security just a bit
> >>>> differently than others so, its ugly.
> >>>>
> >>>>> * I've discarded my own sub-types of AccessToken, they were redundant.
> >>>>> The
> >>>>> only difference between authz tokens and access tokens was a list of
> >>>>> permissions. And the concept behind them is the same. I've added a
> >>>>> "authorization" claim to AccessToken (null by default) from where
> >>>>> permissions granted by the server can be obtained.
> >>>> Is a claim better?
> >>> To represent a RPT, I believe it is.
> >>>
> >>>> Or should AccessTokenResponse optionally contain the RPT?
> >>> IMO, that would make things harder from a client perspective. See my next
> >>> comments.
> >>>
> >>>> Or optionally a query param for Implicit Flow?  Or have both?  I
> >>>> don't know.
> >>> I think we have two different things here:
> >>>
> >>> * How a RPT looks like
> >>> * How a RPT is obtained (the protocol in use)
> >>>
> >>> In the first case, a RPT is just a special type of access token with
> >>> authorization data on it. Where this data is a result of the evaluation
> >>> of
> >>> permissions and authorization policies associated with the resources
> >>> being
> >>> requested. Here, that claim represents this data. This is protocol
> >>> agnostic.
> >>>
> >>> The latter case is how you obtain that data, which is strongly associated
> >>> with the protocol in use. What you said makes a lot of sense, we can
> >>> issue
> >>> this authorization data when doing any of the OAuth2 grant types. That
> >>> can
> >>> be specially useful when you want to obtain all permissions for an user
> >>> at
> >>> once when authenticating in KC, avoiding an additional call to the server
> >>> in order to obtain authorization specific data. One way to achieve that
> >>> would be a
> >>> "Entitlement Protocol Mapper" that is capable of decorating an access
> >>> token
> >>> with the authorization data. Thus, transforming the access token into a
> >>> RPT. See, the client just use the final access token without any
> >>> additional treatment.
> >>>
> >>> There are a lot of other features to implement around both UMA and
> >>> Entitlement protocols. For instance, claims gathering or obligations. So
> >>> the server can ask the client for additional information. Eg.: require a
> >>> higher security level, etc. And for that, we must be able to obtain authz
> >>> data separately.
> >> IIRC, there's a REST API right that allows a client to turn an access
> >> token into an RPT?
> > Yes, that is what both Authorization and Entitlement API are meant for.
> >
> >> So, if Client A gets an access token, it can invoke
> >> on Service B.  Service B can pass the access token to Keycloak to obtain
> >> an RPT?
> > Yes you can. The built-in policy enforcers (related with the changes I did
> > to adapters) can operation in two modes:
> >
> > * Bearer Token
> > * "Stateful" scenario (eg.: monolithic JEE apps)
> >
> > In the first case, is up to the client to obtain and send the RPT with the
> > necessary permissions to access protected resources on the resource
> > server(Service B). Here you can use two protocols: UMA and Entitlement.
> > You know UMA. Entitlement is just a more lightweight and 1-legged protocol
> > based on some UMA concepts. It doesn't require permission tickets and
> > stuff.
> >
> > In the latter case, there is a specific policy enforcer that does exactly
> > what you described. Obtaining a RPT transparently from a Keycloak server
> > using the *Entitlement* API.
> >
> My only reasoning for wanting the option to include the RPT in the
> AccessTokenResponse was for performance reasons.  Obtaining an RPT could
> be obtained for free for a specific client by piggybacking on the OAuth
> protocol, but the access token could remain small/lightweight and not
> contain the RPT.  You'd still want to be able to include the RPT within
> the AT if so desired, but there might come a point when the AT becomes
> too fat.
> 
> All this isn't really important at this time though.  What's more
> important is releasing Authz soon.  I just foresese us wanting to
> provide different optimizations for different environments.
> 
> Bill

+1. And that is the reason why I'm following this path now. So far, I was using a very specific token to hold authz data. But as you said, let's discuss about performance and optimizations at the appropriate time and release this stuff first. We can do a lot of things at this regard.

Regarding token size, during this work I did a research about this topic and there are interesting discussions on OAuth2-WG.

Thanks for all feedback, it was really important to improve things.

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

From sthorger at redhat.com  Fri Jun 17 01:42:10 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 17 Jun 2016 07:42:10 +0200
Subject: [keycloak-dev] Config File for token validator endpoints url in
	keycloak?
In-Reply-To: <BAY172-W358F9DADF6579FEFE9DCC4BE560@phx.gbl>
References: <BAY172-W32E76D10F741212ED00495BE590@phx.gbl>
	<CAJgngAfuNHQ=uyGyq1TRUkvdi18MBbtos4vunTJaGP8qC7QwKQ@mail.gmail.com>
	<BAY172-W292404F2181595C1DCC85CBE560@phx.gbl>
	<CAJgngAdjNWP09LdAs_CEzUWO+LdLAA=YD-eoi_VkZRL49R7sqg@mail.gmail.com>
	<BAY172-W358F9DADF6579FEFE9DCC4BE560@phx.gbl>
Message-ID: <CAJgngAeixGUNqX1+V_b-uJgM6HKoakqug68TRXUD9ZaWe-Ro7A@mail.gmail.com>

The config from keycloak-server.json is passed in to init method of the
provider factory (
https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/provider/ProviderFactory.java#L41)
and is not available in getAuthenticatorConfig.

On 16 June 2016 at 18:01, Eric Son 3016 <desk3016 at live.com> wrote:

> Hi Stian,
>
>
> Based on your response, I changed the configuration to this. But in
> authenticator, I am not able to access this config.
>
> Am I missing something?
>
>
>                 "authenticator": {
>
>                                 "xyz-username-password-authenticator": {
>
>                                                 "tvUrl": "
> https://192.168.0.11/TokenValidator/TokenValidator.asmx",
>
>
>
>                                 }
>
>                 }
>
>
>
> Here is my authenticator provider ID and provider configurations, Btw I
> can see this configuration in the console with empty value.
>
>
> *    public* *static* *final* String *PROVIDER_ID* =
> "xyz-username-password-authenticator";
>
>     *public* String getId() {
>
>         *return* *PROVIDER_ID*;
>
>     }
>
>
>
>     *private* *static* *final* List<ProviderConfigProperty>
> *configProperties* = *new* ArrayList<ProviderConfigProperty>();
>
>
>
>     *static* {
>
>         ProviderConfigProperty property;
>
>         property = *new* ProviderConfigProperty();
>
>         property.setName("tvUrl");
>
>         property.setLabel("Token Validator URL");
>
>         property.setType(ProviderConfigProperty.*STRING_TYPE*);
>
>         property.setHelpText("Token Validator URL.");
>
>         *configProperties*.add(property);
>
>     }
>
> In my authenticator, I am accessing config like this, but it doesn?t have
> value for this config.
>
>
>        *if*(context.getAuthenticatorConfig().getConfig() != *null*) {
>
>               *for* (String key : context.getAuthenticatorConfig().getConfig().keySet())
> {
>
>                      *log*.info("Config Key: " + key + ", Value: " +
> context.getAuthenticatorConfig().getConfig().get(key));
>
>               }
>
>        }
>
> Did you see what I have missed, any? Thanks!
>
> Best Regards,
>
> WJ
>
> ------------------------------
> Date: Thu, 16 Jun 2016 04:57:59 +0200
>
> Subject: Re: [keycloak-dev] Config File for token validator endpoints url
> in keycloak?
> From: sthorger at redhat.com
> To: desk3016 at live.com
> CC: keycloak-dev at lists.jboss.org
>
> The SPI is called "authenticator", not "authentication", so it should be:
>
> "authenticator": {
>
>                                 "xyz-username-password-authenticator": {
>
>                                                 "tvUrl": "
> https://192.168.0.11/TokenValidator/TokenValidator.asmx"
>
>                                 }
>
>                 }
>
>
> Assuming "xyz-username-password-authenticator" is what's returned by your
> factories getId method.
>
> On 16 June 2016 at 04:26, Eric Son 3016 <desk3016 at live.com> wrote:
>
> Hi Stian,
>
>
> For elaborating previous question, I am creating a authentication
> provider, which needs to call an external API.
>
> The payloads needs be encrypted with a key before calling the API.
>
>
> I want API URL and Path of the Key to be configurable, so that Ops team
> can tweak that based on each environment.
>
>
> I?ll be using KeyCloak in multi-tenant environment, so rather than
> configuring it at authenticator level for each relam, we want to configure
> these settings at system level.
>
>
>
> I came across this link
> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html#d4e559
> which shows how you can pass configuration to providers.
>
>
> I tried to do the same thing for my authentication provider but that
> didn?t work. Not Sure if it matters but I am using KeyCloak version 1.9.3.
>
>
>
> This is what I put in keycloak-server.json. Here
> ?xyz-username-password-authenticator? is my provider ID.
>
>
>
> "authentication": {
>
>                                 "xyz-username-password-authenticator": {
>
>                                                 "tvUrl": "
> https://192.168.0.11/TokenValidator/TokenValidator.asmx"
>
>                                 }
>
>                 }
>
> I also tried it by putting following configuration i.e. by removing the
> ?authentication? element from above config.
>
>
>
> "xyz-username-password-authenticator": {
>
> "tvUrl": "https://192.168.0.11/TokenValidator/TokenValidator.asmx"
>
>                 }
>
>
>
> Can you please guide me how can I pass these configurations to my
> authentication providers?
>
>
> Thanks!
>
>
> Best Regards,
>
>
> WJ
>
>
> ------------------------------
> Date: Mon, 6 Jun 2016 08:00:07 +0200
> Subject: Re: [keycloak-dev] Config File for token validator endpoints url
> in keycloak?
> From: sthorger at redhat.com
> To: desk3016 at live.com
> CC: keycloak-dev at lists.jboss.org
>
>
> Please elaborate on what your use-case is.
>
> On 3 June 2016 at 19:09, Eric Son 3016 <desk3016 at live.com> wrote:
>
> Hi,
>
> I would like to use external token validator with the keycloak.
>  Is there any existing configuration file for storing token validator API
> endpoints url and its public key info?
> I want to set them up in "System level" rather than the "Execution level"
> in the code.
>
> Thanks for the help!
>
> Best Regards,
>
> WJ
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160617/a827f3e1/attachment-0001.html 

From mposolda at redhat.com  Fri Jun 17 04:59:55 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 17 Jun 2016 10:59:55 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <889fa832-c988-948c-2842-5348922f07dc@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
Message-ID: <5763BC0B.4020208@redhat.com>

On 16/06/16 16:38, Bill Burke wrote:
>>>> Transactions and 3rd party updates
>>>> -----------------------------------------------
>>>>
>>>> - Will be good to improve registration of user to LDAP. Ideally during
>>>> registration new user to LDAP, we should allow to send all data at 
>>>> once.
>>>> (currently UserFederationProvider.register supports sending just
>>>> username). Also we should allow to specify if register to 3rd party
>>>> provider should be done *before* or *after* the registration to 
>>>> Keycloak
>>>> local DB. For details, see 
>>>> https://issues.jboss.org/browse/KEYCLOAK-1075
>>>> and all the comments from users...
>>>>
>>>> - Also updating user should be ideally at once. For example if you 
>>>> call:
>>>> user.setFirstName("john");
>>>> user.setLastName("Doe");
>>>> user.setEmail("john at email.cz");
>>>>
>>>> we shouldn't have 3 update calls to LDAP, but just one. Maybe we can
>>>> address this with transaction abstraction? I've already did something
>>>> for LDAP provider (see TxAwareLDAPUserModelDelegate ), however will be
>>>> good to provide something more generic for user storage SPI. Then when
>>>> KeycloakTransactionManager.commit is called, the data are send to
>>>> federation storage
>>>>
>>>
>>> This would be an implementation detail.  Similar to JPA Users, the
>>> LDAP UserAdapter will be remembered per session.  The LDAP adapter
>>> could queue up updates then at commit time flush them all.
>>>
>>> Maybe you should consider writing an LDAP version of JPA? ;-)
>>> Probably a lot of code could be borrowed from PL IDM API.
>> I've wrote already something similar for Mongo ;) Also I already
>> addressed the multiple-updates issue for LDAP (see above). However this
>> one is mainly issue for 3rd party providers rather than for LDAP
>> provider. Especially since 3rd party provider may have some validations
>> for some attributes.
>>
>>
>> For example consider this scenario, which can happen in current
>> implementation:
>>
>> UserModel john = session.users().addUser(realm, "john");
>> john.setEmail("john at email.org");
>>
>> All of this happens during "addUser" call:
>>
>> - User "john" is saved to local-db
>> - SomeUserFederationProvider.register calls the registration request to
>> 3rd party federation storage. User "john" is saved in 3rd party storage
>> now.
>>
>> Then john.setEmail is invoked
>> - There is request to 3rd party federation storage to update email.
>> - 3rd party storage refuse to save the email because there is already an
>> existing user with email "john at email.org" . So it sends back the
>> validation error. Now keycloak can rollback the transaction, however
>> user "john" was already registered in 3rd party federation storage from
>> previous "register" call -> FAIL
>>
>> So now you need to manually remove the user from 3rd party storage,
>> which is dirty hack. There are other possible hacks to address this. For
>> example someone "postpone" the registration in "register" method by
>> adding some helper attributes and sends the registration request later
>> when all the attributes are set. I suggest to read the comments in
>> https://issues.jboss.org/browse/KEYCLOAK-1075 for details.
>>
>> IMO the proper solution is to ensure that "register" request to 3rd
>> party is postponed until the transaction.commit when user is filled with
>> all the attributes. Similarly update should be done just once. IMO we
>> should provide something at SPI level to simplify this scenario.
>>
>
> We already have a KeycloakTransaction you can register with.
>
>> I understand that main motivation for you is to avoid "imports", however
>> since we are refactoring anyway, we should try to address other SPI
>> limitations too. And IMO this one is pretty bad and worth improve ;)
>
> So, have a method addUser(RealmModel realm, UserEntity user)? 
I am thinking about adding some helper classes, so the people don't need 
to directly deal with our transaction API and manually enlist 
transactions in their code etc.

Also it will be good to have some support for validations (aka. pseudo 
2-phase commit), so that all "small" userStores have possibility to 
first validate if created/updated user is valid for them and then the 
real update is send. This will help to avoid situation like:
- transaction.commit is invoked
- store1 successfully register the user and commits
- store2 rejects to register user because of some validation error (ie. 
duplicated email)
- now some data of invalid user already saved in store1 -> FAIL . 
Because at this point, whole transaction should be rollback and user 
shouldn't be saved anywhere.


I am thinking about pseudo-code similar to this:

public abstract class FederationTransaction implements KeycloakTransaction {

     protected TransactionState state = TransactionState.NOT_STARTED;
     protected final TxUserStore userStore;
     protected final TxUserModel user;

     public FederationTransaction(TxUserStore userStore, TxUserModel user) {
         this.userStore = userStore;
         this.user = user;
     }

     // Implement common stuff like begin, rollback, setRollbackOnly...

}


// This transaction just validates in 3rd party store if user is ok
public class ValidationTransaction extends FederationTransaction {

     public ValidationTransaction(TxUserStore userStore, TxUserModel user) {
         super(userStore, user);
     }

     @Override
     protected void commit() {
         userStore.validateUser(user);
     }

}


// This transaction finally sends commit to 3rd party store
public class CommitTransaction extends FederationTransaction {

     public CommitTransaction(TxUserStore userStore, TxUserModel user) {
         super(userStore, user);
     }

     @Override
     protected void commit() {
         userStore.createOrUpdateUser(user);
     }

}


public abstract class TxUserStore implements UserStore {

     private final KeycloakSession session;

     public TxUserStore(KeycloakSession session) {
         this.session = session;
     }

     public KeycloakSession getSession() {
         return session;
     }

     // Send request to storage to validate user
     protected abstract void validateUser(TxUserModel user) throws 
FederationValidationException;

     // Send request to create or update user during transaction.commit 
when all stores successfully validated user
     protected abstract void createOrUpdateUser(TxUserModel user);
}



public class TxUserModel extends UserModelDelegate {

     private ValidationTransaction validationTransaction;
     private CommitTransaction commitTransaction;

     private final TxUserStore store;

     public TxUserModel(UserModel delegate, TxUserStore store) {
         super(delegate);
         this.store = store;
     }


     protected void ensureTransactionEnlisted() {
         if (commitTransaction == null) {
             validationTransaction = new ValidationTransaction(store, this);
             commitTransaction = new CommitTransaction(store, this);

             // Ensure all validation transactions are called before 
sending real "commit" to any storage
store.getSession().getTransaction().enlistPrepare(validationTransaction);

             // Enlisting real transaction here
store.getSession().getTransaction().enlistAfterCompletion(commitTransaction);
         }
     }

}



Now in your real store implementation, you need to do just this to 
ensure that registration of user is postponed to transaction commit:

public UserModel register(UserModel register(RealmModel realm, UserModel 
user) {
   MyTxUserModel wrappedUser = new MyTxUserModel(user, this);
   wrappedUser.ensureTransactionEnlisted();
}


And also ensure that transaction is enlisted during any update calls. So 
in MyTxUserModel override the needed setter methods like this:

    @Override
    public void setFirstName(String firstName) {
         ensureTransactionEnlisted();
         super.setFirstName(firstName);
     }

     @Override
     public void setLastName(String lastName) {
         ensureTransactionEnlisted();
         super.setLastName(lastName);
     }


With this approach, when you have:
UserModel john = session.users().addUser("john", realm);
john.setFirstName("John");
john.setLastName("Doe");

you have the register call postponed until the transaction.commit .

The thing is, that with postponed registration you won't know the ID of 
newly created user at the moment when "addUser" is called. However not 
sure if that's big issue... Another approach might be that UserStore 
will have possibility to specify if it supports transactions or not. 
Then we can have method "rollback" on UserStore, which will be called if 
keycloakTransaction.rollback is called.

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

From mposolda at redhat.com  Fri Jun 17 05:10:02 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 17 Jun 2016 11:10:02 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <889fa832-c988-948c-2842-5348922f07dc@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
Message-ID: <5763BE6A.3080007@redhat.com>

On 16/06/16 16:38, Bill Burke wrote:
>>>> Sync users
>>>> --------------
>>>> We should still keep the option to sync users into Keycloak DB as we
>>>> have now. Note some persistent storages like LDAP are limited with
>>>> pagination. So the easiest possibility for some admins is just to sync
>>>> users, so they can easily search them in admin console.
>>>>
>>> Doing a full import just to support pagination is overkill. I'm
>>> guessing that a lot of deployments will not manage users through the
>>> Keycload admin console.  We can offer a manual a Sync SPI that
>>> providers can implement.
>> Maybe it's overkill for 90% of deployments, but remaining 10% want to
>> see all LDAP users in admin console immediatelly and hence want to sync
>> them? IMO it's always good to have SPI flexible so it can easily support
>> all the possible requirements. However I understand that it's not always
>> possible...
>>
>
> This is only an issue for large query result sets where you want to do 
> pagination.  IIRC, we couldn't figure out a way to do this in a 
> scalable manner without imports. 
yeah, I also can't see how to do pagination without imports, assuming 
the 3rd party store (ie. LDAP) doesn't have pagination support.

So then again, the question is if SPI should still have the option to 
support imports? Or maybe don't have it OOTB, but if customers start 
asking for pagination, we have the option to say them "ok, we will try 
to add it" instead of "no, you can't do that and there is no way to 
support it with current SPI" .

Marek

From sthorger at redhat.com  Fri Jun 17 07:59:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 17 Jun 2016 13:59:39 +0200
Subject: [keycloak-dev] Russian localization
In-Reply-To: <CAJgngAc6LQab7x9vK7uHnreR7d_-FM7XJb_vCcQSE0_X1RcVaw@mail.gmail.com>
References: <9ce77698dcf74c24b366d80333249d85@nut-mbx-4.win.ftc.ru>
	<CAJgngAcT5AR8yuZY7Dh84Fa81GM1O=Or_h00UdV9Rh6_LD-R=w@mail.gmail.com>
	<814aec0ea038434e983b95c26ccfe311@nut-mbx-4.win.ftc.ru>
	<1465899218.4620.11.camel@cargosoft.ru>
	<CAJgngAc6LQab7x9vK7uHnreR7d_-FM7XJb_vCcQSE0_X1RcVaw@mail.gmail.com>
Message-ID: <CAJgngAdWzR3wjkVc7tzk4QMmuE5Usn7kiZj+EKCepV1A_qFiSw@mail.gmail.com>

Mitya - would you be able to sanity check the PR? I don't know Russian so
need someone to review it.

On 14 June 2016 at 13:04, Stian Thorgersen <sthorger at redhat.com> wrote:

> Great, you can help already by sanity checking the PR :)
>
> On 14 June 2016 at 12:13, Mitya <mitya at cargosoft.ru> wrote:
>
>> Aleksander, great news! This is something we were planning ourselves.
>> Thank you for your effort!
>>
>> Stian, I think I'll be able to help to maintain and update Russian
>> translation, as well as perform some peer review.
>>
>> Cheers,
>> Mitya
>>
>>
>> Yes, I will trying to update it, when it necessary.
>>
>>
>>
>> *From:* Stian Thorgersen [mailto:sthorger at redhat.com]
>> *Sent:* Wednesday, June 08, 2016 10:53 AM
>> *To:* ???????? ????????? ?????????
>> *Cc:* keycloak-dev at lists.jboss.org
>> *Subject:* Re: [keycloak-dev] Russian localization
>>
>>
>>
>> We would welcome a contribution for Russian. However, we are not able to
>> maintain this translation ourselves. Would you be able to maintain it and
>> update it when it's needed?
>>
>>
>>
>> On 8 June 2016 at 06:36, Nekrasov Aleksandr <a.nekrasov at ftc.ru> wrote:
>>
>> Hi all,
>>
>>
>>
>> I have translated all base theme message resources to russian language
>> and want to create PR.
>>
>> I believe, it will be good, if keycloak will be supports russian locale.
>> How do you think?
>>
>>
>>
>> Nekrasov Aleksander,
>>
>> Developer,
>>
>> Center of Financial Techologies
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160617/f8f47150/attachment-0001.html 

From bburke at redhat.com  Fri Jun 17 09:45:08 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 17 Jun 2016 09:45:08 -0400
Subject: [keycloak-dev] Transactions WAS Re: User Federation Provider Cache
In-Reply-To: <5763BC0B.4020208@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BC0B.4020208@redhat.com>
Message-ID: <58f8a784-b4a5-9fc5-0295-9dcad55c61c0@redhat.com>



On 6/17/16 4:59 AM, Marek Posolda wrote:
> On 16/06/16 16:38, Bill Burke wrote:
>>>>> Transactions and 3rd party updates
>>>>> -----------------------------------------------
>>>>>
>>>>> - Will be good to improve registration of user to LDAP. Ideally during
>>>>> registration new user to LDAP, we should allow to send all data at
>>>>> once.
>>>>> (currently UserFederationProvider.register supports sending just
>>>>> username). Also we should allow to specify if register to 3rd party
>>>>> provider should be done *before* or *after* the registration to
>>>>> Keycloak
>>>>> local DB. For details, see
>>>>> https://issues.jboss.org/browse/KEYCLOAK-1075
>>>>> and all the comments from users...
>>>>>
>>>>> - Also updating user should be ideally at once. For example if you
>>>>> call:
>>>>> user.setFirstName("john");
>>>>> user.setLastName("Doe");
>>>>> user.setEmail("john at email.cz");
>>>>>
>>>>> we shouldn't have 3 update calls to LDAP, but just one. Maybe we can
>>>>> address this with transaction abstraction? I've already did something
>>>>> for LDAP provider (see TxAwareLDAPUserModelDelegate ), however will be
>>>>> good to provide something more generic for user storage SPI. Then when
>>>>> KeycloakTransactionManager.commit is called, the data are send to
>>>>> federation storage
>>>>>
>>>>
>>>> This would be an implementation detail.  Similar to JPA Users, the
>>>> LDAP UserAdapter will be remembered per session.  The LDAP adapter
>>>> could queue up updates then at commit time flush them all.
>>>>
>>>> Maybe you should consider writing an LDAP version of JPA?  ;-)
>>>> Probably a lot of code could be borrowed from PL IDM API.
>>> I've wrote already something similar for Mongo ;) Also I already
>>> addressed the multiple-updates issue for LDAP (see above). However this
>>> one is mainly issue for 3rd party providers rather than for LDAP
>>> provider. Especially since 3rd party provider may have some validations
>>> for some attributes.
>>>
>>>
>>> For example consider this scenario, which can happen in current
>>> implementation:
>>>
>>> UserModel john = session.users().addUser(realm, "john");
>>> john.setEmail("john at email.org");
>>>
>>> All of this happens during "addUser" call:
>>>
>>> - User "john" is saved to local-db
>>> - SomeUserFederationProvider.register calls the registration request to
>>> 3rd party federation storage. User "john" is saved in 3rd party storage
>>> now.
>>>
>>> Then john.setEmail is invoked
>>> - There is request to 3rd party federation storage to update email.
>>> - 3rd party storage refuse to save the email because there is already an
>>> existing user with email "john at email.org" . So it sends back the
>>> validation error. Now keycloak can rollback the transaction, however
>>> user "john" was already registered in 3rd party federation storage from
>>> previous "register" call -> FAIL
>>>
>>> So now you need to manually remove the user from 3rd party storage,
>>> which is dirty hack. There are other possible hacks to address this. For
>>> example someone "postpone" the registration in "register" method by
>>> adding some helper attributes and sends the registration request later
>>> when all the attributes are set. I suggest to read the comments in
>>> https://issues.jboss.org/browse/KEYCLOAK-1075 for details.
>>>
>>> IMO the proper solution is to ensure that "register" request to 3rd
>>> party is postponed until the transaction.commit when user is filled with
>>> all the attributes. Similarly update should be done just once. IMO we
>>> should provide something at SPI level to simplify this scenario.
>>>
>>
>> We already have a KeycloakTransaction you can register with.
>>
>>> I understand that main motivation for you is to avoid "imports", however
>>> since we are refactoring anyway, we should try to address other SPI
>>> limitations too. And IMO this one is pretty bad and worth improve ;)
>>
>> So, have a method addUser(RealmModel realm, UserEntity user)?
> I am thinking about adding some helper classes, so the people don't need
> to directly deal with our transaction API and manually enlist
> transactions in their code etc.
>
> Also it will be good to have some support for validations (aka. pseudo
> 2-phase commit), so that all "small" userStores have possibility to
> first validate if created/updated user is valid for them and then the
> real update is send. This will help to avoid situation like:
> - transaction.commit is invoked
> - store1 successfully register the user and commits
> - store2 rejects to register user because of some validation error (ie.
> duplicated email)
> - now some data of invalid user already saved in store1 -> FAIL .
> Because at this point, whole transaction should be rollback and user
> shouldn't be saved anywhere.
>
>
> I am thinking about pseudo-code similar to this:
>
> public abstract class FederationTransaction implements KeycloakTransaction {
>
>     protected TransactionState state = TransactionState.NOT_STARTED;
>     protected final TxUserStore userStore;
>     protected final TxUserModel user;
>
>     public FederationTransaction(TxUserStore userStore, TxUserModel user) {
>         this.userStore = userStore;
>         this.user = user;
>     }
>
>     // Implement common stuff like begin, rollback, setRollbackOnly...
>
> }
>
>
> // This transaction just validates in 3rd party store if user is ok
> public class ValidationTransaction extends FederationTransaction {
>
>     public ValidationTransaction(TxUserStore userStore, TxUserModel user) {
>         super(userStore, user);
>     }
>
>     @Override
>     protected void commit() {
>         userStore.validateUser(user);
>     }
>
> }
>
>
> // This transaction finally sends commit to 3rd party store
> public class CommitTransaction extends FederationTransaction {
>
>     public CommitTransaction(TxUserStore userStore, TxUserModel user) {
>         super(userStore, user);
>     }
>
>     @Override
>     protected void commit() {
>         userStore.createOrUpdateUser(user);
>     }
>
> }
>
>
> public abstract class TxUserStore implements UserStore {
>
>     private final KeycloakSession session;
>
>     public TxUserStore(KeycloakSession session) {
>         this.session = session;
>     }
>
>     public KeycloakSession getSession() {
>         return session;
>     }
>
>     // Send request to storage to validate user
>     protected abstract void validateUser(TxUserModel user) throws
> FederationValidationException;
>
>     // Send request to create or update user during transaction.commit
> when all stores successfully validated user
>     protected abstract void createOrUpdateUser(TxUserModel user);
> }
>
>
>
> public class TxUserModel extends UserModelDelegate {
>
>     private ValidationTransaction validationTransaction;
>     private CommitTransaction commitTransaction;
>
>     private final TxUserStore store;
>
>     public TxUserModel(UserModel delegate, TxUserStore store) {
>         super(delegate);
>         this.store = store;
>     }
>
>
>     protected void ensureTransactionEnlisted() {
>         if (commitTransaction == null) {
>             validationTransaction = new ValidationTransaction(store, this);
>             commitTransaction = new CommitTransaction(store, this);
>
>             // Ensure all validation transactions are called before
> sending real "commit" to any storage
>
> store.getSession().getTransaction().enlistPrepare(validationTransaction);
>
>             // Enlisting real transaction here
>
> store.getSession().getTransaction().enlistAfterCompletion(commitTransaction);
>         }
>     }
>
> }
>
>
>
> Now in your real store implementation, you need to do just this to
> ensure that registration of user is postponed to transaction commit:
>
> public UserModel register(UserModel register(RealmModel realm, UserModel
> user) {
>   MyTxUserModel wrappedUser = new MyTxUserModel(user, this);
>   wrappedUser.ensureTransactionEnlisted();
> }
>
>
> And also ensure that transaction is enlisted during any update calls. So
> in MyTxUserModel override the needed setter methods like this:
>
>    @Override
>    public void setFirstName(String firstName) {
>         ensureTransactionEnlisted();
>         super.setFirstName(firstName);
>     }
>
>     @Override
>     public void setLastName(String lastName) {
>         ensureTransactionEnlisted();
>         super.setLastName(lastName);
>     }
>
>
> With this approach, when you have:
> UserModel john = session.users().addUser("john", realm);
> john.setFirstName("John");
> john.setLastName("Doe");
>
> you have the register call postponed until the transaction.commit .
>
> The thing is, that with postponed registration you won't know the ID of
> newly created user at the moment when "addUser" is called. However not
> sure if that's big issue... Another approach might be that UserStore
> will have possibility to specify if it supports transactions or not.
> Then we can have method "rollback" on UserStore, which will be called if
> keycloakTransaction.rollback is called.
>

Isn't adding:

addUser(org.keycloak.models.entities.UserEntity)

much simpler than all of the things you propose?  We change the 
registration flow to build up a UserEntity object that is eventually 
used to create the user.

Bill

From bburke at redhat.com  Fri Jun 17 10:07:48 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 17 Jun 2016 10:07:48 -0400
Subject: [keycloak-dev] Pagination Re:  User Federation Provider Cache
In-Reply-To: <5763BE6A.3080007@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
Message-ID: <5b205a08-b24f-ecfb-71b4-61c5b2bef022@redhat.com>



On 6/17/16 5:10 AM, Marek Posolda wrote:
> On 16/06/16 16:38, Bill Burke wrote:
>>>>> Sync users
>>>>> --------------
>>>>> We should still keep the option to sync users into Keycloak DB as we
>>>>> have now. Note some persistent storages like LDAP are limited with
>>>>> pagination. So the easiest possibility for some admins is just to sync
>>>>> users, so they can easily search them in admin console.
>>>>>
>>>> Doing a full import just to support pagination is overkill. I'm
>>>> guessing that a lot of deployments will not manage users through the
>>>> Keycload admin console.  We can offer a manual a Sync SPI that
>>>> providers can implement.
>>> Maybe it's overkill for 90% of deployments, but remaining 10% want to
>>> see all LDAP users in admin console immediatelly and hence want to sync
>>> them? IMO it's always good to have SPI flexible so it can easily support
>>> all the possible requirements. However I understand that it's not always
>>> possible...
>>>
>>
>> This is only an issue for large query result sets where you want to do
>> pagination.  IIRC, we couldn't figure out a way to do this in a
>> scalable manner without imports.
> yeah, I also can't see how to do pagination without imports, assuming
> the 3rd party store (ie. LDAP) doesn't have pagination support.
>
> So then again, the question is if SPI should still have the option to
> support imports? Or maybe don't have it OOTB, but if customers start
> asking for pagination, we have the option to say them "ok, we will try
> to add it" instead of "no, you can't do that and there is no way to
> support it with current SPI" .
>

Currently, the provider is responsible for implementing the import.  The 
SPI *requires* that import is implemented by hand by the developer.  The 
SPI *requires* a proxy which is also implemented by hand by the 
developer.  The provider is also responsible for implementing 
synchronization.  All this just to support pagination on the admin 
console page.

Also, pagination sucks already in our current implementation.  Consider 
a query that returns 1000 users, this would require importing those 1000 
users, before the pagination can even work.  I don't know what we were 
thinking!  It was such a bad idea....

Bill



From mposolda at redhat.com  Fri Jun 17 10:30:39 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 17 Jun 2016 16:30:39 +0200
Subject: [keycloak-dev] Feedback
In-Reply-To: <329467153.20332400.1466097156190.JavaMail.zimbra@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<1136285036.17629717.1465527840459.JavaMail.zimbra@redhat.com>
	<a77d412a-a62b-69e8-5eaf-bee704680041@redhat.com>
	<862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>
	<9ac0a941-666f-15cb-2ff3-8598eaa94660@redhat.com>
	<1920717619.17938110.1465572213044.JavaMail.zimbra@redhat.com>
	<573a2370-59f7-77ca-9544-acd47cfdc23e@redhat.com>
	<1456138264.17954317.1465574139108.JavaMail.zimbra@redhat.com>
	<329467153.20332400.1466097156190.JavaMail.zimbra@redhat.com>
Message-ID: <5764098F.1050700@redhat.com>

I did not yet went deeply through all the details, however briefly went 
through the docs and examples. Few things:

- Term "scope" seems to be overloaded as we have it in other places in 
Keycloak too? Now when you click to some Client and then to tab 
"Authorization" you can see 2 tabs "Scopes" (one in level1 and second in 
level2) but both are used for a bit different thing. Isn't it some 
better term like "Action" ? For example "john can do 'action' DELETE on 
photoalbum xyz" seems to me more intuitive than "john has 'scope' DELETE 
on photoalbum xyz" . Or is this term required by UMA specification?

- Is it possible to merge JSON file representation with the main 
keycloak RealmRepresentation? Currently to have "photoz" example 
running, I need to import realm ( photoz-uma-realm.json ) and then 
separately also another JSON with authorization configuration ( 
photoz-uma-restful-api-authz.json ). If configuration of ResourceServer 
is moved under particular client of realm, it can be exported during 
export/import of whole realm and then imported again in single step. We 
can still support to import just the authorization configuration though, 
but have it supported when inside global file is good too IMO.

- Should be Time-Based Policy the "first-class-citizen" - one of builtin 
policies? It seems you can achieve the same with Rule based policies 
(Javascript or Drools) ? You can simulate some other simpler policies 
like role-based or attribute-based with rule policies too, however they 
will be likely much more common usecase.

- Java AuthzClient seems to be directly using Apache HttpClient. Is it 
easier to have it as jax-rs (or resteasy) client similarly like our 
admin-client? Or you want to avoid another dependency? It seems we 
currently have 3 clients (admin-client , client-registration , authz), 
so maybe we can somehow unify them to use similar approach and we can 
remove some boilerplate code? But this is implementation detail though...

- Is it possible to see the list of available context attributes of 
javascript (or drools) policy? Also it's maybe possible to simplify 
names? For example 'kc.authz.context.client.network.ip_address' is quite 
a long name knowing that this is something, which people will be using 
in their impl?

- During the call few months ago, I mentioned the "weight" of 
authorization decision of aggregation policy. I want to cancel that as 
it looks you can always achieve the same effect by compose more 
aggregate policies together, so weight is not needed though. So this is 
just un-feedback of my previous feedback :)

- Is it possible to dynamically create permissions with Permissions API? 
Looks like just creating resources is possible ATM? For example, I 
wonder about classic social usecase "I want to share my photoalbum with 
user X" . Or "I want to share my photoalbum with group of users Y 
(Google+ circles)" . I guess UMA specs might have some support for this?

- After create new photoalbum in the application, I can see that one new 
session is always created (tabs "Sessions" under client). When I delete 
photoalbum, I can see 6 (!!!) new sessions created. After create and 
delete few albums, I can see 44 active sessions :) I didn't verify what 
happens, looks like quite a lot of resource-owner-password-credentials 
or client-credentials requests? But seems we have time for optimizations 
and polishing later though...

Marek

On 16/06/16 19:12, Pedro Igor Silva wrote:
> Hi All,
>
>     After reviewing somethings based on the feedback from Bill and Stian, I've updated both code and docs [1] to reflect what we have discussed.
>
>     In a nutshell, I think UX is much better now. With less steps to get things done and in some cases with a default configuration to quickly get started with authorization services.
>
>     Special attention to the "Managing Resource Server" [2] section. There you'll understand the main changes that made things more simple.
>
>     I'll be working with some getting started tutorials, I think they will be very simple and easy to follow now.
>
>     Please, let me know your thoughts.
>
> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
> [2] https://keycloak.gitbooks.io/authorization-services-guide/content/topics/resource-server/overview.html
>     
>
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, June 10, 2016 12:55:39 PM
> Subject: Re: [keycloak-dev] Feedback
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, June 10, 2016 12:43:51 PM
>> Subject: Re: Feedback
>>
>>
>>
>> On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Friday, June 10, 2016 12:11:37 PM
>>>> Subject: Re: Feedback
>>>>
>>>>
>>>>
>>>> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Friday, June 10, 2016 10:39:07 AM
>>>>>> Subject: Re: Feedback
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
>>>>>>> Bill,
>>>>>>>
>>>>>>> Got the authz stuff working with the adapters. It was a puzzle but I
>>>>>>> think
>>>>>>> I have something.
>>>>>> Yeah, its nasty.  Every servlet container handlers security just a bit
>>>>>> differently than others so, its ugly.
>>>>>>
>>>>>>> * I've discarded my own sub-types of AccessToken, they were redundant.
>>>>>>> The
>>>>>>> only difference between authz tokens and access tokens was a list of
>>>>>>> permissions. And the concept behind them is the same. I've added a
>>>>>>> "authorization" claim to AccessToken (null by default) from where
>>>>>>> permissions granted by the server can be obtained.
>>>>>> Is a claim better?
>>>>> To represent a RPT, I believe it is.
>>>>>
>>>>>> Or should AccessTokenResponse optionally contain the RPT?
>>>>> IMO, that would make things harder from a client perspective. See my next
>>>>> comments.
>>>>>
>>>>>> Or optionally a query param for Implicit Flow?  Or have both?  I
>>>>>> don't know.
>>>>> I think we have two different things here:
>>>>>
>>>>> * How a RPT looks like
>>>>> * How a RPT is obtained (the protocol in use)
>>>>>
>>>>> In the first case, a RPT is just a special type of access token with
>>>>> authorization data on it. Where this data is a result of the evaluation
>>>>> of
>>>>> permissions and authorization policies associated with the resources
>>>>> being
>>>>> requested. Here, that claim represents this data. This is protocol
>>>>> agnostic.
>>>>>
>>>>> The latter case is how you obtain that data, which is strongly associated
>>>>> with the protocol in use. What you said makes a lot of sense, we can
>>>>> issue
>>>>> this authorization data when doing any of the OAuth2 grant types. That
>>>>> can
>>>>> be specially useful when you want to obtain all permissions for an user
>>>>> at
>>>>> once when authenticating in KC, avoiding an additional call to the server
>>>>> in order to obtain authorization specific data. One way to achieve that
>>>>> would be a
>>>>> "Entitlement Protocol Mapper" that is capable of decorating an access
>>>>> token
>>>>> with the authorization data. Thus, transforming the access token into a
>>>>> RPT. See, the client just use the final access token without any
>>>>> additional treatment.
>>>>>
>>>>> There are a lot of other features to implement around both UMA and
>>>>> Entitlement protocols. For instance, claims gathering or obligations. So
>>>>> the server can ask the client for additional information. Eg.: require a
>>>>> higher security level, etc. And for that, we must be able to obtain authz
>>>>> data separately.
>>>> IIRC, there's a REST API right that allows a client to turn an access
>>>> token into an RPT?
>>> Yes, that is what both Authorization and Entitlement API are meant for.
>>>
>>>> So, if Client A gets an access token, it can invoke
>>>> on Service B.  Service B can pass the access token to Keycloak to obtain
>>>> an RPT?
>>> Yes you can. The built-in policy enforcers (related with the changes I did
>>> to adapters) can operation in two modes:
>>>
>>> * Bearer Token
>>> * "Stateful" scenario (eg.: monolithic JEE apps)
>>>
>>> In the first case, is up to the client to obtain and send the RPT with the
>>> necessary permissions to access protected resources on the resource
>>> server(Service B). Here you can use two protocols: UMA and Entitlement.
>>> You know UMA. Entitlement is just a more lightweight and 1-legged protocol
>>> based on some UMA concepts. It doesn't require permission tickets and
>>> stuff.
>>>
>>> In the latter case, there is a specific policy enforcer that does exactly
>>> what you described. Obtaining a RPT transparently from a Keycloak server
>>> using the *Entitlement* API.
>>>
>> My only reasoning for wanting the option to include the RPT in the
>> AccessTokenResponse was for performance reasons.  Obtaining an RPT could
>> be obtained for free for a specific client by piggybacking on the OAuth
>> protocol, but the access token could remain small/lightweight and not
>> contain the RPT.  You'd still want to be able to include the RPT within
>> the AT if so desired, but there might come a point when the AT becomes
>> too fat.
>>
>> All this isn't really important at this time though.  What's more
>> important is releasing Authz soon.  I just foresese us wanting to
>> provide different optimizations for different environments.
>>
>> Bill
> +1. And that is the reason why I'm following this path now. So far, I was using a very specific token to hold authz data. But as you said, let's discuss about performance and optimizations at the appropriate time and release this stuff first. We can do a lot of things at this regard.
>
> Regarding token size, during this work I did a research about this topic and there are interesting discussions on OAuth2-WG.
>
> Thanks for all feedback, it was really important to improve things.
>
>>
>>
>>
> _______________________________________________
> 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 mitya at cargosoft.ru  Fri Jun 17 10:41:57 2016
From: mitya at cargosoft.ru (Mitya)
Date: Fri, 17 Jun 2016 17:41:57 +0300
Subject: [keycloak-dev] Reloading KeyCloak on the fly
Message-ID: <1466174517.10212.10.camel@cargosoft.ru>

Hi,

I'm developing a KeyCloak extension which is packaged as two JBoss
modules:
- the extension proper (custom authenticator + custom realm resource +
custom admin theme);
- modified org.keycloak.keycloak-model-jpa (since Entity SPI is not yet
available).

Each time I make changes, I have to go through a roundabout of stopping
KeyCloak, deploying modules and starting KeyCloak again. This can
happen as many as several dozen times a day; as soon as I roll a CI
infrastructure, the build server will have to do the same. Needless to
say, the process is pretty time-consuming; additionally, I'll have to
grant permissions to the build server to restart a system service
(KeyCloak is deployed as systemd unit). I've tried the following in
jboss-cli:

[disconnected /] connect
[standalone at localhost:9990 /] module remove --name=foo.bar.main
[standalone at localhost:9990 /] module add --name=foo.bar.main --
resources=...?--dependencies=...
[standalone at localhost:9990 /] reload

This doesn't help, despite WildFly reports to have redeployed and
restarted KeyCloak. The updated modules are simply not picked up.

Am I missing something? KeyCloak developers, what would you recommend
to speed-up the workflow?

Cheers,
Mitya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160617/a13f944a/attachment.html 

From psilva at redhat.com  Fri Jun 17 11:51:35 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 17 Jun 2016 11:51:35 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <5764098F.1050700@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>
	<9ac0a941-666f-15cb-2ff3-8598eaa94660@redhat.com>
	<1920717619.17938110.1465572213044.JavaMail.zimbra@redhat.com>
	<573a2370-59f7-77ca-9544-acd47cfdc23e@redhat.com>
	<1456138264.17954317.1465574139108.JavaMail.zimbra@redhat.com>
	<329467153.20332400.1466097156190.JavaMail.zimbra@redhat.com>
	<5764098F.1050700@redhat.com>
Message-ID: <814043159.20952773.1466178695100.JavaMail.zimbra@redhat.com>

Hey Marek,

   First of all. Thanks for your questions. Answers inline.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, June 17, 2016 11:30:39 AM
> Subject: Re: [keycloak-dev] Feedback
> 
> I did not yet went deeply through all the details, however briefly went
> through the docs and examples. Few things:
> 
> - Term "scope" seems to be overloaded as we have it in other places in
> Keycloak too? Now when you click to some Client and then to tab
> "Authorization" you can see 2 tabs "Scopes" (one in level1 and second in
> level2) but both are used for a bit different thing. Isn't it some
> better term like "Action" ? For example "john can do 'action' DELETE on
> photoalbum xyz" seems to me more intuitive than "john has 'scope' DELETE
> on photoalbum xyz" . Or is this term required by UMA specification?

This is the term adopted by UMA specification:

   "A bounded extent of access that is possible to perform on a resource set. In authorization policy terminology, a scope is one of the potentially many "verbs" that can logically apply to a resource set ("object")."

In UMA, the resources associated with a scope are not implicit, but explicitly defined to a particular registered resource set. 

We can change it to something like "Actions". But I would prefer to stick with the scope term somehow, maybe "Resource Scopes" instead of just "Scopes" ?

I think "Actions" is not a OAuth2/UMA-like terminology :) 

> 
> - Is it possible to merge JSON file representation with the main
> keycloak RealmRepresentation? Currently to have "photoz" example
> running, I need to import realm ( photoz-uma-realm.json ) and then
> separately also another JSON with authorization configuration (
> photoz-uma-restful-api-authz.json ). If configuration of ResourceServer
> is moved under particular client of realm, it can be exported during
> export/import of whole realm and then imported again in single step. We
> can still support to import just the authorization configuration though,
> but have it supported when inside global file is good too IMO.

+1. Can we have that after 2.0.0.CR1 ?

> 
> - Should be Time-Based Policy the "first-class-citizen" - one of builtin
> policies? It seems you can achieve the same with Rule based policies
> (Javascript or Drools) ? You can simulate some other simpler policies
> like role-based or attribute-based with rule policies too, however they
> will be likely much more common usecase.

IMO, it should be kept as a built-in policy type. We should not rely on rule-based policies for everything.

In fact, the idea is make policy mgmt easier. Ideally, we should have a lot of built-in policy types.

> 
> - Java AuthzClient seems to be directly using Apache HttpClient. Is it
> easier to have it as jax-rs (or resteasy) client similarly like our
> admin-client? Or you want to avoid another dependency? It seems we
> currently have 3 clients (admin-client , client-registration , authz),
> so maybe we can somehow unify them to use similar approach and we can
> remove some boilerplate code? But this is implementation detail though...

I was using resteasy client, the reasons for dropping it was:

* adapter-core is using http client
* more flexibility to support an async API. Useful for reactive apps, MSAD, etc

If you look at the client API, I have added a very simple indirection layer to integrate with a third-party http client library. 

> 
> - Is it possible to see the list of available context attributes of
> javascript (or drools) policy? Also it's maybe possible to simplify
> names? For example 'kc.authz.context.client.network.ip_address' is quite
> a long name knowing that this is something, which people will be using
> in their impl?

+1

My main requirement regarding the name is that it should represent what is the attribute and its context. Maybe 'kc.authz.context' is redundant ? So we may have 'client.network.ip' ?

I've documented some of these attributes [1]. I think I need to improve the doc to highlight them. Will provide a specific topic and a table with all supported attributes.

> 
> - During the call few months ago, I mentioned the "weight" of
> authorization decision of aggregation policy. I want to cancel that as
> it looks you can always achieve the same effect by compose more
> aggregate policies together, so weight is not needed though. So this is
> just un-feedback of my previous feedback :)
> 
> - Is it possible to dynamically create permissions with Permissions API?
> Looks like just creating resources is possible ATM? For example, I
> wonder about classic social usecase "I want to share my photoalbum with
> user X" . Or "I want to share my photoalbum with group of users Y
> (Google+ circles)" . I guess UMA specs might have some support for this?

+1

UMA does not provide an API for that. That Permission API is for permission tickets only (UMA thing).

At the beginning, I have published the policy endpoint for remote access and an "Allow Remote Policy Management" button on the "Authorization Settings" page. I have removed it to think about this stuff with a little more love. We can do something really awesome with that.

I'm glad that you found it useful too, I hope to start a separated discussion to understand better your ideas around this topic.

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

> 
> - After create new photoalbum in the application, I can see that one new
> session is always created (tabs "Sessions" under client). When I delete
> photoalbum, I can see 6 (!!!) new sessions created. After create and
> delete few albums, I can see 44 active sessions :) I didn't verify what
> happens, looks like quite a lot of resource-owner-password-credentials
> or client-credentials requests? But seems we have time for optimizations
> and polishing later though...

Oops ! Will check that right away !

> 
> Marek
> 
> On 16/06/16 19:12, Pedro Igor Silva wrote:
> > Hi All,
> >
> >     After reviewing somethings based on the feedback from Bill and Stian,
> >     I've updated both code and docs [1] to reflect what we have discussed.
> >
> >     In a nutshell, I think UX is much better now. With less steps to get
> >     things done and in some cases with a default configuration to quickly
> >     get started with authorization services.
> >
> >     Special attention to the "Managing Resource Server" [2] section. There
> >     you'll understand the main changes that made things more simple.
> >
> >     I'll be working with some getting started tutorials, I think they will
> >     be very simple and easy to follow now.
> >
> >     Please, let me know your thoughts.
> >
> > [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
> > [2]
> > https://keycloak.gitbooks.io/authorization-services-guide/content/topics/resource-server/overview.html
> >     
> >
> > ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, June 10, 2016 12:55:39 PM
> > Subject: Re: [keycloak-dev] Feedback
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Friday, June 10, 2016 12:43:51 PM
> >> Subject: Re: Feedback
> >>
> >>
> >>
> >> On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Friday, June 10, 2016 12:11:37 PM
> >>>> Subject: Re: Feedback
> >>>>
> >>>>
> >>>>
> >>>> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >>>>>> Sent: Friday, June 10, 2016 10:39:07 AM
> >>>>>> Subject: Re: Feedback
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
> >>>>>>> Bill,
> >>>>>>>
> >>>>>>> Got the authz stuff working with the adapters. It was a puzzle but I
> >>>>>>> think
> >>>>>>> I have something.
> >>>>>> Yeah, its nasty.  Every servlet container handlers security just a bit
> >>>>>> differently than others so, its ugly.
> >>>>>>
> >>>>>>> * I've discarded my own sub-types of AccessToken, they were
> >>>>>>> redundant.
> >>>>>>> The
> >>>>>>> only difference between authz tokens and access tokens was a list of
> >>>>>>> permissions. And the concept behind them is the same. I've added a
> >>>>>>> "authorization" claim to AccessToken (null by default) from where
> >>>>>>> permissions granted by the server can be obtained.
> >>>>>> Is a claim better?
> >>>>> To represent a RPT, I believe it is.
> >>>>>
> >>>>>> Or should AccessTokenResponse optionally contain the RPT?
> >>>>> IMO, that would make things harder from a client perspective. See my
> >>>>> next
> >>>>> comments.
> >>>>>
> >>>>>> Or optionally a query param for Implicit Flow?  Or have both?  I
> >>>>>> don't know.
> >>>>> I think we have two different things here:
> >>>>>
> >>>>> * How a RPT looks like
> >>>>> * How a RPT is obtained (the protocol in use)
> >>>>>
> >>>>> In the first case, a RPT is just a special type of access token with
> >>>>> authorization data on it. Where this data is a result of the evaluation
> >>>>> of
> >>>>> permissions and authorization policies associated with the resources
> >>>>> being
> >>>>> requested. Here, that claim represents this data. This is protocol
> >>>>> agnostic.
> >>>>>
> >>>>> The latter case is how you obtain that data, which is strongly
> >>>>> associated
> >>>>> with the protocol in use. What you said makes a lot of sense, we can
> >>>>> issue
> >>>>> this authorization data when doing any of the OAuth2 grant types. That
> >>>>> can
> >>>>> be specially useful when you want to obtain all permissions for an user
> >>>>> at
> >>>>> once when authenticating in KC, avoiding an additional call to the
> >>>>> server
> >>>>> in order to obtain authorization specific data. One way to achieve that
> >>>>> would be a
> >>>>> "Entitlement Protocol Mapper" that is capable of decorating an access
> >>>>> token
> >>>>> with the authorization data. Thus, transforming the access token into a
> >>>>> RPT. See, the client just use the final access token without any
> >>>>> additional treatment.
> >>>>>
> >>>>> There are a lot of other features to implement around both UMA and
> >>>>> Entitlement protocols. For instance, claims gathering or obligations.
> >>>>> So
> >>>>> the server can ask the client for additional information. Eg.: require
> >>>>> a
> >>>>> higher security level, etc. And for that, we must be able to obtain
> >>>>> authz
> >>>>> data separately.
> >>>> IIRC, there's a REST API right that allows a client to turn an access
> >>>> token into an RPT?
> >>> Yes, that is what both Authorization and Entitlement API are meant for.
> >>>
> >>>> So, if Client A gets an access token, it can invoke
> >>>> on Service B.  Service B can pass the access token to Keycloak to obtain
> >>>> an RPT?
> >>> Yes you can. The built-in policy enforcers (related with the changes I
> >>> did
> >>> to adapters) can operation in two modes:
> >>>
> >>> * Bearer Token
> >>> * "Stateful" scenario (eg.: monolithic JEE apps)
> >>>
> >>> In the first case, is up to the client to obtain and send the RPT with
> >>> the
> >>> necessary permissions to access protected resources on the resource
> >>> server(Service B). Here you can use two protocols: UMA and Entitlement.
> >>> You know UMA. Entitlement is just a more lightweight and 1-legged
> >>> protocol
> >>> based on some UMA concepts. It doesn't require permission tickets and
> >>> stuff.
> >>>
> >>> In the latter case, there is a specific policy enforcer that does exactly
> >>> what you described. Obtaining a RPT transparently from a Keycloak server
> >>> using the *Entitlement* API.
> >>>
> >> My only reasoning for wanting the option to include the RPT in the
> >> AccessTokenResponse was for performance reasons.  Obtaining an RPT could
> >> be obtained for free for a specific client by piggybacking on the OAuth
> >> protocol, but the access token could remain small/lightweight and not
> >> contain the RPT.  You'd still want to be able to include the RPT within
> >> the AT if so desired, but there might come a point when the AT becomes
> >> too fat.
> >>
> >> All this isn't really important at this time though.  What's more
> >> important is releasing Authz soon.  I just foresese us wanting to
> >> provide different optimizations for different environments.
> >>
> >> Bill
> > +1. And that is the reason why I'm following this path now. So far, I was
> > using a very specific token to hold authz data. But as you said, let's
> > discuss about performance and optimizations at the appropriate time and
> > release this stuff first. We can do a lot of things at this regard.
> >
> > Regarding token size, during this work I did a research about this topic
> > and there are interesting discussions on OAuth2-WG.
> >
> > Thanks for all feedback, it was really important to improve things.
> >
> >>
> >>
> >>
> > _______________________________________________
> > 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 jdennis at redhat.com  Sun Jun 19 08:39:58 2016
From: jdennis at redhat.com (John Dennis)
Date: Sun, 19 Jun 2016 08:39:58 -0400
Subject: [keycloak-dev] AJP port and port-offset
Message-ID: <25a86135-fab1-11ee-1919-90741ad5bc8b@redhat.com>

In the past we had been using HTTP and utilizing 
jboss.socket.binding.port-offset to move the port to a higher number. 
But now we're using AJP and the port-offset does not seem to apply to 
the ajp port. Is this expected?


-- 
John


From jdennis at redhat.com  Sun Jun 19 08:44:56 2016
From: jdennis at redhat.com (John Dennis)
Date: Sun, 19 Jun 2016 08:44:56 -0400
Subject: [keycloak-dev] server start up errors
Message-ID: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>

[Note: you may get 2 copies of this email, I sent one previously from my 
private email account and it was held for moderator approval, re-sending 
this under my redhat account which is subscribed to this list.]

Using the latest release candidate 
/devel/candidates/jboss/sso/RHSSO-7.0.0 built on 6/13

the server will not initialize, server.log has a number of errors the 
following being the significant one I believe.

Failed to start service 
jboss.undertow.deployment.default-server.default-host./auth

For a while now we've seen errors related to database operations in the 
log, those errors are also present in the attached log but even with 
those database errors the server had seemed to start OK.

Would someone be kind enough to look at the attached log and suggest why 
the server won't start and what errors in the log should be concerning?

Many thanks,

-- 
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.log
Type: text/x-log
Size: 62637 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160619/2c104e84/attachment-0001.bin 

From mposolda at redhat.com  Mon Jun 20 02:50:26 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 20 Jun 2016 08:50:26 +0200
Subject: [keycloak-dev] Feedback
In-Reply-To: <814043159.20952773.1466178695100.JavaMail.zimbra@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<862917108.17926733.1465570777984.JavaMail.zimbra@redhat.com>
	<9ac0a941-666f-15cb-2ff3-8598eaa94660@redhat.com>
	<1920717619.17938110.1465572213044.JavaMail.zimbra@redhat.com>
	<573a2370-59f7-77ca-9544-acd47cfdc23e@redhat.com>
	<1456138264.17954317.1465574139108.JavaMail.zimbra@redhat.com>
	<329467153.20332400.1466097156190.JavaMail.zimbra@redhat.com>
	<5764098F.1050700@redhat.com>
	<814043159.20952773.1466178695100.JavaMail.zimbra@redhat.com>
Message-ID: <57679232.5000202@redhat.com>

On 17/06/16 17:51, Pedro Igor Silva wrote:
> Hey Marek,
>
>     First of all. Thanks for your questions. Answers inline.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, June 17, 2016 11:30:39 AM
>> Subject: Re: [keycloak-dev] Feedback
>>
>> I did not yet went deeply through all the details, however briefly went
>> through the docs and examples. Few things:
>>
>> - Term "scope" seems to be overloaded as we have it in other places in
>> Keycloak too? Now when you click to some Client and then to tab
>> "Authorization" you can see 2 tabs "Scopes" (one in level1 and second in
>> level2) but both are used for a bit different thing. Isn't it some
>> better term like "Action" ? For example "john can do 'action' DELETE on
>> photoalbum xyz" seems to me more intuitive than "john has 'scope' DELETE
>> on photoalbum xyz" . Or is this term required by UMA specification?
> This is the term adopted by UMA specification:
>
>     "A bounded extent of access that is possible to perform on a resource set. In authorization policy terminology, a scope is one of the potentially many "verbs" that can logically apply to a resource set ("object")."
>
> In UMA, the resources associated with a scope are not implicit, but explicitly defined to a particular registered resource set.
>
> We can change it to something like "Actions". But I would prefer to stick with the scope term somehow, maybe "Resource Scopes" instead of just "Scopes" ?
>
> I think "Actions" is not a OAuth2/UMA-like terminology :)
Ok, maybe "Resource Scopes" or "Authorization Scopes" is better then? 
Another possible thing is, that we should maybe also change the original 
meaning of "Scope" under client, which we use for limiting allowed 3rd 
party roles in the accessToken. I don't know TBH, maybe adding role 
namespaces will clearify this a bit...
>
>> - Is it possible to merge JSON file representation with the main
>> keycloak RealmRepresentation? Currently to have "photoz" example
>> running, I need to import realm ( photoz-uma-realm.json ) and then
>> separately also another JSON with authorization configuration (
>> photoz-uma-restful-api-authz.json ). If configuration of ResourceServer
>> is moved under particular client of realm, it can be exported during
>> export/import of whole realm and then imported again in single step. We
>> can still support to import just the authorization configuration though,
>> but have it supported when inside global file is good too IMO.
> +1. Can we have that after 2.0.0.CR1 ?
Sure, it's fine to add later IMO.
>
>> - Should be Time-Based Policy the "first-class-citizen" - one of builtin
>> policies? It seems you can achieve the same with Rule based policies
>> (Javascript or Drools) ? You can simulate some other simpler policies
>> like role-based or attribute-based with rule policies too, however they
>> will be likely much more common usecase.
> IMO, it should be kept as a built-in policy type. We should not rely on rule-based policies for everything.
>
> In fact, the idea is make policy mgmt easier. Ideally, we should have a lot of built-in policy types.
Ok. Just wonder if having many built-in policy types won't make things 
more complex rather than easier. Maybe if some newbie will first see the 
page with 20 builtin policy types, his first impression might be "Oh, 
there are so many policies... This authorization thing looks quite 
complex. I will rather hack something directly to my app, instead of 
learn all of those..."

But hopefully I am wrong :-)
>
>> - Java AuthzClient seems to be directly using Apache HttpClient. Is it
>> easier to have it as jax-rs (or resteasy) client similarly like our
>> admin-client? Or you want to avoid another dependency? It seems we
>> currently have 3 clients (admin-client , client-registration , authz),
>> so maybe we can somehow unify them to use similar approach and we can
>> remove some boilerplate code? But this is implementation detail though...
> I was using resteasy client, the reasons for dropping it was:
>
> * adapter-core is using http client
> * more flexibility to support an async API. Useful for reactive apps, MSAD, etc
>
> If you look at the client API, I have added a very simple indirection layer to integrate with a third-party http client library.
>
>> - Is it possible to see the list of available context attributes of
>> javascript (or drools) policy? Also it's maybe possible to simplify
>> names? For example 'kc.authz.context.client.network.ip_address' is quite
>> a long name knowing that this is something, which people will be using
>> in their impl?
> +1
>
> My main requirement regarding the name is that it should represent what is the attribute and its context. Maybe 'kc.authz.context' is redundant ? So we may have 'client.network.ip' ?
>
> I've documented some of these attributes [1]. I think I need to improve the doc to highlight them. Will provide a specific topic and a table with all supported attributes.
Thanks. Maybe "client.network.ip" or "kc.client.ip" (just keep "kc" 
prefix for all attributes provided by keycloak) is easier?

Btv. just noticed that 2 links from javascript policy page 
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/policy/js-policy.html 
to "Evaluation API" are broken.
>
>> - During the call few months ago, I mentioned the "weight" of
>> authorization decision of aggregation policy. I want to cancel that as
>> it looks you can always achieve the same effect by compose more
>> aggregate policies together, so weight is not needed though. So this is
>> just un-feedback of my previous feedback :)
>>
>> - Is it possible to dynamically create permissions with Permissions API?
>> Looks like just creating resources is possible ATM? For example, I
>> wonder about classic social usecase "I want to share my photoalbum with
>> user X" . Or "I want to share my photoalbum with group of users Y
>> (Google+ circles)" . I guess UMA specs might have some support for this?
> +1
>
> UMA does not provide an API for that. That Permission API is for permission tickets only (UMA thing).
>
> At the beginning, I have published the policy endpoint for remote access and an "Allow Remote Policy Management" button on the "Authorization Settings" page. I have removed it to think about this stuff with a little more love. We can do something really awesome with that.
>
> I'm glad that you found it useful too, I hope to start a separated discussion to understand better your ideas around this topic.
>
> https://issues.jboss.org/browse/KEYCLOAK-3135
Ok, I will add comments to JIRA

Marek
>
>> - After create new photoalbum in the application, I can see that one new
>> session is always created (tabs "Sessions" under client). When I delete
>> photoalbum, I can see 6 (!!!) new sessions created. After create and
>> delete few albums, I can see 44 active sessions :) I didn't verify what
>> happens, looks like quite a lot of resource-owner-password-credentials
>> or client-credentials requests? But seems we have time for optimizations
>> and polishing later though...
> Oops ! Will check that right away !
>
>> Marek
>>
>> On 16/06/16 19:12, Pedro Igor Silva wrote:
>>> Hi All,
>>>
>>>      After reviewing somethings based on the feedback from Bill and Stian,
>>>      I've updated both code and docs [1] to reflect what we have discussed.
>>>
>>>      In a nutshell, I think UX is much better now. With less steps to get
>>>      things done and in some cases with a default configuration to quickly
>>>      get started with authorization services.
>>>
>>>      Special attention to the "Managing Resource Server" [2] section. There
>>>      you'll understand the main changes that made things more simple.
>>>
>>>      I'll be working with some getting started tutorials, I think they will
>>>      be very simple and easy to follow now.
>>>
>>>      Please, let me know your thoughts.
>>>
>>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
>>> [2]
>>> https://keycloak.gitbooks.io/authorization-services-guide/content/topics/resource-server/overview.html
>>>      
>>>
>>> ----- Original Message -----
>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>> To: "Bill Burke" <bburke at redhat.com>
>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Friday, June 10, 2016 12:55:39 PM
>>> Subject: Re: [keycloak-dev] Feedback
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Friday, June 10, 2016 12:43:51 PM
>>>> Subject: Re: Feedback
>>>>
>>>>
>>>>
>>>> On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Friday, June 10, 2016 12:11:37 PM
>>>>>> Subject: Re: Feedback
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>>>>>> Sent: Friday, June 10, 2016 10:39:07 AM
>>>>>>>> Subject: Re: Feedback
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
>>>>>>>>> Bill,
>>>>>>>>>
>>>>>>>>> Got the authz stuff working with the adapters. It was a puzzle but I
>>>>>>>>> think
>>>>>>>>> I have something.
>>>>>>>> Yeah, its nasty.  Every servlet container handlers security just a bit
>>>>>>>> differently than others so, its ugly.
>>>>>>>>
>>>>>>>>> * I've discarded my own sub-types of AccessToken, they were
>>>>>>>>> redundant.
>>>>>>>>> The
>>>>>>>>> only difference between authz tokens and access tokens was a list of
>>>>>>>>> permissions. And the concept behind them is the same. I've added a
>>>>>>>>> "authorization" claim to AccessToken (null by default) from where
>>>>>>>>> permissions granted by the server can be obtained.
>>>>>>>> Is a claim better?
>>>>>>> To represent a RPT, I believe it is.
>>>>>>>
>>>>>>>> Or should AccessTokenResponse optionally contain the RPT?
>>>>>>> IMO, that would make things harder from a client perspective. See my
>>>>>>> next
>>>>>>> comments.
>>>>>>>
>>>>>>>> Or optionally a query param for Implicit Flow?  Or have both?  I
>>>>>>>> don't know.
>>>>>>> I think we have two different things here:
>>>>>>>
>>>>>>> * How a RPT looks like
>>>>>>> * How a RPT is obtained (the protocol in use)
>>>>>>>
>>>>>>> In the first case, a RPT is just a special type of access token with
>>>>>>> authorization data on it. Where this data is a result of the evaluation
>>>>>>> of
>>>>>>> permissions and authorization policies associated with the resources
>>>>>>> being
>>>>>>> requested. Here, that claim represents this data. This is protocol
>>>>>>> agnostic.
>>>>>>>
>>>>>>> The latter case is how you obtain that data, which is strongly
>>>>>>> associated
>>>>>>> with the protocol in use. What you said makes a lot of sense, we can
>>>>>>> issue
>>>>>>> this authorization data when doing any of the OAuth2 grant types. That
>>>>>>> can
>>>>>>> be specially useful when you want to obtain all permissions for an user
>>>>>>> at
>>>>>>> once when authenticating in KC, avoiding an additional call to the
>>>>>>> server
>>>>>>> in order to obtain authorization specific data. One way to achieve that
>>>>>>> would be a
>>>>>>> "Entitlement Protocol Mapper" that is capable of decorating an access
>>>>>>> token
>>>>>>> with the authorization data. Thus, transforming the access token into a
>>>>>>> RPT. See, the client just use the final access token without any
>>>>>>> additional treatment.
>>>>>>>
>>>>>>> There are a lot of other features to implement around both UMA and
>>>>>>> Entitlement protocols. For instance, claims gathering or obligations.
>>>>>>> So
>>>>>>> the server can ask the client for additional information. Eg.: require
>>>>>>> a
>>>>>>> higher security level, etc. And for that, we must be able to obtain
>>>>>>> authz
>>>>>>> data separately.
>>>>>> IIRC, there's a REST API right that allows a client to turn an access
>>>>>> token into an RPT?
>>>>> Yes, that is what both Authorization and Entitlement API are meant for.
>>>>>
>>>>>> So, if Client A gets an access token, it can invoke
>>>>>> on Service B.  Service B can pass the access token to Keycloak to obtain
>>>>>> an RPT?
>>>>> Yes you can. The built-in policy enforcers (related with the changes I
>>>>> did
>>>>> to adapters) can operation in two modes:
>>>>>
>>>>> * Bearer Token
>>>>> * "Stateful" scenario (eg.: monolithic JEE apps)
>>>>>
>>>>> In the first case, is up to the client to obtain and send the RPT with
>>>>> the
>>>>> necessary permissions to access protected resources on the resource
>>>>> server(Service B). Here you can use two protocols: UMA and Entitlement.
>>>>> You know UMA. Entitlement is just a more lightweight and 1-legged
>>>>> protocol
>>>>> based on some UMA concepts. It doesn't require permission tickets and
>>>>> stuff.
>>>>>
>>>>> In the latter case, there is a specific policy enforcer that does exactly
>>>>> what you described. Obtaining a RPT transparently from a Keycloak server
>>>>> using the *Entitlement* API.
>>>>>
>>>> My only reasoning for wanting the option to include the RPT in the
>>>> AccessTokenResponse was for performance reasons.  Obtaining an RPT could
>>>> be obtained for free for a specific client by piggybacking on the OAuth
>>>> protocol, but the access token could remain small/lightweight and not
>>>> contain the RPT.  You'd still want to be able to include the RPT within
>>>> the AT if so desired, but there might come a point when the AT becomes
>>>> too fat.
>>>>
>>>> All this isn't really important at this time though.  What's more
>>>> important is releasing Authz soon.  I just foresese us wanting to
>>>> provide different optimizations for different environments.
>>>>
>>>> Bill
>>> +1. And that is the reason why I'm following this path now. So far, I was
>>> using a very specific token to hold authz data. But as you said, let's
>>> discuss about performance and optimizations at the appropriate time and
>>> release this stuff first. We can do a lot of things at this regard.
>>>
>>> Regarding token size, during this work I did a research about this topic
>>> and there are interesting discussions on OAuth2-WG.
>>>
>>> Thanks for all feedback, it was really important to improve things.
>>>
>>>>
>>>>
>>> _______________________________________________
>>> 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 thomas.darimont at googlemail.com  Mon Jun 20 03:37:06 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 20 Jun 2016 09:37:06 +0200
Subject: [keycloak-dev] Keycloak commit message format
Message-ID: <CAK-7U1i4ny7HPn7r+posMmX2sQN5dAR1e1M9C2pwCyp+DkeP3w@mail.gmail.com>

Hello group,

it's just a minor thing and sorry to ask that as an outsider
but I was wondering whether you could agree on a standard for commit
messages that reference JIRA issues.

In the git log one sees variants like:
KEYCLOAK-XXX 1st line of commit message
KEYCLOAK-XXX: 1st line of commit message
KEYCLOAK-XXX - 1st line of commit message
[KEYCLOAK-XXX] - 1st line of commit message

Would be great if you guys could agree on a style != freestyle :)

Cheers,
Thomas

PS:
I use the git alias lg to glance over the keycloak log

alias.lg=log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset
%s %Cgreen(%cr) %C(yellow)<%an - %ae>%Creset' --abbrev-commit
--date=relative
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160620/ccd49d01/attachment.html 

From mstrukel at redhat.com  Mon Jun 20 06:13:35 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Mon, 20 Jun 2016 12:13:35 +0200
Subject: [keycloak-dev] server start up errors
In-Reply-To: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
Message-ID: <CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>

The first error means that there are existing tables in the local H2
database (under standalone/data there are keycloak.* files).

It looks like the logic determined that they are of some previous db schema
version, and tried to upgrade the schema to latest version, but
unexpectedly the schema in place already seems to contain the tables it
wasn't supposed to contain.

I suppose that could happen if upgrade process is interrupted by restarting
the server?

Since you are using the default H2 database I assume you don't care about
any existing data. The solution for you then is to stop the server, delete
the database (rm standalone/data/keycloak.*), and start the server again.

On Sun, Jun 19, 2016 at 2:44 PM, John Dennis <jdennis at redhat.com> wrote:

> [Note: you may get 2 copies of this email, I sent one previously from my
> private email account and it was held for moderator approval, re-sending
> this under my redhat account which is subscribed to this list.]
>
> Using the latest release candidate /devel/candidates/jboss/sso/RHSSO-7.0.0
> built on 6/13
>
> the server will not initialize, server.log has a number of errors the
> following being the significant one I believe.
>
> Failed to start service
> jboss.undertow.deployment.default-server.default-host./auth
>
> For a while now we've seen errors related to database operations in the
> log, those errors are also present in the attached log but even with those
> database errors the server had seemed to start OK.
>
> Would someone be kind enough to look at the attached log and suggest why
> the server won't start and what errors in the log should be concerning?
>
> Many thanks,
>
> --
> John
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160620/79f80fa2/attachment.html 

From mposolda at redhat.com  Mon Jun 20 09:24:24 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 20 Jun 2016 15:24:24 +0200
Subject: [keycloak-dev] Transactions WAS Re: User Federation Provider
 Cache
In-Reply-To: <58f8a784-b4a5-9fc5-0295-9dcad55c61c0@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BC0B.4020208@redhat.com>
	<58f8a784-b4a5-9fc5-0295-9dcad55c61c0@redhat.com>
Message-ID: <5767EE88.8000902@redhat.com>

On 17/06/16 15:45, Bill Burke wrote:
>
>
> On 6/17/16 4:59 AM, Marek Posolda wrote:
>> On 16/06/16 16:38, Bill Burke wrote:
>>>>>> Transactions and 3rd party updates
>>>>>> -----------------------------------------------
>>>>>>
>>>>>> - Will be good to improve registration of user to LDAP. Ideally 
>>>>>> during
>>>>>> registration new user to LDAP, we should allow to send all data at
>>>>>> once.
>>>>>> (currently UserFederationProvider.register supports sending just
>>>>>> username). Also we should allow to specify if register to 3rd party
>>>>>> provider should be done *before* or *after* the registration to
>>>>>> Keycloak
>>>>>> local DB. For details, see
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-1075
>>>>>> and all the comments from users...
>>>>>>
>>>>>> - Also updating user should be ideally at once. For example if you
>>>>>> call:
>>>>>> user.setFirstName("john");
>>>>>> user.setLastName("Doe");
>>>>>> user.setEmail("john at email.cz");
>>>>>>
>>>>>> we shouldn't have 3 update calls to LDAP, but just one. Maybe we can
>>>>>> address this with transaction abstraction? I've already did 
>>>>>> something
>>>>>> for LDAP provider (see TxAwareLDAPUserModelDelegate ), however 
>>>>>> will be
>>>>>> good to provide something more generic for user storage SPI. Then 
>>>>>> when
>>>>>> KeycloakTransactionManager.commit is called, the data are send to
>>>>>> federation storage
>>>>>>
>>>>>
>>>>> This would be an implementation detail.  Similar to JPA Users, the
>>>>> LDAP UserAdapter will be remembered per session.  The LDAP adapter
>>>>> could queue up updates then at commit time flush them all.
>>>>>
>>>>> Maybe you should consider writing an LDAP version of JPA? ;-)
>>>>> Probably a lot of code could be borrowed from PL IDM API.
>>>> I've wrote already something similar for Mongo ;) Also I already
>>>> addressed the multiple-updates issue for LDAP (see above). However 
>>>> this
>>>> one is mainly issue for 3rd party providers rather than for LDAP
>>>> provider. Especially since 3rd party provider may have some 
>>>> validations
>>>> for some attributes.
>>>>
>>>>
>>>> For example consider this scenario, which can happen in current
>>>> implementation:
>>>>
>>>> UserModel john = session.users().addUser(realm, "john");
>>>> john.setEmail("john at email.org");
>>>>
>>>> All of this happens during "addUser" call:
>>>>
>>>> - User "john" is saved to local-db
>>>> - SomeUserFederationProvider.register calls the registration 
>>>> request to
>>>> 3rd party federation storage. User "john" is saved in 3rd party 
>>>> storage
>>>> now.
>>>>
>>>> Then john.setEmail is invoked
>>>> - There is request to 3rd party federation storage to update email.
>>>> - 3rd party storage refuse to save the email because there is 
>>>> already an
>>>> existing user with email "john at email.org" . So it sends back the
>>>> validation error. Now keycloak can rollback the transaction, however
>>>> user "john" was already registered in 3rd party federation storage 
>>>> from
>>>> previous "register" call -> FAIL
>>>>
>>>> So now you need to manually remove the user from 3rd party storage,
>>>> which is dirty hack. There are other possible hacks to address 
>>>> this. For
>>>> example someone "postpone" the registration in "register" method by
>>>> adding some helper attributes and sends the registration request later
>>>> when all the attributes are set. I suggest to read the comments in
>>>> https://issues.jboss.org/browse/KEYCLOAK-1075 for details.
>>>>
>>>> IMO the proper solution is to ensure that "register" request to 3rd
>>>> party is postponed until the transaction.commit when user is filled 
>>>> with
>>>> all the attributes. Similarly update should be done just once. IMO we
>>>> should provide something at SPI level to simplify this scenario.
>>>>
>>>
>>> We already have a KeycloakTransaction you can register with.
>>>
>>>> I understand that main motivation for you is to avoid "imports", 
>>>> however
>>>> since we are refactoring anyway, we should try to address other SPI
>>>> limitations too. And IMO this one is pretty bad and worth improve ;)
>>>
>>> So, have a method addUser(RealmModel realm, UserEntity user)?
>> I am thinking about adding some helper classes, so the people don't need
>> to directly deal with our transaction API and manually enlist
>> transactions in their code etc.
>>
>> Also it will be good to have some support for validations (aka. pseudo
>> 2-phase commit), so that all "small" userStores have possibility to
>> first validate if created/updated user is valid for them and then the
>> real update is send. This will help to avoid situation like:
>> - transaction.commit is invoked
>> - store1 successfully register the user and commits
>> - store2 rejects to register user because of some validation error (ie.
>> duplicated email)
>> - now some data of invalid user already saved in store1 -> FAIL .
>> Because at this point, whole transaction should be rollback and user
>> shouldn't be saved anywhere.
>>
>>
>> I am thinking about pseudo-code similar to this:
>>
>> public abstract class FederationTransaction implements 
>> KeycloakTransaction {
>>
>>     protected TransactionState state = TransactionState.NOT_STARTED;
>>     protected final TxUserStore userStore;
>>     protected final TxUserModel user;
>>
>>     public FederationTransaction(TxUserStore userStore, TxUserModel 
>> user) {
>>         this.userStore = userStore;
>>         this.user = user;
>>     }
>>
>>     // Implement common stuff like begin, rollback, setRollbackOnly...
>>
>> }
>>
>>
>> // This transaction just validates in 3rd party store if user is ok
>> public class ValidationTransaction extends FederationTransaction {
>>
>>     public ValidationTransaction(TxUserStore userStore, TxUserModel 
>> user) {
>>         super(userStore, user);
>>     }
>>
>>     @Override
>>     protected void commit() {
>>         userStore.validateUser(user);
>>     }
>>
>> }
>>
>>
>> // This transaction finally sends commit to 3rd party store
>> public class CommitTransaction extends FederationTransaction {
>>
>>     public CommitTransaction(TxUserStore userStore, TxUserModel user) {
>>         super(userStore, user);
>>     }
>>
>>     @Override
>>     protected void commit() {
>>         userStore.createOrUpdateUser(user);
>>     }
>>
>> }
>>
>>
>> public abstract class TxUserStore implements UserStore {
>>
>>     private final KeycloakSession session;
>>
>>     public TxUserStore(KeycloakSession session) {
>>         this.session = session;
>>     }
>>
>>     public KeycloakSession getSession() {
>>         return session;
>>     }
>>
>>     // Send request to storage to validate user
>>     protected abstract void validateUser(TxUserModel user) throws
>> FederationValidationException;
>>
>>     // Send request to create or update user during transaction.commit
>> when all stores successfully validated user
>>     protected abstract void createOrUpdateUser(TxUserModel user);
>> }
>>
>>
>>
>> public class TxUserModel extends UserModelDelegate {
>>
>>     private ValidationTransaction validationTransaction;
>>     private CommitTransaction commitTransaction;
>>
>>     private final TxUserStore store;
>>
>>     public TxUserModel(UserModel delegate, TxUserStore store) {
>>         super(delegate);
>>         this.store = store;
>>     }
>>
>>
>>     protected void ensureTransactionEnlisted() {
>>         if (commitTransaction == null) {
>>             validationTransaction = new ValidationTransaction(store, 
>> this);
>>             commitTransaction = new CommitTransaction(store, this);
>>
>>             // Ensure all validation transactions are called before
>> sending real "commit" to any storage
>>
>> store.getSession().getTransaction().enlistPrepare(validationTransaction); 
>>
>>
>>             // Enlisting real transaction here
>>
>> store.getSession().getTransaction().enlistAfterCompletion(commitTransaction); 
>>
>>         }
>>     }
>>
>> }
>>
>>
>>
>> Now in your real store implementation, you need to do just this to
>> ensure that registration of user is postponed to transaction commit:
>>
>> public UserModel register(UserModel register(RealmModel realm, UserModel
>> user) {
>>   MyTxUserModel wrappedUser = new MyTxUserModel(user, this);
>>   wrappedUser.ensureTransactionEnlisted();
>> }
>>
>>
>> And also ensure that transaction is enlisted during any update calls. So
>> in MyTxUserModel override the needed setter methods like this:
>>
>>    @Override
>>    public void setFirstName(String firstName) {
>>         ensureTransactionEnlisted();
>>         super.setFirstName(firstName);
>>     }
>>
>>     @Override
>>     public void setLastName(String lastName) {
>>         ensureTransactionEnlisted();
>>         super.setLastName(lastName);
>>     }
>>
>>
>> With this approach, when you have:
>> UserModel john = session.users().addUser("john", realm);
>> john.setFirstName("John");
>> john.setLastName("Doe");
>>
>> you have the register call postponed until the transaction.commit .
>>
>> The thing is, that with postponed registration you won't know the ID of
>> newly created user at the moment when "addUser" is called. However not
>> sure if that's big issue... Another approach might be that UserStore
>> will have possibility to specify if it supports transactions or not.
>> Then we can have method "rollback" on UserStore, which will be called if
>> keycloakTransaction.rollback is called.
>>
>
> Isn't adding:
>
> addUser(org.keycloak.models.entities.UserEntity)
>
> much simpler than all of the things you propose?  We change the 
> registration flow to build up a UserEntity object that is eventually 
> used to create the user.
It is slightly easier, however it doesn't handle transactions and 
single-step updates.

In more details, scenarios like this:

a) With yours, user will be added right away and not at 
transaction.commit. This might be bad especially for non-transactional 
stores like LDAP. For example scenario like:
- userStorage.addUser(userEntity) is called. User will be created right 
away at 3rd party store
- transaction.setRollbackOnly is called by keycloak
- transaction.rollback at the end of request. However your user was 
already registered at the store.

b) Case when you are updating user and doing something like:

user.setFirstName("john");
user.setLastName("Doe");
user.setEmail("john at email.cz");

and you want to ensure that just one update call is done to the storage 
instead of 3 update calls.


How to handle b) if you don't want people to either update after each 
setter or manually deal with our transaction API and implement all the 
boilerplate code for enlist transaction by themselves? Maybe add the 
method for explicit update call:

userStorage.updateUser(userEntity)

can handle it? However that's still not transaction aware though...


In my proposal, I am trying to simplify the dealing with our transaction 
API and add some helper classes, so people don't need to manually enlist 
transaction and use the same boilerplate code to enlist transaction at 
each setter and implement it by themselves. We will mostly implement for 
them. Only thing they need is to call "ensureTransactionStarted" in 
their setters and 2 lines of code at "register" method to ensure 
transaction is started and enlisted.

Marek
>
> Bill


From mposolda at redhat.com  Mon Jun 20 09:32:50 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 20 Jun 2016 15:32:50 +0200
Subject: [keycloak-dev] Pagination Re:  User Federation Provider Cache
In-Reply-To: <5b205a08-b24f-ecfb-71b4-61c5b2bef022@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
	<5b205a08-b24f-ecfb-71b4-61c5b2bef022@redhat.com>
Message-ID: <5767F082.6010902@redhat.com>

On 17/06/16 16:07, Bill Burke wrote:
>
>
> On 6/17/16 5:10 AM, Marek Posolda wrote:
>> On 16/06/16 16:38, Bill Burke wrote:
>>>>>> Sync users
>>>>>> --------------
>>>>>> We should still keep the option to sync users into Keycloak DB as we
>>>>>> have now. Note some persistent storages like LDAP are limited with
>>>>>> pagination. So the easiest possibility for some admins is just to 
>>>>>> sync
>>>>>> users, so they can easily search them in admin console.
>>>>>>
>>>>> Doing a full import just to support pagination is overkill. I'm
>>>>> guessing that a lot of deployments will not manage users through the
>>>>> Keycload admin console.  We can offer a manual a Sync SPI that
>>>>> providers can implement.
>>>> Maybe it's overkill for 90% of deployments, but remaining 10% want to
>>>> see all LDAP users in admin console immediatelly and hence want to 
>>>> sync
>>>> them? IMO it's always good to have SPI flexible so it can easily 
>>>> support
>>>> all the possible requirements. However I understand that it's not 
>>>> always
>>>> possible...
>>>>
>>>
>>> This is only an issue for large query result sets where you want to do
>>> pagination.  IIRC, we couldn't figure out a way to do this in a
>>> scalable manner without imports.
>> yeah, I also can't see how to do pagination without imports, assuming
>> the 3rd party store (ie. LDAP) doesn't have pagination support.
>>
>> So then again, the question is if SPI should still have the option to
>> support imports? Or maybe don't have it OOTB, but if customers start
>> asking for pagination, we have the option to say them "ok, we will try
>> to add it" instead of "no, you can't do that and there is no way to
>> support it with current SPI" .
>>
>
> Currently, the provider is responsible for implementing the import.  
> The SPI *requires* that import is implemented by hand by the 
> developer.  The SPI *requires* a proxy which is also implemented by 
> hand by the developer.  The provider is also responsible for 
> implementing synchronization.  All this just to support pagination on 
> the admin console page.
>
> Also, pagination sucks already in our current implementation. Consider 
> a query that returns 1000 users, this would require importing those 
> 1000 users, before the pagination can even work. I don't know what we 
> were thinking!  It was such a bad idea....
yes, however once you imported them, they were available and in all next 
queries. You were able to search on them without additional performance 
penalty.

I can't see good solution for pagination TBH... Either we support it 
(even if 3rd party stores doesn't have support for pagination) but then 
we need import though, or we don't support it. We can see later if 
people start to complain that pagination doesn't work as expected...


>
> Bill
>
>


From psilva at redhat.com  Mon Jun 20 12:08:26 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 20 Jun 2016 12:08:26 -0400 (EDT)
Subject: [keycloak-dev] Feedback
In-Reply-To: <57679232.5000202@redhat.com>
References: <1407824939.16771663.1465399417497.JavaMail.zimbra@redhat.com>
	<1920717619.17938110.1465572213044.JavaMail.zimbra@redhat.com>
	<573a2370-59f7-77ca-9544-acd47cfdc23e@redhat.com>
	<1456138264.17954317.1465574139108.JavaMail.zimbra@redhat.com>
	<329467153.20332400.1466097156190.JavaMail.zimbra@redhat.com>
	<5764098F.1050700@redhat.com>
	<814043159.20952773.1466178695100.JavaMail.zimbra@redhat.com>
	<57679232.5000202@redhat.com>
Message-ID: <93683295.322125.1466438906415.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, June 20, 2016 3:50:26 AM
> Subject: Re: [keycloak-dev] Feedback
> 
> On 17/06/16 17:51, Pedro Igor Silva wrote:
> > Hey Marek,
> >
> >     First of all. Thanks for your questions. Answers inline.
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Friday, June 17, 2016 11:30:39 AM
> >> Subject: Re: [keycloak-dev] Feedback
> >>
> >> I did not yet went deeply through all the details, however briefly went
> >> through the docs and examples. Few things:
> >>
> >> - Term "scope" seems to be overloaded as we have it in other places in
> >> Keycloak too? Now when you click to some Client and then to tab
> >> "Authorization" you can see 2 tabs "Scopes" (one in level1 and second in
> >> level2) but both are used for a bit different thing. Isn't it some
> >> better term like "Action" ? For example "john can do 'action' DELETE on
> >> photoalbum xyz" seems to me more intuitive than "john has 'scope' DELETE
> >> on photoalbum xyz" . Or is this term required by UMA specification?
> > This is the term adopted by UMA specification:
> >
> >     "A bounded extent of access that is possible to perform on a resource
> >     set. In authorization policy terminology, a scope is one of the
> >     potentially many "verbs" that can logically apply to a resource set
> >     ("object")."
> >
> > In UMA, the resources associated with a scope are not implicit, but
> > explicitly defined to a particular registered resource set.
> >
> > We can change it to something like "Actions". But I would prefer to stick
> > with the scope term somehow, maybe "Resource Scopes" instead of just
> > "Scopes" ?
> >
> > I think "Actions" is not a OAuth2/UMA-like terminology :)
> Ok, maybe "Resource Scopes" or "Authorization Scopes" is better then?
> Another possible thing is, that we should maybe also change the original
> meaning of "Scope" under client, which we use for limiting allowed 3rd
> party roles in the accessToken. I don't know TBH, maybe adding role
> namespaces will clearify this a bit...

OK, well'l change it to "Resource Scopes".

IMO, we should expand the concept of Keycloak Scopes. Currently, there is a 1:1 mapping between roles and scopes, but scopes are much more than role mapping.

It would be nice to build scopes from attributes or even compose a scope based on multiple attributes.  For instance, a "profile" attribute could be a scope that includes "email", "address", "first name", "last name" attributes. If a client is granted with this scope (based on user consent), these attributes would be available from the access token.

Or is that already supported and I'm missing it ? Maybe we should discuss that on a separated thread :)

> >
> >> - Is it possible to merge JSON file representation with the main
> >> keycloak RealmRepresentation? Currently to have "photoz" example
> >> running, I need to import realm ( photoz-uma-realm.json ) and then
> >> separately also another JSON with authorization configuration (
> >> photoz-uma-restful-api-authz.json ). If configuration of ResourceServer
> >> is moved under particular client of realm, it can be exported during
> >> export/import of whole realm and then imported again in single step. We
> >> can still support to import just the authorization configuration though,
> >> but have it supported when inside global file is good too IMO.
> > +1. Can we have that after 2.0.0.CR1 ?
> Sure, it's fine to add later IMO.

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

> >
> >> - Should be Time-Based Policy the "first-class-citizen" - one of builtin
> >> policies? It seems you can achieve the same with Rule based policies
> >> (Javascript or Drools) ? You can simulate some other simpler policies
> >> like role-based or attribute-based with rule policies too, however they
> >> will be likely much more common usecase.
> > IMO, it should be kept as a built-in policy type. We should not rely on
> > rule-based policies for everything.
> >
> > In fact, the idea is make policy mgmt easier. Ideally, we should have a lot
> > of built-in policy types.
> Ok. Just wonder if having many built-in policy types won't make things
> more complex rather than easier. Maybe if some newbie will first see the
> page with 20 builtin policy types, his first impression might be "Oh,
> there are so many policies... This authorization thing looks quite
> complex. I will rather hack something directly to my app, instead of
> learn all of those..."
> 
> But hopefully I am wrong :-)

I think complexity is not really related with the amount of OOTB and built-in policy types we provided. On the contrary, specific policy types will make life a lot easier for users. For instance, if your requirement says that only users from Brno (location) can access some stuff, we may provide a "Location-based" (group Context-Based) policy that provides a Google-map or some other input to specify a location.

I'm not saying that we should have a policy type for everything, but elect those that may be provided OOTB.

Regarding hacking authz directly into an app, people tend to follow the easiest path. That is pretty much what we (devs) have been doing it for years. However, I strongly believe that this practice is changing, specially if you consider cloud security, IoT and what people call micro services.

In fact, we are starting to see use-cases/specifications like UMA and this one [1] which are already considering fine-grained authz as a first-class citizen. There is also XACML, which is still alive and have its space in enterprises.

I hope we could provide something easy for the most simple to the more complex use cases, where using KC as a centralized authorization server won't be too much different and harder than hack authz directly to your app :)

[1] https://tools.ietf.org/html/draft-seitz-ace-usecases-01

> >
> >> - Java AuthzClient seems to be directly using Apache HttpClient. Is it
> >> easier to have it as jax-rs (or resteasy) client similarly like our
> >> admin-client? Or you want to avoid another dependency? It seems we
> >> currently have 3 clients (admin-client , client-registration , authz),
> >> so maybe we can somehow unify them to use similar approach and we can
> >> remove some boilerplate code? But this is implementation detail though...
> > I was using resteasy client, the reasons for dropping it was:
> >
> > * adapter-core is using http client
> > * more flexibility to support an async API. Useful for reactive apps, MSAD,
> > etc
> >
> > If you look at the client API, I have added a very simple indirection layer
> > to integrate with a third-party http client library.
> >
> >> - Is it possible to see the list of available context attributes of
> >> javascript (or drools) policy? Also it's maybe possible to simplify
> >> names? For example 'kc.authz.context.client.network.ip_address' is quite
> >> a long name knowing that this is something, which people will be using
> >> in their impl?
> > +1
> >
> > My main requirement regarding the name is that it should represent what is
> > the attribute and its context. Maybe 'kc.authz.context' is redundant ? So
> > we may have 'client.network.ip' ?
> >
> > I've documented some of these attributes [1]. I think I need to improve the
> > doc to highlight them. Will provide a specific topic and a table with all
> > supported attributes.
> Thanks. Maybe "client.network.ip" or "kc.client.ip" (just keep "kc"
> prefix for all attributes provided by keycloak) is easier?

+1

> 
> Btv. just noticed that 2 links from javascript policy page
> https://keycloak.gitbooks.io/authorization-services-guide/content/topics/policy/js-policy.html
> to "Evaluation API" are broken.
> >
> >> - During the call few months ago, I mentioned the "weight" of
> >> authorization decision of aggregation policy. I want to cancel that as
> >> it looks you can always achieve the same effect by compose more
> >> aggregate policies together, so weight is not needed though. So this is
> >> just un-feedback of my previous feedback :)
> >>
> >> - Is it possible to dynamically create permissions with Permissions API?
> >> Looks like just creating resources is possible ATM? For example, I
> >> wonder about classic social usecase "I want to share my photoalbum with
> >> user X" . Or "I want to share my photoalbum with group of users Y
> >> (Google+ circles)" . I guess UMA specs might have some support for this?
> > +1
> >
> > UMA does not provide an API for that. That Permission API is for permission
> > tickets only (UMA thing).
> >
> > At the beginning, I have published the policy endpoint for remote access
> > and an "Allow Remote Policy Management" button on the "Authorization
> > Settings" page. I have removed it to think about this stuff with a little
> > more love. We can do something really awesome with that.
> >
> > I'm glad that you found it useful too, I hope to start a separated
> > discussion to understand better your ideas around this topic.
> >
> > https://issues.jboss.org/browse/KEYCLOAK-3135
> Ok, I will add comments to JIRA
> 
> Marek
> >
> >> - After create new photoalbum in the application, I can see that one new
> >> session is always created (tabs "Sessions" under client). When I delete
> >> photoalbum, I can see 6 (!!!) new sessions created. After create and
> >> delete few albums, I can see 44 active sessions :) I didn't verify what
> >> happens, looks like quite a lot of resource-owner-password-credentials
> >> or client-credentials requests? But seems we have time for optimizations
> >> and polishing later though...
> > Oops ! Will check that right away !
> >
> >> Marek
> >>
> >> On 16/06/16 19:12, Pedro Igor Silva wrote:
> >>> Hi All,
> >>>
> >>>      After reviewing somethings based on the feedback from Bill and
> >>>      Stian,
> >>>      I've updated both code and docs [1] to reflect what we have
> >>>      discussed.
> >>>
> >>>      In a nutshell, I think UX is much better now. With less steps to get
> >>>      things done and in some cases with a default configuration to
> >>>      quickly
> >>>      get started with authorization services.
> >>>
> >>>      Special attention to the "Managing Resource Server" [2] section.
> >>>      There
> >>>      you'll understand the main changes that made things more simple.
> >>>
> >>>      I'll be working with some getting started tutorials, I think they
> >>>      will
> >>>      be very simple and easy to follow now.
> >>>
> >>>      Please, let me know your thoughts.
> >>>
> >>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
> >>> [2]
> >>> https://keycloak.gitbooks.io/authorization-services-guide/content/topics/resource-server/overview.html
> >>>      
> >>>
> >>> ----- Original Message -----
> >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>> To: "Bill Burke" <bburke at redhat.com>
> >>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >>> Sent: Friday, June 10, 2016 12:55:39 PM
> >>> Subject: Re: [keycloak-dev] Feedback
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Friday, June 10, 2016 12:43:51 PM
> >>>> Subject: Re: Feedback
> >>>>
> >>>>
> >>>>
> >>>> On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >>>>>> Sent: Friday, June 10, 2016 12:11:37 PM
> >>>>>> Subject: Re: Feedback
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >>>>>>>> Sent: Friday, June 10, 2016 10:39:07 AM
> >>>>>>>> Subject: Re: Feedback
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
> >>>>>>>>> Bill,
> >>>>>>>>>
> >>>>>>>>> Got the authz stuff working with the adapters. It was a puzzle but
> >>>>>>>>> I
> >>>>>>>>> think
> >>>>>>>>> I have something.
> >>>>>>>> Yeah, its nasty.  Every servlet container handlers security just a
> >>>>>>>> bit
> >>>>>>>> differently than others so, its ugly.
> >>>>>>>>
> >>>>>>>>> * I've discarded my own sub-types of AccessToken, they were
> >>>>>>>>> redundant.
> >>>>>>>>> The
> >>>>>>>>> only difference between authz tokens and access tokens was a list
> >>>>>>>>> of
> >>>>>>>>> permissions. And the concept behind them is the same. I've added a
> >>>>>>>>> "authorization" claim to AccessToken (null by default) from where
> >>>>>>>>> permissions granted by the server can be obtained.
> >>>>>>>> Is a claim better?
> >>>>>>> To represent a RPT, I believe it is.
> >>>>>>>
> >>>>>>>> Or should AccessTokenResponse optionally contain the RPT?
> >>>>>>> IMO, that would make things harder from a client perspective. See my
> >>>>>>> next
> >>>>>>> comments.
> >>>>>>>
> >>>>>>>> Or optionally a query param for Implicit Flow?  Or have both?  I
> >>>>>>>> don't know.
> >>>>>>> I think we have two different things here:
> >>>>>>>
> >>>>>>> * How a RPT looks like
> >>>>>>> * How a RPT is obtained (the protocol in use)
> >>>>>>>
> >>>>>>> In the first case, a RPT is just a special type of access token with
> >>>>>>> authorization data on it. Where this data is a result of the
> >>>>>>> evaluation
> >>>>>>> of
> >>>>>>> permissions and authorization policies associated with the resources
> >>>>>>> being
> >>>>>>> requested. Here, that claim represents this data. This is protocol
> >>>>>>> agnostic.
> >>>>>>>
> >>>>>>> The latter case is how you obtain that data, which is strongly
> >>>>>>> associated
> >>>>>>> with the protocol in use. What you said makes a lot of sense, we can
> >>>>>>> issue
> >>>>>>> this authorization data when doing any of the OAuth2 grant types.
> >>>>>>> That
> >>>>>>> can
> >>>>>>> be specially useful when you want to obtain all permissions for an
> >>>>>>> user
> >>>>>>> at
> >>>>>>> once when authenticating in KC, avoiding an additional call to the
> >>>>>>> server
> >>>>>>> in order to obtain authorization specific data. One way to achieve
> >>>>>>> that
> >>>>>>> would be a
> >>>>>>> "Entitlement Protocol Mapper" that is capable of decorating an access
> >>>>>>> token
> >>>>>>> with the authorization data. Thus, transforming the access token into
> >>>>>>> a
> >>>>>>> RPT. See, the client just use the final access token without any
> >>>>>>> additional treatment.
> >>>>>>>
> >>>>>>> There are a lot of other features to implement around both UMA and
> >>>>>>> Entitlement protocols. For instance, claims gathering or obligations.
> >>>>>>> So
> >>>>>>> the server can ask the client for additional information. Eg.:
> >>>>>>> require
> >>>>>>> a
> >>>>>>> higher security level, etc. And for that, we must be able to obtain
> >>>>>>> authz
> >>>>>>> data separately.
> >>>>>> IIRC, there's a REST API right that allows a client to turn an access
> >>>>>> token into an RPT?
> >>>>> Yes, that is what both Authorization and Entitlement API are meant for.
> >>>>>
> >>>>>> So, if Client A gets an access token, it can invoke
> >>>>>> on Service B.  Service B can pass the access token to Keycloak to
> >>>>>> obtain
> >>>>>> an RPT?
> >>>>> Yes you can. The built-in policy enforcers (related with the changes I
> >>>>> did
> >>>>> to adapters) can operation in two modes:
> >>>>>
> >>>>> * Bearer Token
> >>>>> * "Stateful" scenario (eg.: monolithic JEE apps)
> >>>>>
> >>>>> In the first case, is up to the client to obtain and send the RPT with
> >>>>> the
> >>>>> necessary permissions to access protected resources on the resource
> >>>>> server(Service B). Here you can use two protocols: UMA and Entitlement.
> >>>>> You know UMA. Entitlement is just a more lightweight and 1-legged
> >>>>> protocol
> >>>>> based on some UMA concepts. It doesn't require permission tickets and
> >>>>> stuff.
> >>>>>
> >>>>> In the latter case, there is a specific policy enforcer that does
> >>>>> exactly
> >>>>> what you described. Obtaining a RPT transparently from a Keycloak
> >>>>> server
> >>>>> using the *Entitlement* API.
> >>>>>
> >>>> My only reasoning for wanting the option to include the RPT in the
> >>>> AccessTokenResponse was for performance reasons.  Obtaining an RPT could
> >>>> be obtained for free for a specific client by piggybacking on the OAuth
> >>>> protocol, but the access token could remain small/lightweight and not
> >>>> contain the RPT.  You'd still want to be able to include the RPT within
> >>>> the AT if so desired, but there might come a point when the AT becomes
> >>>> too fat.
> >>>>
> >>>> All this isn't really important at this time though.  What's more
> >>>> important is releasing Authz soon.  I just foresese us wanting to
> >>>> provide different optimizations for different environments.
> >>>>
> >>>> Bill
> >>> +1. And that is the reason why I'm following this path now. So far, I was
> >>> using a very specific token to hold authz data. But as you said, let's
> >>> discuss about performance and optimizations at the appropriate time and
> >>> release this stuff first. We can do a lot of things at this regard.
> >>>
> >>> Regarding token size, during this work I did a research about this topic
> >>> and there are interesting discussions on OAuth2-WG.
> >>>
> >>> Thanks for all feedback, it was really important to improve things.
> >>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> 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 jdennis at redhat.com  Mon Jun 20 20:07:56 2016
From: jdennis at redhat.com (John Dennis)
Date: Mon, 20 Jun 2016 20:07:56 -0400
Subject: [keycloak-dev] server start up errors
In-Reply-To: <CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
Message-ID: <2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>

On 06/20/2016 06:13 AM, Marko Strukelj wrote:
> The first error means that there are existing tables in the local H2
> database (under standalone/data there are keycloak.* files).
>
> It looks like the logic determined that they are of some previous db
> schema version, and tried to upgrade the schema to latest version, but
> unexpectedly the schema in place already seems to contain the tables it
> wasn't supposed to contain.
>
> I suppose that could happen if upgrade process is interrupted by
> restarting the server?
>
> Since you are using the default H2 database I assume you don't care
> about any existing data. The solution for you then is to stop the
> server, delete the database (rm standalone/data/keycloak.*), and start
> the server again.

Thank you Marko, I've got a few more questions for you.

These errors occur during automated installation and configuration via 
ansible.

One of the operations performed is invoking bin/add-user-keycloak to add 
the admin user. I seem to recall add-user-keycloak operates on static 
files which are read during start up. Could the use of add-user-keycloak 
trigger the schema errors seen in the log?

This is a brand new install so why would there be an upgrade process 
running?

The ansible scripts do restart the server. Starting the server is done 
via bin/standalone.sh but stopping the server is performed by systemd 
sending a SIGTERM, waiting and then sending a SIGKILL (or so I believe). 
Does the upgrade process gracefully handle SIGTERM such that it 
continues to run until complete and then exit?


-- 
John

From mposolda at redhat.com  Tue Jun 21 04:01:07 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 21 Jun 2016 10:01:07 +0200
Subject: [keycloak-dev] Reloading KeyCloak on the fly
In-Reply-To: <1466174517.10212.10.camel@cargosoft.ru>
References: <1466174517.10212.10.camel@cargosoft.ru>
Message-ID: <5768F443.2060605@redhat.com>

Using KeycloakServer for development. It's using embedded undertow under 
the hood. Server restarted usually in few seconds and it sees the latest 
changes in your IDE if you run it directly from the IDE. See 
https://github.com/keycloak/keycloak/blob/master/misc/Testsuite.md#keycloak-server

Marek

On 17/06/16 16:41, Mitya wrote:
> Hi,
>
> I'm developing a KeyCloak extension which is packaged as two JBoss 
> modules:
> - the extension proper (custom authenticator + custom realm resource + 
> custom admin theme);
> - modified org.keycloak.keycloak-model-jpa (since Entity SPI is not 
> yet available).
>
> Each time I make changes, I have to go through a roundabout of 
> stopping KeyCloak, deploying modules and starting KeyCloak again. This 
> can happen as many as several dozen times a day; as soon as I roll a 
> CI infrastructure, the build server will have to do the same. Needless 
> to say, the process is pretty time-consuming; additionally, I'll have 
> to grant permissions to the build server to restart a system service 
> (KeyCloak is deployed as systemd unit). I've tried the following in 
> jboss-cli:
>
> [disconnected /] connect
> [standalone at localhost <mailto:standalone at localhost>:9990 /] module 
> remove --name=foo.bar.main
> [standalone at localhost <mailto:standalone at localhost>:9990 /] module add 
> --name=foo.bar.main --resources=... --dependencies=...
> [standalone at localhost <mailto:standalone at localhost>:9990 /] reload
>
> This doesn't help, despite WildFly reports to have redeployed and 
> restarted KeyCloak. The updated modules are simply not picked up.
>
> Am I missing something? KeyCloak developers, what would you recommend 
> to speed-up the workflow?
>
> Cheers,
> Mitya
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From thomas.darimont at googlemail.com  Tue Jun 21 05:04:04 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 21 Jun 2016 11:04:04 +0200
Subject: [keycloak-dev] FYI OAuth Security Workshop 2016 July 14th and 15th
	2016 in Trier / Germany
Message-ID: <CAK-7U1h5GEbONxCCYed95HgZv6QqSK9x3P=05dfe-jQy6vjQSQ@mail.gmail.com>

Hello group,

just wanted to let you know that there will be an OAuth Security Workshop
at the
University of Trier (Germany) in July see:
https://infsec.uni-trier.de/events/osw2016

I learned from one of the organizers that they will also discuss Keycloak as
an OpenID Connect Provider - just wanted to let you guys know.

I'm going to attend this workshop as well.

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160621/eca492a1/attachment.html 

From mstrukel at redhat.com  Tue Jun 21 05:27:11 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 21 Jun 2016 11:27:11 +0200
Subject: [keycloak-dev] server start up errors
In-Reply-To: <2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
Message-ID: <CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>

On Tue, Jun 21, 2016 at 2:07 AM, John Dennis <jdennis at redhat.com> wrote:

> On 06/20/2016 06:13 AM, Marko Strukelj wrote:
>
>> The first error means that there are existing tables in the local H2
>> database (under standalone/data there are keycloak.* files).
>>
>> It looks like the logic determined that they are of some previous db
>> schema version, and tried to upgrade the schema to latest version, but
>> unexpectedly the schema in place already seems to contain the tables it
>> wasn't supposed to contain.
>>
>> I suppose that could happen if upgrade process is interrupted by
>> restarting the server?
>>
>> Since you are using the default H2 database I assume you don't care
>> about any existing data. The solution for you then is to stop the
>> server, delete the database (rm standalone/data/keycloak.*), and start
>> the server again.
>>
>
> Thank you Marko, I've got a few more questions for you.
>
> These errors occur during automated installation and configuration via
> ansible.
>
> One of the operations performed is invoking bin/add-user-keycloak to add
> the admin user. I seem to recall add-user-keycloak operates on static files
> which are read during start up. Could the use of add-user-keycloak trigger
> the schema errors seen in the log?
>

No.


>
> This is a brand new install so why would there be an upgrade process
> running?
>

One possibility would be that the packaged installation already contains
standalone/data/keycloak.* files, which it shouldn't - maybe it's a custom
packaging you put together?
Another possibility is that the error does not happen on first start, but
on subsequent start, after server is forcefully restarted.


> The ansible scripts do restart the server. Starting the server is done via
> bin/standalone.sh but stopping the server is performed by systemd sending a
> SIGTERM, waiting and then sending a SIGKILL (or so I believe). Does the
> upgrade process gracefully handle SIGTERM such that it continues to run
> until complete and then exit?


This is the most likely culprit. I don't think upgrade procedure will
properly complete when java process is set to shutdown no matter what
signal is used.
The shutdown should only be performed after server has reached started
state.

That's when you see an entry in the log similar to:

11:26:41,410 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025:
Keycloak 1.9.7.Final (WildFly Core 2.0.10.Final) started in 10219ms -
Started 416 of 782 services (526 services are lazy, passive or on-demand)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160621/4904ddc9/attachment.html 

From jdennis at redhat.com  Tue Jun 21 08:21:47 2016
From: jdennis at redhat.com (John Dennis)
Date: Tue, 21 Jun 2016 08:21:47 -0400
Subject: [keycloak-dev] server start up errors
In-Reply-To: <CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
	<CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
Message-ID: <a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>

On 06/21/2016 05:27 AM, Marko Strukelj wrote:
>
>
> On Tue, Jun 21, 2016 at 2:07 AM, John Dennis <jdennis at redhat.com
> <mailto:jdennis at redhat.com>> wrote:
>
>     On 06/20/2016 06:13 AM, Marko Strukelj wrote:
>
>         The first error means that there are existing tables in the local H2
>         database (under standalone/data there are keycloak.* files).
>
>         It looks like the logic determined that they are of some previous db
>         schema version, and tried to upgrade the schema to latest
>         version, but
>         unexpectedly the schema in place already seems to contain the
>         tables it
>         wasn't supposed to contain.
>
>         I suppose that could happen if upgrade process is interrupted by
>         restarting the server?
>
>         Since you are using the default H2 database I assume you don't care
>         about any existing data. The solution for you then is to stop the
>         server, delete the database (rm standalone/data/keycloak.*), and
>         start
>         the server again.
>
>
>     Thank you Marko, I've got a few more questions for you.
>
>     These errors occur during automated installation and configuration
>     via ansible.
>
>     One of the operations performed is invoking bin/add-user-keycloak to
>     add the admin user. I seem to recall add-user-keycloak operates on
>     static files which are read during start up. Could the use of
>     add-user-keycloak trigger the schema errors seen in the log?
>
>
> No.
>
>
>
>     This is a brand new install so why would there be an upgrade process
>     running?
>
>
> One possibility would be that the packaged installation already contains
> standalone/data/keycloak.* files, which it shouldn't - maybe it's a
> custom packaging you put together?
> Another possibility is that the error does not happen on first start,
> but on subsequent start, after server is forcefully restarted.
>
>
>     The ansible scripts do restart the server. Starting the server is
>     done via bin/standalone.sh but stopping the server is performed by
>     systemd sending a SIGTERM, waiting and then sending a SIGKILL (or so
>     I believe). Does the upgrade process gracefully handle SIGTERM such
>     that it continues to run until complete and then exit?
>
>
> This is the most likely culprit. I don't think upgrade procedure will
> properly complete when java process is set to shutdown no matter what
> signal is used.
> The shutdown should only be performed after server has reached started
> state.
>
> That's when you see an entry in the log similar to:
>
> 11:26:41,410 INFO  [org.jboss.as <http://org.jboss.as>] (Controller Boot
> Thread) WFLYSRV0025: Keycloak 1.9.7.Final (WildFly Core 2.0.10.Final)
> started in 10219ms - Started 416 of 782 services (526 services are lazy,
> passive or on-demand)

 From reading the log (I've attached a copy from another run) I think 
the server is stopping before it properly initialized. I'm not familiar 
with all your log messages but I base this conclusion on the fact 
"stopping" messages appear in the log just after the database errors, 
followed by this "stop" message:

[org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: rh-sso 7.0.0.GA 
(WildFly Core 2.1.2.Final-redhat-1) stopped in 2100ms

The "start" message

[org.jboss.modules] (main) JBoss Modules version 1.5.1.Final-redhat-1

occurs next followed by more database error messages and then finally 
the "ready to run" message you cite:

[org.jboss.as] (Controller Boot Thread) WFLYSRV0026: rh-sso 7.0.0.GA 
(WildFly Core 2.1.2.Final-redhat-1) started (with errors) in 12451ms - 
Started 473 of 839 services (2 services failed or missing dependencies, 
583 services are lazy, passive or on-demand)

Question:

Does the Keycloak team have a working script to start and stop the 
service in RHEL? When we first started working with Keycloak we were 
told no and we would need to cobble together something by calling the 
bin/standalone.sh script.

The "wait for full initialization" problem is not new to us with 
daemons. It's come up a number of times with IPA and other daemons we 
work with. The way we've dealt with it is to have our service scripts 
that start and stop services write to one of the primary sockets and 
only when it gets a valid response back conclude the service is in fact 
up (handling timeouts of course). Systemd came along later and might 
have some support for socket detection, I'll investigate that option.

We really need a script that can start and stop the service reliably 
without errors.


-- 
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.log
Type: text/x-log
Size: 215455 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160621/6b6626a8/attachment-0001.bin 

From mstrukel at redhat.com  Tue Jun 21 09:18:56 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 21 Jun 2016 15:18:56 +0200
Subject: [keycloak-dev] server start up errors
In-Reply-To: <a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
	<CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
	<a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
Message-ID: <CA+1OW+hmRAWabhOun3wPtgFRw3aL6Q3jDG9ykkdXz3kaTtdA+Q@mail.gmail.com>

I don't know about availability of RHEL service script. But the log is very
clear about what happens:

2016-06-20 18:30:13,282 INFO
 [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider]
(ServerService Thread Pool -- 54) Initializing database schema
2016-06-20 18:30:13,351 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220:
Server shutdown has been requested.

Server shutdown is initiated while server is still in the process of
booting up.


On Tue, Jun 21, 2016 at 2:21 PM, John Dennis <jdennis at redhat.com> wrote:

> On 06/21/2016 05:27 AM, Marko Strukelj wrote:
>
>>
>>
>> On Tue, Jun 21, 2016 at 2:07 AM, John Dennis <jdennis at redhat.com
>> <mailto:jdennis at redhat.com>> wrote:
>>
>>     On 06/20/2016 06:13 AM, Marko Strukelj wrote:
>>
>>         The first error means that there are existing tables in the local
>> H2
>>         database (under standalone/data there are keycloak.* files).
>>
>>         It looks like the logic determined that they are of some previous
>> db
>>         schema version, and tried to upgrade the schema to latest
>>         version, but
>>         unexpectedly the schema in place already seems to contain the
>>         tables it
>>         wasn't supposed to contain.
>>
>>         I suppose that could happen if upgrade process is interrupted by
>>         restarting the server?
>>
>>         Since you are using the default H2 database I assume you don't
>> care
>>         about any existing data. The solution for you then is to stop the
>>         server, delete the database (rm standalone/data/keycloak.*), and
>>         start
>>         the server again.
>>
>>
>>     Thank you Marko, I've got a few more questions for you.
>>
>>     These errors occur during automated installation and configuration
>>     via ansible.
>>
>>     One of the operations performed is invoking bin/add-user-keycloak to
>>     add the admin user. I seem to recall add-user-keycloak operates on
>>     static files which are read during start up. Could the use of
>>     add-user-keycloak trigger the schema errors seen in the log?
>>
>>
>> No.
>>
>>
>>
>>     This is a brand new install so why would there be an upgrade process
>>     running?
>>
>>
>> One possibility would be that the packaged installation already contains
>> standalone/data/keycloak.* files, which it shouldn't - maybe it's a
>> custom packaging you put together?
>> Another possibility is that the error does not happen on first start,
>> but on subsequent start, after server is forcefully restarted.
>>
>>
>>     The ansible scripts do restart the server. Starting the server is
>>     done via bin/standalone.sh but stopping the server is performed by
>>     systemd sending a SIGTERM, waiting and then sending a SIGKILL (or so
>>     I believe). Does the upgrade process gracefully handle SIGTERM such
>>     that it continues to run until complete and then exit?
>>
>>
>> This is the most likely culprit. I don't think upgrade procedure will
>> properly complete when java process is set to shutdown no matter what
>> signal is used.
>> The shutdown should only be performed after server has reached started
>> state.
>>
>> That's when you see an entry in the log similar to:
>>
>> 11:26:41,410 INFO  [org.jboss.as <http://org.jboss.as>] (Controller Boot
>> Thread) WFLYSRV0025: Keycloak 1.9.7.Final (WildFly Core 2.0.10.Final)
>> started in 10219ms - Started 416 of 782 services (526 services are lazy,
>> passive or on-demand)
>>
>
> From reading the log (I've attached a copy from another run) I think the
> server is stopping before it properly initialized. I'm not familiar with
> all your log messages but I base this conclusion on the fact "stopping"
> messages appear in the log just after the database errors, followed by this
> "stop" message:
>
> [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: rh-sso 7.0.0.GA
> (WildFly Core 2.1.2.Final-redhat-1) stopped in 2100ms
>
> The "start" message
>
> [org.jboss.modules] (main) JBoss Modules version 1.5.1.Final-redhat-1
>
> occurs next followed by more database error messages and then finally the
> "ready to run" message you cite:
>
> [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: rh-sso 7.0.0.GA
> (WildFly Core 2.1.2.Final-redhat-1) started (with errors) in 12451ms -
> Started 473 of 839 services (2 services failed or missing dependencies, 583
> services are lazy, passive or on-demand)
>
> Question:
>
> Does the Keycloak team have a working script to start and stop the service
> in RHEL? When we first started working with Keycloak we were told no and we
> would need to cobble together something by calling the bin/standalone.sh
> script.
>
> The "wait for full initialization" problem is not new to us with daemons.
> It's come up a number of times with IPA and other daemons we work with. The
> way we've dealt with it is to have our service scripts that start and stop
> services write to one of the primary sockets and only when it gets a valid
> response back conclude the service is in fact up (handling timeouts of
> course). Systemd came along later and might have some support for socket
> detection, I'll investigate that option.
>
> We really need a script that can start and stop the service reliably
> without errors.
>
>
> --
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160621/786ce971/attachment.html 

From bburke at redhat.com  Tue Jun 21 09:34:41 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Jun 2016 09:34:41 -0400
Subject: [keycloak-dev] server start up errors
In-Reply-To: <a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
	<CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
	<a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
Message-ID: <94c534f7-662d-31ff-99f6-74b5f73b1fb7@redhat.com>



On 6/21/16 8:21 AM, John Dennis wrote:
>
> The "wait for full initialization" problem is not new to us with
> daemons. It's come up a number of times with IPA and other daemons we
> work with. The way we've dealt with it is to have our service scripts
> that start and stop services write to one of the primary sockets and
> only when it gets a valid response back conclude the service is in fact
> up (handling timeouts of course). Systemd came along later and might
> have some support for socket detection, I'll investigate that option.
>

This is good feedback.  I'm not sure what you mean by writing to a 
primary socket.  You mean HTTP(S) 80/443?  I'm pretty sure HTTP(S) 
sockets are set up before Keycloak is even deployed.  This is because 
internally Keycloak has a dependency on HTTP subsystem and won't be 
initialized until that subsystem is started.

Can you parse System output for a specific string?  Is that viable? 
I'll ping Wildfly team to see how they've handled stuff like this.

Bill

From jdennis at redhat.com  Tue Jun 21 10:02:48 2016
From: jdennis at redhat.com (John Dennis)
Date: Tue, 21 Jun 2016 10:02:48 -0400
Subject: [keycloak-dev] server start up errors
In-Reply-To: <94c534f7-662d-31ff-99f6-74b5f73b1fb7@redhat.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
	<CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
	<a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
	<94c534f7-662d-31ff-99f6-74b5f73b1fb7@redhat.com>
Message-ID: <89e07830-bff5-1f3c-dc48-5a7dc3730d25@redhat.com>

On 06/21/2016 09:34 AM, Bill Burke wrote:
>
>
> On 6/21/16 8:21 AM, John Dennis wrote:
>>
>> The "wait for full initialization" problem is not new to us with
>> daemons. It's come up a number of times with IPA and other daemons we
>> work with. The way we've dealt with it is to have our service scripts
>> that start and stop services write to one of the primary sockets and
>> only when it gets a valid response back conclude the service is in fact
>> up (handling timeouts of course). Systemd came along later and might
>> have some support for socket detection, I'll investigate that option.
>>
>
> This is good feedback.  I'm not sure what you mean by writing to a
> primary socket.  You mean HTTP(S) 80/443?  I'm pretty sure HTTP(S)
> sockets are set up before Keycloak is even deployed.  This is because
> internally Keycloak has a dependency on HTTP subsystem and won't be
> initialized until that subsystem is started.

Sorry, I guess I wasn't clear. What I meant was to send a request and 
wait for a valid response. It makes sense the servlet container would 
have it's listening sockets set up much earlier but Keycloak won't 
respond to a request on a valid endpoint until it's fully initialized.

What I was trying to describe was something like this, a loop iterates 
trying to send a request, it ignores common socket errors, if a valid 
response is received it terminates the loop with a success status. If 
after a specified time interval or iteration count a valid response has 
not been received it terminates the loop with a failure status.

Of course this means there is some endpoint which does not require 
authentication nor has any side-effect. I'm guessing the REST API 
exposes something which could be used for this purpose but I haven't 
looked into it.

> Can you parse System output for a specific string?  Is that viable?
> I'll ping Wildfly team to see how they've handled stuff like this.

Trying to parse the log is problematic. Normally the log is appended to 
(until log rotation occurs). It could be tricky to identify the matching 
log message associated with the server lifetime. Also in some scenarios 
log messages may not be flushed immediately, especially if logging is 
configured to go to a network location. It also would make the service 
script dependent on knowing the logging configuration and exact messages 
to look for which may change between versions, a maintenance issue.


-- 
John

From mstrukel at redhat.com  Tue Jun 21 10:46:26 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 21 Jun 2016 16:46:26 +0200
Subject: [keycloak-dev] server start up errors
In-Reply-To: <89e07830-bff5-1f3c-dc48-5a7dc3730d25@redhat.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
	<CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
	<a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
	<94c534f7-662d-31ff-99f6-74b5f73b1fb7@redhat.com>
	<89e07830-bff5-1f3c-dc48-5a7dc3730d25@redhat.com>
Message-ID: <CA+1OW+iTnGDvYqz9ra2LHhx4tusrh6+hwMikPGVCFDyAYFZhnA@mail.gmail.com>

I think you can ping http://localhost:8080/auth/ - until you get 200 OK.

Don't forget the final / in the url, otherwise you'll get 303 See Other
rather than 200 OK.



On Tue, Jun 21, 2016 at 4:02 PM, John Dennis <jdennis at redhat.com> wrote:

> On 06/21/2016 09:34 AM, Bill Burke wrote:
> >
> >
> > On 6/21/16 8:21 AM, John Dennis wrote:
> >>
> >> The "wait for full initialization" problem is not new to us with
> >> daemons. It's come up a number of times with IPA and other daemons we
> >> work with. The way we've dealt with it is to have our service scripts
> >> that start and stop services write to one of the primary sockets and
> >> only when it gets a valid response back conclude the service is in fact
> >> up (handling timeouts of course). Systemd came along later and might
> >> have some support for socket detection, I'll investigate that option.
> >>
> >
> > This is good feedback.  I'm not sure what you mean by writing to a
> > primary socket.  You mean HTTP(S) 80/443?  I'm pretty sure HTTP(S)
> > sockets are set up before Keycloak is even deployed.  This is because
> > internally Keycloak has a dependency on HTTP subsystem and won't be
> > initialized until that subsystem is started.
>
> Sorry, I guess I wasn't clear. What I meant was to send a request and
> wait for a valid response. It makes sense the servlet container would
> have it's listening sockets set up much earlier but Keycloak won't
> respond to a request on a valid endpoint until it's fully initialized.
>
> What I was trying to describe was something like this, a loop iterates
> trying to send a request, it ignores common socket errors, if a valid
> response is received it terminates the loop with a success status. If
> after a specified time interval or iteration count a valid response has
> not been received it terminates the loop with a failure status.
>
> Of course this means there is some endpoint which does not require
> authentication nor has any side-effect. I'm guessing the REST API
> exposes something which could be used for this purpose but I haven't
> looked into it.
>
> > Can you parse System output for a specific string?  Is that viable?
> > I'll ping Wildfly team to see how they've handled stuff like this.
>
> Trying to parse the log is problematic. Normally the log is appended to
> (until log rotation occurs). It could be tricky to identify the matching
> log message associated with the server lifetime. Also in some scenarios
> log messages may not be flushed immediately, especially if logging is
> configured to go to a network location. It also would make the service
> script dependent on knowing the logging configuration and exact messages
> to look for which may change between versions, a maintenance issue.
>
>
> --
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160621/4ae3bca5/attachment-0001.html 

From mitya at cargosoft.ru  Tue Jun 21 14:52:48 2016
From: mitya at cargosoft.ru (Mitya)
Date: Tue, 21 Jun 2016 21:52:48 +0300
Subject: [keycloak-dev] Reloading KeyCloak on the fly
In-Reply-To: <5768F443.2060605@redhat.com>
References: <1466174517.10212.10.camel@cargosoft.ru>
	<5768F443.2060605@redhat.com>
Message-ID: <1466535168.7815.5.camel@cargosoft.ru>

Hi Marek,
What I'm looking for is the way to reload KeyCloak modules (providers)
on the fly, hopefully without killing admin session (since not only I
have to restart KeyCloak, but also to relogin each time). I'm afraid
KeycloakServer only sees changes to custom themes, not modules. Or am I
missing something?
Mitya
> Using KeycloakServer for development. It's using embedded undertow
> under the hood. Server restarted usually in few seconds and it sees
> the latest changes in your IDE if you run it directly from the IDE.
> See https://github.com/keycloak/keycloak/blob/master/misc/Testsuite.m
> d#keycloak-server
> 
> Marek
> 
> On 17/06/16 16:41, Mitya wrote:
> 
> > Hi,
> > 
> > 
> > I'm developing a KeyCloak extension which is packaged as two JBoss
> > modules:
> > - the extension proper (custom authenticator + custom realm
> > resource + custom admin theme);
> > - modified org.keycloak.keycloak-model-jpa (since Entity SPI is not
> > yet available).
> > 
> > 
> > Each time I make changes, I have to go through a roundabout of
> > stopping KeyCloak, deploying modules and starting KeyCloak again.
> > This can happen as many as several dozen times a day; as soon as I
> > roll a CI infrastructure, the build server will have to do the
> > same. Needless to say, the process is pretty time-consuming;
> > additionally, I'll have to grant permissions to the build server to
> > restart a system service (KeyCloak is deployed as systemd unit).
> > I've tried the following in jboss-cli:
> > 
> > 
> > [disconnected /] connect
> > [standalone at localhost:9990 /] module remove --name=foo.bar.main
> > [standalone at localhost:9990 /] module add --name=foo.bar.main --
> > resources=...?--dependencies=...
> > [standalone at localhost:9990 /] reload
> > 
> > 
> > This doesn't help, despite WildFly reports to have redeployed and
> > restarted KeyCloak. The updated modules are simply not picked up.
> > 
> > 
> > Am I missing something? KeyCloak developers, what would you
> > recommend to speed-up the workflow?
> > 
> > 
> > Cheers,
> > Mitya
> > 
> > 
> > 
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160621/563cf0cc/attachment.html 

From psilva at redhat.com  Tue Jun 21 15:59:08 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 21 Jun 2016 15:59:08 -0400 (EDT)
Subject: [keycloak-dev] Authorization JS adapter, where should I put it ?
In-Reply-To: <18463826.968343.1466538121086.JavaMail.zimbra@redhat.com>
Message-ID: <203603418.1014823.1466539148586.JavaMail.zimbra@redhat.com>

Would like to make available a JS adapter for authorization. It's purpose is to make life easier for those using JS when interacting with an resource server which resources are being protected by a policy enforcer.

The idea is that you can use the adapter for some very common scenarios. For instance, suppose you are using AngularJS and you want to handle 403 from the resource server so you can obtain a RPT with the necessary permissions to retry the
request:

    var Authorization = new KeycloakAuthorization();

    // our adapters return a WWW-Authenticate header with the necessary information to build an authorization request to a Keycloak Server
    Authorization.authorize(response.headers('WWW-Authenticate')).then(function (rpt) {
        // onGrant callback function. If granted you'll get a RPT which you can use as bearer token to get access to protected resources
    }, function () {
        // onDeny callback function
    }, function () {
        // onError callback function
    });

The above code is particular useful because the JS adapter will automatically identify how the resource server is being protected (if using UMA or our entitlements protocol) and act accordingly.

Or you can just obtain the entitlements using our Entitlements API:

    authorization.entitlement('my-resource-server-id').then(function (rpt) {
        // onGrant callback function. If granted you'll get a RPT which you can use as bearer token to get access to protected resources        
    })

In the future, I would like to introduce more methods such as:

    if (authorization.hasPermission('Main Page', 'Action 1')) {
        // do something if current user has permissions to click a button on a page
    }

Should I put that stuff into keycloak.js or provide it separately ?

Regards.
Pedro Igor

From jdennis at redhat.com  Tue Jun 21 18:46:23 2016
From: jdennis at redhat.com (John Dennis)
Date: Tue, 21 Jun 2016 18:46:23 -0400
Subject: [keycloak-dev] server start up errors
In-Reply-To: <CA+1OW+iTnGDvYqz9ra2LHhx4tusrh6+hwMikPGVCFDyAYFZhnA@mail.gmail.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
	<CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
	<a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
	<94c534f7-662d-31ff-99f6-74b5f73b1fb7@redhat.com>
	<89e07830-bff5-1f3c-dc48-5a7dc3730d25@redhat.com>
	<CA+1OW+iTnGDvYqz9ra2LHhx4tusrh6+hwMikPGVCFDyAYFZhnA@mail.gmail.com>
Message-ID: <edc53ae7-0f73-caa2-1288-d2d72c75029b@redhat.com>

FYI, the following Jira issue was opened for this.

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

-- 
John

From a.nekrasov at ftc.ru  Wed Jun 22 00:10:28 2016
From: a.nekrasov at ftc.ru (Nekrasov Aleksandr)
Date: Wed, 22 Jun 2016 04:10:28 +0000
Subject: [keycloak-dev] Reloading KeyCloak on the fly
In-Reply-To: <1466535168.7815.5.camel@cargosoft.ru>
References: <1466174517.10212.10.camel@cargosoft.ru>
	<5768F443.2060605@redhat.com> <1466535168.7815.5.camel@cargosoft.ru>
Message-ID: <2977e29a2fff40a0b1204e8fe7711132@nut-mbx-1.win.ftc.ru>

Hi,

We have the same problem. We need to deploy the artifacts to remote servers to check regression. Such features of our development process. And it requires a full server restart. Will be good doing it on the fly like Wildfly redeploy wars/ears on the fly without stopping.

From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Mitya
Sent: Wednesday, June 22, 2016 12:53 AM
To: Marek Posolda; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Reloading KeyCloak on the fly

Hi Marek,

What I'm looking for is the way to reload KeyCloak modules (providers) on the fly, hopefully without killing admin session (since not only I have to restart KeyCloak, but also to relogin each time). I'm afraid KeycloakServer only sees changes to custom themes, not modules. Or am I missing something?

Mitya


Using KeycloakServer for development. It's using embedded undertow under the hood. Server restarted usually in few seconds and it sees the latest changes in your IDE if you run it directly from the IDE. See https://github.com/keycloak/keycloak/blob/master/misc/Testsuite.md#keycloak-server

Marek

On 17/06/16 16:41, Mitya wrote:
Hi,

I'm developing a KeyCloak extension which is packaged as two JBoss modules:
- the extension proper (custom authenticator + custom realm resource + custom admin theme);
- modified org.keycloak.keycloak-model-jpa (since Entity SPI is not yet available).

Each time I make changes, I have to go through a roundabout of stopping KeyCloak, deploying modules and starting KeyCloak again. This can happen as many as several dozen times a day; as soon as I roll a CI infrastructure, the build server will have to do the same. Needless to say, the process is pretty time-consuming; additionally, I'll have to grant permissions to the build server to restart a system service (KeyCloak is deployed as systemd unit). I've tried the following in jboss-cli:

[disconnected /] connect
[standalone at localhost<mailto:standalone at localhost>:9990 /] module remove --name=foo.bar.main
[standalone at localhost<mailto:standalone at localhost>:9990 /] module add --name=foo.bar.main --resources=... --dependencies=...
[standalone at localhost<mailto:standalone at localhost>:9990 /] reload

This doesn't help, despite WildFly reports to have redeployed and restarted KeyCloak. The updated modules are simply not picked up.

Am I missing something? KeyCloak developers, what would you recommend to speed-up the workflow?

Cheers,
Mitya





_______________________________________________

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

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

From sthorger at redhat.com  Wed Jun 22 01:50:13 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 22 Jun 2016 07:50:13 +0200
Subject: [keycloak-dev] AJP port and port-offset
In-Reply-To: <25a86135-fab1-11ee-1919-90741ad5bc8b@redhat.com>
References: <25a86135-fab1-11ee-1919-90741ad5bc8b@redhat.com>
Message-ID: <CAJgngAd0q+L3QhtKDjynDNdsd-n=4_YYecFf+iXqi4FAjanQ3w@mail.gmail.com>

jboss.socket.binding.port-offset should affect the AJP port. Just tried
"jboss.socket.binding.port-offset=100" here and AJP is indeed now on port
8109 instead of default 8009.

On 19 June 2016 at 14:39, John Dennis <jdennis at redhat.com> wrote:

> In the past we had been using HTTP and utilizing
> jboss.socket.binding.port-offset to move the port to a higher number.
> But now we're using AJP and the port-offset does not seem to apply to
> the ajp port. Is this expected?
>
>
> --
> John
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160622/9b9ef0b4/attachment.html 

From sthorger at redhat.com  Wed Jun 22 01:52:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 22 Jun 2016 07:52:24 +0200
Subject: [keycloak-dev] Keycloak commit message format
In-Reply-To: <CAK-7U1i4ny7HPn7r+posMmX2sQN5dAR1e1M9C2pwCyp+DkeP3w@mail.gmail.com>
References: <CAK-7U1i4ny7HPn7r+posMmX2sQN5dAR1e1M9C2pwCyp+DkeP3w@mail.gmail.com>
Message-ID: <CAJgngAf8nxhRiNMbNeRxYP0jpbt20zJVP4utUXYcA7tHU0cscA@mail.gmail.com>

Style is supposed to be:

KEYCLOAK-XXX 1st line of commit message

However, I don't feel the need to be too strict. I'm happy as long as
"KEYCLOAK-XXX" is included.

On 20 June 2016 at 09:37, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello group,
>
> it's just a minor thing and sorry to ask that as an outsider
> but I was wondering whether you could agree on a standard for commit
> messages that reference JIRA issues.
>
> In the git log one sees variants like:
> KEYCLOAK-XXX 1st line of commit message
> KEYCLOAK-XXX: 1st line of commit message
> KEYCLOAK-XXX - 1st line of commit message
> [KEYCLOAK-XXX] - 1st line of commit message
>
> Would be great if you guys could agree on a style != freestyle :)
>
> Cheers,
> Thomas
>
> PS:
> I use the git alias lg to glance over the keycloak log
>
> alias.lg=log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset
> %s %Cgreen(%cr) %C(yellow)<%an - %ae>%Creset' --abbrev-commit
> --date=relative
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160622/af2fbb12/attachment.html 

From sthorger at redhat.com  Wed Jun 22 01:56:02 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 22 Jun 2016 07:56:02 +0200
Subject: [keycloak-dev] FYI OAuth Security Workshop 2016 July 14th and
 15th 2016 in Trier / Germany
In-Reply-To: <CAK-7U1h5GEbONxCCYed95HgZv6QqSK9x3P=05dfe-jQy6vjQSQ@mail.gmail.com>
References: <CAK-7U1h5GEbONxCCYed95HgZv6QqSK9x3P=05dfe-jQy6vjQSQ@mail.gmail.com>
Message-ID: <CAJgngAcj=3W+z7JzZjfuQha-3enDZgu31mafRN+4_MVhTLhZWw@mail.gmail.com>

Hi, thanks for letting us now. A summary to the list afterwards would be
appreciated, especially any advice on improving security.

On 21 June 2016 at 11:04, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello group,
>
> just wanted to let you know that there will be an OAuth Security Workshop
> at the
> University of Trier (Germany) in July see:
> https://infsec.uni-trier.de/events/osw2016
>
> I learned from one of the organizers that they will also discuss Keycloak
> as
> an OpenID Connect Provider - just wanted to let you guys know.
>
> I'm going to attend this workshop as well.
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160622/381b64f3/attachment.html 

From sthorger at redhat.com  Wed Jun 22 02:25:42 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 22 Jun 2016 08:25:42 +0200
Subject: [keycloak-dev] Reloading KeyCloak on the fly
In-Reply-To: <1466174517.10212.10.camel@cargosoft.ru>
References: <1466174517.10212.10.camel@cargosoft.ru>
Message-ID: <CAJgngAcnApXy-fz505+S1oU9rAkt=tqCaJQ+UEZaSWid18_1-w@mail.gmail.com>

We don't currently support live deploying of providers and the Keycloak
server has to be restarted for updates as well as new providers to be
picked up.

The 'reload' command only results in manual changes to standalone.xml to be
reloaded and doesn't have any affect on modules or Keycloak itself. You can
use 'shutdown(restart=true)' which will restart the server. I'm afraid you
will use active sessions unless you have multiple nodes and increase owners
for the userSession cache.

Feel free to create a JIRA to support deploying/repdeploying providers
live, but it would most likely be a while until we can get around to it.
Unless we get a community contribution around it that is.

On 17 June 2016 at 16:41, Mitya <mitya at cargosoft.ru> wrote:

> Hi,
>
> I'm developing a KeyCloak extension which is packaged as two JBoss modules:
> - the extension proper (custom authenticator + custom realm resource +
> custom admin theme);
> - modified org.keycloak.keycloak-model-jpa (since Entity SPI is not yet
> available).
>
> Each time I make changes, I have to go through a roundabout of stopping
> KeyCloak, deploying modules and starting KeyCloak again. This can happen as
> many as several dozen times a day; as soon as I roll a CI infrastructure,
> the build server will have to do the same. Needless to say, the process is
> pretty time-consuming; additionally, I'll have to grant permissions to the
> build server to restart a system service (KeyCloak is deployed as systemd
> unit). I've tried the following in jboss-cli:
>
> [disconnected /] connect
> [standalone at localhost:9990 /] module remove --name=foo.bar.main
> [standalone at localhost:9990 /] module add --name=foo.bar.main
> --resources=... --dependencies=...
> [standalone at localhost:9990 /] reload
>
> This doesn't help, despite WildFly reports to have redeployed and
> restarted KeyCloak. The updated modules are simply not picked up.
>
> Am I missing something? KeyCloak developers, what would you recommend to
> speed-up the workflow?
>
> Cheers,
> Mitya
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160622/f5f01ee7/attachment.html 

From sthorger at redhat.com  Wed Jun 22 02:26:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 22 Jun 2016 08:26:47 +0200
Subject: [keycloak-dev] Reloading KeyCloak on the fly
In-Reply-To: <1466535168.7815.5.camel@cargosoft.ru>
References: <1466174517.10212.10.camel@cargosoft.ru>
	<5768F443.2060605@redhat.com>
	<1466535168.7815.5.camel@cargosoft.ru>
Message-ID: <CAJgngAfZhnma42crgY5xY9KSc6NdvJSaEtkunHLEWYiRH=tk9Q@mail.gmail.com>

For the record themes should not be redeployed live for production either
as disabling the caching of themes will impact performance significantly.

On 21 June 2016 at 20:52, Mitya <mitya at cargosoft.ru> wrote:

> Hi Marek,
>
> What I'm looking for is the way to reload KeyCloak modules (providers) on
> the fly, hopefully without killing admin session (since not only I have to
> restart KeyCloak, but also to relogin each time). I'm afraid KeycloakServer
> only sees changes to custom themes, not modules. Or am I missing something?
>
> Mitya
>
>
> Using KeycloakServer for development. It's using embedded undertow under
> the hood. Server restarted usually in few seconds and it sees the latest
> changes in your IDE if you run it directly from the IDE. See
> https://github.com/keycloak/keycloak/blob/master/misc/Testsuite.md#keycloak-server
>
> Marek
>
> On 17/06/16 16:41, Mitya wrote:
>
> Hi,
>
> I'm developing a KeyCloak extension which is packaged as two JBoss modules:
> - the extension proper (custom authenticator + custom realm resource +
> custom admin theme);
> - modified org.keycloak.keycloak-model-jpa (since Entity SPI is not yet
> available).
>
> Each time I make changes, I have to go through a roundabout of stopping
> KeyCloak, deploying modules and starting KeyCloak again. This can happen as
> many as several dozen times a day; as soon as I roll a CI infrastructure,
> the build server will have to do the same. Needless to say, the process is
> pretty time-consuming; additionally, I'll have to grant permissions to the
> build server to restart a system service (KeyCloak is deployed as systemd
> unit). I've tried the following in jboss-cli:
>
> [disconnected /] connect
> [standalone at localhost:9990 /] module remove --name=foo.bar.main
> [standalone at localhost:9990 /] module add --name=foo.bar.main
> --resources=... --dependencies=...
> [standalone at localhost:9990 /] reload
>
> This doesn't help, despite WildFly reports to have redeployed and
> restarted KeyCloak. The updated modules are simply not picked up.
>
> Am I missing something? KeyCloak developers, what would you recommend to
> speed-up the workflow?
>
> Cheers,
> Mitya
>
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160622/f14469a3/attachment-0001.html 

From sthorger at redhat.com  Wed Jun 22 02:37:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 22 Jun 2016 08:37:50 +0200
Subject: [keycloak-dev] server start up errors
In-Reply-To: <edc53ae7-0f73-caa2-1288-d2d72c75029b@redhat.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
	<CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
	<a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
	<94c534f7-662d-31ff-99f6-74b5f73b1fb7@redhat.com>
	<89e07830-bff5-1f3c-dc48-5a7dc3730d25@redhat.com>
	<CA+1OW+iTnGDvYqz9ra2LHhx4tusrh6+hwMikPGVCFDyAYFZhnA@mail.gmail.com>
	<edc53ae7-0f73-caa2-1288-d2d72c75029b@redhat.com>
Message-ID: <CAJgngAeby=wvn9PvimK44EUAOwuL5CMovniW+U3+Xk_rqoh0Cw@mail.gmail.com>

Initializing the database can take a while (1-2min), so you'd need a
relatively long timeout on a first startup. Either pinging '
http://localhost:8080/auth/' or looking in the log would work just fine.
You can also use jboss-cli to check the status, for example to check if
server is started fully:

bin/jboss-cli.sh --connect ':read-attribute(name=server-state)'

Or check the status of Keycloak individually:

bin/jboss-cli.sh --connect 'deployment-info --name=keycloak-server.war'

An alternative is to use Liqubase to extract the SQL schema for your
database. That way Ansible can setup the database fully prior to starting
Keycloak in the first place. If you're interested in that approach let me
know and I'll let you know the details for that.



On 22 June 2016 at 00:46, John Dennis <jdennis at redhat.com> wrote:

> FYI, the following Jira issue was opened for this.
>
> https://issues.jboss.org/browse/KEYCLOAK-3150
>
> --
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160622/a5c6f100/attachment.html 

From sthorger at redhat.com  Wed Jun 22 06:44:26 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 22 Jun 2016 12:44:26 +0200
Subject: [keycloak-dev] Authorization JS adapter, where should I put it ?
In-Reply-To: <203603418.1014823.1466539148586.JavaMail.zimbra@redhat.com>
References: <18463826.968343.1466538121086.JavaMail.zimbra@redhat.com>
	<203603418.1014823.1466539148586.JavaMail.zimbra@redhat.com>
Message-ID: <CAJgngAeGWzMU=Un669O1ADg0_JfjP7_k=ctr3h+69sQFUAzVzQ@mail.gmail.com>

I would go for a separate file, keycloak-authz.js. It can then be included
by only those that need it and also documented separately.

On 21 June 2016 at 21:59, Pedro Igor Silva <psilva at redhat.com> wrote:

> Would like to make available a JS adapter for authorization. It's purpose
> is to make life easier for those using JS when interacting with an resource
> server which resources are being protected by a policy enforcer.
>
> The idea is that you can use the adapter for some very common scenarios.
> For instance, suppose you are using AngularJS and you want to handle 403
> from the resource server so you can obtain a RPT with the necessary
> permissions to retry the
> request:
>
>     var Authorization = new KeycloakAuthorization();
>
>     // our adapters return a WWW-Authenticate header with the necessary
> information to build an authorization request to a Keycloak Server
>
> Authorization.authorize(response.headers('WWW-Authenticate')).then(function
> (rpt) {
>         // onGrant callback function. If granted you'll get a RPT which
> you can use as bearer token to get access to protected resources
>     }, function () {
>         // onDeny callback function
>     }, function () {
>         // onError callback function
>     });
>
> The above code is particular useful because the JS adapter will
> automatically identify how the resource server is being protected (if using
> UMA or our entitlements protocol) and act accordingly.
>
> Or you can just obtain the entitlements using our Entitlements API:
>
>     authorization.entitlement('my-resource-server-id').then(function (rpt)
> {
>         // onGrant callback function. If granted you'll get a RPT which
> you can use as bearer token to get access to protected resources
>     })
>
> In the future, I would like to introduce more methods such as:
>
>     if (authorization.hasPermission('Main Page', 'Action 1')) {
>         // do something if current user has permissions to click a button
> on a page
>     }
>
> Should I put that stuff into keycloak.js or provide it separately ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160622/8a32dcc7/attachment.html 

From mstrukel at redhat.com  Wed Jun 22 08:05:44 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Wed, 22 Jun 2016 14:05:44 +0200
Subject: [keycloak-dev] server start up errors
In-Reply-To: <CAJgngAeby=wvn9PvimK44EUAOwuL5CMovniW+U3+Xk_rqoh0Cw@mail.gmail.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
	<CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
	<a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
	<94c534f7-662d-31ff-99f6-74b5f73b1fb7@redhat.com>
	<89e07830-bff5-1f3c-dc48-5a7dc3730d25@redhat.com>
	<CA+1OW+iTnGDvYqz9ra2LHhx4tusrh6+hwMikPGVCFDyAYFZhnA@mail.gmail.com>
	<edc53ae7-0f73-caa2-1288-d2d72c75029b@redhat.com>
	<CAJgngAeby=wvn9PvimK44EUAOwuL5CMovniW+U3+Xk_rqoh0Cw@mail.gmail.com>
Message-ID: <CA+1OW+h05BZN1Ur0Vk8-XO+=4SY7Rrq_i_EZgVqL=TFa+J71pg@mail.gmail.com>

Another thing to try would be:

bin/jboss-cli.sh --connect shutdown

This one will wait until first time boot is completed properly, and only
then perform a shutdown.

If it times out while waiting, the process will exit with error code, and
display a message:

Failed to connect to the controller: Timeout waiting for the system to boot.


On Wed, Jun 22, 2016 at 8:37 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Initializing the database can take a while (1-2min), so you'd need a
> relatively long timeout on a first startup. Either pinging '
> http://localhost:8080/auth/' or looking in the log would work just fine.
> You can also use jboss-cli to check the status, for example to check if
> server is started fully:
>
> bin/jboss-cli.sh --connect ':read-attribute(name=server-state)'
>
> Or check the status of Keycloak individually:
>
> bin/jboss-cli.sh --connect 'deployment-info --name=keycloak-server.war'
>
> An alternative is to use Liqubase to extract the SQL schema for your
> database. That way Ansible can setup the database fully prior to starting
> Keycloak in the first place. If you're interested in that approach let me
> know and I'll let you know the details for that.
>
>
>
> On 22 June 2016 at 00:46, John Dennis <jdennis at redhat.com> wrote:
>
>> FYI, the following Jira issue was opened for this.
>>
>> https://issues.jboss.org/browse/KEYCLOAK-3150
>>
>> --
>> John
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160622/bff778a3/attachment.html 

From jdennis at redhat.com  Wed Jun 22 09:04:55 2016
From: jdennis at redhat.com (John Dennis)
Date: Wed, 22 Jun 2016 09:04:55 -0400
Subject: [keycloak-dev] server start up errors
In-Reply-To: <CAJgngAeby=wvn9PvimK44EUAOwuL5CMovniW+U3+Xk_rqoh0Cw@mail.gmail.com>
References: <47e1fc5b-33d1-5130-86dd-29d08770f9f4@redhat.com>
	<CA+1OW+i3LW169t+y2Mih=ORXryGaj=GOvy7VGvUvh_LdvP9XYA@mail.gmail.com>
	<2a156a55-4fce-4a06-edf3-925a20d3cfdf@redhat.com>
	<CA+1OW+jMo+ubWJMyqEn2RFBGH75KCSVZ69H5J5oXnwqJMqm3Cg@mail.gmail.com>
	<a3538d6c-773e-2f89-6f66-a4430dd73745@redhat.com>
	<94c534f7-662d-31ff-99f6-74b5f73b1fb7@redhat.com>
	<89e07830-bff5-1f3c-dc48-5a7dc3730d25@redhat.com>
	<CA+1OW+iTnGDvYqz9ra2LHhx4tusrh6+hwMikPGVCFDyAYFZhnA@mail.gmail.com>
	<edc53ae7-0f73-caa2-1288-d2d72c75029b@redhat.com>
	<CAJgngAeby=wvn9PvimK44EUAOwuL5CMovniW+U3+Xk_rqoh0Cw@mail.gmail.com>
Message-ID: <c4970f92-1f47-25df-930f-880b55867529@redhat.com>

Thank you Stian and Marko for your suggestions regarding the use of
bin/jboss-cli.sh. I added your suggestions into the Jira so the
information would be collected in one place for future reference.

bin/jboss-cli.sh probably has a role to play in the start up and 
shutdown scripts.

-- 
John

From singhrasster at gmail.com  Thu Jun 23 00:17:10 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Wed, 22 Jun 2016 23:17:10 -0500
Subject: [keycloak-dev] Remove/unregister a registered RequiredAction from
	RequiredActions tab
Message-ID: <CAJ0vL+K3BiL5m6GT3v6pYJMGHqDpHSxfprZ_jyK-NsotYQ-i3Q@mail.gmail.com>

I have a question on the RequiredActions. On the keycloak admin console, I
go to Authentication - > Required Actions tab and register a new
RequiredAction. It then displays under the list of required actions. Now, I
don't see an option to remove this requiredAction. Is there a way to
remove/unregister this from here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160622/0e4d179a/attachment.html 

From mposolda at redhat.com  Thu Jun 23 05:25:38 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 23 Jun 2016 11:25:38 +0200
Subject: [keycloak-dev] Remove/unregister a registered RequiredAction
 from RequiredActions tab
In-Reply-To: <CAJ0vL+K3BiL5m6GT3v6pYJMGHqDpHSxfprZ_jyK-NsotYQ-i3Q@mail.gmail.com>
References: <CAJ0vL+K3BiL5m6GT3v6pYJMGHqDpHSxfprZ_jyK-NsotYQ-i3Q@mail.gmail.com>
Message-ID: <576BAB12.6040409@redhat.com>

We have REST admin endpoint for remove registered requiredAction, but 
seems it's not available in admin console UI. However if you uncheck the 
"enabled" switch for your requiredAction, it won't be used anywhere. Is 
it sufficient for your usecase?

Marek

On 23/06/16 06:17, Rashmi Singh wrote:
> I have a question on the RequiredActions. On the keycloak admin 
> console, I go to Authentication - > Required Actions tab and register 
> a new RequiredAction. It then displays under the list of required 
> actions. Now, I don't see an option to remove this requiredAction. Is 
> there a way to remove/unregister this from here?
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Thu Jun 23 06:01:38 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 Jun 2016 12:01:38 +0200
Subject: [keycloak-dev] Thinking about a change to providers
Message-ID: <CAJgngAfb1zoc1VkTg6MFAAp8g-LXjhNNi_Wxf834NVLxzSZEjg@mail.gmail.com>

Currently it's expected that the factory is application scoped, while
provider instances are request scoped. Factories can if they want return
the same instance for provider to make it application scoped.

This works as long as config is server-wide, but not if there are config
per-realm or even multiple different instances per-realm. This applies to
for example User Federation SPI (multiple per-realm), Password Hashing SPI
(one per-realm), etc.

Currently the User Federation SPI creates and manages instances outside of
the session factory and session, which results in multiple instances
created per-request, not all being closed properly, etc..

With that in mind I'd like to change the provider factories so that there
can be multiple provider factory instances. It's not completely figured
out, but I wanted to discuss it before I start a POC around it.

We'd have the following methods on KeycloakSession:

* getProvider(Class<T> clazz, Provider.class) - returns default provider
* getProvider(Class<T> clazz, Provider.class, String providerId) - returns
a specific provider, with the default config
* getProvider(Class<T> clazz, Provider.class, String providerId, String
instanceId) - returns a specific provider, with the specific config

We'd also add a method:

* invalidateProvider(Class<T> clazz, Provider.class, String providerId,
String instanceId) - this would be called when the config for a specific
provider instance is updated

Behind the covers the instances would be maintained. Each provider factory
would internally be responsible to retrieve config and cache config for
instances.

Does this sound like an idea worth pursuing? I'd like to try it out on the
PasswordPolicy SPI first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/12b108e9/attachment.html 

From mposolda at redhat.com  Thu Jun 23 08:19:10 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 23 Jun 2016 14:19:10 +0200
Subject: [keycloak-dev] Thinking about a change to providers
In-Reply-To: <CAJgngAfb1zoc1VkTg6MFAAp8g-LXjhNNi_Wxf834NVLxzSZEjg@mail.gmail.com>
References: <CAJgngAfb1zoc1VkTg6MFAAp8g-LXjhNNi_Wxf834NVLxzSZEjg@mail.gmail.com>
Message-ID: <576BD3BE.4020708@redhat.com>

+1 on having "invalidateProvider" method.

For the other stuff,  we already have the first 2 "getProvider" methods, 
so the new stuff will be the methods with "String instanceId" parameter, 
right?

We already discuss adding the "String instanceId" . Now when thinking 
more, it looks that it is not so convenient.

When adding again UserFederation SPI as an example:

- UserFederationProviderFactory needs UserFederationProviderModel to 
create instance of UserFederationProvider
- So factory needs to lookup model from cache/db. Hence the instanceId 
would need to be compound of something like: 
<REALM-UUID>::<USER-FEDERATION-PROVIDER-MODEL-ID>
That's because to lookup UserFederationProviderModel, you first need 
RealmModel and then find the UserFederationProviderModel by it's ID 
within the realm.

You may admit that RealmModel is available on KeycloakContext. However I 
don't think that we can rely on it. KeycloakContext is available in REST 
requests, but in some other cases (ie. ExportImport, periodic tasks 
etc), it's not available. Caller usually have the RealmModel and he can 
manually set it to KeycloakContext before calling session.getProvider, 
however that doesn't look like good approach to me and should be rather 
avoided. So in shortcut, we shouldn't rely on realm being available in 
KeycloakContext IMO.

The logic for parse the "instanceId" and retrieve 
UserFederationProviderModel from DB would be boilerplate code same to 
all UserFederationProviderFactory impls.


With that in mind, it really seems to me that instead of "String 
instanceId", it may work better to have some common configuration class 
like "ProviderModel" . Then signature will look like:

* getProvider(Class<T> clazz, String providerId, ProviderModel  model)

All the model subclasses (UserFederationProviderModel, 
IdentityProviderModel, PasswordPolicyModel ...) will be subclasses of 
ProviderModel

Marek

On 23/06/16 12:01, Stian Thorgersen wrote:
> Currently it's expected that the factory is application scoped, while 
> provider instances are request scoped. Factories can if they want 
> return the same instance for provider to make it application scoped.
>
> This works as long as config is server-wide, but not if there are 
> config per-realm or even multiple different instances per-realm. This 
> applies to for example User Federation SPI (multiple per-realm), 
> Password Hashing SPI (one per-realm), etc.
>
> Currently the User Federation SPI creates and manages instances 
> outside of the session factory and session, which results in multiple 
> instances created per-request, not all being closed properly, etc..
>
> With that in mind I'd like to change the provider factories so that 
> there can be multiple provider factory instances. It's not completely 
> figured out, but I wanted to discuss it before I start a POC around it.
>
> We'd have the following methods on KeycloakSession:
>
> * getProvider(Class<T> clazz, Provider.class) - returns default provider
> * getProvider(Class<T> clazz, Provider.class, String providerId) - 
> returns a specific provider, with the default config
> * getProvider(Class<T> clazz, Provider.class, String providerId, 
> String instanceId) - returns a specific provider, with the specific config
>
> We'd also add a method:
>
> * invalidateProvider(Class<T> clazz, Provider.class, String 
> providerId, String instanceId) - this would be called when the config 
> for a specific provider instance is updated
>
> Behind the covers the instances would be maintained. Each provider 
> factory would internally be responsible to retrieve config and cache 
> config for instances.
>
> Does this sound like an idea worth pursuing? I'd like to try it out on 
> the PasswordPolicy SPI first.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Thu Jun 23 08:28:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 Jun 2016 14:28:49 +0200
Subject: [keycloak-dev] Thinking about a change to providers
In-Reply-To: <576BD3BE.4020708@redhat.com>
References: <CAJgngAfb1zoc1VkTg6MFAAp8g-LXjhNNi_Wxf834NVLxzSZEjg@mail.gmail.com>
	<576BD3BE.4020708@redhat.com>
Message-ID: <CAJgngAfZZEZKWCcfgR91vKd+FPiNO9hFmru6vDc2vNcmGvyUAg@mail.gmail.com>

On 23 June 2016 at 14:19, Marek Posolda <mposolda at redhat.com> wrote:

> +1 on having "invalidateProvider" method.
>
> For the other stuff,  we already have the first 2 "getProvider" methods,
> so the new stuff will be the methods with "String instanceId" parameter,
> right?
>

Yes, I just included the two existing methods to point out that they will
still be there.


>
> We already discuss adding the "String instanceId" . Now when thinking
> more, it looks that it is not so convenient.
>
> When adding again UserFederation SPI as an example:
>
> - UserFederationProviderFactory needs UserFederationProviderModel to
> create instance of UserFederationProvider
> - So factory needs to lookup model from cache/db. Hence the instanceId
> would need to be compound of something like:
> <REALM-UUID>::<USER-FEDERATION-PROVIDER-MODEL-ID>
> That's because to lookup UserFederationProviderModel, you first need
> RealmModel and then find the UserFederationProviderModel by it's ID within
> the realm.
>
> You may admit that RealmModel is available on KeycloakContext. However I
> don't think that we can rely on it. KeycloakContext is available in REST
> requests, but in some other cases (ie. ExportImport, periodic tasks etc),
> it's not available. Caller usually have the RealmModel and he can manually
> set it to KeycloakContext before calling session.getProvider, however that
> doesn't look like good approach to me and should be rather avoided. So in
> shortcut, we shouldn't rely on realm being available in KeycloakContext
> IMO.
>

Going forward we should rely on the realm being available in
KeycloakContext IMO. The whole purpose of it is so we don't have to pass
details around all the time, including the realm.

I see two options to it:

* Don't require the realm to load provider config. If instances ids are
UUIDs this would work, but I don't think they always are right?
* Add RealmModel to the lookup, so it becomes:
  getProvider(Class<T> clazz, String providerId, RealModel realm, String
instanceId)
  That would also require a invalidateProviders(RealmModel realm) that can
clear all provider instances for a specific realm


>
> The logic for parse the "instanceId" and retrieve
> UserFederationProviderModel from DB would be boilerplate code same to all
> UserFederationProviderFactory impls.
>
>
> With that in mind, it really seems to me that instead of "String
> instanceId", it may work better to have some common configuration class
> like "ProviderModel" . Then signature will look like:
>
> * getProvider(Class<T> clazz, String providerId, ProviderModel  model)
>
> All the model subclasses (UserFederationProviderModel,
> IdentityProviderModel, PasswordPolicyModel ...) will be subclasses of
> ProviderModel
>

I don't like that at all as it requires loading and retrieving the model to
be able to get the instance. It should be the responsibility of the factory
and provider framework to be able to do that, not the code that wants to
use the provider.


>
> Marek
>
>
> On 23/06/16 12:01, Stian Thorgersen wrote:
>
> Currently it's expected that the factory is application scoped, while
> provider instances are request scoped. Factories can if they want return
> the same instance for provider to make it application scoped.
>
> This works as long as config is server-wide, but not if there are config
> per-realm or even multiple different instances per-realm. This applies to
> for example User Federation SPI (multiple per-realm), Password Hashing SPI
> (one per-realm), etc.
>
> Currently the User Federation SPI creates and manages instances outside of
> the session factory and session, which results in multiple instances
> created per-request, not all being closed properly, etc..
>
> With that in mind I'd like to change the provider factories so that there
> can be multiple provider factory instances. It's not completely figured
> out, but I wanted to discuss it before I start a POC around it.
>
> We'd have the following methods on KeycloakSession:
>
> * getProvider(Class<T> clazz, Provider.class) - returns default provider
> * getProvider(Class<T> clazz, Provider.class, String providerId) - returns
> a specific provider, with the default config
> * getProvider(Class<T> clazz, Provider.class, String providerId, String
> instanceId) - returns a specific provider, with the specific config
>
> We'd also add a method:
>
> * invalidateProvider(Class<T> clazz, Provider.class, String providerId,
> String instanceId) - this would be called when the config for a specific
> provider instance is updated
>
> Behind the covers the instances would be maintained. Each provider factory
> would internally be responsible to retrieve config and cache config for
> instances.
>
> Does this sound like an idea worth pursuing? I'd like to try it out on the
> PasswordPolicy SPI first.
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/7aa382e0/attachment-0001.html 

From sthorger at redhat.com  Thu Jun 23 08:46:02 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 Jun 2016 14:46:02 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <5763BE6A.3080007@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
Message-ID: <CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>

Admins will still want the ability to manage users through the admin
console.  That's important, especially since not all capabilities like
required actions might be available from for example an LDAP management
util. That being said I don't think there's a need to have a full import
for it. Rather the admin console could be slightly changed/tweaked.

I propose we add an option to select what providers to search. If one or
more of the selected providers doesn't support pagination we should remove
the view all option as well as the pagination.

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

> On 16/06/16 16:38, Bill Burke wrote:
> >>>> Sync users
> >>>> --------------
> >>>> We should still keep the option to sync users into Keycloak DB as we
> >>>> have now. Note some persistent storages like LDAP are limited with
> >>>> pagination. So the easiest possibility for some admins is just to sync
> >>>> users, so they can easily search them in admin console.
> >>>>
> >>> Doing a full import just to support pagination is overkill. I'm
> >>> guessing that a lot of deployments will not manage users through the
> >>> Keycload admin console.  We can offer a manual a Sync SPI that
> >>> providers can implement.
> >> Maybe it's overkill for 90% of deployments, but remaining 10% want to
> >> see all LDAP users in admin console immediatelly and hence want to sync
> >> them? IMO it's always good to have SPI flexible so it can easily support
> >> all the possible requirements. However I understand that it's not always
> >> possible...
> >>
> >
> > This is only an issue for large query result sets where you want to do
> > pagination.  IIRC, we couldn't figure out a way to do this in a
> > scalable manner without imports.
> yeah, I also can't see how to do pagination without imports, assuming
> the 3rd party store (ie. LDAP) doesn't have pagination support.
>
> So then again, the question is if SPI should still have the option to
> support imports? Or maybe don't have it OOTB, but if customers start
> asking for pagination, we have the option to say them "ok, we will try
> to add it" instead of "no, you can't do that and there is no way to
> support it with current SPI" .
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/4d71297a/attachment.html 

From sthorger at redhat.com  Thu Jun 23 08:53:36 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 Jun 2016 14:53:36 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
	<CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>
Message-ID: <CAJgngAfGhp712Jje5tpj4LBU4c5F1CFaRuCsv23S4cf1Wh-XqA@mail.gmail.com>

Some comments on
https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI:

* Different cache policies per provider may be difficult. Wouldn't that
require having a Infinispan cache per provider? That wouldn't be very
manageable.
* My vote goes to remove UserFederationProvider unless it has no impact on
design of the new providers. We shouldn't sacrifice the usability/design of
the new SPI for the sake of this.
* We should be careful about changing behavior of LDAP provider as it's
supported in product
* JTA - should we support proper JTA transactions for consistency?


On 23 June 2016 at 14:46, Stian Thorgersen <sthorger at redhat.com> wrote:

> Admins will still want the ability to manage users through the admin
> console.  That's important, especially since not all capabilities like
> required actions might be available from for example an LDAP management
> util. That being said I don't think there's a need to have a full import
> for it. Rather the admin console could be slightly changed/tweaked.
>
> I propose we add an option to select what providers to search. If one or
> more of the selected providers doesn't support pagination we should remove
> the view all option as well as the pagination.
>
> On 17 June 2016 at 11:10, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 16/06/16 16:38, Bill Burke wrote:
>> >>>> Sync users
>> >>>> --------------
>> >>>> We should still keep the option to sync users into Keycloak DB as we
>> >>>> have now. Note some persistent storages like LDAP are limited with
>> >>>> pagination. So the easiest possibility for some admins is just to
>> sync
>> >>>> users, so they can easily search them in admin console.
>> >>>>
>> >>> Doing a full import just to support pagination is overkill. I'm
>> >>> guessing that a lot of deployments will not manage users through the
>> >>> Keycload admin console.  We can offer a manual a Sync SPI that
>> >>> providers can implement.
>> >> Maybe it's overkill for 90% of deployments, but remaining 10% want to
>> >> see all LDAP users in admin console immediatelly and hence want to sync
>> >> them? IMO it's always good to have SPI flexible so it can easily
>> support
>> >> all the possible requirements. However I understand that it's not
>> always
>> >> possible...
>> >>
>> >
>> > This is only an issue for large query result sets where you want to do
>> > pagination.  IIRC, we couldn't figure out a way to do this in a
>> > scalable manner without imports.
>> yeah, I also can't see how to do pagination without imports, assuming
>> the 3rd party store (ie. LDAP) doesn't have pagination support.
>>
>> So then again, the question is if SPI should still have the option to
>> support imports? Or maybe don't have it OOTB, but if customers start
>> asking for pagination, we have the option to say them "ok, we will try
>> to add it" instead of "no, you can't do that and there is no way to
>> support it with current SPI" .
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/d972c145/attachment.html 

From mposolda at redhat.com  Thu Jun 23 09:33:39 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 23 Jun 2016 15:33:39 +0200
Subject: [keycloak-dev] Thinking about a change to providers
In-Reply-To: <CAJgngAfZZEZKWCcfgR91vKd+FPiNO9hFmru6vDc2vNcmGvyUAg@mail.gmail.com>
References: <CAJgngAfb1zoc1VkTg6MFAAp8g-LXjhNNi_Wxf834NVLxzSZEjg@mail.gmail.com>
	<576BD3BE.4020708@redhat.com>
	<CAJgngAfZZEZKWCcfgR91vKd+FPiNO9hFmru6vDc2vNcmGvyUAg@mail.gmail.com>
Message-ID: <576BE533.7010301@redhat.com>

On 23/06/16 14:28, Stian Thorgersen wrote:
>
>
> On 23 June 2016 at 14:19, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     +1 on having "invalidateProvider" method.
>
>     For the other stuff,  we already have the first 2 "getProvider"
>     methods, so the new stuff will be the methods with "String
>     instanceId" parameter, right?
>
>
> Yes, I just included the two existing methods to point out that they 
> will still be there.
>
>
>     We already discuss adding the "String instanceId" . Now when
>     thinking more, it looks that it is not so convenient.
>
>     When adding again UserFederation SPI as an example:
>
>     - UserFederationProviderFactory needs UserFederationProviderModel
>     to create instance of UserFederationProvider
>     - So factory needs to lookup model from cache/db. Hence the
>     instanceId would need to be compound of something like:
>     <REALM-UUID>::<USER-FEDERATION-PROVIDER-MODEL-ID>
>     That's because to lookup UserFederationProviderModel, you first
>     need RealmModel and then find the UserFederationProviderModel by
>     it's ID within the realm.
>
>     You may admit that RealmModel is available on KeycloakContext.
>     However I don't think that we can rely on it. KeycloakContext is
>     available in REST requests, but in some other cases (ie.
>     ExportImport, periodic tasks etc), it's not available. Caller
>     usually have the RealmModel and he can manually set it to
>     KeycloakContext before calling session.getProvider, however that
>     doesn't look like good approach to me and should be rather
>     avoided. So in shortcut, we shouldn't rely on realm being
>     available in KeycloakContext IMO.
>
>
> Going forward we should rely on the realm being available in 
> KeycloakContext IMO. The whole purpose of it is so we don't have to 
> pass details around all the time, including the realm.
>
> I see two options to it:
>
> * Don't require the realm to load provider config. If instances ids 
> are UUIDs this would work, but I don't think they always are right?
Even if they are just UUID, we will require to refactor model and have 
all the models lookup methods (e.g. "getUserFederationPRoviderModel", 
"getIdentityProviderModel" ) available globally on RealmProvider rather 
than on RealmModel. Not sure if it's very good, especially since in 
admin console, you create providers per particular realm.
> * Add RealmModel to the lookup, so it becomes:
>   getProvider(Class<T> clazz, String providerId, RealModel realm, 
> String instanceId)
>   That would also require a invalidateProviders(RealmModel realm) that 
> can clear all provider instances for a specific realm
Not sure adding RealmModel is sufficient... Some providers might not be 
scoped per-realm but rather per-client though. For example recently 
added authz based ResourceServer is scoped per client, so I can imagine 
it can be valid use-case to have providers scoped per-client as well.
>
>
>     The logic for parse the "instanceId" and retrieve
>     UserFederationProviderModel from DB would be boilerplate code same
>     to all UserFederationProviderFactory impls.
>
>
>     With that in mind, it really seems to me that instead of "String
>     instanceId", it may work better to have some common configuration
>     class like "ProviderModel" . Then signature will look like:
>
>     * getProvider(Class<T> clazz, String providerId, ProviderModel  model)
>
>     All the model subclasses (UserFederationProviderModel,
>     IdentityProviderModel, PasswordPolicyModel ...) will be subclasses
>     of ProviderModel
>
>
> I don't like that at all as it requires loading and retrieving the 
> model to be able to get the instance. It should be the responsibility 
> of the factory and provider framework to be able to do that, not the 
> code that wants to use the provider.
Well, I don't see that as an issue, but rather an advantage. It's better 
if model is loaded by caller rather than an implementation. So the 
custom UserFederationProviderFactory (or IdentityProviderFactory) 
implemented by customers don't need to contain same code for lookup the 
model based on instanceId String.

Marek
>
>
>     Marek
>
>
>     On 23/06/16 12:01, Stian Thorgersen wrote:
>>     Currently it's expected that the factory is application scoped,
>>     while provider instances are request scoped. Factories can if
>>     they want return the same instance for provider to make it
>>     application scoped.
>>
>>     This works as long as config is server-wide, but not if there are
>>     config per-realm or even multiple different instances per-realm.
>>     This applies to for example User Federation SPI (multiple
>>     per-realm), Password Hashing SPI (one per-realm), etc.
>>
>>     Currently the User Federation SPI creates and manages instances
>>     outside of the session factory and session, which results in
>>     multiple instances created per-request, not all being closed
>>     properly, etc..
>>
>>     With that in mind I'd like to change the provider factories so
>>     that there can be multiple provider factory instances. It's not
>>     completely figured out, but I wanted to discuss it before I start
>>     a POC around it.
>>
>>     We'd have the following methods on KeycloakSession:
>>
>>     * getProvider(Class<T> clazz, Provider.class) - returns default
>>     provider
>>     * getProvider(Class<T> clazz, Provider.class, String providerId)
>>     - returns a specific provider, with the default config
>>     * getProvider(Class<T> clazz, Provider.class, String providerId,
>>     String instanceId) - returns a specific provider, with the
>>     specific config
>>
>>     We'd also add a method:
>>
>>     * invalidateProvider(Class<T> clazz, Provider.class, String
>>     providerId, String instanceId) - this would be called when the
>>     config for a specific provider instance is updated
>>
>>     Behind the covers the instances would be maintained. Each
>>     provider factory would internally be responsible to retrieve
>>     config and cache config for instances.
>>
>>     Does this sound like an idea worth pursuing? I'd like to try it
>>     out on the PasswordPolicy SPI first.
>>
>>
>>     _______________________________________________
>>     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
>
>

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

From sthorger at redhat.com  Thu Jun 23 09:40:33 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 Jun 2016 15:40:33 +0200
Subject: [keycloak-dev] Thinking about a change to providers
In-Reply-To: <576BE533.7010301@redhat.com>
References: <CAJgngAfb1zoc1VkTg6MFAAp8g-LXjhNNi_Wxf834NVLxzSZEjg@mail.gmail.com>
	<576BD3BE.4020708@redhat.com>
	<CAJgngAfZZEZKWCcfgR91vKd+FPiNO9hFmru6vDc2vNcmGvyUAg@mail.gmail.com>
	<576BE533.7010301@redhat.com>
Message-ID: <CAJgngAd7Yx68+4+K2PQY=nXpF8Q=wkafFwyNwCVjpbDtXTPsgw@mail.gmail.com>

On 23 June 2016 at 15:33, Marek Posolda <mposolda at redhat.com> wrote:

> On 23/06/16 14:28, Stian Thorgersen wrote:
>
>
>
> On 23 June 2016 at 14:19, Marek Posolda <mposolda at redhat.com> wrote:
>
>> +1 on having "invalidateProvider" method.
>>
>> For the other stuff,  we already have the first 2 "getProvider" methods,
>> so the new stuff will be the methods with "String instanceId" parameter,
>> right?
>>
>
> Yes, I just included the two existing methods to point out that they will
> still be there.
>
>
>>
>> We already discuss adding the "String instanceId" . Now when thinking
>> more, it looks that it is not so convenient.
>>
>> When adding again UserFederation SPI as an example:
>>
>> - UserFederationProviderFactory needs UserFederationProviderModel to
>> create instance of UserFederationProvider
>> - So factory needs to lookup model from cache/db. Hence the instanceId
>> would need to be compound of something like:
>> <REALM-UUID>::<USER-FEDERATION-PROVIDER-MODEL-ID>
>> That's because to lookup UserFederationProviderModel, you first need
>> RealmModel and then find the UserFederationProviderModel by it's ID within
>> the realm.
>>
>> You may admit that RealmModel is available on KeycloakContext. However I
>> don't think that we can rely on it. KeycloakContext is available in REST
>> requests, but in some other cases (ie. ExportImport, periodic tasks etc),
>> it's not available. Caller usually have the RealmModel and he can manually
>> set it to KeycloakContext before calling session.getProvider, however that
>> doesn't look like good approach to me and should be rather avoided. So in
>> shortcut, we shouldn't rely on realm being available in KeycloakContext
>> IMO.
>>
>
> Going forward we should rely on the realm being available in
> KeycloakContext IMO. The whole purpose of it is so we don't have to pass
> details around all the time, including the realm.
>
> I see two options to it:
>
> * Don't require the realm to load provider config. If instances ids are
> UUIDs this would work, but I don't think they always are right?
>
> Even if they are just UUID, we will require to refactor model and have all
> the models lookup methods (e.g. "getUserFederationPRoviderModel",
> "getIdentityProviderModel" ) available globally on RealmProvider rather
> than on RealmModel. Not sure if it's very good, especially since in admin
> console, you create providers per particular realm.
>
> * Add RealmModel to the lookup, so it becomes:
>   getProvider(Class<T> clazz, String providerId, RealModel realm, String
> instanceId)
>   That would also require a invalidateProviders(RealmModel realm) that
> can clear all provider instances for a specific realm
>
> Not sure adding RealmModel is sufficient... Some providers might not be
> scoped per-realm but rather per-client though. For example recently added
> authz based ResourceServer is scoped per client, so I can imagine it can be
> valid use-case to have providers scoped per-client as well.
>

Not sure why a provider should be scoped per-client. A ResourceServer in
either case it's an internal thing and there should be a
getResourceServer(ClientModel client) rather than
getProvider(ResourceServer..). Not sure what the code does now though.


>
>
>
>>
>> The logic for parse the "instanceId" and retrieve
>> UserFederationProviderModel from DB would be boilerplate code same to all
>> UserFederationProviderFactory impls.
>>
>>
>> With that in mind, it really seems to me that instead of "String
>> instanceId", it may work better to have some common configuration class
>> like "ProviderModel" . Then signature will look like:
>>
>> * getProvider(Class<T> clazz, String providerId, ProviderModel  model)
>>
>> All the model subclasses (UserFederationProviderModel,
>> IdentityProviderModel, PasswordPolicyModel ...) will be subclasses of
>> ProviderModel
>>
>
> I don't like that at all as it requires loading and retrieving the model
> to be able to get the instance. It should be the responsibility of the
> factory and provider framework to be able to do that, not the code that
> wants to use the provider.
>
> Well, I don't see that as an issue, but rather an advantage. It's better
> if model is loaded by caller rather than an implementation. So the custom
> UserFederationProviderFactory (or IdentityProviderFactory) implemented by
> customers don't need to contain same code for lookup the model based on
> instanceId String.
>

It's basic principals of dependency injection and loosely coupling to not
require knowing how to create something to be able to use it. I strongly
disagree that the calling code needs to know how to load the config. There
are multiple places that may need to use a provider, which would then
require all those places to be able to load the config. Further, not all
providers may want to use the model directly. If it's up to the factory
itself to load the config the config can be located elsewhere.


>
>
> Marek
>
>
>> Marek
>>
>>
>> On 23/06/16 12:01, Stian Thorgersen wrote:
>>
>> Currently it's expected that the factory is application scoped, while
>> provider instances are request scoped. Factories can if they want return
>> the same instance for provider to make it application scoped.
>>
>> This works as long as config is server-wide, but not if there are config
>> per-realm or even multiple different instances per-realm. This applies to
>> for example User Federation SPI (multiple per-realm), Password Hashing SPI
>> (one per-realm), etc.
>>
>> Currently the User Federation SPI creates and manages instances outside
>> of the session factory and session, which results in multiple instances
>> created per-request, not all being closed properly, etc..
>>
>> With that in mind I'd like to change the provider factories so that there
>> can be multiple provider factory instances. It's not completely figured
>> out, but I wanted to discuss it before I start a POC around it.
>>
>> We'd have the following methods on KeycloakSession:
>>
>> * getProvider(Class<T> clazz, Provider.class) - returns default provider
>> * getProvider(Class<T> clazz, Provider.class, String providerId) -
>> returns a specific provider, with the default config
>> * getProvider(Class<T> clazz, Provider.class, String providerId, String
>> instanceId) - returns a specific provider, with the specific config
>>
>> We'd also add a method:
>>
>> * invalidateProvider(Class<T> clazz, Provider.class, String providerId,
>> String instanceId) - this would be called when the config for a specific
>> provider instance is updated
>>
>> Behind the covers the instances would be maintained. Each provider
>> factory would internally be responsible to retrieve config and cache config
>> for instances.
>>
>> Does this sound like an idea worth pursuing? I'd like to try it out on
>> the PasswordPolicy SPI first.
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/58a5f19f/attachment.html 

From bruno at abstractj.org  Thu Jun 23 10:00:52 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 23 Jun 2016 11:00:52 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
Message-ID: <20160623140052.GC2835@abstractj.org>

Good morning,

One of the use case scenarios described for FreeIPA, is the integration via PAM
and SSSD, which "automagically" handles the authentication against the IdM.

This first step requires pretty much an IPA setup, but
works with libpam4j[1]. Now, thinking about Keycloak, I
would like to have an Authenticator for PAM[2], which is pretty much our
UsernamePasswordForm + PAM. Does it make sense?

Current flow:

* User logs into Web application with username/password
* PAM authenticator collects data and authenticate against PAM
* SSSD authenticates against IdM
* Authentication is complete

After the last step, should we propagate that user to our database?
Maybe, like Marek already mentioned, have a SSSDFederationProvider?

[1] -
http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
[2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html



--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Thu Jun 23 10:31:18 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Jun 2016 10:31:18 -0400
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <CAJgngAfGhp712Jje5tpj4LBU4c5F1CFaRuCsv23S4cf1Wh-XqA@mail.gmail.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
	<CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>
	<CAJgngAfGhp712Jje5tpj4LBU4c5F1CFaRuCsv23S4cf1Wh-XqA@mail.gmail.com>
Message-ID: <1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>

First on pagination.  I was thinking about this a bit.  Do we really 
think that admins are going to paginate through 1000s of users?  Or will 
it be more like a couple of hundred at most?  Right now I've implemented 
something that is pretty inefficient to keep it backward compatible 
right now.  Basically I iterate all providers from the beginning until 
the page desired is identified and filled up.  Minimally it is a stop 
gap until I get everything working.

The API will need to change if we want pagination to work efficiently. 
Invokers on the API will need to keep an index as we need to know the 
last provider queried and what was the index for the last entry read. 
As a result, the REST API would have to change too.

On 6/23/16 8:53 AM, Stian Thorgersen wrote:
> Some comments on
> https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI:
>
> * Different cache policies per provider may be difficult. Wouldn't that
> require having a Infinispan cache per provider? That wouldn't be very
> manageable.

I think there is some flexibility here in the Infinispan API.  I know 
the old api at least allowed you to define zones in the cache.

> * My vote goes to remove UserFederationProvider unless it has no impact
> on design of the new providers. We shouldn't sacrifice the
> usability/design of the new SPI for the sake of this.

With what I got so far, I've written it to be completely backward 
compatible and allow them to co-exist.

> * We should be careful about changing behavior of LDAP provider as it's
> supported in product

Honestly, we made a very bad decision to not refactor the federation SPI 
and to force users to import.  It is going to be a really big headache 
to migrate existing LDAP users to the new LDAP provider.  IMO, it is 
ultra important to stop importing everything.

> * JTA - should we support proper JTA transactions for consistency?
>

Yes, but not all federation providers will be able to take advantage of 
it, i.e. LDAP.

Bill

From bburke at redhat.com  Thu Jun 23 11:58:21 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Jun 2016 11:58:21 -0400
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <20160623140052.GC2835@abstractj.org>
References: <20160623140052.GC2835@abstractj.org>
Message-ID: <7bc4c23a-facf-310e-a263-d5094ecd2966@redhat.com>

In this scenario, can a user be looked up out of band?  Meaning, out of 
band of the authentication process?

On 6/23/16 10:00 AM, Bruno Oliveira wrote:
> Good morning,
>
> One of the use case scenarios described for FreeIPA, is the integration via PAM
> and SSSD, which "automagically" handles the authentication against the IdM.
>
> This first step requires pretty much an IPA setup, but
> works with libpam4j[1]. Now, thinking about Keycloak, I
> would like to have an Authenticator for PAM[2], which is pretty much our
> UsernamePasswordForm + PAM. Does it make sense?
>
> Current flow:
>
> * User logs into Web application with username/password
> * PAM authenticator collects data and authenticate against PAM
> * SSSD authenticates against IdM
> * Authentication is complete
>
> After the last step, should we propagate that user to our database?
> Maybe, like Marek already mentioned, have a SSSDFederationProvider?
>
> [1] -
> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
>
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From jdennis at redhat.com  Thu Jun 23 12:25:42 2016
From: jdennis at redhat.com (John Dennis)
Date: Thu, 23 Jun 2016 12:25:42 -0400
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <20160623140052.GC2835@abstractj.org>
References: <20160623140052.GC2835@abstractj.org>
Message-ID: <c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>

On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> Good morning,
>
> One of the use case scenarios described for FreeIPA, is the integration via PAM
> and SSSD, which "automagically" handles the authentication against the IdM.
>
> This first step requires pretty much an IPA setup, but
> works with libpam4j[1]. Now, thinking about Keycloak, I
> would like to have an Authenticator for PAM[2], which is pretty much our
> UsernamePasswordForm + PAM. Does it make sense?
>
> Current flow:
>
> * User logs into Web application with username/password
> * PAM authenticator collects data and authenticate against PAM
> * SSSD authenticates against IdM
> * Authentication is complete
>
> After the last step, should we propagate that user to our database?
> Maybe, like Marek already mentioned, have a SSSDFederationProvider?
>
> [1] -
> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html

Simo brought up a concern after forwarding this to our internal identity 
team list. His comment is:

 >
 > Current flow:
 >
 > * User logs into Web application with username/password
 > * PAM authenticator collects data and authenticate against PAM

I am worried about how these 2 steps are expressed, it seem to imply PAM
is used only as a username/password verifier.
There is no mention/awarness of PAM conversations where we can prompt
for things like second factors or password changes.



-- 
John

From bruno at abstractj.org  Thu Jun 23 13:56:20 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 23 Jun 2016 14:56:20 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <7bc4c23a-facf-310e-a263-d5094ecd2966@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<7bc4c23a-facf-310e-a263-d5094ecd2966@redhat.com>
Message-ID: <20160623175620.GA6983@abstractj.org>

I'm not sure if I follow your question. Do you mean using two channels
to authenticate a user? Could you please elaborate more?


On 2016-06-23, Bill Burke wrote:
> In this scenario, can a user be looked up out of band?  Meaning, out of
> band of the authentication process?
>
> On 6/23/16 10:00 AM, Bruno Oliveira wrote:
> > Good morning,
> >
> > One of the use case scenarios described for FreeIPA, is the integration via PAM
> > and SSSD, which "automagically" handles the authentication against the IdM.
> >
> > This first step requires pretty much an IPA setup, but
> > works with libpam4j[1]. Now, thinking about Keycloak, I
> > would like to have an Authenticator for PAM[2], which is pretty much our
> > UsernamePasswordForm + PAM. Does it make sense?
> >
> > Current flow:
> >
> > * User logs into Web application with username/password
> > * PAM authenticator collects data and authenticate against PAM
> > * SSSD authenticates against IdM
> > * Authentication is complete
> >
> > After the last step, should we propagate that user to our database?
> > Maybe, like Marek already mentioned, have a SSSDFederationProvider?
> >
> > [1] -
> > http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> > [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
> >
> >
> >
> > --
> >
> > 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 bruno at abstractj.org  Thu Jun 23 13:59:59 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 23 Jun 2016 14:59:59 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
Message-ID: <20160623175959.GB6983@abstractj.org>

On 2016-06-23, John Dennis wrote:
> On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> > Good morning,
> >
> > One of the use case scenarios described for FreeIPA, is the integration via PAM
> > and SSSD, which "automagically" handles the authentication against the IdM.
> >
> > This first step requires pretty much an IPA setup, but
> > works with libpam4j[1]. Now, thinking about Keycloak, I
> > would like to have an Authenticator for PAM[2], which is pretty much our
> > UsernamePasswordForm + PAM. Does it make sense?
> >
> > Current flow:
> >
> > * User logs into Web application with username/password
> > * PAM authenticator collects data and authenticate against PAM
> > * SSSD authenticates against IdM
> > * Authentication is complete
> >
> > After the last step, should we propagate that user to our database?
> > Maybe, like Marek already mentioned, have a SSSDFederationProvider?
> >
> > [1] -
> > http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> > [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
>
> Simo brought up a concern after forwarding this to our internal identity
> team list. His comment is:
>
> >
> > Current flow:
> >
> > * User logs into Web application with username/password
> > * PAM authenticator collects data and authenticate against PAM
>
> I am worried about how these 2 steps are expressed, it seem to imply PAM
> is used only as a username/password verifier.
> There is no mention/awarness of PAM conversations where we can prompt
> for things like second factors or password changes.

We discussed several scenarios with Dmitri, one of the most basic
scenario that he described is the following:

* AD user starts browser and connects to a resource
* Resource redirects to Keycloak
* User is presented with a login form
* User fills username and password
* User data is collected and passed to SSSD over D-Bus
* SSSD authenticates against AD via IdM, user data is returned from AD and IdM

After some talk, we agreed that this should happen with PAM, because
today there's no way to pass arguments to SSSD.

* Authentication complete
* Assertion/token is issued
* User is redirected to the resource

OTP is covered and properly described for other scenarios and will be
taken into consideration when I start to look at this.

>
>
>
> --
> John

--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Thu Jun 23 14:05:48 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Jun 2016 14:05:48 -0400
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
Message-ID: <44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>



On 6/23/16 12:25 PM, John Dennis wrote:
> On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
>> Good morning,
>>
>> One of the use case scenarios described for FreeIPA, is the integration via PAM
>> and SSSD, which "automagically" handles the authentication against the IdM.
>>
>> This first step requires pretty much an IPA setup, but
>> works with libpam4j[1]. Now, thinking about Keycloak, I
>> would like to have an Authenticator for PAM[2], which is pretty much our
>> UsernamePasswordForm + PAM. Does it make sense?
>>
>> Current flow:
>>
>> * User logs into Web application with username/password
>> * PAM authenticator collects data and authenticate against PAM
>> * SSSD authenticates against IdM
>> * Authentication is complete
>>
>> After the last step, should we propagate that user to our database?
>> Maybe, like Marek already mentioned, have a SSSDFederationProvider?
>>
>> [1] -
>> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
>> [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
>
> Simo brought up a concern after forwarding this to our internal identity
> team list. His comment is:
>
>  >
>  > Current flow:
>  >
>  > * User logs into Web application with username/password
>  > * PAM authenticator collects data and authenticate against PAM
>
> I am worried about how these 2 steps are expressed, it seem to imply PAM
> is used only as a username/password verifier.
> There is no mention/awarness of PAM conversations where we can prompt
> for things like second factors or password changes.
>

Ok, I've spent maybe 20 seconds googling into what PAM conversations are 
"PAM example conversation code".   You'll have to explain to me why PAM 
conversations have any relevance to web login.  Just looking at this 
example:

https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html

It looks as if PAM conversations are targeted to simple text logins 
(i.e. SSH, telnet, etc.).  Pushing and pulling text to and from stdin 
and stdout.  What does that have to do with web login?

As for PAM itself, it looks like it is a library.  (again a 20 second 
Google search).  What I don't know is where PAM ends and SSSD takes 
over.  So its hard to give you advice.

Our SPIs can handle challenge response protocols.  Kerberos is an 
example of this in action.  We have 3 SPIs around this right now:

*  Our Authentication SPI is the "authentication conversation" layer 
that is responsible for gathering information and rendering through web 
protocols.  It is a simple workflow engine.
* Our User Federation SPI is really a storage SPI.  This is used to 
lookup information about a user.  Validation of specific credentials can 
also be delegated to this layer.  Alternatively this layer can queried 
by the Authentication SPI to obtain the user's credentials directly so 
that they can be validated in authentication code.
* Our Required Actions SPI is similar to authentication SPI in that it 
is a "web conversation".  Required actions are actions an authenticated 
user is required to execute before they can complete web login. 
Examples of this are update password, verify email, setup OTP, terms and 
conditions, etc...

So, there it is.  If you can explain to me the basics I can maybe help 
guide how you should implement this in Keycloak.

Bill





From aharnly at amplify.com  Thu Jun 23 14:35:43 2016
From: aharnly at amplify.com (Aaron Harnly)
Date: Thu, 23 Jun 2016 14:35:43 -0400
Subject: [keycloak-dev] Customizing UserEntity to encrypt personally
	identifiable information
Message-ID: <CALmwAuj6V19m7hPF9E5S2uQG8LxAAcH=gf3Ls9_WmA4d+SA2-A@mail.gmail.com>

Hi there,

I'm on Day 1 of looking at Keycloak, although some colleagues have been
using it successfully. Please forgive the naivet? of the question, but I'd
love confirmation that I'm on the right track.

I'd like to ensure that user email addresses, names, and usernames are
encrypted by the KeyCloak application before persisting to a relational
store.

org.keycloak.models.jpa.entities.UserEntity is pretty obviously the place
to do that ? the natural question is, what is the best way for me to
provide a slightly customized UserEntity.java in which I can do my desired
encryption/decryption?

My initial scan of docs and repo suggests one of the following:

1) Create a UserProvider analogous to the JpaUserProvider, but with my own
UserEntity subclass.
2) If needed, follow the approach described in this thread[1] from November
to implement a custom Hibernate EntityManager, but I don't think that's
necessary for my case, and don't yet fully understand that.
3) Something else.

[1] http://lists.jboss.org/pipermail/keycloak-dev/2015-November/005745.html

Thoughts or advice appreciated!
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/1719d72e/attachment.html 

From bruno at abstractj.org  Thu Jun 23 14:56:58 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 23 Jun 2016 15:56:58 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
Message-ID: <20160623185658.GD6983@abstractj.org>

On 2016-06-23, Bill Burke wrote:
>
>
> On 6/23/16 12:25 PM, John Dennis wrote:
> > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> >> Good morning,
> >>
> >> One of the use case scenarios described for FreeIPA, is the integration via PAM
> >> and SSSD, which "automagically" handles the authentication against the IdM.
> >>
> >> This first step requires pretty much an IPA setup, but
> >> works with libpam4j[1]. Now, thinking about Keycloak, I
> >> would like to have an Authenticator for PAM[2], which is pretty much our
> >> UsernamePasswordForm + PAM. Does it make sense?
> >>
> >> Current flow:
> >>
> >> * User logs into Web application with username/password
> >> * PAM authenticator collects data and authenticate against PAM
> >> * SSSD authenticates against IdM
> >> * Authentication is complete
> >>
> >> After the last step, should we propagate that user to our database?
> >> Maybe, like Marek already mentioned, have a SSSDFederationProvider?
> >>
> >> [1] -
> >> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> >> [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
> >
> > Simo brought up a concern after forwarding this to our internal identity
> > team list. His comment is:
> >
> >  >
> >  > Current flow:
> >  >
> >  > * User logs into Web application with username/password
> >  > * PAM authenticator collects data and authenticate against PAM
> >
> > I am worried about how these 2 steps are expressed, it seem to imply PAM
> > is used only as a username/password verifier.
> > There is no mention/awarness of PAM conversations where we can prompt
> > for things like second factors or password changes.
> >
>
> Ok, I've spent maybe 20 seconds googling into what PAM conversations are
> "PAM example conversation code".   You'll have to explain to me why PAM
> conversations have any relevance to web login.  Just looking at this
> example:
>
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
>
> It looks as if PAM conversations are targeted to simple text logins
> (i.e. SSH, telnet, etc.).  Pushing and pulling text to and from stdin
> and stdout.  What does that have to do with web login?

Your question is totally fair. And the reason why we have to integrate
with PAM is pretty much because there's no DBus interface for SSSD
to provide username/password. Otherwise we would just communicate
directly with DBus and call it a day.

The goal is pretty much to be used for Basic Authentication.

>
> As for PAM itself, it looks like it is a library.  (again a 20 second

It's pretty much a low level authentication module to support multiple
schemes like: login, ftp, ssh, telnet...(you certainly found it already)

> Google search).  What I don't know is where PAM ends and SSSD takes
> over.  So its hard to give you advice.

This is how it happens from my understanding:

1. We start the PAM conversation from our client application (a IPA client machine),
pam_sss is contacted (SSSD)
2. SSSD's PAM responder receives the authentication request and forwards
it to FreeIPA server
3. FreeIPA server process the request and returns the result back to PAM
responder.

The data flow is better described here (https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder).

>
> Our SPIs can handle challenge response protocols.  Kerberos is an
> example of this in action.  We have 3 SPIs around this right now:
>
> *  Our Authentication SPI is the "authentication conversation" layer
> that is responsible for gathering information and rendering through web
> protocols.  It is a simple workflow engine.
> * Our User Federation SPI is really a storage SPI.  This is used to
> lookup information about a user.  Validation of specific credentials can
> also be delegated to this layer.  Alternatively this layer can queried
> by the Authentication SPI to obtain the user's credentials directly so
> that they can be validated in authentication code.
> * Our Required Actions SPI is similar to authentication SPI in that it
> is a "web conversation".  Required actions are actions an authenticated
> user is required to execute before they can complete web login.
> Examples of this are update password, verify email, setup OTP, terms and
> conditions, etc...
>
> So, there it is.  If you can explain to me the basics I can maybe help
> guide how you should implement this in Keycloak.

Just let me know if what I said makes some sense.

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

--

abstractj
PGP: 0x84DC9914

From sthorger at redhat.com  Thu Jun 23 15:58:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 Jun 2016 21:58:29 +0200
Subject: [keycloak-dev] Productized Keycloak now available from Red Hat
Message-ID: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>

For nearly 4 years ago Bill Burke and myself started two individual proof
of concepts, both focusing on making it easier for developers to securing
applications and services. Keycloak was born out of combining these two
proof of concepts. There was barely any overlap and the two perfectly
complemented each other.

Fast forward to today and we now have a huge community with over 100
contributors and over 400 forks of our Github repository. It's no longer
just myself and Bill working on Keycloak, we now have a strong team working
on it and I'm very exited about the future of the project.

You may have noticed that lately we've stopped adding new features and
focused on improvements and testing. There's a good reason behind that!
We've been working on creating a productized and supported version of
Keycloak.

I'm extremely pleased to announce that Red Hat now offers a productized and
supported version of Keycloak!

For more details on how to get support for Keycloak check out the product
pages at:
https://access.redhat.com/products/red-hat-single-sign-on

Finally, I'd like to thank everyone that's been involved. All the core
developers, quality engineers, others at Red Hat and last but not least our
community!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/43d8fb7c/attachment.html 

From bburke at redhat.com  Thu Jun 23 16:04:54 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Jun 2016 16:04:54 -0400
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <20160623185658.GD6983@abstractj.org>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
Message-ID: <33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>



On 6/23/16 2:56 PM, Bruno Oliveira wrote:
> On 2016-06-23, Bill Burke wrote:
>>
>>
>> On 6/23/16 12:25 PM, John Dennis wrote:
>>> On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
>>>> Good morning,
>>>>
>>>> One of the use case scenarios described for FreeIPA, is the integration via PAM
>>>> and SSSD, which "automagically" handles the authentication against the IdM.
>>>>
>>>> This first step requires pretty much an IPA setup, but
>>>> works with libpam4j[1]. Now, thinking about Keycloak, I
>>>> would like to have an Authenticator for PAM[2], which is pretty much our
>>>> UsernamePasswordForm + PAM. Does it make sense?
>>>>
>>>> Current flow:
>>>>
>>>> * User logs into Web application with username/password
>>>> * PAM authenticator collects data and authenticate against PAM
>>>> * SSSD authenticates against IdM
>>>> * Authentication is complete
>>>>
>>>> After the last step, should we propagate that user to our database?
>>>> Maybe, like Marek already mentioned, have a SSSDFederationProvider?
>>>>
>>>> [1] -
>>>> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
>>>> [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
>>>
>>> Simo brought up a concern after forwarding this to our internal identity
>>> team list. His comment is:
>>>
>>>  >
>>>  > Current flow:
>>>  >
>>>  > * User logs into Web application with username/password
>>>  > * PAM authenticator collects data and authenticate against PAM
>>>
>>> I am worried about how these 2 steps are expressed, it seem to imply PAM
>>> is used only as a username/password verifier.
>>> There is no mention/awarness of PAM conversations where we can prompt
>>> for things like second factors or password changes.
>>>
>>
>> Ok, I've spent maybe 20 seconds googling into what PAM conversations are
>> "PAM example conversation code".   You'll have to explain to me why PAM
>> conversations have any relevance to web login.  Just looking at this
>> example:
>>
>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
>>
>> It looks as if PAM conversations are targeted to simple text logins
>> (i.e. SSH, telnet, etc.).  Pushing and pulling text to and from stdin
>> and stdout.  What does that have to do with web login?
>
> Your question is totally fair. And the reason why we have to integrate
> with PAM is pretty much because there's no DBus interface for SSSD
> to provide username/password. Otherwise we would just communicate
> directly with DBus and call it a day.
>

This is solely to allow keycloak to update passwords?  Not really 
understanding here.

> The goal is pretty much to be used for Basic Authentication.
>
>>
>> As for PAM itself, it looks like it is a library.  (again a 20 second
>
> It's pretty much a low level authentication module to support multiple
> schemes like: login, ftp, ssh, telnet...(you certainly found it already)
>
>> Google search).  What I don't know is where PAM ends and SSSD takes
>> over.  So its hard to give you advice.
>
> This is how it happens from my understanding:
>
> 1. We start the PAM conversation from our client application (a IPA client machine),
> pam_sss is contacted (SSSD)
> 2. SSSD's PAM responder receives the authentication request and forwards
> it to FreeIPA server
> 3. FreeIPA server process the request and returns the result back to PAM
> responder.
>
> The data flow is better described here (https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder).
>

It looks like a conversation requires some sort of session object or 
session connection.  Remember, a web login can span multiple requests 
and could possibly be serviced on different machines.  Sounds like any 
integration with PAM is going to be quite limited.  Maybe that's what 
you are getting at?

Or are you just talking about writing a client adapter and this has 
nothing to do with the Keycloak auth server?

Also, where does the identity data come into play (aka LDAP info)?  Is 
this also a part of the PAM/SSSD flow?

Bill

From sthorger at redhat.com  Thu Jun 23 16:06:02 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 Jun 2016 22:06:02 +0200
Subject: [keycloak-dev] Keycloak 2.0.0.CR1 Released
Message-ID: <CAJgngAfkPq=pbDAPyDZnQfZHq4gcZezJ79aUu4jiU+MtUOoWXg@mail.gmail.com>

We're finally back to adding new features. This release is just the
beginning and we've planned loads of existing new features in the coming
months.

I'm really exited to introduce the authorization services we've just added.
Through the authorization services you can centrally define and manage
fine-grained permissions for your services. For more details check out
the Authorization
Services Guide
<https://keycloak.gitbooks.io/authorization-services-guide/content/v/2.0/>.

There's a brand new website at www.keycloak.org.

Finally we've also completely reworked and significantly improved our
documentation <http://www.keycloak.org/documentation.html>.

For the full list of resolved issues check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%202.0.0.CR1>
and
to download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>. Before you upgrade refer to the migration
guide
<https://keycloak.gitbooks.io/server-adminstration-guide/content/v/2.0/topics/MigrationFromOlderVersions.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/6378220a/attachment.html 

From jdennis at redhat.com  Thu Jun 23 16:10:38 2016
From: jdennis at redhat.com (John Dennis)
Date: Thu, 23 Jun 2016 16:10:38 -0400
Subject: [keycloak-dev] Productized Keycloak now available from Red Hat
In-Reply-To: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
References: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
Message-ID: <258226fc-f60c-7fef-2e86-87183a3b25db@redhat.com>

Congratulations to Stian, Bill and the entire Keycloak team. You've 
produced an impressive and vital product. A job well done, thank you to 
everyone for all the hard work.

-- 
John

From singhrasster at gmail.com  Thu Jun 23 21:03:52 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Thu, 23 Jun 2016 20:03:52 -0500
Subject: [keycloak-dev] Does setRequiredActions method need to be invoked
	explicitly?
Message-ID: <CAJ0vL+KBgvToPn263NjG1hfvCkN084Q+e3ft6PcH0uuekgttqQ@mail.gmail.com>

I have an authenticator where I have the following method:

public void setRequiredActions(KeycloakSession session, RealmModel realm,
UserModel user) {
        user.addRequiredAction(NewRequiredAction.PROVIDER_ID);
}

Is this method invoked automatically by keycloak when authentication is
performed or we need to explicitly call this when we want to add the
RequiredAction? For me, it is not being invoked automatically by keycloak
which I first thought was the case. Could you please explain this in more
detail on how this exactly works?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/95e47d81/attachment.html 

From singhrasster at gmail.com  Thu Jun 23 23:40:36 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Thu, 23 Jun 2016 22:40:36 -0500
Subject: [keycloak-dev] How to set configs for RequiredAction in
	keycloak-server.json file
Message-ID: <CAJ0vL+K51LQX6wBh6UC10q2Z6+BEWMSwgKj9niCq4zUJxq6NqA@mail.gmail.com>

In keycloak-server.json, if we add the following

"authenticator": {
  "test-authenticator": {
    "config1": "xxxx"
  }
}

the value of config1 can be retrieved in the factory class init method as:

config.get("config1")


Now, in the same way, if I want to get configs in the init method of a
RequiredAction class instead of an authenticator, how do I set it in
keyclock-server.json? What will be the exact syntax? Is it possible?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/945ca430/attachment.html 

From mposolda at redhat.com  Fri Jun 24 00:21:23 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Jun 2016 06:21:23 +0200
Subject: [keycloak-dev] Thinking about a change to providers
In-Reply-To: <CAJgngAd7Yx68+4+K2PQY=nXpF8Q=wkafFwyNwCVjpbDtXTPsgw@mail.gmail.com>
References: <CAJgngAfb1zoc1VkTg6MFAAp8g-LXjhNNi_Wxf834NVLxzSZEjg@mail.gmail.com>
	<576BD3BE.4020708@redhat.com>
	<CAJgngAfZZEZKWCcfgR91vKd+FPiNO9hFmru6vDc2vNcmGvyUAg@mail.gmail.com>
	<576BE533.7010301@redhat.com>
	<CAJgngAd7Yx68+4+K2PQY=nXpF8Q=wkafFwyNwCVjpbDtXTPsgw@mail.gmail.com>
Message-ID: <576CB543.1060402@redhat.com>

On 23/06/16 15:40, Stian Thorgersen wrote:
>
>
> On 23 June 2016 at 15:33, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 23/06/16 14:28, Stian Thorgersen wrote:
>>
>>
>>     On 23 June 2016 at 14:19, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         +1 on having "invalidateProvider" method.
>>
>>         For the other stuff,  we already have the first 2
>>         "getProvider" methods, so the new stuff will be the methods
>>         with "String instanceId" parameter, right?
>>
>>
>>     Yes, I just included the two existing methods to point out that
>>     they will still be there.
>>
>>
>>         We already discuss adding the "String instanceId" . Now when
>>         thinking more, it looks that it is not so convenient.
>>
>>         When adding again UserFederation SPI as an example:
>>
>>         - UserFederationProviderFactory needs
>>         UserFederationProviderModel to create instance of
>>         UserFederationProvider
>>         - So factory needs to lookup model from cache/db. Hence the
>>         instanceId would need to be compound of something like:
>>         <REALM-UUID>::<USER-FEDERATION-PROVIDER-MODEL-ID>
>>         That's because to lookup UserFederationProviderModel, you
>>         first need RealmModel and then find the
>>         UserFederationProviderModel by it's ID within the realm.
>>
>>         You may admit that RealmModel is available on
>>         KeycloakContext. However I don't think that we can rely on
>>         it. KeycloakContext is available in REST requests, but in
>>         some other cases (ie. ExportImport, periodic tasks etc), it's
>>         not available. Caller usually have the RealmModel and he can
>>         manually set it to KeycloakContext before calling
>>         session.getProvider, however that doesn't look like good
>>         approach to me and should be rather avoided. So in shortcut,
>>         we shouldn't rely on realm being available in KeycloakContext
>>         IMO.
>>
>>
>>     Going forward we should rely on the realm being available in
>>     KeycloakContext IMO. The whole purpose of it is so we don't have
>>     to pass details around all the time, including the realm.
>>
>>     I see two options to it:
>>
>>     * Don't require the realm to load provider config. If instances
>>     ids are UUIDs this would work, but I don't think they always are
>>     right?
>     Even if they are just UUID, we will require to refactor model and
>     have all the models lookup methods (e.g.
>     "getUserFederationPRoviderModel", "getIdentityProviderModel" )
>     available globally on RealmProvider rather than on RealmModel. Not
>     sure if it's very good, especially since in admin console, you
>     create providers per particular realm.
>>     * Add RealmModel to the lookup, so it becomes:
>>       getProvider(Class<T> clazz, String providerId, RealModel realm,
>>     String instanceId)
>>       That would also require a invalidateProviders(RealmModel realm)
>>     that can clear all provider instances for a specific realm
>     Not sure adding RealmModel is sufficient... Some providers might
>     not be scoped per-realm but rather per-client though. For example
>     recently added authz based ResourceServer is scoped per client, so
>     I can imagine it can be valid use-case to have providers scoped
>     per-client as well.
>
>
> Not sure why a provider should be scoped per-client. A ResourceServer 
> in either case it's an internal thing and there should be a 
> getResourceServer(ClientModel client) rather than 
> getProvider(ResourceServer..). Not sure what the code does now though.
>
>
>>
>>         The logic for parse the "instanceId" and retrieve
>>         UserFederationProviderModel from DB would be boilerplate code
>>         same to all UserFederationProviderFactory impls.
>>
>>
>>         With that in mind, it really seems to me that instead of
>>         "String instanceId", it may work better to have some common
>>         configuration class like "ProviderModel" . Then signature
>>         will look like:
>>
>>         * getProvider(Class<T> clazz, String providerId,
>>         ProviderModel  model)
>>
>>         All the model subclasses (UserFederationProviderModel,
>>         IdentityProviderModel, PasswordPolicyModel ...) will be
>>         subclasses of ProviderModel
>>
>>
>>     I don't like that at all as it requires loading and retrieving
>>     the model to be able to get the instance. It should be the
>>     responsibility of the factory and provider framework to be able
>>     to do that, not the code that wants to use the provider.
>     Well, I don't see that as an issue, but rather an advantage. It's
>     better if model is loaded by caller rather than an implementation.
>     So the custom UserFederationProviderFactory (or
>     IdentityProviderFactory) implemented by customers don't need to
>     contain same code for lookup the model based on instanceId String.
>
>
> It's basic principals of dependency injection and loosely coupling to 
> not require knowing how to create something to be able to use it. I 
> strongly disagree that the calling code needs to know how to load the 
> config. There are multiple places that may need to use a provider, 
> which would then require all those places to be able to load the 
> config. Further, not all providers may want to use the model directly. 
> If it's up to the factory itself to load the config the config can be 
> located elsewhere.
Sure, the caller shouldn't be required to know how to create provider, 
it's the responsibility of factory. But the caller should know what it 
wants. And calling code (Keycloak) always knows model in all cases I can 
think of.

For example, in case of UserFederation the workflow is like:
- Admin creates some user federation provider (eg. ldap) in admin 
console. The model is saved to Keycloak db
- Then some user "john" wants to login.
- Keycloak (UserFederationManager) needs to load all the 
UserFederationProviderModel from DB as the providerId is saved on the 
model. Then when it knows the providerId is "ldap", it can finally call 
session.getProvider and instantiate provider based on that.

Similarly when some user has "federationLink" on him, it points to the 
ID of UserFederationProviderModel. So you first need to load this model 
to know the providerId.

It's very similar to IdentityProvider. When you click on login screen to 
"Login with 3rdPartyOidc", Keycloak first needs to load the 
IdentityProviderModel by alias "3rd-party-oidc" and then see that 
providerId is "oidc",  so it can call session.getProvider to retrieve 
the IdentityProvider implementation ( OIDCIdentityPRovider ).

We have the generic mechanism to create provider models in admin 
console  and the key/value pairs, which are saved as part of model. 
People are not required to use this if their implementation doesn't need 
any metadata configured through keycloak admin console (eg. someone can 
store all metadata about their UserFederation provider implementation 
into their private DB or into known property file in filesystem etc), 
and then they don't need model. But then they also don't need instanceId.

Honestly ATM, I can't see any benefit in having "String instanceId" 
instead of "ProviderModel providerModel" . Just one disadvantage that 
factory would always need to download model, which the caller already 
knows. However, maybe if you do the POC based on instanceId, I will see 
that I am wrong...;)

Marek
>
>
>
>     Marek
>>
>>
>>         Marek
>>
>>
>>         On 23/06/16 12:01, Stian Thorgersen wrote:
>>>         Currently it's expected that the factory is application
>>>         scoped, while provider instances are request scoped.
>>>         Factories can if they want return the same instance for
>>>         provider to make it application scoped.
>>>
>>>         This works as long as config is server-wide, but not if
>>>         there are config per-realm or even multiple different
>>>         instances per-realm. This applies to for example User
>>>         Federation SPI (multiple per-realm), Password Hashing SPI
>>>         (one per-realm), etc.
>>>
>>>         Currently the User Federation SPI creates and manages
>>>         instances outside of the session factory and session, which
>>>         results in multiple instances created per-request, not all
>>>         being closed properly, etc..
>>>
>>>         With that in mind I'd like to change the provider factories
>>>         so that there can be multiple provider factory instances.
>>>         It's not completely figured out, but I wanted to discuss it
>>>         before I start a POC around it.
>>>
>>>         We'd have the following methods on KeycloakSession:
>>>
>>>         * getProvider(Class<T> clazz, Provider.class) - returns
>>>         default provider
>>>         * getProvider(Class<T> clazz, Provider.class, String
>>>         providerId) - returns a specific provider, with the default
>>>         config
>>>         * getProvider(Class<T> clazz, Provider.class, String
>>>         providerId, String instanceId) - returns a specific
>>>         provider, with the specific config
>>>
>>>         We'd also add a method:
>>>
>>>         * invalidateProvider(Class<T> clazz, Provider.class, String
>>>         providerId, String instanceId) - this would be called when
>>>         the config for a specific provider instance is updated
>>>
>>>         Behind the covers the instances would be maintained. Each
>>>         provider factory would internally be responsible to retrieve
>>>         config and cache config for instances.
>>>
>>>         Does this sound like an idea worth pursuing? I'd like to try
>>>         it out on the PasswordPolicy SPI first.
>>>
>>>
>>>         _______________________________________________
>>>         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
>>
>>
>
>

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

From mposolda at redhat.com  Fri Jun 24 00:34:34 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Jun 2016 06:34:34 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
	<CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>
	<CAJgngAfGhp712Jje5tpj4LBU4c5F1CFaRuCsv23S4cf1Wh-XqA@mail.gmail.com>
	<1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>
Message-ID: <576CB85A.6030305@redhat.com>

On 23/06/16 16:31, Bill Burke wrote:
> First on pagination.  I was thinking about this a bit.  Do we really 
> think that admins are going to paginate through 1000s of users?  Or 
> will it be more like a couple of hundred at most?  Right now I've 
> implemented something that is pretty inefficient to keep it backward 
> compatible right now.  Basically I iterate all providers from the 
> beginning until the page desired is identified and filled up.  
> Minimally it is a stop gap until I get everything working.
>
> The API will need to change if we want pagination to work efficiently. 
> Invokers on the API will need to keep an index as we need to know the 
> last provider queried and what was the index for the last entry read. 
> As a result, the REST API would have to change too.
+1 to change the REST API. The admin console already works in a way that 
there are arrows for the "next" page and "previous" page right? So if we 
don't have support for "Go directly for users from 1500 to 1600" it 
won't be a big headache though...

It will be also good for LDAP as some LDAP servers have support for 
pagination extension. This is based on the functionality, that you can 
send pagination query to return first 10 users and LDAP will return you 
a "cookie" for going to next page. So just browsing between "next" page 
and "previous" page is easily possible. The most important LDAP vendors 
like MSAD and RHDS have the support for this.

>
> On 6/23/16 8:53 AM, Stian Thorgersen wrote:
>> Some comments on
>> https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI: 
>>
>>
>> * Different cache policies per provider may be difficult. Wouldn't that
>> require having a Infinispan cache per provider? That wouldn't be very
>> manageable.
>
> I think there is some flexibility here in the Infinispan API.  I know 
> the old api at least allowed you to define zones in the cache.
>
>> * My vote goes to remove UserFederationProvider unless it has no impact
>> on design of the new providers. We shouldn't sacrifice the
>> usability/design of the new SPI for the sake of this.
>
> With what I got so far, I've written it to be completely backward 
> compatible and allow them to co-exist.
>
>> * We should be careful about changing behavior of LDAP provider as it's
>> supported in product
>
> Honestly, we made a very bad decision to not refactor the federation 
> SPI and to force users to import.  It is going to be a really big 
> headache to migrate existing LDAP users to the new LDAP provider.  
> IMO, it is ultra important to stop importing everything.
Maybe I am missing something, but not sure why is it a headache? Is it 
because of the UUID of user is going to change to new format like 
f:<PROVIDER-UUID> , so users may not be referenced from the applications 
with correct UUID? This looks to be a migration issue for all existing 
federation providers, not just LDAP specific?

Marek
>
>> * JTA - should we support proper JTA transactions for consistency?
>>
>
> Yes, but not all federation providers will be able to take advantage 
> of it, i.e. LDAP.
>
> Bill


From mposolda at redhat.com  Fri Jun 24 00:39:14 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Jun 2016 06:39:14 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
	<CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>
	<CAJgngAfGhp712Jje5tpj4LBU4c5F1CFaRuCsv23S4cf1Wh-XqA@mail.gmail.com>
	<1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>
Message-ID: <576CB972.2030503@redhat.com>

On 23/06/16 16:31, Bill Burke wrote:
> First on pagination.  I was thinking about this a bit.  Do we really 
> think that admins are going to paginate through 1000s of users?  Or 
> will it be more like a couple of hundred at most?  Right now I've 
> implemented something that is pretty inefficient to keep it backward 
> compatible right now.  Basically I iterate all providers from the 
> beginning until the page desired is identified and filled up.  
> Minimally it is a stop gap until I get everything working.
>
> The API will need to change if we want pagination to work efficiently. 
> Invokers on the API will need to keep an index as we need to know the 
> last provider queried and what was the index for the last entry read. 
> As a result, the REST API would have to change too.
>
> On 6/23/16 8:53 AM, Stian Thorgersen wrote:
>> Some comments on
>> https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI: 
>>
>>
>> * Different cache policies per provider may be difficult. Wouldn't that
>> require having a Infinispan cache per provider? That wouldn't be very
>> manageable.
>
> I think there is some flexibility here in the Infinispan API.  I know 
> the old api at least allowed you to define zones in the cache.
The Infinispan has method like "put(K key, V value, long lifespan, 
TimeUnit unit)" . So if the only difference is expiration time for 
different users, then it might be sufficient?

Marek
>
>> * My vote goes to remove UserFederationProvider unless it has no impact
>> on design of the new providers. We shouldn't sacrifice the
>> usability/design of the new SPI for the sake of this.
>
> With what I got so far, I've written it to be completely backward 
> compatible and allow them to co-exist.
>
>> * We should be careful about changing behavior of LDAP provider as it's
>> supported in product
>
> Honestly, we made a very bad decision to not refactor the federation 
> SPI and to force users to import.  It is going to be a really big 
> headache to migrate existing LDAP users to the new LDAP provider.  
> IMO, it is ultra important to stop importing everything.
>
>> * JTA - should we support proper JTA transactions for consistency?
>>
>
> Yes, but not all federation providers will be able to take advantage 
> of it, i.e. LDAP.
>
> Bill

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

From sthorger at redhat.com  Fri Jun 24 04:00:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jun 2016 10:00:50 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
	<CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>
	<CAJgngAfGhp712Jje5tpj4LBU4c5F1CFaRuCsv23S4cf1Wh-XqA@mail.gmail.com>
	<1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>
Message-ID: <CAJgngAdpjTfeSQ00-KzJo3UpAfu=GK53u9K8TOSTLrwnkrZm1A@mail.gmail.com>

On 23 June 2016 at 16:31, Bill Burke <bburke at redhat.com> wrote:

> First on pagination.  I was thinking about this a bit.  Do we really think
> that admins are going to paginate through 1000s of users?  Or will it be
> more like a couple of hundred at most?  Right now I've implemented
> something that is pretty inefficient to keep it backward compatible right
> now.  Basically I iterate all providers from the beginning until the page
> desired is identified and filled up.  Minimally it is a stop gap until I
> get everything working.
>

I doubt anyone would and instead search for users if there are many. With
that in mind a solution that fetches a maximum number of users would work
fine.

Can we at least show a count? It would be helpful to be able to show the
total number of users and maybe even users per provider. As well as showing
total number of users returned by a search.


>
> The API will need to change if we want pagination to work efficiently.
> Invokers on the API will need to keep an index as we need to know the last
> provider queried and what was the index for the last entry read. As a
> result, the REST API would have to change too.


If we want to be able to select what providers to search the API would have
to change in any case though.


>
>
> On 6/23/16 8:53 AM, Stian Thorgersen wrote:
>
>> Some comments on
>> https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI
>> :
>>
>> * Different cache policies per provider may be difficult. Wouldn't that
>> require having a Infinispan cache per provider? That wouldn't be very
>> manageable.
>>
>
> I think there is some flexibility here in the Infinispan API.  I know the
> old api at least allowed you to define zones in the cache.


If that's possible then allowing configuring it per-realm or even
per-provider could be beneficial. I'd say it's a priority 2 though.


>
>
> * My vote goes to remove UserFederationProvider unless it has no impact
>> on design of the new providers. We shouldn't sacrifice the
>> usability/design of the new SPI for the sake of this.
>>
>
> With what I got so far, I've written it to be completely backward
> compatible and allow them to co-exist.


Sounds good


>
>
> * We should be careful about changing behavior of LDAP provider as it's
>> supported in product
>>
>
> Honestly, we made a very bad decision to not refactor the federation SPI
> and to force users to import.  It is going to be a really big headache to
> migrate existing LDAP users to the new LDAP provider.  IMO, it is ultra
> important to stop importing everything.


Forcing users to import true, but having the option to import is good. One
thing quite a few people have asked me is if we support migrating users
completely. Unless you have workstations authenticating to LDAP there's no
need to keep an LDAP server around once all your web apps are migrated to
Keycloak. Could we have an option to decommission a provider that would
provide the option to either import all users or to remove all
corresponding user data (required actions, etc..) in Keycloak?


>
>
> * JTA - should we support proper JTA transactions for consistency?
>>
>>
> Yes, but not all federation providers will be able to take advantage of
> it, i.e. LDAP.


Sure, I don't even think it should be enabled by default. The option would
be nice to have though. Same goes to other providers. Although for JPA the
better approach is to use a single db and transaction rather than XA
transactions. We've just had the ability to add custom entities merged in
2.0.0.CR1 that would allow someone to create user provider that shares the
same entity manager and connect/transaction with the realm, user, etc
stores.


>
>
> Bill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/d0d095db/attachment.html 

From sthorger at redhat.com  Fri Jun 24 04:06:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jun 2016 10:06:24 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <576CB85A.6030305@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
	<CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>
	<CAJgngAfGhp712Jje5tpj4LBU4c5F1CFaRuCsv23S4cf1Wh-XqA@mail.gmail.com>
	<1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>
	<576CB85A.6030305@redhat.com>
Message-ID: <CAJgngAcNB=6KRVhPuZLfppDT6mJ5VQFKNEAOFpzuqu-DXw1u2w@mail.gmail.com>

On 24 June 2016 at 06:34, Marek Posolda <mposolda at redhat.com> wrote:

> On 23/06/16 16:31, Bill Burke wrote:
>
>> First on pagination.  I was thinking about this a bit.  Do we really
>> think that admins are going to paginate through 1000s of users?  Or will it
>> be more like a couple of hundred at most?  Right now I've implemented
>> something that is pretty inefficient to keep it backward compatible right
>> now.  Basically I iterate all providers from the beginning until the page
>> desired is identified and filled up.  Minimally it is a stop gap until I
>> get everything working.
>>
>> The API will need to change if we want pagination to work efficiently.
>> Invokers on the API will need to keep an index as we need to know the last
>> provider queried and what was the index for the last entry read. As a
>> result, the REST API would have to change too.
>>
> +1 to change the REST API. The admin console already works in a way that
> there are arrows for the "next" page and "previous" page right? So if we
> don't have support for "Go directly for users from 1500 to 1600" it won't
> be a big headache though...
>

Actually our tables don't follow PatternFly and we need to update them to
make it consistent. Take a look at:

https://www.patternfly.org/pattern-library/widgets/#data-tables

It displays total number of items, has previous/next, jump to start/end as
well as ability to enter a specific page.

We could either support pagination properly or we have a maximum items that
are fetched. If the latter we'd display a message retrieving N users out of
X users or something to indicate that all users are not loaded. However,
that's just a poor attempt at pagination isn't it?


>
> It will be also good for LDAP as some LDAP servers have support for
> pagination extension. This is based on the functionality, that you can send
> pagination query to return first 10 users and LDAP will return you a
> "cookie" for going to next page. So just browsing between "next" page and
> "previous" page is easily possible. The most important LDAP vendors like
> MSAD and RHDS have the support for this.


IMO we should support pagination when possible, but a provider should have
the option to not support pagination.


>
>
>
>> On 6/23/16 8:53 AM, Stian Thorgersen wrote:
>>
>>> Some comments on
>>> https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI:
>>>
>>>
>>> * Different cache policies per provider may be difficult. Wouldn't that
>>> require having a Infinispan cache per provider? That wouldn't be very
>>> manageable.
>>>
>>
>> I think there is some flexibility here in the Infinispan API.  I know the
>> old api at least allowed you to define zones in the cache.
>>
>> * My vote goes to remove UserFederationProvider unless it has no impact
>>> on design of the new providers. We shouldn't sacrifice the
>>> usability/design of the new SPI for the sake of this.
>>>
>>
>> With what I got so far, I've written it to be completely backward
>> compatible and allow them to co-exist.
>>
>> * We should be careful about changing behavior of LDAP provider as it's
>>> supported in product
>>>
>>
>> Honestly, we made a very bad decision to not refactor the federation SPI
>> and to force users to import.  It is going to be a really big headache to
>> migrate existing LDAP users to the new LDAP provider.  IMO, it is ultra
>> important to stop importing everything.
>>
> Maybe I am missing something, but not sure why is it a headache? Is it
> because of the UUID of user is going to change to new format like
> f:<PROVIDER-UUID> , so users may not be referenced from the applications
> with correct UUID? This looks to be a migration issue for all existing
> federation providers, not just LDAP specific?
>
> Marek
>
>
>> * JTA - should we support proper JTA transactions for consistency?
>>>
>>>
>> Yes, but not all federation providers will be able to take advantage of
>> it, i.e. LDAP.
>>
>> Bill
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/cdfe5ac7/attachment-0001.html 

From thomas.raehalme at aitiofinland.com  Fri Jun 24 04:14:40 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Fri, 24 Jun 2016 11:14:40 +0300
Subject: [keycloak-dev] Productized Keycloak now available from Red Hat
In-Reply-To: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
References: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
Message-ID: <CAPyAMoYA=baG3UHzCyPrkJF5tW1OdkO7VzyKLyzYtf9i6hAiwA@mail.gmail.com>

Congrats to both of you for creating such a great open source product!

Best regards,
Thomas
On Jun 23, 2016 22:59, "Stian Thorgersen" <sthorger at redhat.com> wrote:

> For nearly 4 years ago Bill Burke and myself started two individual proof
> of concepts, both focusing on making it easier for developers to securing
> applications and services. Keycloak was born out of combining these two
> proof of concepts. There was barely any overlap and the two perfectly
> complemented each other.
>
> Fast forward to today and we now have a huge community with over 100
> contributors and over 400 forks of our Github repository. It's no longer
> just myself and Bill working on Keycloak, we now have a strong team working
> on it and I'm very exited about the future of the project.
>
> You may have noticed that lately we've stopped adding new features and
> focused on improvements and testing. There's a good reason behind that!
> We've been working on creating a productized and supported version of
> Keycloak.
>
> I'm extremely pleased to announce that Red Hat now offers a productized
> and supported version of Keycloak!
>
> For more details on how to get support for Keycloak check out the product
> pages at:
> https://access.redhat.com/products/red-hat-single-sign-on
>
> Finally, I'd like to thank everyone that's been involved. All the core
> developers, quality engineers, others at Red Hat and last but not least our
> community!
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/ef6573af/attachment.html 

From thomas.darimont at googlemail.com  Fri Jun 24 04:17:38 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 24 Jun 2016 10:17:38 +0200
Subject: [keycloak-dev] Productized Keycloak now available from Red Hat
In-Reply-To: <CAPyAMoYA=baG3UHzCyPrkJF5tW1OdkO7VzyKLyzYtf9i6hAiwA@mail.gmail.com>
References: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
	<CAPyAMoYA=baG3UHzCyPrkJF5tW1OdkO7VzyKLyzYtf9i6hAiwA@mail.gmail.com>
Message-ID: <CAK-7U1gTnNdK-g2Hz5Yzc1fU6B5qO1iT5o4+5-8ZRfOQTruXnA@mail.gmail.com>

Congratulations to everyone involved! Well done!

Cheers,
Thomas

2016-06-24 10:14 GMT+02:00 Thomas Raehalme <thomas.raehalme at aitiofinland.com
>:

> Congrats to both of you for creating such a great open source product!
>
> Best regards,
> Thomas
> On Jun 23, 2016 22:59, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>
>> For nearly 4 years ago Bill Burke and myself started two individual proof
>> of concepts, both focusing on making it easier for developers to securing
>> applications and services. Keycloak was born out of combining these two
>> proof of concepts. There was barely any overlap and the two perfectly
>> complemented each other.
>>
>> Fast forward to today and we now have a huge community with over 100
>> contributors and over 400 forks of our Github repository. It's no longer
>> just myself and Bill working on Keycloak, we now have a strong team working
>> on it and I'm very exited about the future of the project.
>>
>> You may have noticed that lately we've stopped adding new features and
>> focused on improvements and testing. There's a good reason behind that!
>> We've been working on creating a productized and supported version of
>> Keycloak.
>>
>> I'm extremely pleased to announce that Red Hat now offers a productized
>> and supported version of Keycloak!
>>
>> For more details on how to get support for Keycloak check out the product
>> pages at:
>> https://access.redhat.com/products/red-hat-single-sign-on
>>
>> Finally, I'd like to thank everyone that's been involved. All the core
>> developers, quality engineers, others at Red Hat and last but not least our
>> community!
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/01aa096d/attachment.html 

From sthorger at redhat.com  Fri Jun 24 04:26:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jun 2016 10:26:35 +0200
Subject: [keycloak-dev] Thinking about a change to providers
In-Reply-To: <576CB543.1060402@redhat.com>
References: <CAJgngAfb1zoc1VkTg6MFAAp8g-LXjhNNi_Wxf834NVLxzSZEjg@mail.gmail.com>
	<576BD3BE.4020708@redhat.com>
	<CAJgngAfZZEZKWCcfgR91vKd+FPiNO9hFmru6vDc2vNcmGvyUAg@mail.gmail.com>
	<576BE533.7010301@redhat.com>
	<CAJgngAd7Yx68+4+K2PQY=nXpF8Q=wkafFwyNwCVjpbDtXTPsgw@mail.gmail.com>
	<576CB543.1060402@redhat.com>
Message-ID: <CAJgngAfbkjaNKS+xe_qwy+a=0A1gFA0FkZDYDxk2pVxbs7mWzQ@mail.gmail.com>

UserFederationManager hides the complexity of loading providers directly.
However, that's not always the case. For example if we implement some
feature that allows displaying only users from a specific provider in the
admin console.

It needs to be a generic mechanism though and not all providers are
loaded/used through a manager either. For example identity providers. For
those you just need to get the correct provider and don't need model when
dealing with callbacks, etc..

As I said not all providers will want to use the model at all. It may very
well be that someone wants to implement a custom provider that stores the
config differently. In which case if you inject the config that's not
possible anymore.

It also complicates if someone wants to use a provider from their own
custom provider. They would have to know how to load the config first to
get the provider.

If you in the future refactor the config you now need to change everywhere
that uses it as well, not just the one place that creates the provider.

For the record this is not something new and as I said it's basic
principles of dependency injection (although we don't support injection,
it's pretty similar). You shouldn't need to know how to construct something
to be able to use it.

On 24 June 2016 at 06:21, Marek Posolda <mposolda at redhat.com> wrote:

> On 23/06/16 15:40, Stian Thorgersen wrote:
>
>
>
> On 23 June 2016 at 15:33, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 23/06/16 14:28, Stian Thorgersen wrote:
>>
>>
>>
>> On 23 June 2016 at 14:19, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> +1 on having "invalidateProvider" method.
>>>
>>> For the other stuff,  we already have the first 2 "getProvider" methods,
>>> so the new stuff will be the methods with "String instanceId" parameter,
>>> right?
>>>
>>
>> Yes, I just included the two existing methods to point out that they will
>> still be there.
>>
>>
>>>
>>> We already discuss adding the "String instanceId" . Now when thinking
>>> more, it looks that it is not so convenient.
>>>
>>> When adding again UserFederation SPI as an example:
>>>
>>> - UserFederationProviderFactory needs UserFederationProviderModel to
>>> create instance of UserFederationProvider
>>> - So factory needs to lookup model from cache/db. Hence the instanceId
>>> would need to be compound of something like:
>>> <REALM-UUID>::<USER-FEDERATION-PROVIDER-MODEL-ID>
>>> That's because to lookup UserFederationProviderModel, you first need
>>> RealmModel and then find the UserFederationProviderModel by it's ID within
>>> the realm.
>>>
>>> You may admit that RealmModel is available on KeycloakContext. However I
>>> don't think that we can rely on it. KeycloakContext is available in REST
>>> requests, but in some other cases (ie. ExportImport, periodic tasks etc),
>>> it's not available. Caller usually have the RealmModel and he can manually
>>> set it to KeycloakContext before calling session.getProvider, however that
>>> doesn't look like good approach to me and should be rather avoided. So in
>>> shortcut, we shouldn't rely on realm being available in KeycloakContext
>>> IMO.
>>>
>>
>> Going forward we should rely on the realm being available in
>> KeycloakContext IMO. The whole purpose of it is so we don't have to pass
>> details around all the time, including the realm.
>>
>> I see two options to it:
>>
>> * Don't require the realm to load provider config. If instances ids are
>> UUIDs this would work, but I don't think they always are right?
>>
>> Even if they are just UUID, we will require to refactor model and have
>> all the models lookup methods (e.g. "getUserFederationPRoviderModel",
>> "getIdentityProviderModel" ) available globally on RealmProvider rather
>> than on RealmModel. Not sure if it's very good, especially since in admin
>> console, you create providers per particular realm.
>>
>> * Add RealmModel to the lookup, so it becomes:
>>   getProvider(Class<T> clazz, String providerId, RealModel realm, String
>> instanceId)
>>   That would also require a invalidateProviders(RealmModel realm) that
>> can clear all provider instances for a specific realm
>>
>> Not sure adding RealmModel is sufficient... Some providers might not be
>> scoped per-realm but rather per-client though. For example recently added
>> authz based ResourceServer is scoped per client, so I can imagine it can be
>> valid use-case to have providers scoped per-client as well.
>>
>
> Not sure why a provider should be scoped per-client. A ResourceServer in
> either case it's an internal thing and there should be a
> getResourceServer(ClientModel client) rather than
> getProvider(ResourceServer..). Not sure what the code does now though.
>
>
>>
>>
>>
>>>
>>> The logic for parse the "instanceId" and retrieve
>>> UserFederationProviderModel from DB would be boilerplate code same to all
>>> UserFederationProviderFactory impls.
>>>
>>>
>>> With that in mind, it really seems to me that instead of "String
>>> instanceId", it may work better to have some common configuration class
>>> like "ProviderModel" . Then signature will look like:
>>>
>>> * getProvider(Class<T> clazz, String providerId, ProviderModel  model)
>>>
>>> All the model subclasses (UserFederationProviderModel,
>>> IdentityProviderModel, PasswordPolicyModel ...) will be subclasses of
>>> ProviderModel
>>>
>>
>> I don't like that at all as it requires loading and retrieving the model
>> to be able to get the instance. It should be the responsibility of the
>> factory and provider framework to be able to do that, not the code that
>> wants to use the provider.
>>
>> Well, I don't see that as an issue, but rather an advantage. It's better
>> if model is loaded by caller rather than an implementation. So the custom
>> UserFederationProviderFactory (or IdentityProviderFactory) implemented by
>> customers don't need to contain same code for lookup the model based on
>> instanceId String.
>>
>
> It's basic principals of dependency injection and loosely coupling to not
> require knowing how to create something to be able to use it. I strongly
> disagree that the calling code needs to know how to load the config. There
> are multiple places that may need to use a provider, which would then
> require all those places to be able to load the config. Further, not all
> providers may want to use the model directly. If it's up to the factory
> itself to load the config the config can be located elsewhere.
>
> Sure, the caller shouldn't be required to know how to create provider,
> it's the responsibility of factory. But the caller should know what it
> wants. And calling code (Keycloak) always knows model in all cases I can
> think of.
>
> For example, in case of UserFederation the workflow is like:
> - Admin creates some user federation provider (eg. ldap) in admin console.
> The model is saved to Keycloak db
> - Then some user "john" wants to login.
> - Keycloak (UserFederationManager) needs to load all the
> UserFederationProviderModel from DB as the providerId is saved on the
> model. Then when it knows the providerId is "ldap", it can finally call
> session.getProvider and instantiate provider based on that.
>
> Similarly when some user has "federationLink" on him, it points to the ID
> of UserFederationProviderModel. So you first need to load this model to
> know the providerId.
>
> It's very similar to IdentityProvider. When you click on login screen to
> "Login with 3rdPartyOidc", Keycloak first needs to load the
> IdentityProviderModel by alias "3rd-party-oidc" and then see that
> providerId is "oidc",  so it can call session.getProvider to retrieve the
> IdentityProvider implementation ( OIDCIdentityPRovider ).
>
> We have the generic mechanism to create provider models in admin console
> and the key/value pairs, which are saved as part of model. People are not
> required to use this if their implementation doesn't need any metadata
> configured through keycloak admin console (eg. someone can store all
> metadata about their UserFederation provider implementation into their
> private DB or into known property file in filesystem etc), and then they
> don't need model. But then they also don't need instanceId.
>
> Honestly ATM, I can't see any benefit in having "String instanceId"
> instead of "ProviderModel providerModel" . Just one disadvantage that
> factory would always need to download model, which the caller already
> knows. However, maybe if you do the POC based on instanceId, I will see
> that I am wrong...;)
>
> Marek
>
>
>
>>
>>
>> Marek
>>
>>
>>> Marek
>>>
>>>
>>> On 23/06/16 12:01, Stian Thorgersen wrote:
>>>
>>> Currently it's expected that the factory is application scoped, while
>>> provider instances are request scoped. Factories can if they want return
>>> the same instance for provider to make it application scoped.
>>>
>>> This works as long as config is server-wide, but not if there are config
>>> per-realm or even multiple different instances per-realm. This applies to
>>> for example User Federation SPI (multiple per-realm), Password Hashing SPI
>>> (one per-realm), etc.
>>>
>>> Currently the User Federation SPI creates and manages instances outside
>>> of the session factory and session, which results in multiple instances
>>> created per-request, not all being closed properly, etc..
>>>
>>> With that in mind I'd like to change the provider factories so that
>>> there can be multiple provider factory instances. It's not completely
>>> figured out, but I wanted to discuss it before I start a POC around it.
>>>
>>> We'd have the following methods on KeycloakSession:
>>>
>>> * getProvider(Class<T> clazz, Provider.class) - returns default provider
>>> * getProvider(Class<T> clazz, Provider.class, String providerId) -
>>> returns a specific provider, with the default config
>>> * getProvider(Class<T> clazz, Provider.class, String providerId, String
>>> instanceId) - returns a specific provider, with the specific config
>>>
>>> We'd also add a method:
>>>
>>> * invalidateProvider(Class<T> clazz, Provider.class, String providerId,
>>> String instanceId) - this would be called when the config for a specific
>>> provider instance is updated
>>>
>>> Behind the covers the instances would be maintained. Each provider
>>> factory would internally be responsible to retrieve config and cache config
>>> for instances.
>>>
>>> Does this sound like an idea worth pursuing? I'd like to try it out on
>>> the PasswordPolicy SPI first.
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/88886812/attachment-0001.html 

From sthorger at redhat.com  Fri Jun 24 05:48:32 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jun 2016 11:48:32 +0200
Subject: [keycloak-dev] Customizing UserEntity to encrypt personally
 identifiable information
In-Reply-To: <CALmwAuj6V19m7hPF9E5S2uQG8LxAAcH=gf3Ls9_WmA4d+SA2-A@mail.gmail.com>
References: <CALmwAuj6V19m7hPF9E5S2uQG8LxAAcH=gf3Ls9_WmA4d+SA2-A@mail.gmail.com>
Message-ID: <CAJgngAfomkwqD0mi64e_SA8H2JMyJpV15ZrwTmeOxraUGb54bw@mail.gmail.com>

You can use option 1. Create your own user provider, inside the provider
lookup the JPA provider and delegate to that, but create a wrapper that
encrypts/decrypts the personal details.

Just to point out that the User SPI is currently being reworked and you
would most likely have to do some refactoring once it is ready, which
should be in a month or two.

On 23 June 2016 at 20:35, Aaron Harnly <aharnly at amplify.com> wrote:

> Hi there,
>
> I'm on Day 1 of looking at Keycloak, although some colleagues have been
> using it successfully. Please forgive the naivet? of the question, but I'd
> love confirmation that I'm on the right track.
>
> I'd like to ensure that user email addresses, names, and usernames are
> encrypted by the KeyCloak application before persisting to a relational
> store.
>
> org.keycloak.models.jpa.entities.UserEntity is pretty obviously the place
> to do that ? the natural question is, what is the best way for me to
> provide a slightly customized UserEntity.java in which I can do my desired
> encryption/decryption?
>
> My initial scan of docs and repo suggests one of the following:
>
> 1) Create a UserProvider analogous to the JpaUserProvider, but with my own
> UserEntity subclass.
> 2) If needed, follow the approach described in this thread[1] from
> November to implement a custom Hibernate EntityManager, but I don't think
> that's necessary for my case, and don't yet fully understand that.
> 3) Something else.
>
> [1]
> http://lists.jboss.org/pipermail/keycloak-dev/2015-November/005745.html
>
> Thoughts or advice appreciated!
> Aaron
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/78e8b77a/attachment.html 

From ivan at akvo.org  Fri Jun 24 08:48:40 2016
From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=)
Date: Fri, 24 Jun 2016 14:48:40 +0200
Subject: [keycloak-dev] [keycloak-user] Keycloak 2.0.0.CR1 Released
In-Reply-To: <CAJgngAfkPq=pbDAPyDZnQfZHq4gcZezJ79aUu4jiU+MtUOoWXg@mail.gmail.com>
References: <CAJgngAfkPq=pbDAPyDZnQfZHq4gcZezJ79aUu4jiU+MtUOoWXg@mail.gmail.com>
Message-ID: <755b695c-b705-a3c6-bdf2-157306f0566a@akvo.org>

Congratulations to everyone who contributed to this release.

Looking forward to test the new authorization services.

On 06/23/2016 10:06 PM, Stian Thorgersen wrote:
> We're finally back to adding new features. This release is just the
> beginning and we've planned loads of existing new features in the coming
> months.
> 
> I'm really exited to introduce the authorization services we've just
> added. Through the authorization services you can centrally define and
> manage fine-grained permissions for your services. For more details
> check out the Authorization Services Guide
> <https://keycloak.gitbooks.io/authorization-services-guide/content/v/2.0/>.
> 
> There's a brand new website at www.keycloak.org <http://www.keycloak.org/>.
> 
> Finally we've also completely reworked and significantly improved
> our documentation <http://www.keycloak.org/documentation.html>.
> 
> For the full list of resolved issues check out JIRA
> <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%202.0.0.CR1> and
> to download the release go to the Keycloak homepage
> <http://www.keycloak.org/downloads>. Before you upgrade refer to
> the migration guide
> <https://keycloak.gitbooks.io/server-adminstration-guide/content/v/2.0/topics/MigrationFromOlderVersions.html>
> 
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 

-- 
Iv?n

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/67fd98a1/attachment.bin 

From Stephen.Merchant at gandlake.com  Fri Jun 24 08:51:57 2016
From: Stephen.Merchant at gandlake.com (Stephen Merchant)
Date: Fri, 24 Jun 2016 12:51:57 +0000
Subject: [keycloak-dev] Using Keycloak to secure a Spring Security based
 application deployed under Tomcat 8.
Message-ID: <3DE4BF1BF8EDD84B8F8D61B0A88BD56310122D@EXCH01.gandlake.local>

Hello,
I have a need to SSO secure a web application using Keycloak.  The application is Spring Security (annotation) based, and will be deployed under Tomcat 8 (either via Spring Boot or conventionally).

I was intending to use the Keycloak "Spring Security" and "Tomcat 6,7,8" Keycloak adapters to do this.

I have read articles that it is not possible to run two adapters successfully together in the same project?

Can anyone confirm this please?  Any alternative suggestions on how to achieve this coverage would also be welcome.

Thanks in anticipation,
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/218a15e4/attachment.html 

From cpitman at redhat.com  Fri Jun 24 09:04:11 2016
From: cpitman at redhat.com (Chris Pitman)
Date: Fri, 24 Jun 2016 09:04:11 -0400 (EDT)
Subject: [keycloak-dev] Using Keycloak to secure a Spring Security based
 application deployed under Tomcat 8.
In-Reply-To: <3DE4BF1BF8EDD84B8F8D61B0A88BD56310122D@EXCH01.gandlake.local>
References: <3DE4BF1BF8EDD84B8F8D61B0A88BD56310122D@EXCH01.gandlake.local>
Message-ID: <1405207036.2434888.1466773451493.JavaMail.zimbra@redhat.com>

Is there a reason you cannot just use the Spring Security adapter?

Chris Pitman
Architect, Red Hat Consulting

----- Original Message -----
> 
> 
> Hello,
> 
> I have a need to SSO secure a web application using Keycloak. The application
> is Spring Security (annotation) based, and will be deployed under Tomcat 8
> (either via Spring Boot or conventionally).
> 
> 
> 
> I was intending to use the Keycloak ? Spring Security ? and ? Tomcat 6,7,8 ?
> Keycloak adapters to do this.
> 
> 
> 
> I have read articles that it is not possible to run two adapters successfully
> together in the same project?
> 
> 
> 
> Can anyone confirm this please? Any alternative suggestions on how to achieve
> this coverage would also be welcome.
> 
> 
> 
> Thanks in anticipation,
> 
> 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 bruno at abstractj.org  Fri Jun 24 09:07:43 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Jun 2016 10:07:43 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
Message-ID: <20160624130743.GA22962@abstractj.org>

On 2016-06-23, Bill Burke wrote:
>
>
> On 6/23/16 2:56 PM, Bruno Oliveira wrote:
> > On 2016-06-23, Bill Burke wrote:
> > >
> > >
> > > On 6/23/16 12:25 PM, John Dennis wrote:
> > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> > > > > Good morning,
> > > > >
> > > > > One of the use case scenarios described for FreeIPA, is the integration via PAM
> > > > > and SSSD, which "automagically" handles the authentication against the IdM.
> > > > >
> > > > > This first step requires pretty much an IPA setup, but
> > > > > works with libpam4j[1]. Now, thinking about Keycloak, I
> > > > > would like to have an Authenticator for PAM[2], which is pretty much our
> > > > > UsernamePasswordForm + PAM. Does it make sense?
> > > > >
> > > > > Current flow:
> > > > >
> > > > > * User logs into Web application with username/password
> > > > > * PAM authenticator collects data and authenticate against PAM
> > > > > * SSSD authenticates against IdM
> > > > > * Authentication is complete
> > > > >
> > > > > After the last step, should we propagate that user to our database?
> > > > > Maybe, like Marek already mentioned, have a SSSDFederationProvider?
> > > > >
> > > > > [1] -
> > > > > http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> > > > > [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
> > > >
> > > > Simo brought up a concern after forwarding this to our internal identity
> > > > team list. His comment is:
> > > >
> > > >  >
> > > >  > Current flow:
> > > >  >
> > > >  > * User logs into Web application with username/password
> > > >  > * PAM authenticator collects data and authenticate against PAM
> > > >
> > > > I am worried about how these 2 steps are expressed, it seem to imply PAM
> > > > is used only as a username/password verifier.
> > > > There is no mention/awarness of PAM conversations where we can prompt
> > > > for things like second factors or password changes.
> > > >
> > >
> > > Ok, I've spent maybe 20 seconds googling into what PAM conversations are
> > > "PAM example conversation code".   You'll have to explain to me why PAM
> > > conversations have any relevance to web login.  Just looking at this
> > > example:
> > >
> > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
> > >
> > > It looks as if PAM conversations are targeted to simple text logins
> > > (i.e. SSH, telnet, etc.).  Pushing and pulling text to and from stdin
> > > and stdout.  What does that have to do with web login?
> >
> > Your question is totally fair. And the reason why we have to integrate
> > with PAM is pretty much because there's no DBus interface for SSSD
> > to provide username/password. Otherwise we would just communicate
> > directly with DBus and call it a day.
> >
>
> This is solely to allow keycloak to update passwords?  Not really
> understanding here.

Not really Bill, to give you more context. Login through PAM is just one
of the scenarios described by Dmitri at slide #19[1].

* User starts browser and connects to a resource
* Resource redirects to Keycloak
* User is presented with a login form
* User fills username and password
* User data is collected and passed to SSSD over D-Bus

Here, we can't provide username/password to SSSD, because we don't have
a DBus interface for it. So instead, we make use of PAM to make it happen.

* SSSD authenticates against AD
* Authentication complete (against FreeIPA)

This is where I need some help to define what would be the best next
step for us.

* Assertion/token is issued
* User is redirected to the resource

In this scenario nothing is stored/updated on Keycloak.

>
> > The goal is pretty much to be used for Basic Authentication.
> >
> > >
> > > As for PAM itself, it looks like it is a library.  (again a 20 second
> >
> > It's pretty much a low level authentication module to support multiple
> > schemes like: login, ftp, ssh, telnet...(you certainly found it already)
> >
> > > Google search).  What I don't know is where PAM ends and SSSD takes
> > > over.  So its hard to give you advice.
> >
> > This is how it happens from my understanding:
> >
> > 1. We start the PAM conversation from our client application (a IPA client machine),
> > pam_sss is contacted (SSSD)
> > 2. SSSD's PAM responder receives the authentication request and forwards
> > it to FreeIPA server
> > 3. FreeIPA server process the request and returns the result back to PAM
> > responder.
> >
> > The data flow is better described here (https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder).
> >
>
> It looks like a conversation requires some sort of session object or session
> connection.  Remember, a web login can span multiple requests and could
> possibly be serviced on different machines.  Sounds like any integration
> with PAM is going to be quite limited.  Maybe that's what you are getting
> at?

I fully understand that, certainly something that requires more testing
to see how SSSD will behave with PAM.

>
> Or are you just talking about writing a client adapter and this has nothing
> to do with the Keycloak auth server?

Good question. My initial naive idea was to have an authenticator SPI
for PAM and benefit from the work already done by Marek with LDAP and
Kerberos. Plus, have a federation SPI to retrieve user's data from SSSD
and propagate it to Keycloak.

>
> Also, where does the identity data come into play (aka LDAP info)?  Is this
> also a part of the PAM/SSSD flow?

At the flow described here#17[2]:

* User starts browser and connects to a resource
* Resource redirects to Keycloak
* User is presented with a login form
* User fills username and password
* User data is collected and passed to SSSD over D-Bus
* SSSD authenticates against LDAP server
* Authentication complete
* Assertion/token is issued
* User is redirected to the resource

>
> Bill

[1] - https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
[2] - https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
--

abstractj
PGP: 0x84DC9914

From sthorger at redhat.com  Fri Jun 24 09:52:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jun 2016 15:52:25 +0200
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <20160624130743.GA22962@abstractj.org>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
Message-ID: <CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>

On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2016-06-23, Bill Burke wrote:
> >
> >
> > On 6/23/16 2:56 PM, Bruno Oliveira wrote:
> > > On 2016-06-23, Bill Burke wrote:
> > > >
> > > >
> > > > On 6/23/16 12:25 PM, John Dennis wrote:
> > > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> > > > > > Good morning,
> > > > > >
> > > > > > One of the use case scenarios described for FreeIPA, is the
> integration via PAM
> > > > > > and SSSD, which "automagically" handles the authentication
> against the IdM.
> > > > > >
> > > > > > This first step requires pretty much an IPA setup, but
> > > > > > works with libpam4j[1]. Now, thinking about Keycloak, I
> > > > > > would like to have an Authenticator for PAM[2], which is pretty
> much our
> > > > > > UsernamePasswordForm + PAM. Does it make sense?
> > > > > >
> > > > > > Current flow:
> > > > > >
> > > > > > * User logs into Web application with username/password
> > > > > > * PAM authenticator collects data and authenticate against PAM
> > > > > > * SSSD authenticates against IdM
> > > > > > * Authentication is complete
> > > > > >
> > > > > > After the last step, should we propagate that user to our
> database?
> > > > > > Maybe, like Marek already mentioned, have a
> SSSDFederationProvider?
> > > > > >
> > > > > > [1] -
> > > > > >
> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> > > > > > [2] -
> https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
> > > > >
> > > > > Simo brought up a concern after forwarding this to our internal
> identity
> > > > > team list. His comment is:
> > > > >
> > > > >  >
> > > > >  > Current flow:
> > > > >  >
> > > > >  > * User logs into Web application with username/password
> > > > >  > * PAM authenticator collects data and authenticate against PAM
> > > > >
> > > > > I am worried about how these 2 steps are expressed, it seem to
> imply PAM
> > > > > is used only as a username/password verifier.
> > > > > There is no mention/awarness of PAM conversations where we can
> prompt
> > > > > for things like second factors or password changes.
> > > > >
> > > >
> > > > Ok, I've spent maybe 20 seconds googling into what PAM conversations
> are
> > > > "PAM example conversation code".   You'll have to explain to me why
> PAM
> > > > conversations have any relevance to web login.  Just looking at this
> > > > example:
> > > >
> > > >
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
> > > >
> > > > It looks as if PAM conversations are targeted to simple text logins
> > > > (i.e. SSH, telnet, etc.).  Pushing and pulling text to and from stdin
> > > > and stdout.  What does that have to do with web login?
> > >
> > > Your question is totally fair. And the reason why we have to integrate
> > > with PAM is pretty much because there's no DBus interface for SSSD
> > > to provide username/password. Otherwise we would just communicate
> > > directly with DBus and call it a day.
> > >
> >
> > This is solely to allow keycloak to update passwords?  Not really
> > understanding here.
>
> Not really Bill, to give you more context. Login through PAM is just one
> of the scenarios described by Dmitri at slide #19[1].
>
> * User starts browser and connects to a resource
> * Resource redirects to Keycloak
> * User is presented with a login form
> * User fills username and password
> * User data is collected and passed to SSSD over D-Bus
>
> Here, we can't provide username/password to SSSD, because we don't have
> a DBus interface for it. So instead, we make use of PAM to make it happen.
>

Isn't the flow actually:

* User starts browser and connects to a resource
* Resource redirects to Keycloak
* User is presented with a login form
* User fills username and password
* Username and password is verified through PAM (in the future SSSD once
that becomes available) - this should be a custom authenticator
* User profile is retrieved from SSSD over D-Bus - this should be a custom
user federation provider
* Done


>
> * SSSD authenticates against AD
> * Authentication complete (against FreeIPA)
>
> This is where I need some help to define what would be the best next
> step for us.
>
> * Assertion/token is issued
> * User is redirected to the resource
>
> In this scenario nothing is stored/updated on Keycloak.
>
> >
> > > The goal is pretty much to be used for Basic Authentication.
> > >
> > > >
> > > > As for PAM itself, it looks like it is a library.  (again a 20 second
> > >
> > > It's pretty much a low level authentication module to support multiple
> > > schemes like: login, ftp, ssh, telnet...(you certainly found it
> already)
> > >
> > > > Google search).  What I don't know is where PAM ends and SSSD takes
> > > > over.  So its hard to give you advice.
> > >
> > > This is how it happens from my understanding:
> > >
> > > 1. We start the PAM conversation from our client application (a IPA
> client machine),
> > > pam_sss is contacted (SSSD)
> > > 2. SSSD's PAM responder receives the authentication request and
> forwards
> > > it to FreeIPA server
> > > 3. FreeIPA server process the request and returns the result back to
> PAM
> > > responder.
> > >
> > > The data flow is better described here (
> https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder
> ).
> > >
> >
> > It looks like a conversation requires some sort of session object or
> session
> > connection.  Remember, a web login can span multiple requests and could
> > possibly be serviced on different machines.  Sounds like any integration
> > with PAM is going to be quite limited.  Maybe that's what you are getting
> > at?
>
> I fully understand that, certainly something that requires more testing
> to see how SSSD will behave with PAM.
>
> >
> > Or are you just talking about writing a client adapter and this has
> nothing
> > to do with the Keycloak auth server?
>
> Good question. My initial naive idea was to have an authenticator SPI
> for PAM and benefit from the work already done by Marek with LDAP and
> Kerberos. Plus, have a federation SPI to retrieve user's data from SSSD
> and propagate it to Keycloak.
>
> >
> > Also, where does the identity data come into play (aka LDAP info)?  Is
> this
> > also a part of the PAM/SSSD flow?
>
> At the flow described here#17[2]:
>
> * User starts browser and connects to a resource
> * Resource redirects to Keycloak
> * User is presented with a login form
> * User fills username and password
> * User data is collected and passed to SSSD over D-Bus
> * SSSD authenticates against LDAP server
> * Authentication complete
> * Assertion/token is issued
> * User is redirected to the resource
>
> >
> > Bill
>
> [1] -
> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
> [2] -
> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/73e89d50/attachment.html 

From jdennis at redhat.com  Fri Jun 24 09:53:34 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 24 Jun 2016 09:53:34 -0400
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <20160624130743.GA22962@abstractj.org>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
Message-ID: <764b1cbe-02c9-1bf6-2736-6f322020b01c@redhat.com>

On 06/24/2016 09:07 AM, Bruno Oliveira wrote:
> On 2016-06-23, Bill Burke wrote:
>>
>>
>> On 6/23/16 2:56 PM, Bruno Oliveira wrote:
>>> On 2016-06-23, Bill Burke wrote:
>>>>
>>>>
>>>> On 6/23/16 12:25 PM, John Dennis wrote:
>>>>> On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
>>>>>> Good morning,
>>>>>>
>>>>>> One of the use case scenarios described for FreeIPA, is the integration via PAM
>>>>>> and SSSD, which "automagically" handles the authentication against the IdM.
>>>>>>
>>>>>> This first step requires pretty much an IPA setup, but
>>>>>> works with libpam4j[1]. Now, thinking about Keycloak, I
>>>>>> would like to have an Authenticator for PAM[2], which is pretty much our
>>>>>> UsernamePasswordForm + PAM. Does it make sense?
>>>>>>
>>>>>> Current flow:
>>>>>>
>>>>>> * User logs into Web application with username/password
>>>>>> * PAM authenticator collects data and authenticate against PAM
>>>>>> * SSSD authenticates against IdM
>>>>>> * Authentication is complete
>>>>>>
>>>>>> After the last step, should we propagate that user to our database?
>>>>>> Maybe, like Marek already mentioned, have a SSSDFederationProvider?
>>>>>>
>>>>>> [1] -
>>>>>> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
>>>>>> [2] - https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
>>>>>
>>>>> Simo brought up a concern after forwarding this to our internal identity
>>>>> team list. His comment is:
>>>>>
>>>>>  >
>>>>>  > Current flow:
>>>>>  >
>>>>>  > * User logs into Web application with username/password
>>>>>  > * PAM authenticator collects data and authenticate against PAM
>>>>>
>>>>> I am worried about how these 2 steps are expressed, it seem to imply PAM
>>>>> is used only as a username/password verifier.
>>>>> There is no mention/awarness of PAM conversations where we can prompt
>>>>> for things like second factors or password changes.
>>>>>
>>>>
>>>> Ok, I've spent maybe 20 seconds googling into what PAM conversations are
>>>> "PAM example conversation code".   You'll have to explain to me why PAM
>>>> conversations have any relevance to web login.  Just looking at this
>>>> example:
>>>>
>>>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
>>>>
>>>> It looks as if PAM conversations are targeted to simple text logins
>>>> (i.e. SSH, telnet, etc.).  Pushing and pulling text to and from stdin
>>>> and stdout.  What does that have to do with web login?
>>>
>>> Your question is totally fair. And the reason why we have to integrate
>>> with PAM is pretty much because there's no DBus interface for SSSD
>>> to provide username/password. Otherwise we would just communicate
>>> directly with DBus and call it a day.
>>>
>>
>> This is solely to allow keycloak to update passwords?  Not really
>> understanding here.
>
> Not really Bill, to give you more context. Login through PAM is just one
> of the scenarios described by Dmitri at slide #19[1].
>
> * User starts browser and connects to a resource
> * Resource redirects to Keycloak
> * User is presented with a login form
> * User fills username and password
> * User data is collected and passed to SSSD over D-Bus
>
> Here, we can't provide username/password to SSSD, because we don't have
> a DBus interface for it. So instead, we make use of PAM to make it happen.
>
> * SSSD authenticates against AD
> * Authentication complete (against FreeIPA)
>
> This is where I need some help to define what would be the best next
> step for us.
>
> * Assertion/token is issued
> * User is redirected to the resource
>
> In this scenario nothing is stored/updated on Keycloak.
>
>>
>>> The goal is pretty much to be used for Basic Authentication.
>>>
>>>>
>>>> As for PAM itself, it looks like it is a library.  (again a 20 second
>>>
>>> It's pretty much a low level authentication module to support multiple
>>> schemes like: login, ftp, ssh, telnet...(you certainly found it already)
>>>
>>>> Google search).  What I don't know is where PAM ends and SSSD takes
>>>> over.  So its hard to give you advice.
>>>
>>> This is how it happens from my understanding:
>>>
>>> 1. We start the PAM conversation from our client application (a IPA client machine),
>>> pam_sss is contacted (SSSD)
>>> 2. SSSD's PAM responder receives the authentication request and forwards
>>> it to FreeIPA server
>>> 3. FreeIPA server process the request and returns the result back to PAM
>>> responder.
>>>
>>> The data flow is better described here (https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder).
>>>
>>
>> It looks like a conversation requires some sort of session object or session
>> connection.  Remember, a web login can span multiple requests and could
>> possibly be serviced on different machines.  Sounds like any integration
>> with PAM is going to be quite limited.  Maybe that's what you are getting
>> at?
>
> I fully understand that, certainly something that requires more testing
> to see how SSSD will behave with PAM.
>
>>
>> Or are you just talking about writing a client adapter and this has nothing
>> to do with the Keycloak auth server?
>
> Good question. My initial naive idea was to have an authenticator SPI
> for PAM and benefit from the work already done by Marek with LDAP and
> Kerberos. Plus, have a federation SPI to retrieve user's data from SSSD
> and propagate it to Keycloak.
>
>>
>> Also, where does the identity data come into play (aka LDAP info)?  Is this
>> also a part of the PAM/SSSD flow?
>
> At the flow described here#17[2]:
>
> * User starts browser and connects to a resource
> * Resource redirects to Keycloak
> * User is presented with a login form
> * User fills username and password
> * User data is collected and passed to SSSD over D-Bus
> * SSSD authenticates against LDAP server
> * Authentication complete
> * Assertion/token is issued
> * User is redirected to the resource
>
>>
>> Bill
>
> [1] - https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
> [2] - https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107

Let me try to clarify a few things.

PAM is designed as a "conversation", there are a few analogues you could 
compare it to:

* a series of requests/responses

* challenge/response authentication (e.g. CRAM)

PAM has something equivalent to a session where state is stored during 
the "conversation". When you use PAM you establish a context (session) 
and iterate. In each iteration the PAM library will ask you for 
something and you reply. The iteration stops when the library signals 
completion.

For simple password auth the iteration is very short. But depending on 
how the PAM service is configured you could be prompted for other 
things. I suspect with Web forms they way you handle this is via 
redirects until such time as the PAM conversation completes.

So my suggestion would be to design this where there is a simple web 
form prompting for username/password but allow for the fact you may have 
to redirect to another page.

Currently SSSD does not allow for authentication conversations which is 
one reason PAM is being promoted as an interim solution. The SSSD team 
does not want to add equivalent DBus authentication without carefully 
designing it. The concern is in a rush to provide authentication with 
SSSD DBus it would end up as just another broken variant of PAM (yes, 
PAM has warts, it was designed 20 years ago for Solaris and it's showing 
it's age and weaknesses, but none the less it remains the standard 
authentication interface on UNIX like systems).

Does that help?


-- 
John

From jdennis at redhat.com  Fri Jun 24 10:00:01 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 24 Jun 2016 10:00:01 -0400
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
Message-ID: <db095d87-3aac-1242-ea04-b17dd95f23dc@redhat.com>

On 06/24/2016 09:52 AM, Stian Thorgersen wrote:
>
>
> On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org
> <mailto:bruno at abstractj.org>> wrote:
>
>     On 2016-06-23, Bill Burke wrote:
>     >
>     >
>     > On 6/23/16 2:56 PM, Bruno Oliveira wrote:
>     > > On 2016-06-23, Bill Burke wrote:
>     > > >
>     > > >
>     > > > On 6/23/16 12:25 PM, John Dennis wrote:
>     > > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
>     > > > > > Good morning,
>     > > > > >
>     > > > > > One of the use case scenarios described for FreeIPA, is
>     the integration via PAM
>     > > > > > and SSSD, which "automagically" handles the authentication
>     against the IdM.
>     > > > > >
>     > > > > > This first step requires pretty much an IPA setup, but
>     > > > > > works with libpam4j[1]. Now, thinking about Keycloak, I
>     > > > > > would like to have an Authenticator for PAM[2], which is
>     pretty much our
>     > > > > > UsernamePasswordForm + PAM. Does it make sense?
>     > > > > >
>     > > > > > Current flow:
>     > > > > >
>     > > > > > * User logs into Web application with username/password
>     > > > > > * PAM authenticator collects data and authenticate against PAM
>     > > > > > * SSSD authenticates against IdM
>     > > > > > * Authentication is complete
>     > > > > >
>     > > > > > After the last step, should we propagate that user to our
>     database?
>     > > > > > Maybe, like Marek already mentioned, have a
>     SSSDFederationProvider?
>     > > > > >
>     > > > > > [1] -
>     > > > > >
>     http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
>     > > > > > [2] -
>     https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
>     > > > >
>     > > > > Simo brought up a concern after forwarding this to our
>     internal identity
>     > > > > team list. His comment is:
>     > > > >
>     > > > >  >
>     > > > >  > Current flow:
>     > > > >  >
>     > > > >  > * User logs into Web application with username/password
>     > > > >  > * PAM authenticator collects data and authenticate
>     against PAM
>     > > > >
>     > > > > I am worried about how these 2 steps are expressed, it seem
>     to imply PAM
>     > > > > is used only as a username/password verifier.
>     > > > > There is no mention/awarness of PAM conversations where we
>     can prompt
>     > > > > for things like second factors or password changes.
>     > > > >
>     > > >
>     > > > Ok, I've spent maybe 20 seconds googling into what PAM
>     conversations are
>     > > > "PAM example conversation code".   You'll have to explain to
>     me why PAM
>     > > > conversations have any relevance to web login.  Just looking
>     at this
>     > > > example:
>     > > >
>     > > >
>     https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
>     > > >
>     > > > It looks as if PAM conversations are targeted to simple text
>     logins
>     > > > (i.e. SSH, telnet, etc.).  Pushing and pulling text to and
>     from stdin
>     > > > and stdout.  What does that have to do with web login?
>     > >
>     > > Your question is totally fair. And the reason why we have to
>     integrate
>     > > with PAM is pretty much because there's no DBus interface for SSSD
>     > > to provide username/password. Otherwise we would just communicate
>     > > directly with DBus and call it a day.
>     > >
>     >
>     > This is solely to allow keycloak to update passwords?  Not really
>     > understanding here.
>
>     Not really Bill, to give you more context. Login through PAM is just one
>     of the scenarios described by Dmitri at slide #19[1].
>
>     * User starts browser and connects to a resource
>     * Resource redirects to Keycloak
>     * User is presented with a login form
>     * User fills username and password
>     * User data is collected and passed to SSSD over D-Bus
>
>     Here, we can't provide username/password to SSSD, because we don't have
>     a DBus interface for it. So instead, we make use of PAM to make it
>     happen.
>
>
> Isn't the flow actually:
>
> * User starts browser and connects to a resource
> * Resource redirects to Keycloak
> * User is presented with a login form
> * User fills username and password
> * Username and password is verified through PAM (in the future SSSD once
> that becomes available) - this should be a custom authenticator
> * User profile is retrieved from SSSD over D-Bus - this should be a
> custom user federation provider
> * Done

Yes, this is a good summary Stian and clearly articulates the immediate 
first implementation.

I think the only additional thing is sometime down the road it might not 
just be one login form, you might be prompted for additional 
information. But that is *not* part of the requirements for the first 
implementation as I understand it. Just don't box yourself into a corner 
by prohibiting it down the road.

>
>
>     * SSSD authenticates against AD
>     * Authentication complete (against FreeIPA)
>
>     This is where I need some help to define what would be the best next
>     step for us.
>
>     * Assertion/token is issued
>     * User is redirected to the resource
>
>     In this scenario nothing is stored/updated on Keycloak.
>
>     >
>     > > The goal is pretty much to be used for Basic Authentication.
>     > >
>     > > >
>     > > > As for PAM itself, it looks like it is a library.  (again a 20 second
>     > >
>     > > It's pretty much a low level authentication module to support multiple
>     > > schemes like: login, ftp, ssh, telnet...(you certainly found it already)
>     > >
>     > > > Google search).  What I don't know is where PAM ends and SSSD takes
>     > > > over.  So its hard to give you advice.
>     > >
>     > > This is how it happens from my understanding:
>     > >
>     > > 1. We start the PAM conversation from our client application (a IPA client machine),
>     > > pam_sss is contacted (SSSD)
>     > > 2. SSSD's PAM responder receives the authentication request and forwards
>     > > it to FreeIPA server
>     > > 3. FreeIPA server process the request and returns the result back to PAM
>     > > responder.
>     > >
>     > > The data flow is better described here (https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder).
>     > >
>     >
>     > It looks like a conversation requires some sort of session object or session
>     > connection.  Remember, a web login can span multiple requests and could
>     > possibly be serviced on different machines.  Sounds like any integration
>     > with PAM is going to be quite limited.  Maybe that's what you are getting
>     > at?
>
>     I fully understand that, certainly something that requires more testing
>     to see how SSSD will behave with PAM.
>
>     >
>     > Or are you just talking about writing a client adapter and this has nothing
>     > to do with the Keycloak auth server?
>
>     Good question. My initial naive idea was to have an authenticator SPI
>     for PAM and benefit from the work already done by Marek with LDAP and
>     Kerberos. Plus, have a federation SPI to retrieve user's data from SSSD
>     and propagate it to Keycloak.
>
>     >
>     > Also, where does the identity data come into play (aka LDAP info)?  Is this
>     > also a part of the PAM/SSSD flow?
>
>     At the flow described here#17[2]:
>
>     * User starts browser and connects to a resource
>     * Resource redirects to Keycloak
>     * User is presented with a login form
>     * User fills username and password
>     * User data is collected and passed to SSSD over D-Bus
>     * SSSD authenticates against LDAP server
>     * Authentication complete
>     * Assertion/token is issued
>     * User is redirected to the resource
>
>     >
>     > Bill
>
>     [1] -
>     https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
>     [2] -
>     https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
>     --
>
>     abstractj
>     PGP: 0x84DC9914
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


-- 
John

From singhrasster at gmail.com  Fri Jun 24 10:01:12 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Fri, 24 Jun 2016 09:01:12 -0500
Subject: [keycloak-dev] How to set configs for RequiredAction in
	keycloak-server.json file
In-Reply-To: <CAJ0vL+K51LQX6wBh6UC10q2Z6+BEWMSwgKj9niCq4zUJxq6NqA@mail.gmail.com>
References: <CAJ0vL+K51LQX6wBh6UC10q2Z6+BEWMSwgKj9niCq4zUJxq6NqA@mail.gmail.com>
Message-ID: <CAJ0vL+KbePejXWfXZq3MVh95rMwwrEk=VbpKumCyjQ5w1vCasA@mail.gmail.com>

Any clue for this?

On Thu, Jun 23, 2016 at 10:40 PM, Rashmi Singh <singhrasster at gmail.com>
wrote:

> In keycloak-server.json, if we add the following
>
> "authenticator": {
>   "test-authenticator": {
>     "config1": "xxxx"
>   }
> }
>
> the value of config1 can be retrieved in the factory class init method as:
>
> config.get("config1")
>
>
> Now, in the same way, if I want to get configs in the init method of a
> RequiredAction class instead of an authenticator, how do I set it in
> keyclock-server.json? What will be the exact syntax? Is it possible?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/9e0785f8/attachment.html 

From sthorger at redhat.com  Fri Jun 24 10:02:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jun 2016 16:02:39 +0200
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <db095d87-3aac-1242-ea04-b17dd95f23dc@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
	<db095d87-3aac-1242-ea04-b17dd95f23dc@redhat.com>
Message-ID: <CAJgngAcDJSOW-0Fnms59xezrqS+3zzdXCh0MJGZ-gvy8CDdVdA@mail.gmail.com>

On 24 June 2016 at 16:00, John Dennis <jdennis at redhat.com> wrote:

> On 06/24/2016 09:52 AM, Stian Thorgersen wrote:
>
>>
>>
>> On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org
>> <mailto:bruno at abstractj.org>> wrote:
>>
>>     On 2016-06-23, Bill Burke wrote:
>>     >
>>     >
>>     > On 6/23/16 2:56 PM, Bruno Oliveira wrote:
>>     > > On 2016-06-23, Bill Burke wrote:
>>     > > >
>>     > > >
>>     > > > On 6/23/16 12:25 PM, John Dennis wrote:
>>     > > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
>>     > > > > > Good morning,
>>     > > > > >
>>     > > > > > One of the use case scenarios described for FreeIPA, is
>>     the integration via PAM
>>     > > > > > and SSSD, which "automagically" handles the authentication
>>     against the IdM.
>>     > > > > >
>>     > > > > > This first step requires pretty much an IPA setup, but
>>     > > > > > works with libpam4j[1]. Now, thinking about Keycloak, I
>>     > > > > > would like to have an Authenticator for PAM[2], which is
>>     pretty much our
>>     > > > > > UsernamePasswordForm + PAM. Does it make sense?
>>     > > > > >
>>     > > > > > Current flow:
>>     > > > > >
>>     > > > > > * User logs into Web application with username/password
>>     > > > > > * PAM authenticator collects data and authenticate against
>> PAM
>>     > > > > > * SSSD authenticates against IdM
>>     > > > > > * Authentication is complete
>>     > > > > >
>>     > > > > > After the last step, should we propagate that user to our
>>     database?
>>     > > > > > Maybe, like Marek already mentioned, have a
>>     SSSDFederationProvider?
>>     > > > > >
>>     > > > > > [1] -
>>     > > > > >
>>
>> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
>>     > > > > > [2] -
>>
>> https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
>>     > > > >
>>     > > > > Simo brought up a concern after forwarding this to our
>>     internal identity
>>     > > > > team list. His comment is:
>>     > > > >
>>     > > > >  >
>>     > > > >  > Current flow:
>>     > > > >  >
>>     > > > >  > * User logs into Web application with username/password
>>     > > > >  > * PAM authenticator collects data and authenticate
>>     against PAM
>>     > > > >
>>     > > > > I am worried about how these 2 steps are expressed, it seem
>>     to imply PAM
>>     > > > > is used only as a username/password verifier.
>>     > > > > There is no mention/awarness of PAM conversations where we
>>     can prompt
>>     > > > > for things like second factors or password changes.
>>     > > > >
>>     > > >
>>     > > > Ok, I've spent maybe 20 seconds googling into what PAM
>>     conversations are
>>     > > > "PAM example conversation code".   You'll have to explain to
>>     me why PAM
>>     > > > conversations have any relevance to web login.  Just looking
>>     at this
>>     > > > example:
>>     > > >
>>     > > >
>>
>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
>>     > > >
>>     > > > It looks as if PAM conversations are targeted to simple text
>>     logins
>>     > > > (i.e. SSH, telnet, etc.).  Pushing and pulling text to and
>>     from stdin
>>     > > > and stdout.  What does that have to do with web login?
>>     > >
>>     > > Your question is totally fair. And the reason why we have to
>>     integrate
>>     > > with PAM is pretty much because there's no DBus interface for SSSD
>>     > > to provide username/password. Otherwise we would just communicate
>>     > > directly with DBus and call it a day.
>>     > >
>>     >
>>     > This is solely to allow keycloak to update passwords?  Not really
>>     > understanding here.
>>
>>     Not really Bill, to give you more context. Login through PAM is just
>> one
>>     of the scenarios described by Dmitri at slide #19[1].
>>
>>     * User starts browser and connects to a resource
>>     * Resource redirects to Keycloak
>>     * User is presented with a login form
>>     * User fills username and password
>>     * User data is collected and passed to SSSD over D-Bus
>>
>>     Here, we can't provide username/password to SSSD, because we don't
>> have
>>     a DBus interface for it. So instead, we make use of PAM to make it
>>     happen.
>>
>>
>> Isn't the flow actually:
>>
>> * User starts browser and connects to a resource
>> * Resource redirects to Keycloak
>> * User is presented with a login form
>> * User fills username and password
>> * Username and password is verified through PAM (in the future SSSD once
>> that becomes available) - this should be a custom authenticator
>> * User profile is retrieved from SSSD over D-Bus - this should be a
>> custom user federation provider
>> * Done
>>
>
> Yes, this is a good summary Stian and clearly articulates the immediate
> first implementation.
>
> I think the only additional thing is sometime down the road it might not
> just be one login form, you might be prompted for additional information.
> But that is *not* part of the requirements for the first implementation as
> I understand it. Just don't box yourself into a corner by prohibiting it
> down the road.
>

We can support authentication over multiple steps as we already do that for
OTP. However, the problem will be with regards to the conversation as this
would require sticky sessions if clustered to make sure the second step is
sent to the same node. Can't PAM verify the two independently? First
password, then separately OTP? That would make it much simpler and
stateless.


>
>
>>
>>     * SSSD authenticates against AD
>>     * Authentication complete (against FreeIPA)
>>
>>     This is where I need some help to define what would be the best next
>>     step for us.
>>
>>     * Assertion/token is issued
>>     * User is redirected to the resource
>>
>>     In this scenario nothing is stored/updated on Keycloak.
>>
>>     >
>>     > > The goal is pretty much to be used for Basic Authentication.
>>     > >
>>     > > >
>>     > > > As for PAM itself, it looks like it is a library.  (again a 20
>> second
>>     > >
>>     > > It's pretty much a low level authentication module to support
>> multiple
>>     > > schemes like: login, ftp, ssh, telnet...(you certainly found it
>> already)
>>     > >
>>     > > > Google search).  What I don't know is where PAM ends and SSSD
>> takes
>>     > > > over.  So its hard to give you advice.
>>     > >
>>     > > This is how it happens from my understanding:
>>     > >
>>     > > 1. We start the PAM conversation from our client application (a
>> IPA client machine),
>>     > > pam_sss is contacted (SSSD)
>>     > > 2. SSSD's PAM responder receives the authentication request and
>> forwards
>>     > > it to FreeIPA server
>>     > > 3. FreeIPA server process the request and returns the result back
>> to PAM
>>     > > responder.
>>     > >
>>     > > The data flow is better described here (
>> https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder
>> ).
>>     > >
>>     >
>>     > It looks like a conversation requires some sort of session object
>> or session
>>     > connection.  Remember, a web login can span multiple requests and
>> could
>>     > possibly be serviced on different machines.  Sounds like any
>> integration
>>     > with PAM is going to be quite limited.  Maybe that's what you are
>> getting
>>     > at?
>>
>>     I fully understand that, certainly something that requires more
>> testing
>>     to see how SSSD will behave with PAM.
>>
>>     >
>>     > Or are you just talking about writing a client adapter and this has
>> nothing
>>     > to do with the Keycloak auth server?
>>
>>     Good question. My initial naive idea was to have an authenticator SPI
>>     for PAM and benefit from the work already done by Marek with LDAP and
>>     Kerberos. Plus, have a federation SPI to retrieve user's data from
>> SSSD
>>     and propagate it to Keycloak.
>>
>>     >
>>     > Also, where does the identity data come into play (aka LDAP info)?
>> Is this
>>     > also a part of the PAM/SSSD flow?
>>
>>     At the flow described here#17[2]:
>>
>>     * User starts browser and connects to a resource
>>     * Resource redirects to Keycloak
>>     * User is presented with a login form
>>     * User fills username and password
>>     * User data is collected and passed to SSSD over D-Bus
>>     * SSSD authenticates against LDAP server
>>     * Authentication complete
>>     * Assertion/token is issued
>>     * User is redirected to the resource
>>
>>     >
>>     > Bill
>>
>>     [1] -
>>
>> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
>>     [2] -
>>
>> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
>>     --
>>
>>     abstractj
>>     PGP: 0x84DC9914
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
> --
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/3d873693/attachment-0001.html 

From bruno at abstractj.org  Fri Jun 24 10:08:31 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Jun 2016 11:08:31 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
Message-ID: <20160624140831.GA4026@abstractj.org>

On 2016-06-24, Stian Thorgersen wrote:
> On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > On 2016-06-23, Bill Burke wrote:
> > >
> > >
> > > On 6/23/16 2:56 PM, Bruno Oliveira wrote:
> > > > On 2016-06-23, Bill Burke wrote:
> > > > >
> > > > >
> > > > > On 6/23/16 12:25 PM, John Dennis wrote:
> > > > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> > > > > > > Good morning,
> > > > > > >
> > > > > > > One of the use case scenarios described for FreeIPA, is the
> > integration via PAM
> > > > > > > and SSSD, which "automagically" handles the authentication
> > against the IdM.
> > > > > > >
> > > > > > > This first step requires pretty much an IPA setup, but
> > > > > > > works with libpam4j[1]. Now, thinking about Keycloak, I
> > > > > > > would like to have an Authenticator for PAM[2], which is pretty
> > much our
> > > > > > > UsernamePasswordForm + PAM. Does it make sense?
> > > > > > >
> > > > > > > Current flow:
> > > > > > >
> > > > > > > * User logs into Web application with username/password
> > > > > > > * PAM authenticator collects data and authenticate against PAM
> > > > > > > * SSSD authenticates against IdM
> > > > > > > * Authentication is complete
> > > > > > >
> > > > > > > After the last step, should we propagate that user to our
> > database?
> > > > > > > Maybe, like Marek already mentioned, have a
> > SSSDFederationProvider?
> > > > > > >
> > > > > > > [1] -
> > > > > > >
> > http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> > > > > > > [2] -
> > https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
> > > > > >
> > > > > > Simo brought up a concern after forwarding this to our internal
> > identity
> > > > > > team list. His comment is:
> > > > > >
> > > > > >  >
> > > > > >  > Current flow:
> > > > > >  >
> > > > > >  > * User logs into Web application with username/password
> > > > > >  > * PAM authenticator collects data and authenticate against PAM
> > > > > >
> > > > > > I am worried about how these 2 steps are expressed, it seem to
> > imply PAM
> > > > > > is used only as a username/password verifier.
> > > > > > There is no mention/awarness of PAM conversations where we can
> > prompt
> > > > > > for things like second factors or password changes.
> > > > > >
> > > > >
> > > > > Ok, I've spent maybe 20 seconds googling into what PAM conversations
> > are
> > > > > "PAM example conversation code".   You'll have to explain to me why
> > PAM
> > > > > conversations have any relevance to web login.  Just looking at this
> > > > > example:
> > > > >
> > > > >
> > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
> > > > >
> > > > > It looks as if PAM conversations are targeted to simple text logins
> > > > > (i.e. SSH, telnet, etc.).  Pushing and pulling text to and from stdin
> > > > > and stdout.  What does that have to do with web login?
> > > >
> > > > Your question is totally fair. And the reason why we have to integrate
> > > > with PAM is pretty much because there's no DBus interface for SSSD
> > > > to provide username/password. Otherwise we would just communicate
> > > > directly with DBus and call it a day.
> > > >
> > >
> > > This is solely to allow keycloak to update passwords?  Not really
> > > understanding here.
> >
> > Not really Bill, to give you more context. Login through PAM is just one
> > of the scenarios described by Dmitri at slide #19[1].
> >
> > * User starts browser and connects to a resource
> > * Resource redirects to Keycloak
> > * User is presented with a login form
> > * User fills username and password
> > * User data is collected and passed to SSSD over D-Bus
> >
> > Here, we can't provide username/password to SSSD, because we don't have
> > a DBus interface for it. So instead, we make use of PAM to make it happen.
> >
>
> Isn't the flow actually:
>
> * User starts browser and connects to a resource
> * Resource redirects to Keycloak
> * User is presented with a login form
> * User fills username and password
> * Username and password is verified through PAM (in the future SSSD once
> that becomes available) - this should be a custom authenticator
> * User profile is retrieved from SSSD over D-Bus - this should be a custom
> user federation provider

That's correct, I just quoted the original slides for reference
and added the notes (maybe was more confuse than helpful).

After the retrieval of user's profile from SSSD. Should the data be propagated
to Keycloak database? Should we validate such credentials on the next
login?

> * Done
>
>
> >
> > * SSSD authenticates against AD
> > * Authentication complete (against FreeIPA)
> >
> > This is where I need some help to define what would be the best next
> > step for us.
> >
> > * Assertion/token is issued
> > * User is redirected to the resource
> >
> > In this scenario nothing is stored/updated on Keycloak.
> >
> > >
> > > > The goal is pretty much to be used for Basic Authentication.
> > > >
> > > > >
> > > > > As for PAM itself, it looks like it is a library.  (again a 20 second
> > > >
> > > > It's pretty much a low level authentication module to support multiple
> > > > schemes like: login, ftp, ssh, telnet...(you certainly found it
> > already)
> > > >
> > > > > Google search).  What I don't know is where PAM ends and SSSD takes
> > > > > over.  So its hard to give you advice.
> > > >
> > > > This is how it happens from my understanding:
> > > >
> > > > 1. We start the PAM conversation from our client application (a IPA
> > client machine),
> > > > pam_sss is contacted (SSSD)
> > > > 2. SSSD's PAM responder receives the authentication request and
> > forwards
> > > > it to FreeIPA server
> > > > 3. FreeIPA server process the request and returns the result back to
> > PAM
> > > > responder.
> > > >
> > > > The data flow is better described here (
> > https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder
> > ).
> > > >
> > >
> > > It looks like a conversation requires some sort of session object or
> > session
> > > connection.  Remember, a web login can span multiple requests and could
> > > possibly be serviced on different machines.  Sounds like any integration
> > > with PAM is going to be quite limited.  Maybe that's what you are getting
> > > at?
> >
> > I fully understand that, certainly something that requires more testing
> > to see how SSSD will behave with PAM.
> >
> > >
> > > Or are you just talking about writing a client adapter and this has
> > nothing
> > > to do with the Keycloak auth server?
> >
> > Good question. My initial naive idea was to have an authenticator SPI
> > for PAM and benefit from the work already done by Marek with LDAP and
> > Kerberos. Plus, have a federation SPI to retrieve user's data from SSSD
> > and propagate it to Keycloak.
> >
> > >
> > > Also, where does the identity data come into play (aka LDAP info)?  Is
> > this
> > > also a part of the PAM/SSSD flow?
> >
> > At the flow described here#17[2]:
> >
> > * User starts browser and connects to a resource
> > * Resource redirects to Keycloak
> > * User is presented with a login form
> > * User fills username and password
> > * User data is collected and passed to SSSD over D-Bus
> > * SSSD authenticates against LDAP server
> > * Authentication complete
> > * Assertion/token is issued
> > * User is redirected to the resource
> >
> > >
> > > Bill
> >
> > [1] -
> > https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
> > [2] -
> > https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >

--

abstractj
PGP: 0x84DC9914

From sthorger at redhat.com  Fri Jun 24 10:08:32 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jun 2016 16:08:32 +0200
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <CAJgngAcDJSOW-0Fnms59xezrqS+3zzdXCh0MJGZ-gvy8CDdVdA@mail.gmail.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
	<db095d87-3aac-1242-ea04-b17dd95f23dc@redhat.com>
	<CAJgngAcDJSOW-0Fnms59xezrqS+3zzdXCh0MJGZ-gvy8CDdVdA@mail.gmail.com>
Message-ID: <CAJgngAeGiTH08=tMj+t1ZvWac0i9FBFoQbPCZO--hjCsQqw_yA@mail.gmail.com>

Just to check - PAM can have multiple ongoing conversations on the same box
right?

On 24 June 2016 at 16:02, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On 24 June 2016 at 16:00, John Dennis <jdennis at redhat.com> wrote:
>
>> On 06/24/2016 09:52 AM, Stian Thorgersen wrote:
>>
>>>
>>>
>>> On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org
>>> <mailto:bruno at abstractj.org>> wrote:
>>>
>>>     On 2016-06-23, Bill Burke wrote:
>>>     >
>>>     >
>>>     > On 6/23/16 2:56 PM, Bruno Oliveira wrote:
>>>     > > On 2016-06-23, Bill Burke wrote:
>>>     > > >
>>>     > > >
>>>     > > > On 6/23/16 12:25 PM, John Dennis wrote:
>>>     > > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
>>>     > > > > > Good morning,
>>>     > > > > >
>>>     > > > > > One of the use case scenarios described for FreeIPA, is
>>>     the integration via PAM
>>>     > > > > > and SSSD, which "automagically" handles the authentication
>>>     against the IdM.
>>>     > > > > >
>>>     > > > > > This first step requires pretty much an IPA setup, but
>>>     > > > > > works with libpam4j[1]. Now, thinking about Keycloak, I
>>>     > > > > > would like to have an Authenticator for PAM[2], which is
>>>     pretty much our
>>>     > > > > > UsernamePasswordForm + PAM. Does it make sense?
>>>     > > > > >
>>>     > > > > > Current flow:
>>>     > > > > >
>>>     > > > > > * User logs into Web application with username/password
>>>     > > > > > * PAM authenticator collects data and authenticate against
>>> PAM
>>>     > > > > > * SSSD authenticates against IdM
>>>     > > > > > * Authentication is complete
>>>     > > > > >
>>>     > > > > > After the last step, should we propagate that user to our
>>>     database?
>>>     > > > > > Maybe, like Marek already mentioned, have a
>>>     SSSDFederationProvider?
>>>     > > > > >
>>>     > > > > > [1] -
>>>     > > > > >
>>>
>>> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
>>>     > > > > > [2] -
>>>
>>> https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
>>>     > > > >
>>>     > > > > Simo brought up a concern after forwarding this to our
>>>     internal identity
>>>     > > > > team list. His comment is:
>>>     > > > >
>>>     > > > >  >
>>>     > > > >  > Current flow:
>>>     > > > >  >
>>>     > > > >  > * User logs into Web application with username/password
>>>     > > > >  > * PAM authenticator collects data and authenticate
>>>     against PAM
>>>     > > > >
>>>     > > > > I am worried about how these 2 steps are expressed, it seem
>>>     to imply PAM
>>>     > > > > is used only as a username/password verifier.
>>>     > > > > There is no mention/awarness of PAM conversations where we
>>>     can prompt
>>>     > > > > for things like second factors or password changes.
>>>     > > > >
>>>     > > >
>>>     > > > Ok, I've spent maybe 20 seconds googling into what PAM
>>>     conversations are
>>>     > > > "PAM example conversation code".   You'll have to explain to
>>>     me why PAM
>>>     > > > conversations have any relevance to web login.  Just looking
>>>     at this
>>>     > > > example:
>>>     > > >
>>>     > > >
>>>
>>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
>>>     > > >
>>>     > > > It looks as if PAM conversations are targeted to simple text
>>>     logins
>>>     > > > (i.e. SSH, telnet, etc.).  Pushing and pulling text to and
>>>     from stdin
>>>     > > > and stdout.  What does that have to do with web login?
>>>     > >
>>>     > > Your question is totally fair. And the reason why we have to
>>>     integrate
>>>     > > with PAM is pretty much because there's no DBus interface for
>>> SSSD
>>>     > > to provide username/password. Otherwise we would just communicate
>>>     > > directly with DBus and call it a day.
>>>     > >
>>>     >
>>>     > This is solely to allow keycloak to update passwords?  Not really
>>>     > understanding here.
>>>
>>>     Not really Bill, to give you more context. Login through PAM is just
>>> one
>>>     of the scenarios described by Dmitri at slide #19[1].
>>>
>>>     * User starts browser and connects to a resource
>>>     * Resource redirects to Keycloak
>>>     * User is presented with a login form
>>>     * User fills username and password
>>>     * User data is collected and passed to SSSD over D-Bus
>>>
>>>     Here, we can't provide username/password to SSSD, because we don't
>>> have
>>>     a DBus interface for it. So instead, we make use of PAM to make it
>>>     happen.
>>>
>>>
>>> Isn't the flow actually:
>>>
>>> * User starts browser and connects to a resource
>>> * Resource redirects to Keycloak
>>> * User is presented with a login form
>>> * User fills username and password
>>> * Username and password is verified through PAM (in the future SSSD once
>>> that becomes available) - this should be a custom authenticator
>>> * User profile is retrieved from SSSD over D-Bus - this should be a
>>> custom user federation provider
>>> * Done
>>>
>>
>> Yes, this is a good summary Stian and clearly articulates the immediate
>> first implementation.
>>
>> I think the only additional thing is sometime down the road it might not
>> just be one login form, you might be prompted for additional information.
>> But that is *not* part of the requirements for the first implementation as
>> I understand it. Just don't box yourself into a corner by prohibiting it
>> down the road.
>>
>
> We can support authentication over multiple steps as we already do that
> for OTP. However, the problem will be with regards to the conversation as
> this would require sticky sessions if clustered to make sure the second
> step is sent to the same node. Can't PAM verify the two independently?
> First password, then separately OTP? That would make it much simpler and
> stateless.
>
>
>>
>>
>>>
>>>     * SSSD authenticates against AD
>>>     * Authentication complete (against FreeIPA)
>>>
>>>     This is where I need some help to define what would be the best next
>>>     step for us.
>>>
>>>     * Assertion/token is issued
>>>     * User is redirected to the resource
>>>
>>>     In this scenario nothing is stored/updated on Keycloak.
>>>
>>>     >
>>>     > > The goal is pretty much to be used for Basic Authentication.
>>>     > >
>>>     > > >
>>>     > > > As for PAM itself, it looks like it is a library.  (again a 20
>>> second
>>>     > >
>>>     > > It's pretty much a low level authentication module to support
>>> multiple
>>>     > > schemes like: login, ftp, ssh, telnet...(you certainly found it
>>> already)
>>>     > >
>>>     > > > Google search).  What I don't know is where PAM ends and SSSD
>>> takes
>>>     > > > over.  So its hard to give you advice.
>>>     > >
>>>     > > This is how it happens from my understanding:
>>>     > >
>>>     > > 1. We start the PAM conversation from our client application (a
>>> IPA client machine),
>>>     > > pam_sss is contacted (SSSD)
>>>     > > 2. SSSD's PAM responder receives the authentication request and
>>> forwards
>>>     > > it to FreeIPA server
>>>     > > 3. FreeIPA server process the request and returns the result
>>> back to PAM
>>>     > > responder.
>>>     > >
>>>     > > The data flow is better described here (
>>> https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder
>>> ).
>>>     > >
>>>     >
>>>     > It looks like a conversation requires some sort of session object
>>> or session
>>>     > connection.  Remember, a web login can span multiple requests and
>>> could
>>>     > possibly be serviced on different machines.  Sounds like any
>>> integration
>>>     > with PAM is going to be quite limited.  Maybe that's what you are
>>> getting
>>>     > at?
>>>
>>>     I fully understand that, certainly something that requires more
>>> testing
>>>     to see how SSSD will behave with PAM.
>>>
>>>     >
>>>     > Or are you just talking about writing a client adapter and this
>>> has nothing
>>>     > to do with the Keycloak auth server?
>>>
>>>     Good question. My initial naive idea was to have an authenticator SPI
>>>     for PAM and benefit from the work already done by Marek with LDAP and
>>>     Kerberos. Plus, have a federation SPI to retrieve user's data from
>>> SSSD
>>>     and propagate it to Keycloak.
>>>
>>>     >
>>>     > Also, where does the identity data come into play (aka LDAP
>>> info)?  Is this
>>>     > also a part of the PAM/SSSD flow?
>>>
>>>     At the flow described here#17[2]:
>>>
>>>     * User starts browser and connects to a resource
>>>     * Resource redirects to Keycloak
>>>     * User is presented with a login form
>>>     * User fills username and password
>>>     * User data is collected and passed to SSSD over D-Bus
>>>     * SSSD authenticates against LDAP server
>>>     * Authentication complete
>>>     * Assertion/token is issued
>>>     * User is redirected to the resource
>>>
>>>     >
>>>     > Bill
>>>
>>>     [1] -
>>>
>>> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
>>>     [2] -
>>>
>>> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
>>>     --
>>>
>>>     abstractj
>>>     PGP: 0x84DC9914
>>>     _______________________________________________
>>>     keycloak-dev mailing list
>>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>> --
>> John
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/274f7d63/attachment-0001.html 

From sthorger at redhat.com  Fri Jun 24 10:10:59 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 24 Jun 2016 16:10:59 +0200
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <20160624140831.GA4026@abstractj.org>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
	<20160624140831.GA4026@abstractj.org>
Message-ID: <CAJgngAdpiM92+xRXz9DHyNC5k1cLGuAfiCU7oZu6CiijPz1VQg@mail.gmail.com>

On 24 June 2016 at 16:08, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2016-06-24, Stian Thorgersen wrote:
> > On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org> wrote:
> >
> > > On 2016-06-23, Bill Burke wrote:
> > > >
> > > >
> > > > On 6/23/16 2:56 PM, Bruno Oliveira wrote:
> > > > > On 2016-06-23, Bill Burke wrote:
> > > > > >
> > > > > >
> > > > > > On 6/23/16 12:25 PM, John Dennis wrote:
> > > > > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> > > > > > > > Good morning,
> > > > > > > >
> > > > > > > > One of the use case scenarios described for FreeIPA, is the
> > > integration via PAM
> > > > > > > > and SSSD, which "automagically" handles the authentication
> > > against the IdM.
> > > > > > > >
> > > > > > > > This first step requires pretty much an IPA setup, but
> > > > > > > > works with libpam4j[1]. Now, thinking about Keycloak, I
> > > > > > > > would like to have an Authenticator for PAM[2], which is
> pretty
> > > much our
> > > > > > > > UsernamePasswordForm + PAM. Does it make sense?
> > > > > > > >
> > > > > > > > Current flow:
> > > > > > > >
> > > > > > > > * User logs into Web application with username/password
> > > > > > > > * PAM authenticator collects data and authenticate against
> PAM
> > > > > > > > * SSSD authenticates against IdM
> > > > > > > > * Authentication is complete
> > > > > > > >
> > > > > > > > After the last step, should we propagate that user to our
> > > database?
> > > > > > > > Maybe, like Marek already mentioned, have a
> > > SSSDFederationProvider?
> > > > > > > >
> > > > > > > > [1] -
> > > > > > > >
> > >
> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> > > > > > > > [2] -
> > >
> https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
> > > > > > >
> > > > > > > Simo brought up a concern after forwarding this to our internal
> > > identity
> > > > > > > team list. His comment is:
> > > > > > >
> > > > > > >  >
> > > > > > >  > Current flow:
> > > > > > >  >
> > > > > > >  > * User logs into Web application with username/password
> > > > > > >  > * PAM authenticator collects data and authenticate against
> PAM
> > > > > > >
> > > > > > > I am worried about how these 2 steps are expressed, it seem to
> > > imply PAM
> > > > > > > is used only as a username/password verifier.
> > > > > > > There is no mention/awarness of PAM conversations where we can
> > > prompt
> > > > > > > for things like second factors or password changes.
> > > > > > >
> > > > > >
> > > > > > Ok, I've spent maybe 20 seconds googling into what PAM
> conversations
> > > are
> > > > > > "PAM example conversation code".   You'll have to explain to me
> why
> > > PAM
> > > > > > conversations have any relevance to web login.  Just looking at
> this
> > > > > > example:
> > > > > >
> > > > > >
> > >
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
> > > > > >
> > > > > > It looks as if PAM conversations are targeted to simple text
> logins
> > > > > > (i.e. SSH, telnet, etc.).  Pushing and pulling text to and from
> stdin
> > > > > > and stdout.  What does that have to do with web login?
> > > > >
> > > > > Your question is totally fair. And the reason why we have to
> integrate
> > > > > with PAM is pretty much because there's no DBus interface for SSSD
> > > > > to provide username/password. Otherwise we would just communicate
> > > > > directly with DBus and call it a day.
> > > > >
> > > >
> > > > This is solely to allow keycloak to update passwords?  Not really
> > > > understanding here.
> > >
> > > Not really Bill, to give you more context. Login through PAM is just
> one
> > > of the scenarios described by Dmitri at slide #19[1].
> > >
> > > * User starts browser and connects to a resource
> > > * Resource redirects to Keycloak
> > > * User is presented with a login form
> > > * User fills username and password
> > > * User data is collected and passed to SSSD over D-Bus
> > >
> > > Here, we can't provide username/password to SSSD, because we don't have
> > > a DBus interface for it. So instead, we make use of PAM to make it
> happen.
> > >
> >
> > Isn't the flow actually:
> >
> > * User starts browser and connects to a resource
> > * Resource redirects to Keycloak
> > * User is presented with a login form
> > * User fills username and password
> > * Username and password is verified through PAM (in the future SSSD once
> > that becomes available) - this should be a custom authenticator
> > * User profile is retrieved from SSSD over D-Bus - this should be a
> custom
> > user federation provider
>
> That's correct, I just quoted the original slides for reference
> and added the notes (maybe was more confuse than helpful).
>
> After the retrieval of user's profile from SSSD. Should the data be
> propagated
> to Keycloak database? Should we validate such credentials on the next
> login?
>

The user profile would currently be imported into Keycloak database as
that's how user federation currently works. Bill is working on changing
that though so user profile would not be imported in the future.

Not sure what you mean about validate such credentials - username/password
would always be verified against PAM


>
> > * Done
> >
> >
> > >
> > > * SSSD authenticates against AD
> > > * Authentication complete (against FreeIPA)
> > >
> > > This is where I need some help to define what would be the best next
> > > step for us.
> > >
> > > * Assertion/token is issued
> > > * User is redirected to the resource
> > >
> > > In this scenario nothing is stored/updated on Keycloak.
> > >
> > > >
> > > > > The goal is pretty much to be used for Basic Authentication.
> > > > >
> > > > > >
> > > > > > As for PAM itself, it looks like it is a library.  (again a 20
> second
> > > > >
> > > > > It's pretty much a low level authentication module to support
> multiple
> > > > > schemes like: login, ftp, ssh, telnet...(you certainly found it
> > > already)
> > > > >
> > > > > > Google search).  What I don't know is where PAM ends and SSSD
> takes
> > > > > > over.  So its hard to give you advice.
> > > > >
> > > > > This is how it happens from my understanding:
> > > > >
> > > > > 1. We start the PAM conversation from our client application (a IPA
> > > client machine),
> > > > > pam_sss is contacted (SSSD)
> > > > > 2. SSSD's PAM responder receives the authentication request and
> > > forwards
> > > > > it to FreeIPA server
> > > > > 3. FreeIPA server process the request and returns the result back
> to
> > > PAM
> > > > > responder.
> > > > >
> > > > > The data flow is better described here (
> > >
> https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder
> > > ).
> > > > >
> > > >
> > > > It looks like a conversation requires some sort of session object or
> > > session
> > > > connection.  Remember, a web login can span multiple requests and
> could
> > > > possibly be serviced on different machines.  Sounds like any
> integration
> > > > with PAM is going to be quite limited.  Maybe that's what you are
> getting
> > > > at?
> > >
> > > I fully understand that, certainly something that requires more testing
> > > to see how SSSD will behave with PAM.
> > >
> > > >
> > > > Or are you just talking about writing a client adapter and this has
> > > nothing
> > > > to do with the Keycloak auth server?
> > >
> > > Good question. My initial naive idea was to have an authenticator SPI
> > > for PAM and benefit from the work already done by Marek with LDAP and
> > > Kerberos. Plus, have a federation SPI to retrieve user's data from SSSD
> > > and propagate it to Keycloak.
> > >
> > > >
> > > > Also, where does the identity data come into play (aka LDAP info)?
> Is
> > > this
> > > > also a part of the PAM/SSSD flow?
> > >
> > > At the flow described here#17[2]:
> > >
> > > * User starts browser and connects to a resource
> > > * Resource redirects to Keycloak
> > > * User is presented with a login form
> > > * User fills username and password
> > > * User data is collected and passed to SSSD over D-Bus
> > > * SSSD authenticates against LDAP server
> > > * Authentication complete
> > > * Assertion/token is issued
> > > * User is redirected to the resource
> > >
> > > >
> > > > Bill
> > >
> > > [1] -
> > >
> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
> > > [2] -
> > >
> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
> > > --
> > >
> > > abstractj
> > > PGP: 0x84DC9914
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
>
> --
>
> abstractj
> PGP: 0x84DC9914
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/95077609/attachment.html 

From singhrasster at gmail.com  Fri Jun 24 10:15:17 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Fri, 24 Jun 2016 09:15:17 -0500
Subject: [keycloak-dev] How to set configs for RequiredAction in
	keycloak-server.json file
In-Reply-To: <CAJ0vL+KbePejXWfXZq3MVh95rMwwrEk=VbpKumCyjQ5w1vCasA@mail.gmail.com>
References: <CAJ0vL+K51LQX6wBh6UC10q2Z6+BEWMSwgKj9niCq4zUJxq6NqA@mail.gmail.com>
	<CAJ0vL+KbePejXWfXZq3MVh95rMwwrEk=VbpKumCyjQ5w1vCasA@mail.gmail.com>
Message-ID: <CAJ0vL+Jyj7SAUCWikF2UM6q1XZZX1EzHqMt17qU-qVLvVPnJiA@mail.gmail.com>

Would this type of format work?

"requiredAction": {
  "test-required-action": {
    "config1": "xxxx"
  }
}

If yes, not sure what should be the name instead of "requiredAction" above
though



On Fri, Jun 24, 2016 at 9:01 AM, Rashmi Singh <singhrasster at gmail.com>
wrote:

> Any clue for this?
>
> On Thu, Jun 23, 2016 at 10:40 PM, Rashmi Singh <singhrasster at gmail.com>
> wrote:
>
>> In keycloak-server.json, if we add the following
>>
>> "authenticator": {
>>   "test-authenticator": {
>>     "config1": "xxxx"
>>   }
>> }
>>
>> the value of config1 can be retrieved in the factory class init method as:
>>
>> config.get("config1")
>>
>>
>> Now, in the same way, if I want to get configs in the init method of a
>> RequiredAction class instead of an authenticator, how do I set it in
>> keyclock-server.json? What will be the exact syntax? Is it possible?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/01889a34/attachment-0001.html 

From bruno at abstractj.org  Fri Jun 24 10:30:14 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Jun 2016 11:30:14 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <CAJgngAeGiTH08=tMj+t1ZvWac0i9FBFoQbPCZO--hjCsQqw_yA@mail.gmail.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
	<db095d87-3aac-1242-ea04-b17dd95f23dc@redhat.com>
	<CAJgngAcDJSOW-0Fnms59xezrqS+3zzdXCh0MJGZ-gvy8CDdVdA@mail.gmail.com>
	<CAJgngAeGiTH08=tMj+t1ZvWac0i9FBFoQbPCZO--hjCsQqw_yA@mail.gmail.com>
Message-ID: <20160624143014.GC4026@abstractj.org>

On 2016-06-24, Stian Thorgersen wrote:
> Just to check - PAM can have multiple ongoing conversations on the same box
> right?

That's correct.

>
> On 24 June 2016 at 16:02, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> >
> >
> > On 24 June 2016 at 16:00, John Dennis <jdennis at redhat.com> wrote:
> >
> >> On 06/24/2016 09:52 AM, Stian Thorgersen wrote:
> >>
> >>>
> >>>
> >>> On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org
> >>> <mailto:bruno at abstractj.org>> wrote:
> >>>
> >>>     On 2016-06-23, Bill Burke wrote:
> >>>     >
> >>>     >
> >>>     > On 6/23/16 2:56 PM, Bruno Oliveira wrote:
> >>>     > > On 2016-06-23, Bill Burke wrote:
> >>>     > > >
> >>>     > > >
> >>>     > > > On 6/23/16 12:25 PM, John Dennis wrote:
> >>>     > > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> >>>     > > > > > Good morning,
> >>>     > > > > >
> >>>     > > > > > One of the use case scenarios described for FreeIPA, is
> >>>     the integration via PAM
> >>>     > > > > > and SSSD, which "automagically" handles the authentication
> >>>     against the IdM.
> >>>     > > > > >
> >>>     > > > > > This first step requires pretty much an IPA setup, but
> >>>     > > > > > works with libpam4j[1]. Now, thinking about Keycloak, I
> >>>     > > > > > would like to have an Authenticator for PAM[2], which is
> >>>     pretty much our
> >>>     > > > > > UsernamePasswordForm + PAM. Does it make sense?
> >>>     > > > > >
> >>>     > > > > > Current flow:
> >>>     > > > > >
> >>>     > > > > > * User logs into Web application with username/password
> >>>     > > > > > * PAM authenticator collects data and authenticate against
> >>> PAM
> >>>     > > > > > * SSSD authenticates against IdM
> >>>     > > > > > * Authentication is complete
> >>>     > > > > >
> >>>     > > > > > After the last step, should we propagate that user to our
> >>>     database?
> >>>     > > > > > Maybe, like Marek already mentioned, have a
> >>>     SSSDFederationProvider?
> >>>     > > > > >
> >>>     > > > > > [1] -
> >>>     > > > > >
> >>>
> >>> http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> >>>     > > > > > [2] -
> >>>
> >>> https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
> >>>     > > > >
> >>>     > > > > Simo brought up a concern after forwarding this to our
> >>>     internal identity
> >>>     > > > > team list. His comment is:
> >>>     > > > >
> >>>     > > > >  >
> >>>     > > > >  > Current flow:
> >>>     > > > >  >
> >>>     > > > >  > * User logs into Web application with username/password
> >>>     > > > >  > * PAM authenticator collects data and authenticate
> >>>     against PAM
> >>>     > > > >
> >>>     > > > > I am worried about how these 2 steps are expressed, it seem
> >>>     to imply PAM
> >>>     > > > > is used only as a username/password verifier.
> >>>     > > > > There is no mention/awarness of PAM conversations where we
> >>>     can prompt
> >>>     > > > > for things like second factors or password changes.
> >>>     > > > >
> >>>     > > >
> >>>     > > > Ok, I've spent maybe 20 seconds googling into what PAM
> >>>     conversations are
> >>>     > > > "PAM example conversation code".   You'll have to explain to
> >>>     me why PAM
> >>>     > > > conversations have any relevance to web login.  Just looking
> >>>     at this
> >>>     > > > example:
> >>>     > > >
> >>>     > > >
> >>>
> >>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
> >>>     > > >
> >>>     > > > It looks as if PAM conversations are targeted to simple text
> >>>     logins
> >>>     > > > (i.e. SSH, telnet, etc.).  Pushing and pulling text to and
> >>>     from stdin
> >>>     > > > and stdout.  What does that have to do with web login?
> >>>     > >
> >>>     > > Your question is totally fair. And the reason why we have to
> >>>     integrate
> >>>     > > with PAM is pretty much because there's no DBus interface for
> >>> SSSD
> >>>     > > to provide username/password. Otherwise we would just communicate
> >>>     > > directly with DBus and call it a day.
> >>>     > >
> >>>     >
> >>>     > This is solely to allow keycloak to update passwords?  Not really
> >>>     > understanding here.
> >>>
> >>>     Not really Bill, to give you more context. Login through PAM is just
> >>> one
> >>>     of the scenarios described by Dmitri at slide #19[1].
> >>>
> >>>     * User starts browser and connects to a resource
> >>>     * Resource redirects to Keycloak
> >>>     * User is presented with a login form
> >>>     * User fills username and password
> >>>     * User data is collected and passed to SSSD over D-Bus
> >>>
> >>>     Here, we can't provide username/password to SSSD, because we don't
> >>> have
> >>>     a DBus interface for it. So instead, we make use of PAM to make it
> >>>     happen.
> >>>
> >>>
> >>> Isn't the flow actually:
> >>>
> >>> * User starts browser and connects to a resource
> >>> * Resource redirects to Keycloak
> >>> * User is presented with a login form
> >>> * User fills username and password
> >>> * Username and password is verified through PAM (in the future SSSD once
> >>> that becomes available) - this should be a custom authenticator
> >>> * User profile is retrieved from SSSD over D-Bus - this should be a
> >>> custom user federation provider
> >>> * Done
> >>>
> >>
> >> Yes, this is a good summary Stian and clearly articulates the immediate
> >> first implementation.
> >>
> >> I think the only additional thing is sometime down the road it might not
> >> just be one login form, you might be prompted for additional information.
> >> But that is *not* part of the requirements for the first implementation as
> >> I understand it. Just don't box yourself into a corner by prohibiting it
> >> down the road.
> >>
> >
> > We can support authentication over multiple steps as we already do that
> > for OTP. However, the problem will be with regards to the conversation as
> > this would require sticky sessions if clustered to make sure the second
> > step is sent to the same node. Can't PAM verify the two independently?
> > First password, then separately OTP? That would make it much simpler and
> > stateless.
> >
> >
> >>
> >>
> >>>
> >>>     * SSSD authenticates against AD
> >>>     * Authentication complete (against FreeIPA)
> >>>
> >>>     This is where I need some help to define what would be the best next
> >>>     step for us.
> >>>
> >>>     * Assertion/token is issued
> >>>     * User is redirected to the resource
> >>>
> >>>     In this scenario nothing is stored/updated on Keycloak.
> >>>
> >>>     >
> >>>     > > The goal is pretty much to be used for Basic Authentication.
> >>>     > >
> >>>     > > >
> >>>     > > > As for PAM itself, it looks like it is a library.  (again a 20
> >>> second
> >>>     > >
> >>>     > > It's pretty much a low level authentication module to support
> >>> multiple
> >>>     > > schemes like: login, ftp, ssh, telnet...(you certainly found it
> >>> already)
> >>>     > >
> >>>     > > > Google search).  What I don't know is where PAM ends and SSSD
> >>> takes
> >>>     > > > over.  So its hard to give you advice.
> >>>     > >
> >>>     > > This is how it happens from my understanding:
> >>>     > >
> >>>     > > 1. We start the PAM conversation from our client application (a
> >>> IPA client machine),
> >>>     > > pam_sss is contacted (SSSD)
> >>>     > > 2. SSSD's PAM responder receives the authentication request and
> >>> forwards
> >>>     > > it to FreeIPA server
> >>>     > > 3. FreeIPA server process the request and returns the result
> >>> back to PAM
> >>>     > > responder.
> >>>     > >
> >>>     > > The data flow is better described here (
> >>> https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder
> >>> ).
> >>>     > >
> >>>     >
> >>>     > It looks like a conversation requires some sort of session object
> >>> or session
> >>>     > connection.  Remember, a web login can span multiple requests and
> >>> could
> >>>     > possibly be serviced on different machines.  Sounds like any
> >>> integration
> >>>     > with PAM is going to be quite limited.  Maybe that's what you are
> >>> getting
> >>>     > at?
> >>>
> >>>     I fully understand that, certainly something that requires more
> >>> testing
> >>>     to see how SSSD will behave with PAM.
> >>>
> >>>     >
> >>>     > Or are you just talking about writing a client adapter and this
> >>> has nothing
> >>>     > to do with the Keycloak auth server?
> >>>
> >>>     Good question. My initial naive idea was to have an authenticator SPI
> >>>     for PAM and benefit from the work already done by Marek with LDAP and
> >>>     Kerberos. Plus, have a federation SPI to retrieve user's data from
> >>> SSSD
> >>>     and propagate it to Keycloak.
> >>>
> >>>     >
> >>>     > Also, where does the identity data come into play (aka LDAP
> >>> info)?  Is this
> >>>     > also a part of the PAM/SSSD flow?
> >>>
> >>>     At the flow described here#17[2]:
> >>>
> >>>     * User starts browser and connects to a resource
> >>>     * Resource redirects to Keycloak
> >>>     * User is presented with a login form
> >>>     * User fills username and password
> >>>     * User data is collected and passed to SSSD over D-Bus
> >>>     * SSSD authenticates against LDAP server
> >>>     * Authentication complete
> >>>     * Assertion/token is issued
> >>>     * User is redirected to the resource
> >>>
> >>>     >
> >>>     > Bill
> >>>
> >>>     [1] -
> >>>
> >>> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
> >>>     [2] -
> >>>
> >>> https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
> >>>     --
> >>>
> >>>     abstractj
> >>>     PGP: 0x84DC9914
> >>>     _______________________________________________
> >>>     keycloak-dev mailing list
> >>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>>
> >>
> >> --
> >> John
> >>
> >
> >

--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Fri Jun 24 10:36:43 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Jun 2016 11:36:43 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <CAJgngAdpiM92+xRXz9DHyNC5k1cLGuAfiCU7oZu6CiijPz1VQg@mail.gmail.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
	<20160624140831.GA4026@abstractj.org>
	<CAJgngAdpiM92+xRXz9DHyNC5k1cLGuAfiCU7oZu6CiijPz1VQg@mail.gmail.com>
Message-ID: <20160624143643.GD4026@abstractj.org>

On 2016-06-24, Stian Thorgersen wrote:
> On 24 June 2016 at 16:08, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > On 2016-06-24, Stian Thorgersen wrote:
> > > On 24 June 2016 at 15:07, Bruno Oliveira <bruno at abstractj.org> wrote:
> > >
> > > > On 2016-06-23, Bill Burke wrote:
> > > > >
> > > > >
> > > > > On 6/23/16 2:56 PM, Bruno Oliveira wrote:
> > > > > > On 2016-06-23, Bill Burke wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 6/23/16 12:25 PM, John Dennis wrote:
> > > > > > > > On 06/23/2016 10:00 AM, Bruno Oliveira wrote:
> > > > > > > > > Good morning,
> > > > > > > > >
> > > > > > > > > One of the use case scenarios described for FreeIPA, is the
> > > > integration via PAM
> > > > > > > > > and SSSD, which "automagically" handles the authentication
> > > > against the IdM.
> > > > > > > > >
> > > > > > > > > This first step requires pretty much an IPA setup, but
> > > > > > > > > works with libpam4j[1]. Now, thinking about Keycloak, I
> > > > > > > > > would like to have an Authenticator for PAM[2], which is
> > pretty
> > > > much our
> > > > > > > > > UsernamePasswordForm + PAM. Does it make sense?
> > > > > > > > >
> > > > > > > > > Current flow:
> > > > > > > > >
> > > > > > > > > * User logs into Web application with username/password
> > > > > > > > > * PAM authenticator collects data and authenticate against
> > PAM
> > > > > > > > > * SSSD authenticates against IdM
> > > > > > > > > * Authentication is complete
> > > > > > > > >
> > > > > > > > > After the last step, should we propagate that user to our
> > > > database?
> > > > > > > > > Maybe, like Marek already mentioned, have a
> > > > SSSDFederationProvider?
> > > > > > > > >
> > > > > > > > > [1] -
> > > > > > > > >
> > > >
> > http://search.maven.org/#artifactdetails%7Corg.abstractj%7Clibpam4j%7C1.9.0%7Cjar
> > > > > > > > > [2] -
> > > >
> > https://keycloak.gitbooks.io/server-developer-guide/content/topics/auth-spi.html
> > > > > > > >
> > > > > > > > Simo brought up a concern after forwarding this to our internal
> > > > identity
> > > > > > > > team list. His comment is:
> > > > > > > >
> > > > > > > >  >
> > > > > > > >  > Current flow:
> > > > > > > >  >
> > > > > > > >  > * User logs into Web application with username/password
> > > > > > > >  > * PAM authenticator collects data and authenticate against
> > PAM
> > > > > > > >
> > > > > > > > I am worried about how these 2 steps are expressed, it seem to
> > > > imply PAM
> > > > > > > > is used only as a username/password verifier.
> > > > > > > > There is no mention/awarness of PAM conversations where we can
> > > > prompt
> > > > > > > > for things like second factors or password changes.
> > > > > > > >
> > > > > > >
> > > > > > > Ok, I've spent maybe 20 seconds googling into what PAM
> > conversations
> > > > are
> > > > > > > "PAM example conversation code".   You'll have to explain to me
> > why
> > > > PAM
> > > > > > > conversations have any relevance to web login.  Just looking at
> > this
> > > > > > > example:
> > > > > > >
> > > > > > >
> > > >
> > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/pam-sample-conv.html
> > > > > > >
> > > > > > > It looks as if PAM conversations are targeted to simple text
> > logins
> > > > > > > (i.e. SSH, telnet, etc.).  Pushing and pulling text to and from
> > stdin
> > > > > > > and stdout.  What does that have to do with web login?
> > > > > >
> > > > > > Your question is totally fair. And the reason why we have to
> > integrate
> > > > > > with PAM is pretty much because there's no DBus interface for SSSD
> > > > > > to provide username/password. Otherwise we would just communicate
> > > > > > directly with DBus and call it a day.
> > > > > >
> > > > >
> > > > > This is solely to allow keycloak to update passwords?  Not really
> > > > > understanding here.
> > > >
> > > > Not really Bill, to give you more context. Login through PAM is just
> > one
> > > > of the scenarios described by Dmitri at slide #19[1].
> > > >
> > > > * User starts browser and connects to a resource
> > > > * Resource redirects to Keycloak
> > > > * User is presented with a login form
> > > > * User fills username and password
> > > > * User data is collected and passed to SSSD over D-Bus
> > > >
> > > > Here, we can't provide username/password to SSSD, because we don't have
> > > > a DBus interface for it. So instead, we make use of PAM to make it
> > happen.
> > > >
> > >
> > > Isn't the flow actually:
> > >
> > > * User starts browser and connects to a resource
> > > * Resource redirects to Keycloak
> > > * User is presented with a login form
> > > * User fills username and password
> > > * Username and password is verified through PAM (in the future SSSD once
> > > that becomes available) - this should be a custom authenticator
> > > * User profile is retrieved from SSSD over D-Bus - this should be a
> > custom
> > > user federation provider
> >
> > That's correct, I just quoted the original slides for reference
> > and added the notes (maybe was more confuse than helpful).
> >
> > After the retrieval of user's profile from SSSD. Should the data be
> > propagated
> > to Keycloak database? Should we validate such credentials on the next
> > login?
> >
>
> The user profile would currently be imported into Keycloak database as
> that's how user federation currently works. Bill is working on changing
> that though so user profile would not be imported in the future.

It's always better to double check than be sorry :)

>
> Not sure what you mean about validate such credentials - username/password
> would always be verified against PAM

Never mind, you already answered. Thank you.

Will move forward based on our discussion here and for sure ask more questions.

>
>
> >
> > > * Done
> > >
> > >
> > > >
> > > > * SSSD authenticates against AD
> > > > * Authentication complete (against FreeIPA)
> > > >
> > > > This is where I need some help to define what would be the best next
> > > > step for us.
> > > >
> > > > * Assertion/token is issued
> > > > * User is redirected to the resource
> > > >
> > > > In this scenario nothing is stored/updated on Keycloak.
> > > >
> > > > >
> > > > > > The goal is pretty much to be used for Basic Authentication.
> > > > > >
> > > > > > >
> > > > > > > As for PAM itself, it looks like it is a library.  (again a 20
> > second
> > > > > >
> > > > > > It's pretty much a low level authentication module to support
> > multiple
> > > > > > schemes like: login, ftp, ssh, telnet...(you certainly found it
> > > > already)
> > > > > >
> > > > > > > Google search).  What I don't know is where PAM ends and SSSD
> > takes
> > > > > > > over.  So its hard to give you advice.
> > > > > >
> > > > > > This is how it happens from my understanding:
> > > > > >
> > > > > > 1. We start the PAM conversation from our client application (a IPA
> > > > client machine),
> > > > > > pam_sss is contacted (SSSD)
> > > > > > 2. SSSD's PAM responder receives the authentication request and
> > > > forwards
> > > > > > it to FreeIPA server
> > > > > > 3. FreeIPA server process the request and returns the result back
> > to
> > > > PAM
> > > > > > responder.
> > > > > >
> > > > > > The data flow is better described here (
> > > >
> > https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.2.2.2.DataFlowPAMResponder
> > > > ).
> > > > > >
> > > > >
> > > > > It looks like a conversation requires some sort of session object or
> > > > session
> > > > > connection.  Remember, a web login can span multiple requests and
> > could
> > > > > possibly be serviced on different machines.  Sounds like any
> > integration
> > > > > with PAM is going to be quite limited.  Maybe that's what you are
> > getting
> > > > > at?
> > > >
> > > > I fully understand that, certainly something that requires more testing
> > > > to see how SSSD will behave with PAM.
> > > >
> > > > >
> > > > > Or are you just talking about writing a client adapter and this has
> > > > nothing
> > > > > to do with the Keycloak auth server?
> > > >
> > > > Good question. My initial naive idea was to have an authenticator SPI
> > > > for PAM and benefit from the work already done by Marek with LDAP and
> > > > Kerberos. Plus, have a federation SPI to retrieve user's data from SSSD
> > > > and propagate it to Keycloak.
> > > >
> > > > >
> > > > > Also, where does the identity data come into play (aka LDAP info)?
> > Is
> > > > this
> > > > > also a part of the PAM/SSSD flow?
> > > >
> > > > At the flow described here#17[2]:
> > > >
> > > > * User starts browser and connects to a resource
> > > > * Resource redirects to Keycloak
> > > > * User is presented with a login form
> > > > * User fills username and password
> > > > * User data is collected and passed to SSSD over D-Bus
> > > > * SSSD authenticates against LDAP server
> > > > * Authentication complete
> > > > * Assertion/token is issued
> > > > * User is redirected to the resource
> > > >
> > > > >
> > > > > Bill
> > > >
> > > > [1] -
> > > >
> > https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_130
> > > > [2] -
> > > >
> > https://docs.google.com/presentation/d/1-WvQTQ1M0Q9kfRl3d7FVWFn9GLL7vn8sAQmXGv0SVcs/edit#slide=id.g113bf6b186_1_107
> > > > --
> > > >
> > > > abstractj
> > > > PGP: 0x84DC9914
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> >

--

abstractj
PGP: 0x84DC9914

From jdennis at redhat.com  Fri Jun 24 10:54:37 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 24 Jun 2016 10:54:37 -0400
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <CAJgngAcDJSOW-0Fnms59xezrqS+3zzdXCh0MJGZ-gvy8CDdVdA@mail.gmail.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
	<db095d87-3aac-1242-ea04-b17dd95f23dc@redhat.com>
	<CAJgngAcDJSOW-0Fnms59xezrqS+3zzdXCh0MJGZ-gvy8CDdVdA@mail.gmail.com>
Message-ID: <7da54e7d-68b7-8872-2bac-5032a87c29ea@redhat.com>

On 06/24/2016 10:02 AM, Stian Thorgersen wrote:
> We can support authentication over multiple steps as we already do that
> for OTP. However, the problem will be with regards to the conversation
> as this would require sticky sessions if clustered to make sure the
> second step is sent to the same node. Can't PAM verify the two
> independently? First password, then separately OTP? That would make it
> much simpler and stateless.

PAM is implemented as a C language library running in the address space 
of a single process (remember I said it was 20 years old :-). The state 
is kept in the address space of that process. That is the primary 
limitation and would really restrict you with regards to distributing 
the conversation across processes.

I'd don't know if anyone has tried to address this, perhaps others in 
our group would know. It's been years since I coded PAM I hope my 
recollections are correct on all accounts.

This constraint should not be an issue for simple username/password auth 
because the PAM conversation can be completed as part of one single HTTP 
request.

My thought here (but I don't have the final say) is let's not worry 
about this for the first implementation. If we can avoid boxing 
ourselves in by some implementation design choice we should take it into 
consideration if possible.

-- 
John

From bruno at abstractj.org  Fri Jun 24 11:03:15 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Jun 2016 12:03:15 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <7da54e7d-68b7-8872-2bac-5032a87c29ea@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<CAJgngAetbYrz8g5NcAM4sSox1d+rHhJnUyL_BgoMrHHcQxBqUA@mail.gmail.com>
	<db095d87-3aac-1242-ea04-b17dd95f23dc@redhat.com>
	<CAJgngAcDJSOW-0Fnms59xezrqS+3zzdXCh0MJGZ-gvy8CDdVdA@mail.gmail.com>
	<7da54e7d-68b7-8872-2bac-5032a87c29ea@redhat.com>
Message-ID: <20160624150315.GE4026@abstractj.org>

On 2016-06-24, John Dennis wrote:
> On 06/24/2016 10:02 AM, Stian Thorgersen wrote:
> > We can support authentication over multiple steps as we already do that
> > for OTP. However, the problem will be with regards to the conversation
> > as this would require sticky sessions if clustered to make sure the
> > second step is sent to the same node. Can't PAM verify the two
> > independently? First password, then separately OTP? That would make it
> > much simpler and stateless.
>
> PAM is implemented as a C language library running in the address space of a
> single process (remember I said it was 20 years old :-). The state is kept
> in the address space of that process. That is the primary limitation and
> would really restrict you with regards to distributing the conversation
> across processes.
>
> I'd don't know if anyone has tried to address this, perhaps others in our
> group would know. It's been years since I coded PAM I hope my recollections
> are correct on all accounts.
>
> This constraint should not be an issue for simple username/password auth
> because the PAM conversation can be completed as part of one single HTTP
> request.
>
> My thought here (but I don't have the final say) is let's not worry about
> this for the first implementation. If we can avoid boxing ourselves in by
> some implementation design choice we should take it into consideration if
> possible.

My limited knowledge, says that's possible with pam-radius-auth[1], but
I wouldn't risk it before perform some tests. I agree with John here,
plus libpam4j only supports username/password.

I get the feeling that if we take this road, certainly we gonna end up
with our own bindings for libpam.


[1] - http://freeradius.org/pam_radius_auth/

>
> --
> John

--

abstractj
PGP: 0x84DC9914

From singhrasster at gmail.com  Fri Jun 24 11:45:46 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Fri, 24 Jun 2016 10:45:46 -0500
Subject: [keycloak-dev] How to pass values from authenticators to
	RequiredAction
Message-ID: <CAJ0vL+JabuoTy_HTqEzcqMhdNVxC-GPdf2b=i6cy1r7b0VV98g@mail.gmail.com>

I know we can pass value across authenticators by setting them in:

context.getClientSession().setNote

But is there a way to retrieve the value set in an authenticator from a
RequiredAction?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/ccb84d5a/attachment.html 

From singhrasster at gmail.com  Fri Jun 24 12:13:27 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Fri, 24 Jun 2016 11:13:27 -0500
Subject: [keycloak-dev] How to pass values from authenticators to
	RequiredAction
In-Reply-To: <CAJ0vL+JabuoTy_HTqEzcqMhdNVxC-GPdf2b=i6cy1r7b0VV98g@mail.gmail.com>
References: <CAJ0vL+JabuoTy_HTqEzcqMhdNVxC-GPdf2b=i6cy1r7b0VV98g@mail.gmail.com>
Message-ID: <CAJ0vL+L-LAUiWjLJ2dXZ0yvC4UZGEKaU8_Z-KzP4=-UY4eTxYQ@mail.gmail.com>

OK, I figured it will be done the same way. So it works fine

On Fri, Jun 24, 2016 at 10:45 AM, Rashmi Singh <singhrasster at gmail.com>
wrote:

> I know we can pass value across authenticators by setting them in:
>
> context.getClientSession().setNote
>
> But is there a way to retrieve the value set in an authenticator from a
> RequiredAction?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/12c7b380/attachment.html 

From bburke at redhat.com  Fri Jun 24 12:49:16 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Jun 2016 12:49:16 -0400
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <576CB85A.6030305@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
	<CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>
	<CAJgngAfGhp712Jje5tpj4LBU4c5F1CFaRuCsv23S4cf1Wh-XqA@mail.gmail.com>
	<1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>
	<576CB85A.6030305@redhat.com>
Message-ID: <a1e1a3b4-38c7-f2f1-1e7b-a174324d8483@redhat.com>



On 6/24/16 12:34 AM, Marek Posolda wrote:
>>> * We should be careful about changing behavior of LDAP provider as it's
>>> supported in product
>>
>> Honestly, we made a very bad decision to not refactor the federation
>> SPI and to force users to import.  It is going to be a really big
>> headache to migrate existing LDAP users to the new LDAP provider.
>> IMO, it is ultra important to stop importing everything.
> Maybe I am missing something, but not sure why is it a headache? Is it
> because of the UUID of user is going to change to new format like
> f:<PROVIDER-UUID> , so users may not be referenced from the applications
> with correct UUID? This looks to be a migration issue for all existing
> federation providers, not just LDAP specific?
>

We don't support federation providers in product except for LDAP and 
Kerberos.  There are a few migration headaches:

* New model won't support on-demand loading or proxying.  It will work 
just as the current JPA and Mongo UserProviders work.
* With importing, you don't know where the import begins and ends and it 
will be very hard to unwind it to use a non-importing LDAP impl. 
Honestly, I just don't want to support import and sync.  I think it is 
really really bad.

As for existing deployments, it looks like I can keep the 
UserFederationProvider SPI and have it co-exist with the new one.  We 
can do that and @Deprecate the UserFederation SPI.  We might want to 
consider keeping support for the old LDAP provider in product too.  For 
example, if one exists, show the admin console screens for it, if one 
doesn't don't show the screens for it.

Bill

From bburke at redhat.com  Fri Jun 24 13:01:29 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Jun 2016 13:01:29 -0400
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <764b1cbe-02c9-1bf6-2736-6f322020b01c@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<764b1cbe-02c9-1bf6-2736-6f322020b01c@redhat.com>
Message-ID: <16be3de6-86f7-f7d7-475d-9f050d1e5ca7@redhat.com>



On 6/24/16 9:53 AM, John Dennis wrote:

>
> Let me try to clarify a few things.
>
> PAM is designed as a "conversation", there are a few analogues you could
> compare it to:
>
> * a series of requests/responses
>
> * challenge/response authentication (e.g. CRAM)
>
> PAM has something equivalent to a session where state is stored during
> the "conversation". When you use PAM you establish a context (session)
> and iterate. In each iteration the PAM library will ask you for
> something and you reply. The iteration stops when the library signals
> completion.
>

Will the PAM conversation object be able to be serialized in-between web 
requests? Is it something that can be rebuilt with HTTP session information?

> For simple password auth the iteration is very short. But depending on
> how the PAM service is configured you could be prompted for other
> things. I suspect with Web forms they way you handle this is via
> redirects until such time as the PAM conversation completes.
>

What do you mean by "prompted"?  Are we going to have to screen-scrape 
this information, or is it a well defined structure?

> So my suggestion would be to design this where there is a simple web
> form prompting for username/password but allow for the fact you may have
> to redirect to another page.
>

As I mentioned early, we already have these generic redirection 
capabilities.    Login is a "workflow" and you can define nodes in this 
workflow.  The current node in the flow can fail, pass, ignore, or 
challenge an incoming request.

>
> Does that help?
>

We're getting there!  :)  My current thoughts are that PAM integration 
should be implemented as a Keycloak Authenticator and user profile 
lookup, via SSSD, should be done via a User Federation Provider (the new 
interface).

Bill

From bruno at abstractj.org  Fri Jun 24 13:14:30 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Jun 2016 14:14:30 -0300
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <16be3de6-86f7-f7d7-475d-9f050d1e5ca7@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<764b1cbe-02c9-1bf6-2736-6f322020b01c@redhat.com>
	<16be3de6-86f7-f7d7-475d-9f050d1e5ca7@redhat.com>
Message-ID: <20160624171430.GA30566@abstractj.org>

On 2016-06-24, Bill Burke wrote:
>
>
> On 6/24/16 9:53 AM, John Dennis wrote:
>
> >
> > Let me try to clarify a few things.
> >
> > PAM is designed as a "conversation", there are a few analogues you could
> > compare it to:
> >
> > * a series of requests/responses
> >
> > * challenge/response authentication (e.g. CRAM)
> >
> > PAM has something equivalent to a session where state is stored during
> > the "conversation". When you use PAM you establish a context (session)
> > and iterate. In each iteration the PAM library will ask you for
> > something and you reply. The iteration stops when the library signals
> > completion.
> >
>
> Will the PAM conversation object be able to be serialized in-between web
> requests? Is it something that can be rebuilt with HTTP session information?
>
> > For simple password auth the iteration is very short. But depending on
> > how the PAM service is configured you could be prompted for other
> > things. I suspect with Web forms they way you handle this is via
> > redirects until such time as the PAM conversation completes.
> >
>
> What do you mean by "prompted"?  Are we going to have to screen-scrape this
> information, or is it a well defined structure?
>
> > So my suggestion would be to design this where there is a simple web
> > form prompting for username/password but allow for the fact you may have
> > to redirect to another page.
> >
>
> As I mentioned early, we already have these generic redirection
> capabilities.    Login is a "workflow" and you can define nodes in this
> workflow.  The current node in the flow can fail, pass, ignore, or challenge
> an incoming request.
>
> >
> > Does that help?
> >
>
> We're getting there!  :)  My current thoughts are that PAM integration
> should be implemented as a Keycloak Authenticator and user profile lookup,
> via SSSD, should be done via a User Federation Provider (the new interface).

Phew! I think we are on the same page about it.

>
> Bill

--

abstractj
PGP: 0x84DC9914

From srossillo at smartling.com  Fri Jun 24 15:01:38 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Fri, 24 Jun 2016 15:01:38 -0400
Subject: [keycloak-dev] Productized Keycloak now available from Red Hat
In-Reply-To: <CAK-7U1gTnNdK-g2Hz5Yzc1fU6B5qO1iT5o4+5-8ZRfOQTruXnA@mail.gmail.com>
References: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
	<CAPyAMoYA=baG3UHzCyPrkJF5tW1OdkO7VzyKLyzYtf9i6hAiwA@mail.gmail.com>
	<CAK-7U1gTnNdK-g2Hz5Yzc1fU6B5qO1iT5o4+5-8ZRfOQTruXnA@mail.gmail.com>
Message-ID: <8229327E-240A-44C9-B00C-847A6214BF76@smartling.com>

Well done, guys! Great work and congratulations. Looking forward to continuing to work with the entire team.

PS - what Keycloak version is RH SSO based?

Best,
Scott

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

> On Jun 24, 2016, at 4:17 AM, Thomas Darimont <thomas.darimont at googlemail.com> wrote:
> 
> Congratulations to everyone involved! Well done!
> 
> Cheers,
> Thomas
> 
> 2016-06-24 10:14 GMT+02:00 Thomas Raehalme <thomas.raehalme at aitiofinland.com <mailto:thomas.raehalme at aitiofinland.com>>:
> Congrats to both of you for creating such a great open source product!
> 
> Best regards,
> Thomas
> 
> On Jun 23, 2016 22:59, "Stian Thorgersen" <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
> For nearly 4 years ago Bill Burke and myself started two individual proof of concepts, both focusing on making it easier for developers to securing applications and services. Keycloak was born out of combining these two proof of concepts. There was barely any overlap and the two perfectly complemented each other.
> 
> Fast forward to today and we now have a huge community with over 100 contributors and over 400 forks of our Github repository. It's no longer just myself and Bill working on Keycloak, we now have a strong team working on it and I'm very exited about the future of the project.
> 
> You may have noticed that lately we've stopped adding new features and focused on improvements and testing. There's a good reason behind that! We've been working on creating a productized and supported version of Keycloak.
> 
> I'm extremely pleased to announce that Red Hat now offers a productized and supported version of Keycloak!
> 
> For more details on how to get support for Keycloak check out the product pages at:
> https://access.redhat.com/products/red-hat-single-sign-on <https://access.redhat.com/products/red-hat-single-sign-on>
> 
> Finally, I'd like to thank everyone that's been involved. All the core developers, quality engineers, others at Red Hat and last but not least our community!
> 
> _______________________________________________
> 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>
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From jorsol at gmail.com  Sat Jun 25 12:33:48 2016
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Sat, 25 Jun 2016 10:33:48 -0600
Subject: [keycloak-dev] Productized Keycloak now available from Red Hat
In-Reply-To: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
References: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
Message-ID: <CA+cVU8NBqubhMmKG12-UMSnhHiXGhp4wTpFC2PmCiAmZCu4j=Q@mail.gmail.com>

Congratulations and excelent work!!!

Looking forward to the backport of Authorization Services from KC 2.x,
maybe in RH-SSO 7.1.0.

Best regards,

Jorge Sol?rzano
me.jorsol.com

On Thu, Jun 23, 2016 at 1:58 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> For nearly 4 years ago Bill Burke and myself started two individual proof
> of concepts, both focusing on making it easier for developers to securing
> applications and services. Keycloak was born out of combining these two
> proof of concepts. There was barely any overlap and the two perfectly
> complemented each other.
>
> Fast forward to today and we now have a huge community with over 100
> contributors and over 400 forks of our Github repository. It's no longer
> just myself and Bill working on Keycloak, we now have a strong team working
> on it and I'm very exited about the future of the project.
>
> You may have noticed that lately we've stopped adding new features and
> focused on improvements and testing. There's a good reason behind that!
> We've been working on creating a productized and supported version of
> Keycloak.
>
> I'm extremely pleased to announce that Red Hat now offers a productized
> and supported version of Keycloak!
>
> For more details on how to get support for Keycloak check out the product
> pages at:
> https://access.redhat.com/products/red-hat-single-sign-on
>
> Finally, I'd like to thank everyone that's been involved. All the core
> developers, quality engineers, others at Red Hat and last but not least our
> community!
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160625/75d85f1e/attachment.html 

From marc.savy at redhat.com  Sun Jun 26 06:20:53 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Sun, 26 Jun 2016 11:20:53 +0100
Subject: [keycloak-dev] Productized Keycloak now available from Red Hat
In-Reply-To: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
References: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
Message-ID: <CAA7j38JiuqcXeVC8h-jXrsbmYpNNOxXjbuTXAnKvZz+USbCY0A@mail.gmail.com>

Huge congratulations to the team! This is a fantastic project, and
undoubtedly will be a successful product. I think you're in the right place
at the right time, with the right team and the right technological
approach.

I hope everyone who's thinking that they'd like support goes out there and
buys it :-).

On 23 June 2016 at 20:58, Stian Thorgersen <sthorger at redhat.com> wrote:

> For nearly 4 years ago Bill Burke and myself started two individual proof
> of concepts, both focusing on making it easier for developers to securing
> applications and services. Keycloak was born out of combining these two
> proof of concepts. There was barely any overlap and the two perfectly
> complemented each other.
>
> Fast forward to today and we now have a huge community with over 100
> contributors and over 400 forks of our Github repository. It's no longer
> just myself and Bill working on Keycloak, we now have a strong team working
> on it and I'm very exited about the future of the project.
>
> You may have noticed that lately we've stopped adding new features and
> focused on improvements and testing. There's a good reason behind that!
> We've been working on creating a productized and supported version of
> Keycloak.
>
> I'm extremely pleased to announce that Red Hat now offers a productized
> and supported version of Keycloak!
>
> For more details on how to get support for Keycloak check out the product
> pages at:
> https://access.redhat.com/products/red-hat-single-sign-on
>
> Finally, I'd like to thank everyone that's been involved. All the core
> developers, quality engineers, others at Red Hat and last but not least our
> community!
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160626/d09a7e98/attachment.html 

From sthorger at redhat.com  Mon Jun 27 02:05:13 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 27 Jun 2016 08:05:13 +0200
Subject: [keycloak-dev] How to set configs for RequiredAction in
	keycloak-server.json file
In-Reply-To: <CAJ0vL+Jyj7SAUCWikF2UM6q1XZZX1EzHqMt17qU-qVLvVPnJiA@mail.gmail.com>
References: <CAJ0vL+K51LQX6wBh6UC10q2Z6+BEWMSwgKj9niCq4zUJxq6NqA@mail.gmail.com>
	<CAJ0vL+KbePejXWfXZq3MVh95rMwwrEk=VbpKumCyjQ5w1vCasA@mail.gmail.com>
	<CAJ0vL+Jyj7SAUCWikF2UM6q1XZZX1EzHqMt17qU-qVLvVPnJiA@mail.gmail.com>
Message-ID: <CAJgngAd1K0jyADRfiFJfzpxVhmgtXZmziChC3xUME43LbpMJMA@mail.gmail.com>

"required-action". FIY if you go to the admin console, login, then click on
the menu where you logout there's a server info option. That will list all
available providers and the ids.

On 24 June 2016 at 16:15, Rashmi Singh <singhrasster at gmail.com> wrote:

> Would this type of format work?
>
> "requiredAction": {
>   "test-required-action": {
>     "config1": "xxxx"
>   }
> }
>
> If yes, not sure what should be the name instead of "requiredAction" above
> though
>
>
>
> On Fri, Jun 24, 2016 at 9:01 AM, Rashmi Singh <singhrasster at gmail.com>
> wrote:
>
>> Any clue for this?
>>
>> On Thu, Jun 23, 2016 at 10:40 PM, Rashmi Singh <singhrasster at gmail.com>
>> wrote:
>>
>>> In keycloak-server.json, if we add the following
>>>
>>> "authenticator": {
>>>   "test-authenticator": {
>>>     "config1": "xxxx"
>>>   }
>>> }
>>>
>>> the value of config1 can be retrieved in the factory class init method
>>> as:
>>>
>>> config.get("config1")
>>>
>>>
>>> Now, in the same way, if I want to get configs in the init method of a
>>> RequiredAction class instead of an authenticator, how do I set it in
>>> keyclock-server.json? What will be the exact syntax? Is it possible?
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160627/0b8f5db0/attachment.html 

From sthorger at redhat.com  Mon Jun 27 02:12:06 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 27 Jun 2016 08:12:06 +0200
Subject: [keycloak-dev] [keycloak-user] Productized Keycloak now
 available from Red Hat
In-Reply-To: <576EAD77.10903@redhat.com>
References: <CAJgngAd0QehZK9JgDvXL5FTj0NtYKRTF=eMpoYLkh46o78Poxw@mail.gmail.com>
	<CAPyAMoYA=baG3UHzCyPrkJF5tW1OdkO7VzyKLyzYtf9i6hAiwA@mail.gmail.com>
	<CAK-7U1gTnNdK-g2Hz5Yzc1fU6B5qO1iT5o4+5-8ZRfOQTruXnA@mail.gmail.com>
	<8229327E-240A-44C9-B00C-847A6214BF76@smartling.com>
	<576EAD77.10903@redhat.com>
Message-ID: <CAJgngAdjFcYJ=if04yotAwAUBtiVzVhqs_adtDiTozLWz6dzmg@mail.gmail.com>

Yes, it's 1.9.8.Final

On 25 June 2016 at 18:12, James Falkner <jfalkner at redhat.com> wrote:

> Looks like 1.9.8 <https://access.redhat.com/articles/2342881>.
>
> -James
>
> Scott Rossillo <srossillo at smartling.com>
> June 24, 2016 at 3:01 PM
> Well done, guys! Great work and congratulations. Looking forward to
> continuing to work with the entire team.
>
> PS - what Keycloak version is RH SSO based?
>
> Best,
> Scott
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> Thomas Darimont <thomas.darimont at googlemail.com>
> June 24, 2016 at 4:17 AM
> Congratulations to everyone involved! Well done!
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> Thomas Raehalme <thomas.raehalme at aitiofinland.com>
> June 24, 2016 at 4:14 AM
>
> Congrats to both of you for creating such a great open source product!
>
> Best regards,
> Thomas
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> Stian Thorgersen <sthorger at redhat.com>
> June 23, 2016 at 3:58 PM
> For nearly 4 years ago Bill Burke and myself started two individual proof
> of concepts, both focusing on making it easier for developers to securing
> applications and services. Keycloak was born out of combining these two
> proof of concepts. There was barely any overlap and the two perfectly
> complemented each other.
>
> Fast forward to today and we now have a huge community with over 100
> contributors and over 400 forks of our Github repository. It's no longer
> just myself and Bill working on Keycloak, we now have a strong team working
> on it and I'm very exited about the future of the project.
>
> You may have noticed that lately we've stopped adding new features and
> focused on improvements and testing. There's a good reason behind that!
> We've been working on creating a productized and supported version of
> Keycloak.
>
> I'm extremely pleased to announce that Red Hat now offers a productized
> and supported version of Keycloak!
>
> For more details on how to get support for Keycloak check out the product
> pages at:
> https://access.redhat.com/products/red-hat-single-sign-on
>
> Finally, I'd like to thank everyone that's been involved. All the core
> developers, quality engineers, others at Red Hat and last but not least our
> community!
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160627/63e9d790/attachment-0001.html 

From sthorger at redhat.com  Mon Jun 27 02:22:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 27 Jun 2016 08:22:20 +0200
Subject: [keycloak-dev] User Federation Provider Cache
In-Reply-To: <a1e1a3b4-38c7-f2f1-1e7b-a174324d8483@redhat.com>
References: <CAFzO_6crwKto0nU=1U7e2if8gRQ2OHnSCqUDk_N=CdUdgc884A@mail.gmail.com>
	<1f0efb6b-18b3-9efc-5c2b-8a3c38b0e669@redhat.com>
	<CAFzO_6dmuZq0tZQ8jubLvSUgy0xf+k3nmuJfM41=hmjNa_ayUA@mail.gmail.com>
	<c23eddb3-1f47-eaa6-c9e6-d569d55996b6@redhat.com>
	<CAFzO_6eMxCyjP=hudF569yUOCxtopDQ=DGEWZnRX_kuxqnGFKg@mail.gmail.com>
	<e8f0814e-6183-611d-5f73-b64585de5093@redhat.com>
	<CAFzO_6c=RBb=Xin_G4vDcqeihqQ0x5U4q5G09TRapwCOa2RCuw@mail.gmail.com>
	<575E6344.3000605@redhat.com>
	<96df1edb-cfee-9459-3ddd-926e418ceb4a@redhat.com>
	<57611632.9080300@redhat.com>
	<01a2f28c-36cc-7fef-1da9-8d5f5c0f684f@redhat.com>
	<57627010.4010003@redhat.com>
	<889fa832-c988-948c-2842-5348922f07dc@redhat.com>
	<5763BE6A.3080007@redhat.com>
	<CAJgngAeA+2RfiiE_aTf8q9QbSu1pD1Ews5qom02c07S6cTxjOQ@mail.gmail.com>
	<CAJgngAfGhp712Jje5tpj4LBU4c5F1CFaRuCsv23S4cf1Wh-XqA@mail.gmail.com>
	<1abe4774-e203-5296-4702-af5eab085bdf@redhat.com>
	<576CB85A.6030305@redhat.com>
	<a1e1a3b4-38c7-f2f1-1e7b-a174324d8483@redhat.com>
Message-ID: <CAJgngAd6tgEF3fduSnSJ=ENTDvLc3JApAjfcJW13MCwNFyGzgg@mail.gmail.com>

There could be benefits to sync/import, but we don't see these even in the
current implementation:

* Migration - users may want to migrate away from LDAP gradually. We should
support some mechanism of permanently migrating all users from a provider
to the internal Keycloak DB (or even another provider).
* Scaling - if users in an LDAP server are more or less read-only then you
would only have to load users from the Keycloak DB. This may be useful if
the LDAP server is overloaded and you want to scale. However, that could
possibly also be solved by more aggressive caching.

Can you elaborate a bit on why you think the current sync/import is really
really bad?

With the new model there's a few things I'm a bit unsure about:

* Will there always be a representation of a user in Keycloak DB? For the
UUID as well as other items that can't be stored in the provider. Or will
we have the option of not having anything in the KC DB about a user, only
in-mem?
* By supporting the old UserFederationProvider will those have exactly the
same behavior? For example with regards to sync/import?

On 24 June 2016 at 18:49, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 6/24/16 12:34 AM, Marek Posolda wrote:
>
>> * We should be careful about changing behavior of LDAP provider as it's
>>>> supported in product
>>>>
>>>
>>> Honestly, we made a very bad decision to not refactor the federation
>>> SPI and to force users to import.  It is going to be a really big
>>> headache to migrate existing LDAP users to the new LDAP provider.
>>> IMO, it is ultra important to stop importing everything.
>>>
>> Maybe I am missing something, but not sure why is it a headache? Is it
>> because of the UUID of user is going to change to new format like
>> f:<PROVIDER-UUID> , so users may not be referenced from the applications
>> with correct UUID? This looks to be a migration issue for all existing
>> federation providers, not just LDAP specific?
>>
>>
> We don't support federation providers in product except for LDAP and
> Kerberos.  There are a few migration headaches:
>
> * New model won't support on-demand loading or proxying.  It will work
> just as the current JPA and Mongo UserProviders work.
> * With importing, you don't know where the import begins and ends and it
> will be very hard to unwind it to use a non-importing LDAP impl. Honestly,
> I just don't want to support import and sync.  I think it is really really
> bad.
>
> As for existing deployments, it looks like I can keep the
> UserFederationProvider SPI and have it co-exist with the new one.  We can
> do that and @Deprecate the UserFederation SPI.  We might want to consider
> keeping support for the old LDAP provider in product too.  For example, if
> one exists, show the admin console screens for it, if one doesn't don't
> show the screens for it.
>
> Bill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160627/4fca2f84/attachment.html 

From sthorger at redhat.com  Mon Jun 27 02:27:46 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 27 Jun 2016 08:27:46 +0200
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <20160624171430.GA30566@abstractj.org>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<764b1cbe-02c9-1bf6-2736-6f322020b01c@redhat.com>
	<16be3de6-86f7-f7d7-475d-9f050d1e5ca7@redhat.com>
	<20160624171430.GA30566@abstractj.org>
Message-ID: <CAJgngAcY0W=V5=dO3q5Wh6M_JX82tOPMzebzn175SMtcJ2pNxw@mail.gmail.com>

My hope was that PAM would support verifying password and OTP as two
completely separate calls without requiring a conversation and state
between them. However, sounds like that's not possible. If libpam4j doesn't
even support OTP it makes matters even worse.

The sooner we can use SSSD rather than PAM for authentication the better.
Or at least do the OTP verification over SSSD.

On 24 June 2016 at 19:14, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2016-06-24, Bill Burke wrote:
> >
> >
> > On 6/24/16 9:53 AM, John Dennis wrote:
> >
> > >
> > > Let me try to clarify a few things.
> > >
> > > PAM is designed as a "conversation", there are a few analogues you
> could
> > > compare it to:
> > >
> > > * a series of requests/responses
> > >
> > > * challenge/response authentication (e.g. CRAM)
> > >
> > > PAM has something equivalent to a session where state is stored during
> > > the "conversation". When you use PAM you establish a context (session)
> > > and iterate. In each iteration the PAM library will ask you for
> > > something and you reply. The iteration stops when the library signals
> > > completion.
> > >
> >
> > Will the PAM conversation object be able to be serialized in-between web
> > requests? Is it something that can be rebuilt with HTTP session
> information?
> >
> > > For simple password auth the iteration is very short. But depending on
> > > how the PAM service is configured you could be prompted for other
> > > things. I suspect with Web forms they way you handle this is via
> > > redirects until such time as the PAM conversation completes.
> > >
> >
> > What do you mean by "prompted"?  Are we going to have to screen-scrape
> this
> > information, or is it a well defined structure?
> >
> > > So my suggestion would be to design this where there is a simple web
> > > form prompting for username/password but allow for the fact you may
> have
> > > to redirect to another page.
> > >
> >
> > As I mentioned early, we already have these generic redirection
> > capabilities.    Login is a "workflow" and you can define nodes in this
> > workflow.  The current node in the flow can fail, pass, ignore, or
> challenge
> > an incoming request.
> >
> > >
> > > Does that help?
> > >
> >
> > We're getting there!  :)  My current thoughts are that PAM integration
> > should be implemented as a Keycloak Authenticator and user profile
> lookup,
> > via SSSD, should be done via a User Federation Provider (the new
> interface).
>
> Phew! I think we are on the same page about it.
>
> >
> > Bill
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160627/6c41b676/attachment.html 

From mstrukel at redhat.com  Mon Jun 27 07:48:54 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Mon, 27 Jun 2016 13:48:54 +0200
Subject: [keycloak-dev] Client Registration CLI tool
Message-ID: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>

I've started work on Client Registration CLI tool. As a first step, here is
a design document describing how I imagine the tool would be used.


https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing


I'll use this document as a spec / guide as I implement the client tool.

Within days I'll also send a link to initial ideas for Admin Client tool
which in principle should allow administrator to configure everything that
can otherwise be done through Admin Console.

Any feedback welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160627/dc19adbc/attachment.html 

From bburke at redhat.com  Mon Jun 27 08:24:33 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Jun 2016 08:24:33 -0400
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <CAJgngAcY0W=V5=dO3q5Wh6M_JX82tOPMzebzn175SMtcJ2pNxw@mail.gmail.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<764b1cbe-02c9-1bf6-2736-6f322020b01c@redhat.com>
	<16be3de6-86f7-f7d7-475d-9f050d1e5ca7@redhat.com>
	<20160624171430.GA30566@abstractj.org>
	<CAJgngAcY0W=V5=dO3q5Wh6M_JX82tOPMzebzn175SMtcJ2pNxw@mail.gmail.com>
Message-ID: <446d2e25-1242-4212-28c8-74c9e2d0cc5f@redhat.com>

Don't think that is an issue either.  We can just write another a 
different flow for PAM and gather password and OTP on the same page, or 
the same field like RHT IT does for our login.

On 6/27/16 2:27 AM, Stian Thorgersen wrote:
> My hope was that PAM would support verifying password and OTP as two
> completely separate calls without requiring a conversation and state
> between them. However, sounds like that's not possible. If libpam4j
> doesn't even support OTP it makes matters even worse.
>
> The sooner we can use SSSD rather than PAM for authentication the
> better. Or at least do the OTP verification over SSSD.
>
> On 24 June 2016 at 19:14, Bruno Oliveira <bruno at abstractj.org
> <mailto:bruno at abstractj.org>> wrote:
>
>     On 2016-06-24, Bill Burke wrote:
>     >
>     >
>     > On 6/24/16 9:53 AM, John Dennis wrote:
>     >
>     > >
>     > > Let me try to clarify a few things.
>     > >
>     > > PAM is designed as a "conversation", there are a few analogues
>     you could
>     > > compare it to:
>     > >
>     > > * a series of requests/responses
>     > >
>     > > * challenge/response authentication (e.g. CRAM)
>     > >
>     > > PAM has something equivalent to a session where state is stored
>     during
>     > > the "conversation". When you use PAM you establish a context
>     (session)
>     > > and iterate. In each iteration the PAM library will ask you for
>     > > something and you reply. The iteration stops when the library
>     signals
>     > > completion.
>     > >
>     >
>     > Will the PAM conversation object be able to be serialized
>     in-between web
>     > requests? Is it something that can be rebuilt with HTTP session
>     information?
>     >
>     > > For simple password auth the iteration is very short. But
>     depending on
>     > > how the PAM service is configured you could be prompted for other
>     > > things. I suspect with Web forms they way you handle this is via
>     > > redirects until such time as the PAM conversation completes.
>     > >
>     >
>     > What do you mean by "prompted"?  Are we going to have to
>     screen-scrape this
>     > information, or is it a well defined structure?
>     >
>     > > So my suggestion would be to design this where there is a simple web
>     > > form prompting for username/password but allow for the fact you
>     may have
>     > > to redirect to another page.
>     > >
>     >
>     > As I mentioned early, we already have these generic redirection
>     > capabilities.    Login is a "workflow" and you can define nodes in
>     this
>     > workflow.  The current node in the flow can fail, pass, ignore, or
>     challenge
>     > an incoming request.
>     >
>     > >
>     > > Does that help?
>     > >
>     >
>     > We're getting there!  :)  My current thoughts are that PAM integration
>     > should be implemented as a Keycloak Authenticator and user profile
>     lookup,
>     > via SSSD, should be done via a User Federation Provider (the new
>     interface).
>
>     Phew! I think we are on the same page about it.
>
>     >
>     > Bill
>
>     --
>
>     abstractj
>     PGP: 0x84DC9914
>     _______________________________________________
>     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
>
>

From lholmqui at redhat.com  Mon Jun 27 08:50:36 2016
From: lholmqui at redhat.com (Luke Holmquist)
Date: Mon, 27 Jun 2016 08:50:36 -0400
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
Message-ID: <CALD3Fd2d1c2HKeNHywnNysbr=3G7fs+d3L3sEt6PA-aoHJZi+Q@mail.gmail.com>

if you are interested in writing this cli in javascript,  there is this
little project i had been working on ,
https://github.com/bucharest-gold/keycloak-admin-client

On Mon, Jun 27, 2016 at 7:48 AM, Marko Strukelj <mstrukel at redhat.com> wrote:

> I've started work on Client Registration CLI tool. As a first step, here
> is a design document describing how I imagine the tool would be used.
>
>
>
> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
>
>
> I'll use this document as a spec / guide as I implement the client tool.
>
> Within days I'll also send a link to initial ideas for Admin Client tool
> which in principle should allow administrator to configure everything that
> can otherwise be done through Admin Console.
>
> Any feedback welcome.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160627/b0416aac/attachment-0001.html 

From jdennis at redhat.com  Mon Jun 27 15:26:15 2016
From: jdennis at redhat.com (John Dennis)
Date: Mon, 27 Jun 2016 15:26:15 -0400
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
Message-ID: <a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>

On 06/27/2016 07:48 AM, Marko Strukelj wrote:
> I've started work on Client Registration CLI tool. As a first step, here
> is a design document describing how I imagine the tool would be used.
>
>
> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
>
>
> I'll use this document as a spec / guide as I implement the client tool.
>
> Within days I'll also send a link to initial ideas for Admin Client tool
> which in principle should allow administrator to configure everything
> that can otherwise be done through Admin Console.
>
> Any feedback welcome.

FWIW we've already written a client registration tool for Keycloak. At 
the moment it is specifically targeted for SAML clients (SP, Service 
Provider) in Apache HTTPD but we have plans to extend it to OIDC.

It is currently in Fedora and will also ship in OSP.

It is hosted here:
https://github.com/jdennis/keycloak-httpd-client-install

The man page for it (formatted for HTML) can be found here:
https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html

The man page discusses 3 different ways you can authenticate and 2 
different ways client registration can be performed.

I have a lot of experience with Keycloak client registration tools and 
have worked through many issues, I'm happy to share my experience.

Here are some thoughts/issues you may want to take into account:

* The tool must be capable of running without interactivity as part of a 
scripted installation task.

* It should not depend on a home directory being available.

* If a home directory is utilized how will you disambiguate any stored 
state belonging to a script that is run by different processes but under 
the same user (possibly simultaneously)? To clarify, many install tools 
run as the root user or some other admin user. Each invocation of these 
install tools can be run with entirely different parameters and may 
execute either in parallel or partially overlapping in time.

* The tool should be idempotent.

* You suggest storing tokens in a cache, how do you plan on handling the 
case where a token expires before all operations are complete?

* We also initially took the approach of caching tokens but discovered 
the complexity did not justify the minimal cost of obtaining a new token 
for each invocation. This greatly simplified the code with very little 
performance impact.

* You do not mention what type of client you're registering. I'm 
assuming it's OpenID but SAML clients (SP) are equally important. The 
tool must be able to handle both.

* I don't see anything in your document on how to specify the SAML metadata.

* I don't see anything in your document on how the user modifies the 
client. It appears as if you are retrieving a ClientRepresentation JSON 
document and expecting the user to edit it in a text editor which will 
then be sent back. That won't work for non-interactive installs. It also 
presumes the user knows how to read and modify the JSON.

* Keycloak currently has a few problems with client registration and 
it's necessary to modify the client before it will work correctly. We 
currently do this via the REST API. How are you planning on handling 
these issues in your installer? It would be nice if the installer was 
aware of the Keycloak version and could apply "fix-ups" as needed based 
on the version.

* Keycloak has two ways to register a client (client registration 
service vs. REST API). The two methods do not produce the same client 
configuration (I suspect because they do not share common code in the 
server). How are you planning on addressing the discrepancies?

* The tool should be smart enough to produce a working client without 
manual intervention (i.e. the need to run admin cli commands afterwards 
to fix problems). Most admins won't know how to tweak the configuration.

* The tool should not have significant dependencies.

Those are the thoughts off the top of my head, as you fill out the 
details I'll continue to review. Recall the plan of record is for 
Keycloak to provide such tools which we will then utilize. The 
keycloak-httpd-client-install tool is a stop-gap solution until such 
time as "offical" tools become available.



-- 
John

From sthorger at redhat.com  Tue Jun 28 01:35:58 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 28 Jun 2016 07:35:58 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
Message-ID: <CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>

On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com> wrote:

> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
> > I've started work on Client Registration CLI tool. As a first step, here
> > is a design document describing how I imagine the tool would be used.
> >
> >
> >
> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
> >
> >
> > I'll use this document as a spec / guide as I implement the client tool.
> >
> > Within days I'll also send a link to initial ideas for Admin Client tool
> > which in principle should allow administrator to configure everything
> > that can otherwise be done through Admin Console.
> >
> > Any feedback welcome.
>
> FWIW we've already written a client registration tool for Keycloak. At
> the moment it is specifically targeted for SAML clients (SP, Service
> Provider) in Apache HTTPD but we have plans to extend it to OIDC.
>
> It is currently in Fedora and will also ship in OSP.
>
> It is hosted here:
> https://github.com/jdennis/keycloak-httpd-client-install
>
> The man page for it (formatted for HTML) can be found here:
> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
>
> The man page discusses 3 different ways you can authenticate and 2
> different ways client registration can be performed.
>
> I have a lot of experience with Keycloak client registration tools and
> have worked through many issues, I'm happy to share my experience.
>
> Here are some thoughts/issues you may want to take into account:
>
> * The tool must be capable of running without interactivity as part of a
> scripted installation task.
>
> * It should not depend on a home directory being available.
>
> * If a home directory is utilized how will you disambiguate any stored
> state belonging to a script that is run by different processes but under
> the same user (possibly simultaneously)? To clarify, many install tools
> run as the root user or some other admin user. Each invocation of these
> install tools can be run with entirely different parameters and may
> execute either in parallel or partially overlapping in time.
>
> * The tool should be idempotent.
>
> * You suggest storing tokens in a cache, how do you plan on handling the
> case where a token expires before all operations are complete?
>
> * We also initially took the approach of caching tokens but discovered
> the complexity did not justify the minimal cost of obtaining a new token
> for each invocation. This greatly simplified the code with very little
> performance impact.
>
> * You do not mention what type of client you're registering. I'm
> assuming it's OpenID but SAML clients (SP) are equally important. The
> tool must be able to handle both.
>

Marko is probably referring to the Keycloak client representation, which
can be either OpenID or SAML. However, we also need to support OpenID
Connect client descriptions as well as SAML entity descriptors as both are
supported by client reg services.


>
> * I don't see anything in your document on how to specify the SAML
> metadata.
>
> * I don't see anything in your document on how the user modifies the
> client. It appears as if you are retrieving a ClientRepresentation JSON
> document and expecting the user to edit it in a text editor which will
> then be sent back. That won't work for non-interactive installs. It also
> presumes the user knows how to read and modify the JSON.
>

It would be nice to be able to set specific fields without having to modify
JSON. We discussed that for the Admin CLI, but we should probably also add
it to the client reg CLI


>
> * Keycloak currently has a few problems with client registration and
> it's necessary to modify the client before it will work correctly. We
> currently do this via the REST API. How are you planning on handling
> these issues in your installer? It would be nice if the installer was
> aware of the Keycloak version and could apply "fix-ups" as needed based
> on the version.
>

AFAIK you have one problem? About not all redirect URI included from the
SAML entity descriptor. Is that what you are referring to or do you have
other problems?

In either case fix-ups should be performed by the client registration
services, not in the CLI.


>
> * Keycloak has two ways to register a client (client registration
> service vs. REST API). The two methods do not produce the same client
> configuration (I suspect because they do not share common code in the
> server). How are you planning on addressing the discrepancies?
>

The task of the CLI is not to address any discrepancies. It's just invoking
the client reg services. Any discrepancies should be handled by the client
reg services themselves. Have you created JIRA's for these or can you list
them to us?


>
> * The tool should be smart enough to produce a working client without
> manual intervention (i.e. the need to run admin cli commands afterwards
> to fix problems). Most admins won't know how to tweak the configuration.
>

Can you list any you are aware of? Same comment as above applies though,
it's the responsibility of the client reg services to handle this, not the
CLI. Otherwise you'd have different behavior if you invoke client reg
services directly rather than through the CLI.


>
> * The tool should not have significant dependencies.
>

It'll be a fat-jar and will have a single dependency on the JVM.


>
> Those are the thoughts off the top of my head, as you fill out the
> details I'll continue to review. Recall the plan of record is for
> Keycloak to provide such tools which we will then utilize. The
> keycloak-httpd-client-install tool is a stop-gap solution until such
> time as "offical" tools become available.
>
>
>
> --
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160628/24025a94/attachment.html 

From sthorger at redhat.com  Tue Jun 28 02:31:31 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 28 Jun 2016 08:31:31 +0200
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <446d2e25-1242-4212-28c8-74c9e2d0cc5f@redhat.com>
References: <20160623140052.GC2835@abstractj.org>
	<c8c166f5-e786-7467-ff9d-0d034f86a037@redhat.com>
	<44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<764b1cbe-02c9-1bf6-2736-6f322020b01c@redhat.com>
	<16be3de6-86f7-f7d7-475d-9f050d1e5ca7@redhat.com>
	<20160624171430.GA30566@abstractj.org>
	<CAJgngAcY0W=V5=dO3q5Wh6M_JX82tOPMzebzn175SMtcJ2pNxw@mail.gmail.com>
	<446d2e25-1242-4212-28c8-74c9e2d0cc5f@redhat.com>
Message-ID: <CAJgngAej6AL_sV15dw0muVDvcvZTnSzNqQy+zoFC-yV5u3NjUw@mail.gmail.com>

That only works if all users have OTP setup. I don't think we can rely on
that and we'll have to support both options.

On 27 June 2016 at 14:24, Bill Burke <bburke at redhat.com> wrote:

> Don't think that is an issue either.  We can just write another a
> different flow for PAM and gather password and OTP on the same page, or the
> same field like RHT IT does for our login.
>
> On 6/27/16 2:27 AM, Stian Thorgersen wrote:
>
>> My hope was that PAM would support verifying password and OTP as two
>> completely separate calls without requiring a conversation and state
>> between them. However, sounds like that's not possible. If libpam4j
>> doesn't even support OTP it makes matters even worse.
>>
>> The sooner we can use SSSD rather than PAM for authentication the
>> better. Or at least do the OTP verification over SSSD.
>>
>> On 24 June 2016 at 19:14, Bruno Oliveira <bruno at abstractj.org
>> <mailto:bruno at abstractj.org>> wrote:
>>
>>     On 2016-06-24, Bill Burke wrote:
>>     >
>>     >
>>     > On 6/24/16 9:53 AM, John Dennis wrote:
>>     >
>>     > >
>>     > > Let me try to clarify a few things.
>>     > >
>>     > > PAM is designed as a "conversation", there are a few analogues
>>     you could
>>     > > compare it to:
>>     > >
>>     > > * a series of requests/responses
>>     > >
>>     > > * challenge/response authentication (e.g. CRAM)
>>     > >
>>     > > PAM has something equivalent to a session where state is stored
>>     during
>>     > > the "conversation". When you use PAM you establish a context
>>     (session)
>>     > > and iterate. In each iteration the PAM library will ask you for
>>     > > something and you reply. The iteration stops when the library
>>     signals
>>     > > completion.
>>     > >
>>     >
>>     > Will the PAM conversation object be able to be serialized
>>     in-between web
>>     > requests? Is it something that can be rebuilt with HTTP session
>>     information?
>>     >
>>     > > For simple password auth the iteration is very short. But
>>     depending on
>>     > > how the PAM service is configured you could be prompted for other
>>     > > things. I suspect with Web forms they way you handle this is via
>>     > > redirects until such time as the PAM conversation completes.
>>     > >
>>     >
>>     > What do you mean by "prompted"?  Are we going to have to
>>     screen-scrape this
>>     > information, or is it a well defined structure?
>>     >
>>     > > So my suggestion would be to design this where there is a simple
>> web
>>     > > form prompting for username/password but allow for the fact you
>>     may have
>>     > > to redirect to another page.
>>     > >
>>     >
>>     > As I mentioned early, we already have these generic redirection
>>     > capabilities.    Login is a "workflow" and you can define nodes in
>>     this
>>     > workflow.  The current node in the flow can fail, pass, ignore, or
>>     challenge
>>     > an incoming request.
>>     >
>>     > >
>>     > > Does that help?
>>     > >
>>     >
>>     > We're getting there!  :)  My current thoughts are that PAM
>> integration
>>     > should be implemented as a Keycloak Authenticator and user profile
>>     lookup,
>>     > via SSSD, should be done via a User Federation Provider (the new
>>     interface).
>>
>>     Phew! I think we are on the same page about it.
>>
>>     >
>>     > Bill
>>
>>     --
>>
>>     abstractj
>>     PGP: 0x84DC9914
>>     _______________________________________________
>>     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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160628/d3dfaf45/attachment-0001.html 

From mstrukel at redhat.com  Tue Jun 28 04:36:51 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 28 Jun 2016 10:36:51 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CALD3Fd2d1c2HKeNHywnNysbr=3G7fs+d3L3sEt6PA-aoHJZi+Q@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<CALD3Fd2d1c2HKeNHywnNysbr=3G7fs+d3L3sEt6PA-aoHJZi+Q@mail.gmail.com>
Message-ID: <CA+1OW+iTEFt6R4jV91nRzGB5Q_vNXExubFfBC05-UMxkVaQN=w@mail.gmail.com>

An interesting project. However, for a tool that will be a part of Keycloak
server distribution, using javascript doesn't make much sense when
everything else we have is in Java including tested existing libraries that
CLI will need to use.

On Mon, Jun 27, 2016 at 2:50 PM, Luke Holmquist <lholmqui at redhat.com> wrote:

> if you are interested in writing this cli in javascript,  there is this
> little project i had been working on ,
> https://github.com/bucharest-gold/keycloak-admin-client
>
> On Mon, Jun 27, 2016 at 7:48 AM, Marko Strukelj <mstrukel at redhat.com>
> wrote:
>
>> I've started work on Client Registration CLI tool. As a first step, here
>> is a design document describing how I imagine the tool would be used.
>>
>>
>>
>> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
>>
>>
>> I'll use this document as a spec / guide as I implement the client tool.
>>
>> Within days I'll also send a link to initial ideas for Admin Client tool
>> which in principle should allow administrator to configure everything that
>> can otherwise be done through Admin Console.
>>
>> Any feedback welcome.
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160628/c97844c9/attachment.html 

From mstrukel at redhat.com  Tue Jun 28 05:40:59 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 28 Jun 2016 11:40:59 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
Message-ID: <CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>

On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com> wrote:
>
>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
>> > I've started work on Client Registration CLI tool. As a first step, here
>> > is a design document describing how I imagine the tool would be used.
>> >
>> >
>> >
>> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
>> >
>> >
>> > I'll use this document as a spec / guide as I implement the client tool.
>> >
>> > Within days I'll also send a link to initial ideas for Admin Client tool
>> > which in principle should allow administrator to configure everything
>> > that can otherwise be done through Admin Console.
>> >
>> > Any feedback welcome.
>>
>> FWIW we've already written a client registration tool for Keycloak. At
>> the moment it is specifically targeted for SAML clients (SP, Service
>> Provider) in Apache HTTPD but we have plans to extend it to OIDC.
>>
>> It is currently in Fedora and will also ship in OSP.
>>
>> It is hosted here:
>> https://github.com/jdennis/keycloak-httpd-client-install
>>
>> The man page for it (formatted for HTML) can be found here:
>> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
>>
>> The man page discusses 3 different ways you can authenticate and 2
>> different ways client registration can be performed.
>>
>> I have a lot of experience with Keycloak client registration tools and
>> have worked through many issues, I'm happy to share my experience.
>>
>> Here are some thoughts/issues you may want to take into account:
>>
>> * The tool must be capable of running without interactivity as part of a
>> scripted installation task.
>>
>> * It should not depend on a home directory being available.
>>
>> * If a home directory is utilized how will you disambiguate any stored
>> state belonging to a script that is run by different processes but under
>> the same user (possibly simultaneously)? To clarify, many install tools
>> run as the root user or some other admin user. Each invocation of these
>> install tools can be run with entirely different parameters and may
>> execute either in parallel or partially overlapping in time.
>>
>
Maybe I should have included this link in the design document to make it
clear to everyone what Client Registration this tool is for:
http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html

It's a REST API defined by specs, and is separate from Admin REST API.

About using home directory, the way I see it - you either a) specify all
the state when executing a command, or b) you have a mechanism that allows
the concept of 'session' between command invocations.

If you use the first approach (a) then on each invocation of the command
you have to specify either username:password, or a token. The client
registration specification defines workflow for Initial Access Tokens, and
Registration Access Tokens, which require to automatically intercept a
newly issued token after each CRUD operation, and save it for any
subsequent operation on the same client resource. I can't see how this
could be achieved by using the first approach.

For the second approach (b) you need a way to communicate 'session' state.
The state we are saving are just tokens associated with current user or
specific clients, or specific grants. Looks to me that if multiple parallel
sessions are in collision about these tokens then the cli tool itself might
be used the wrong way. Namely, once the client authenticates with a login,
access token and refresh token are cached. Multiple client instances can
use the same access token, and the same refresh token. A thing to maybe be
careful about is just properly locking the file when making changes to it.
For initial access token you have to explicitly add it, and assign it an
alias - you can use any random value there if you want. For registration
access token they are automatically associated with initial token they were
initiated from - again there should be no collision.

What alternative mechanism would you suggest for storing 'session' info? We
want to support Windows as well so it can't be Unix / Bash specific.



>
>> * The tool should be idempotent.
>>
>> * You suggest storing tokens in a cache, how do you plan on handling the
>> case where a token expires before all operations are complete?
>>
>> * We also initially took the approach of caching tokens but discovered
>> the complexity did not justify the minimal cost of obtaining a new token
>> for each invocation. This greatly simplified the code with very little
>> performance impact.
>>
>> * You do not mention what type of client you're registering. I'm
>> assuming it's OpenID but SAML clients (SP) are equally important. The
>> tool must be able to handle both.
>>
>
> Marko is probably referring to the Keycloak client representation, which
> can be either OpenID or SAML. However, we also need to support OpenID
> Connect client descriptions as well as SAML entity descriptors as both are
> supported by client reg services.
>

The CLI needs to know which of the client registration providers (REST
endpoints) to use - there are four as described in the Client Registration
documentation (
http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
)

Ideally the input format of the file could be recognised as only
appropriate for one of these providers, and the correct provider then
automatically used. But maybe we need a way to explicitly tell the tool
what provider to use. For example:

kc new --type default --name test-app --enabled true --base-url
http://localhost:8480/test-app --redirect-uri '
http://localhost:8480/test-app/*' --admin-url
http://localhost:8480/test-app/logout --secret password | kc create --type
default -f -



Having to set --type for both creating a description (kc new), and pushing
it to the server (kc create) is not ideal.


>
>
>>
>> * I don't see anything in your document on how to specify the SAML
>> metadata.
>>
>
Instead of piping in my-client.json, you would pipe in my-client-saml.xml,
possibly requiring an extra --type specifier as described above.


>
>> * I don't see anything in your document on how the user modifies the
>> client. It appears as if you are retrieving a ClientRepresentation JSON
>> document and expecting the user to edit it in a text editor which will
>> then be sent back. That won't work for non-interactive installs. It also
>> presumes the user knows how to read and modify the JSON.
>>
>
> It would be nice to be able to set specific fields without having to
> modify JSON. We discussed that for the Admin CLI, but we should probably
> also add it to the client reg CLI
>

It would be very valuable to see some of the usecases, what kind of changes
people do on existing clients.


>
>
>>
>> * Keycloak currently has a few problems with client registration and
>> it's necessary to modify the client before it will work correctly. We
>> currently do this via the REST API. How are you planning on handling
>> these issues in your installer? It would be nice if the installer was
>> aware of the Keycloak version and could apply "fix-ups" as needed based
>> on the version.
>>
>
> AFAIK you have one problem? About not all redirect URI included from the
> SAML entity descriptor. Is that what you are referring to or do you have
> other problems?
>
> In either case fix-ups should be performed by the client registration
> services, not in the CLI.
>
>
>>
>> * Keycloak has two ways to register a client (client registration
>> service vs. REST API). The two methods do not produce the same client
>> configuration (I suspect because they do not share common code in the
>> server). How are you planning on addressing the discrepancies?
>>
>
> The task of the CLI is not to address any discrepancies. It's just
> invoking the client reg services. Any discrepancies should be handled by
> the client reg services themselves. Have you created JIRA's for these or
> can you list them to us?
>
>
>>
>> * The tool should be smart enough to produce a working client without
>> manual intervention (i.e. the need to run admin cli commands afterwards
>> to fix problems). Most admins won't know how to tweak the configuration.
>>
>
> Can you list any you are aware of? Same comment as above applies though,
> it's the responsibility of the client reg services to handle this, not the
> CLI. Otherwise you'd have different behavior if you invoke client reg
> services directly rather than through the CLI.
>
>
>>
>> * The tool should not have significant dependencies.
>>
>
> It'll be a fat-jar and will have a single dependency on the JVM.
>
>
>>
>> Those are the thoughts off the top of my head, as you fill out the
>> details I'll continue to review. Recall the plan of record is for
>> Keycloak to provide such tools which we will then utilize. The
>> keycloak-httpd-client-install tool is a stop-gap solution until such
>> time as "offical" tools become available.
>>
>>
>>
>> --
>> John
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160628/5cece369/attachment-0001.html 

From jdennis at redhat.com  Tue Jun 28 09:28:46 2016
From: jdennis at redhat.com (John Dennis)
Date: Tue, 28 Jun 2016 09:28:46 -0400
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
Message-ID: <218b003d-be25-4335-8355-2f0336728efa@redhat.com>

On 06/28/2016 01:35 AM, Stian Thorgersen wrote:
> AFAIK you have one problem? About not all redirect URI included from the
> SAML entity descriptor. Is that what you are referring to or do you have
> other problems?
>
> In either case fix-ups should be performed by the client registration
> services, not in the CLI.
>
>
>
>     * Keycloak has two ways to register a client (client registration
>     service vs. REST API). The two methods do not produce the same client
>     configuration (I suspect because they do not share common code in the
>     server). How are you planning on addressing the discrepancies?
>
>
> The task of the CLI is not to address any discrepancies. It's just
> invoking the client reg services. Any discrepancies should be handled by
> the client reg services themselves. Have you created JIRA's for these or
> can you list them to us?

I think these are all things previously discussed, but here is a recap:

* Force POST Binding must be enabled (saml.force.post.binding). This is 
an example of where the client registration service and the REST API 
have different behavior. One of them produces a ClientRepresentation 
with this SAML attribute defaulted to False and the other defaults it to 
True. I believe the consensus is that this flag needs to be removed 
because it's inconsistent with the SAML spec. On the client side we need 
to know if we are talking to a server which implements the flag or not, 
so far we do not have that check implemented.

* Adding all the SAML binding endpoints to the list of Redirect URI's. 
The endpoint's are present in the SAML Metadata sent to Keycloak but for 
some reason they are ignored. A related issue (not specific to client 
registration) is significant parts of the SAML metadata is ignored and 
discarded (among these are the endpoints)

* Adding the group attribute mapper to the client. A reasonable argument 
could be made this is not part of initial client registration but rather 
a post registration configuration operation. However without group 
information many SAML SP's will not operate correctly because groups are 
typically used to make authorization access decisions. Therefore we must 
assure a new client will return group attribute information.



>
>
>
>     * The tool should be smart enough to produce a working client without
>     manual intervention (i.e. the need to run admin cli commands afterwards
>     to fix problems). Most admins won't know how to tweak the configuration.
>
>
> Can you list any you are aware of? Same comment as above applies though,
> it's the responsibility of the client reg services to handle this, not
> the CLI. Otherwise you'd have different behavior if you invoke client
> reg services directly rather than through the CLI.




-- 
John

From mstrukel at redhat.com  Tue Jun 28 10:22:01 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 28 Jun 2016 16:22:01 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
Message-ID: <CA+1OW+hy+24PuPYus10HnyLuyYbsVsA=ELPvd=KMS99hgoeRpA@mail.gmail.com>

On Tue, Jun 28, 2016 at 11:40 AM, Marko Strukelj <mstrukel at redhat.com>
wrote:

>
>
> On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com> wrote:
>>
>>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
>>> > I've started work on Client Registration CLI tool. As a first step,
>>> here
>>> > is a design document describing how I imagine the tool would be used.
>>> >
>>> >
>>> >
>>> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
>>> >
>>> >
>>> > I'll use this document as a spec / guide as I implement the client
>>> tool.
>>> >
>>> > Within days I'll also send a link to initial ideas for Admin Client
>>> tool
>>> > which in principle should allow administrator to configure everything
>>> > that can otherwise be done through Admin Console.
>>> >
>>> > Any feedback welcome.
>>>
>>> FWIW we've already written a client registration tool for Keycloak. At
>>> the moment it is specifically targeted for SAML clients (SP, Service
>>> Provider) in Apache HTTPD but we have plans to extend it to OIDC.
>>>
>>> It is currently in Fedora and will also ship in OSP.
>>>
>>> It is hosted here:
>>> https://github.com/jdennis/keycloak-httpd-client-install
>>>
>>> The man page for it (formatted for HTML) can be found here:
>>> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
>>>
>>> The man page discusses 3 different ways you can authenticate and 2
>>> different ways client registration can be performed.
>>>
>>> I have a lot of experience with Keycloak client registration tools and
>>> have worked through many issues, I'm happy to share my experience.
>>>
>>> Here are some thoughts/issues you may want to take into account:
>>>
>>> * The tool must be capable of running without interactivity as part of a
>>> scripted installation task.
>>>
>>> * It should not depend on a home directory being available.
>>>
>>> * If a home directory is utilized how will you disambiguate any stored
>>> state belonging to a script that is run by different processes but under
>>> the same user (possibly simultaneously)? To clarify, many install tools
>>> run as the root user or some other admin user. Each invocation of these
>>> install tools can be run with entirely different parameters and may
>>> execute either in parallel or partially overlapping in time.
>>>
>>
> Maybe I should have included this link in the design document to make it
> clear to everyone what Client Registration this tool is for:
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
>
> It's a REST API defined by specs, and is separate from Admin REST API.
>
> About using home directory, the way I see it - you either a) specify all
> the state when executing a command, or b) you have a mechanism that allows
> the concept of 'session' between command invocations.
>
> If you use the first approach (a) then on each invocation of the command
> you have to specify either username:password, or a token. The client
> registration specification defines workflow for Initial Access Tokens, and
> Registration Access Tokens, which require to automatically intercept a
> newly issued token after each CRUD operation, and save it for any
> subsequent operation on the same client resource. I can't see how this
> could be achieved by using the first approach.
>
> For the second approach (b) you need a way to communicate 'session' state.
> The state we are saving are just tokens associated with current user or
> specific clients, or specific grants. Looks to me that if multiple parallel
> sessions are in collision about these tokens then the cli tool itself might
> be used the wrong way. Namely, once the client authenticates with a login,
> access token and refresh token are cached. Multiple client instances can
> use the same access token, and the same refresh token. A thing to maybe be
> careful about is just properly locking the file when making changes to it.
> For initial access token you have to explicitly add it, and assign it an
> alias - you can use any random value there if you want. For registration
> access token they are automatically associated with initial token they were
> initiated from - again there should be no collision.
>
> What alternative mechanism would you suggest for storing 'session' info?
> We want to support Windows as well so it can't be Unix / Bash specific.
>
>
Thinking a bit more about this, I think OpenShift Client solves this
problem by allowing you to specify a path to .kubeconfig file (via
--credentials or --config argument) which I believe serves the same purpose
as the proposed kc.cache file.

So by adding something like --config PATH or --credentials PATH or --cachefile
PATH you can use a random file path for each 'session', and thus achieve
clear separation.

For example:

$ kc login -s http://localhost:8080/auth -r $REALM -u $USER -p
$PASSWORD --config
/tmp/.kc_$SESSION.cfg

$ kc create --config /tmp/.kc_$SESSION.cfg -f /tmp/.kc_client_$SESSION.json
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160628/fff5f5a4/attachment.html 

From alexander.schwartz at gmx.net  Wed Jun 29 05:13:04 2016
From: alexander.schwartz at gmx.net (Alexander Schwartz)
Date: Wed, 29 Jun 2016 11:13:04 +0200
Subject: [keycloak-dev] KEYCLOAK-2684 / support Jetty 9.3
Message-ID: <trinity-2c236917-9db2-4c4b-82ad-adb3a85771c9-1467191584121@3capp-gmx-bs47>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160629/411656be/attachment.html 

From sthorger at redhat.com  Wed Jun 29 07:09:23 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 29 Jun 2016 13:09:23 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
Message-ID: <CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>

On 28 June 2016 at 11:40, Marko Strukelj <mstrukel at redhat.com> wrote:

>
>
> On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com> wrote:
>>
>>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
>>> > I've started work on Client Registration CLI tool. As a first step,
>>> here
>>> > is a design document describing how I imagine the tool would be used.
>>> >
>>> >
>>> >
>>> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
>>> >
>>> >
>>> > I'll use this document as a spec / guide as I implement the client
>>> tool.
>>> >
>>> > Within days I'll also send a link to initial ideas for Admin Client
>>> tool
>>> > which in principle should allow administrator to configure everything
>>> > that can otherwise be done through Admin Console.
>>> >
>>> > Any feedback welcome.
>>>
>>> FWIW we've already written a client registration tool for Keycloak. At
>>> the moment it is specifically targeted for SAML clients (SP, Service
>>> Provider) in Apache HTTPD but we have plans to extend it to OIDC.
>>>
>>> It is currently in Fedora and will also ship in OSP.
>>>
>>> It is hosted here:
>>> https://github.com/jdennis/keycloak-httpd-client-install
>>>
>>> The man page for it (formatted for HTML) can be found here:
>>> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
>>>
>>> The man page discusses 3 different ways you can authenticate and 2
>>> different ways client registration can be performed.
>>>
>>> I have a lot of experience with Keycloak client registration tools and
>>> have worked through many issues, I'm happy to share my experience.
>>>
>>> Here are some thoughts/issues you may want to take into account:
>>>
>>> * The tool must be capable of running without interactivity as part of a
>>> scripted installation task.
>>>
>>> * It should not depend on a home directory being available.
>>>
>>> * If a home directory is utilized how will you disambiguate any stored
>>> state belonging to a script that is run by different processes but under
>>> the same user (possibly simultaneously)? To clarify, many install tools
>>> run as the root user or some other admin user. Each invocation of these
>>> install tools can be run with entirely different parameters and may
>>> execute either in parallel or partially overlapping in time.
>>>
>>
> Maybe I should have included this link in the design document to make it
> clear to everyone what Client Registration this tool is for:
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
>
> It's a REST API defined by specs, and is separate from Admin REST API.
>
> About using home directory, the way I see it - you either a) specify all
> the state when executing a command, or b) you have a mechanism that allows
> the concept of 'session' between command invocations.
>
> If you use the first approach (a) then on each invocation of the command
> you have to specify either username:password, or a token. The client
> registration specification defines workflow for Initial Access Tokens, and
> Registration Access Tokens, which require to automatically intercept a
> newly issued token after each CRUD operation, and save it for any
> subsequent operation on the same client resource. I can't see how this
> could be achieved by using the first approach.
>
> For the second approach (b) you need a way to communicate 'session' state.
> The state we are saving are just tokens associated with current user or
> specific clients, or specific grants. Looks to me that if multiple parallel
> sessions are in collision about these tokens then the cli tool itself might
> be used the wrong way. Namely, once the client authenticates with a login,
> access token and refresh token are cached. Multiple client instances can
> use the same access token, and the same refresh token. A thing to maybe be
> careful about is just properly locking the file when making changes to it.
> For initial access token you have to explicitly add it, and assign it an
> alias - you can use any random value there if you want. For registration
> access token they are automatically associated with initial token they were
> initiated from - again there should be no collision.
>

I like the option to have two approaches as there are two use-cases. One is
manually registering for example during development or when manually
configuring an application to use Keycloak. Another is scripted. Even for
scripted you may quite likely want to just add service account credentials
or initial access token directly to ~/.keycloak/ rather than pass these to
the commands.

Registration access tokens are associated with a client, not an initial
access token. Also, remember the registration access token is changed on
updates.


>
> What alternative mechanism would you suggest for storing 'session' info?
> We want to support Windows as well so it can't be Unix / Bash specific.
>
>
>
>>
>>> * The tool should be idempotent.
>>>
>>> * You suggest storing tokens in a cache, how do you plan on handling the
>>> case where a token expires before all operations are complete?
>>>
>>> * We also initially took the approach of caching tokens but discovered
>>> the complexity did not justify the minimal cost of obtaining a new token
>>> for each invocation. This greatly simplified the code with very little
>>> performance impact.
>>>
>>> * You do not mention what type of client you're registering. I'm
>>> assuming it's OpenID but SAML clients (SP) are equally important. The
>>> tool must be able to handle both.
>>>
>>
>> Marko is probably referring to the Keycloak client representation, which
>> can be either OpenID or SAML. However, we also need to support OpenID
>> Connect client descriptions as well as SAML entity descriptors as both are
>> supported by client reg services.
>>
>
> The CLI needs to know which of the client registration providers (REST
> endpoints) to use - there are four as described in the Client Registration
> documentation (
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> )
>
> Ideally the input format of the file could be recognised as only
> appropriate for one of these providers, and the correct provider then
> automatically used. But maybe we need a way to explicitly tell the tool
> what provider to use. For example:
>
> kc new --type default --name test-app --enabled true --base-url
> http://localhost:8480/test-app --redirect-uri '
> http://localhost:8480/test-app/*' --admin-url
> http://localhost:8480/test-app/logout --secret password | kc create
> --type default -f -
>
>
>
> Having to set --type for both creating a description (kc new), and
> pushing it to the server (kc create) is not ideal.
>

We can detect the difference between Keycloak client rep, SAML and OIDC
json that's pretty trivial and we should do that. However, there needs to
be a way to specify the provider as well as there could be custom providers
added.

For getting the client it should by default return Keycloak client
representation, but we need an option to be able to specify the provider so
it can return the client installation file instead.

With regards to creating by passing arguments rather than a file that
should only support client representation files.



>
>
>>
>>
>>>
>>> * I don't see anything in your document on how to specify the SAML
>>> metadata.
>>>
>>
> Instead of piping in my-client.json, you would pipe in my-client-saml.xml,
> possibly requiring an extra --type specifier as described above.
>
>
>>
>>> * I don't see anything in your document on how the user modifies the
>>> client. It appears as if you are retrieving a ClientRepresentation JSON
>>> document and expecting the user to edit it in a text editor which will
>>> then be sent back. That won't work for non-interactive installs. It also
>>> presumes the user knows how to read and modify the JSON.
>>>
>>
>> It would be nice to be able to set specific fields without having to
>> modify JSON. We discussed that for the Admin CLI, but we should probably
>> also add it to the client reg CLI
>>
>
> It would be very valuable to see some of the usecases, what kind of
> changes people do on existing clients.
>

We should support anything that is in client representation. It should just
be a generic way to change json fields. For example:

# kcreg update <client id> --set enabled=false --set baseUrl=
http://new-url/myapp --remove rootUrl

This would get the KC client rep, change the corresponding fields and send
it back.


>
>
>>
>>
>>>
>>> * Keycloak currently has a few problems with client registration and
>>> it's necessary to modify the client before it will work correctly. We
>>> currently do this via the REST API. How are you planning on handling
>>> these issues in your installer? It would be nice if the installer was
>>> aware of the Keycloak version and could apply "fix-ups" as needed based
>>> on the version.
>>>
>>
>> AFAIK you have one problem? About not all redirect URI included from the
>> SAML entity descriptor. Is that what you are referring to or do you have
>> other problems?
>>
>> In either case fix-ups should be performed by the client registration
>> services, not in the CLI.
>>
>>
>>>
>>> * Keycloak has two ways to register a client (client registration
>>> service vs. REST API). The two methods do not produce the same client
>>> configuration (I suspect because they do not share common code in the
>>> server). How are you planning on addressing the discrepancies?
>>>
>>
>> The task of the CLI is not to address any discrepancies. It's just
>> invoking the client reg services. Any discrepancies should be handled by
>> the client reg services themselves. Have you created JIRA's for these or
>> can you list them to us?
>>
>>
>>>
>>> * The tool should be smart enough to produce a working client without
>>> manual intervention (i.e. the need to run admin cli commands afterwards
>>> to fix problems). Most admins won't know how to tweak the configuration.
>>>
>>
>> Can you list any you are aware of? Same comment as above applies though,
>> it's the responsibility of the client reg services to handle this, not the
>> CLI. Otherwise you'd have different behavior if you invoke client reg
>> services directly rather than through the CLI.
>>
>>
>>>
>>> * The tool should not have significant dependencies.
>>>
>>
>> It'll be a fat-jar and will have a single dependency on the JVM.
>>
>>
>>>
>>> Those are the thoughts off the top of my head, as you fill out the
>>> details I'll continue to review. Recall the plan of record is for
>>> Keycloak to provide such tools which we will then utilize. The
>>> keycloak-httpd-client-install tool is a stop-gap solution until such
>>> time as "offical" tools become available.
>>>
>>>
>>>
>>> --
>>> John
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160629/9c76865a/attachment-0001.html 

From sthorger at redhat.com  Wed Jun 29 07:11:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 29 Jun 2016 13:11:07 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <218b003d-be25-4335-8355-2f0336728efa@redhat.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<218b003d-be25-4335-8355-2f0336728efa@redhat.com>
Message-ID: <CAJgngAdhapTjRJV-QFu6ahELHjeA6vndg=HFKXwmiwtjWBkmPQ@mail.gmail.com>

On 28 June 2016 at 15:28, John Dennis <jdennis at redhat.com> wrote:

> On 06/28/2016 01:35 AM, Stian Thorgersen wrote:
>
>> AFAIK you have one problem? About not all redirect URI included from the
>> SAML entity descriptor. Is that what you are referring to or do you have
>> other problems?
>>
>> In either case fix-ups should be performed by the client registration
>> services, not in the CLI.
>>
>>
>>
>>     * Keycloak has two ways to register a client (client registration
>>     service vs. REST API). The two methods do not produce the same client
>>     configuration (I suspect because they do not share common code in the
>>     server). How are you planning on addressing the discrepancies?
>>
>>
>> The task of the CLI is not to address any discrepancies. It's just
>> invoking the client reg services. Any discrepancies should be handled by
>> the client reg services themselves. Have you created JIRA's for these or
>> can you list them to us?
>>
>
> I think these are all things previously discussed, but here is a recap:
>
> * Force POST Binding must be enabled (saml.force.post.binding). This is an
> example of where the client registration service and the REST API have
> different behavior. One of them produces a ClientRepresentation with this
> SAML attribute defaulted to False and the other defaults it to True. I
> believe the consensus is that this flag needs to be removed because it's
> inconsistent with the SAML spec. On the client side we need to know if we
> are talking to a server which implements the flag or not, so far we do not
> have that check implemented.
>
> * Adding all the SAML binding endpoints to the list of Redirect URI's. The
> endpoint's are present in the SAML Metadata sent to Keycloak but for some
> reason they are ignored. A related issue (not specific to client
> registration) is significant parts of the SAML metadata is ignored and
> discarded (among these are the endpoints)
>
> * Adding the group attribute mapper to the client. A reasonable argument
> could be made this is not part of initial client registration but rather a
> post registration configuration operation. However without group
> information many SAML SP's will not operate correctly because groups are
> typically used to make authorization access decisions. Therefore we must
> assure a new client will return group attribute information.


Can you create JIRAs for these please?


>
>

>
>
>
>>
>>
>>     * The tool should be smart enough to produce a working client without
>>     manual intervention (i.e. the need to run admin cli commands
>> afterwards
>>     to fix problems). Most admins won't know how to tweak the
>> configuration.
>>
>>
>> Can you list any you are aware of? Same comment as above applies though,
>> it's the responsibility of the client reg services to handle this, not
>> the CLI. Otherwise you'd have different behavior if you invoke client
>> reg services directly rather than through the CLI.
>>
>
>
>
>
> --
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160629/db047fe2/attachment.html 

From thomas.darimont at googlemail.com  Wed Jun 29 11:55:54 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 29 Jun 2016 17:55:54 +0200
Subject: [keycloak-dev] Code cleanup
Message-ID: <CAK-7U1jsvgF7JF3M6Qqzc_u+uuyM8bQvN5UAt_bM6_XBE_5Wiw@mail.gmail.com>

Hello group,

I just ran findbugs [1] with the find-sec-bugs [0] and found quite a bunch
of rather
suspicious places in the Keycloak codebase.

Note that I don't wont to blame anyone but rather try to improve the
codebase :)

For instance there are some quite prominent (and sensitive) non-final
public static fields that could
be easily changed to something else (in case they aren't inlined).
https://github.com/keycloak/keycloak/blob/3c0f7e2ee2140a9e69e4e95eb24d5a122e63e09a/server-spi/src/main/java/org/keycloak/models/AdminRoles.java#L25

Further more there seem to be some dead code left-overs from merges spread
over the codebase e.g:
https://github.com/keycloak/keycloak/blob/3a669ad7d5b4a72a8eb2bbb23e91083b63f59a2f/adapters/saml/tomcat/tomcat-core/src/main/java/org/keycloak/adapters/saml/CatalinaSamlSessionStore.java#L144

Question is how to deal with that?
I could send PRs for those issues - they would contain quite a bunch of
files
with minor changes. Would you be open to such contributions and if so, what
JIRA issue
should one reference here?

Cheers,
Thomas

[0] http://find-sec-bugs.github.io/
[1] https://github.com/find-sec-bugs/find-sec-bugs/wiki/Maven-configuration
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160629/fb2bf8b0/attachment.html 

From bruno at abstractj.org  Wed Jun 29 15:24:54 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 29 Jun 2016 12:24:54 -0700
Subject: [keycloak-dev] Code cleanup
In-Reply-To: <CAK-7U1jsvgF7JF3M6Qqzc_u+uuyM8bQvN5UAt_bM6_XBE_5Wiw@mail.gmail.com>
References: <CAK-7U1jsvgF7JF3M6Qqzc_u+uuyM8bQvN5UAt_bM6_XBE_5Wiw@mail.gmail.com>
Message-ID: <20160629192454.GA3221@abstractj.org>

Hi Thomas, some months ago I did the same with findbugs, the problems is
the fact that the plugin can show you some false positives, into other
situations where they are not exploitable. For example, non final public
static fields for let's say a code with no exposure.

For the dead code, I would definitely file a Jira and submit a PR. For
the security reports from findbugs, maybe a separated (sensitive) Jira
makes sense.

In this way we evaluated how likely and exploitable is the issue.

Makes sense?

On 2016-06-29, Thomas Darimont wrote:
> Hello group,
>
> I just ran findbugs [1] with the find-sec-bugs [0] and found quite a bunch
> of rather
> suspicious places in the Keycloak codebase.
>
> Note that I don't wont to blame anyone but rather try to improve the
> codebase :)
>
> For instance there are some quite prominent (and sensitive) non-final
> public static fields that could
> be easily changed to something else (in case they aren't inlined).
> https://github.com/keycloak/keycloak/blob/3c0f7e2ee2140a9e69e4e95eb24d5a122e63e09a/server-spi/src/main/java/org/keycloak/models/AdminRoles.java#L25
>
> Further more there seem to be some dead code left-overs from merges spread
> over the codebase e.g:
> https://github.com/keycloak/keycloak/blob/3a669ad7d5b4a72a8eb2bbb23e91083b63f59a2f/adapters/saml/tomcat/tomcat-core/src/main/java/org/keycloak/adapters/saml/CatalinaSamlSessionStore.java#L144
>
> Question is how to deal with that?
> I could send PRs for those issues - they would contain quite a bunch of
> files
> with minor changes. Would you be open to such contributions and if so, what
> JIRA issue
> should one reference here?
>
> Cheers,
> Thomas
>
> [0] http://find-sec-bugs.github.io/
> [1] https://github.com/find-sec-bugs/find-sec-bugs/wiki/Maven-configuration

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


--

abstractj
PGP: 0x84DC9914

From watson409 at gmail.com  Wed Jun 29 15:36:00 2016
From: watson409 at gmail.com (Brian Watson)
Date: Wed, 29 Jun 2016 15:36:00 -0400
Subject: [keycloak-dev] User updates not reflected in validateAndProxy()
Message-ID: <CAC9D9d-mK0Y9wvkx5uE99OdYC4cuZDMCrptw_bug7AGRAr7qqA@mail.gmail.com>

Hi all,

I am creating a custom user federation provider as a temporary bridge to
sync users between our old, custom auth solution's database and Keycloak. I
noticed an issue, and was looking for some clarification:

When I update a user via the administration UI, the validateAndProxy()
method of my UserFederationProvider instance is called, as expected.
However, the user passed into the method call contains the _old_
information for the user, not the _updated_ information. I set a breakpoint
in my code, and at the time that validateAndProxy() is called, the data
store still contains the _old_ information. Is this expected behavior? Is
there another SPI I should be using to see the updated information for the
user so that I can sync it with my data store?

Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160629/e6ac890b/attachment.html 

From bruno at abstractj.org  Wed Jun 29 15:43:33 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 29 Jun 2016 12:43:33 -0700
Subject: [keycloak-dev] PAM integration with FreeIPA
In-Reply-To: <CAJgngAej6AL_sV15dw0muVDvcvZTnSzNqQy+zoFC-yV5u3NjUw@mail.gmail.com>
References: <44d58191-79c8-865e-281f-fc3f34f32415@redhat.com>
	<20160623185658.GD6983@abstractj.org>
	<33b6139f-a295-59b7-3aca-770a7682070f@redhat.com>
	<20160624130743.GA22962@abstractj.org>
	<764b1cbe-02c9-1bf6-2736-6f322020b01c@redhat.com>
	<16be3de6-86f7-f7d7-475d-9f050d1e5ca7@redhat.com>
	<20160624171430.GA30566@abstractj.org>
	<CAJgngAcY0W=V5=dO3q5Wh6M_JX82tOPMzebzn175SMtcJ2pNxw@mail.gmail.com>
	<446d2e25-1242-4212-28c8-74c9e2d0cc5f@redhat.com>
	<CAJgngAej6AL_sV15dw0muVDvcvZTnSzNqQy+zoFC-yV5u3NjUw@mail.gmail.com>
Message-ID: <20160629194333.GA4141@abstractj.org>

That's not how PAM conversations where supposed to work from my
standpoint. From my understanding, a second factor can be an OTP, secret
question or any other thing.

Indeed libpam4j is quite limited and does not include such conversations
as part of this scope. My last resort is to provide the proper bindings
to make this happen, not easy, not stupid simple, but possible.

On 2016-06-28, Stian Thorgersen wrote:
> That only works if all users have OTP setup. I don't think we can rely on
> that and we'll have to support both options.
>
> On 27 June 2016 at 14:24, Bill Burke <bburke at redhat.com> wrote:
>
> > Don't think that is an issue either.  We can just write another a
> > different flow for PAM and gather password and OTP on the same page, or the
> > same field like RHT IT does for our login.
> >
> > On 6/27/16 2:27 AM, Stian Thorgersen wrote:
> >
> >> My hope was that PAM would support verifying password and OTP as two
> >> completely separate calls without requiring a conversation and state
> >> between them. However, sounds like that's not possible. If libpam4j
> >> doesn't even support OTP it makes matters even worse.
> >>
> >> The sooner we can use SSSD rather than PAM for authentication the
> >> better. Or at least do the OTP verification over SSSD.
> >>
> >> On 24 June 2016 at 19:14, Bruno Oliveira <bruno at abstractj.org
> >> <mailto:bruno at abstractj.org>> wrote:
> >>
> >>     On 2016-06-24, Bill Burke wrote:
> >>     >
> >>     >
> >>     > On 6/24/16 9:53 AM, John Dennis wrote:
> >>     >
> >>     > >
> >>     > > Let me try to clarify a few things.
> >>     > >
> >>     > > PAM is designed as a "conversation", there are a few analogues
> >>     you could
> >>     > > compare it to:
> >>     > >
> >>     > > * a series of requests/responses
> >>     > >
> >>     > > * challenge/response authentication (e.g. CRAM)
> >>     > >
> >>     > > PAM has something equivalent to a session where state is stored
> >>     during
> >>     > > the "conversation". When you use PAM you establish a context
> >>     (session)
> >>     > > and iterate. In each iteration the PAM library will ask you for
> >>     > > something and you reply. The iteration stops when the library
> >>     signals
> >>     > > completion.
> >>     > >
> >>     >
> >>     > Will the PAM conversation object be able to be serialized
> >>     in-between web
> >>     > requests? Is it something that can be rebuilt with HTTP session
> >>     information?
> >>     >
> >>     > > For simple password auth the iteration is very short. But
> >>     depending on
> >>     > > how the PAM service is configured you could be prompted for other
> >>     > > things. I suspect with Web forms they way you handle this is via
> >>     > > redirects until such time as the PAM conversation completes.
> >>     > >
> >>     >
> >>     > What do you mean by "prompted"?  Are we going to have to
> >>     screen-scrape this
> >>     > information, or is it a well defined structure?
> >>     >
> >>     > > So my suggestion would be to design this where there is a simple
> >> web
> >>     > > form prompting for username/password but allow for the fact you
> >>     may have
> >>     > > to redirect to another page.
> >>     > >
> >>     >
> >>     > As I mentioned early, we already have these generic redirection
> >>     > capabilities.    Login is a "workflow" and you can define nodes in
> >>     this
> >>     > workflow.  The current node in the flow can fail, pass, ignore, or
> >>     challenge
> >>     > an incoming request.
> >>     >
> >>     > >
> >>     > > Does that help?
> >>     > >
> >>     >
> >>     > We're getting there!  :)  My current thoughts are that PAM
> >> integration
> >>     > should be implemented as a Keycloak Authenticator and user profile
> >>     lookup,
> >>     > via SSSD, should be done via a User Federation Provider (the new
> >>     interface).
> >>
> >>     Phew! I think we are on the same page about it.
> >>
> >>     >
> >>     > Bill
> >>
> >>     --
> >>
> >>     abstractj
> >>     PGP: 0x84DC9914
> >>     _______________________________________________
> >>     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
> >>
> >>
> >>

--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Wed Jun 29 15:49:34 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 29 Jun 2016 12:49:34 -0700
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
	<CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>
Message-ID: <20160629194934.GB4141@abstractj.org>

I'm not sure if it's part of the scope for now. But
thinking about situations where you have to automate jobs plus provide
credentials without exposing them.

My suggestion, even if it's not part of the scope for now is to encrypt it,
like travis does[1]. I know that our plan is to deal of access token,
but would be nice to not expose credentials not even a single time.


[1] - https://docs.travis-ci.com/user/encryption-keys/

On 2016-06-29, Stian Thorgersen wrote:
> On 28 June 2016 at 11:40, Marko Strukelj <mstrukel at redhat.com> wrote:
>
> >
> >
> > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> >
> >>
> >>
> >> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com> wrote:
> >>
> >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
> >>> > I've started work on Client Registration CLI tool. As a first step,
> >>> here
> >>> > is a design document describing how I imagine the tool would be used.
> >>> >
> >>> >
> >>> >
> >>> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
> >>> >
> >>> >
> >>> > I'll use this document as a spec / guide as I implement the client
> >>> tool.
> >>> >
> >>> > Within days I'll also send a link to initial ideas for Admin Client
> >>> tool
> >>> > which in principle should allow administrator to configure everything
> >>> > that can otherwise be done through Admin Console.
> >>> >
> >>> > Any feedback welcome.
> >>>
> >>> FWIW we've already written a client registration tool for Keycloak. At
> >>> the moment it is specifically targeted for SAML clients (SP, Service
> >>> Provider) in Apache HTTPD but we have plans to extend it to OIDC.
> >>>
> >>> It is currently in Fedora and will also ship in OSP.
> >>>
> >>> It is hosted here:
> >>> https://github.com/jdennis/keycloak-httpd-client-install
> >>>
> >>> The man page for it (formatted for HTML) can be found here:
> >>> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
> >>>
> >>> The man page discusses 3 different ways you can authenticate and 2
> >>> different ways client registration can be performed.
> >>>
> >>> I have a lot of experience with Keycloak client registration tools and
> >>> have worked through many issues, I'm happy to share my experience.
> >>>
> >>> Here are some thoughts/issues you may want to take into account:
> >>>
> >>> * The tool must be capable of running without interactivity as part of a
> >>> scripted installation task.
> >>>
> >>> * It should not depend on a home directory being available.
> >>>
> >>> * If a home directory is utilized how will you disambiguate any stored
> >>> state belonging to a script that is run by different processes but under
> >>> the same user (possibly simultaneously)? To clarify, many install tools
> >>> run as the root user or some other admin user. Each invocation of these
> >>> install tools can be run with entirely different parameters and may
> >>> execute either in parallel or partially overlapping in time.
> >>>
> >>
> > Maybe I should have included this link in the design document to make it
> > clear to everyone what Client Registration this tool is for:
> > http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> >
> > It's a REST API defined by specs, and is separate from Admin REST API.
> >
> > About using home directory, the way I see it - you either a) specify all
> > the state when executing a command, or b) you have a mechanism that allows
> > the concept of 'session' between command invocations.
> >
> > If you use the first approach (a) then on each invocation of the command
> > you have to specify either username:password, or a token. The client
> > registration specification defines workflow for Initial Access Tokens, and
> > Registration Access Tokens, which require to automatically intercept a
> > newly issued token after each CRUD operation, and save it for any
> > subsequent operation on the same client resource. I can't see how this
> > could be achieved by using the first approach.
> >
> > For the second approach (b) you need a way to communicate 'session' state.
> > The state we are saving are just tokens associated with current user or
> > specific clients, or specific grants. Looks to me that if multiple parallel
> > sessions are in collision about these tokens then the cli tool itself might
> > be used the wrong way. Namely, once the client authenticates with a login,
> > access token and refresh token are cached. Multiple client instances can
> > use the same access token, and the same refresh token. A thing to maybe be
> > careful about is just properly locking the file when making changes to it.
> > For initial access token you have to explicitly add it, and assign it an
> > alias - you can use any random value there if you want. For registration
> > access token they are automatically associated with initial token they were
> > initiated from - again there should be no collision.
> >
>
> I like the option to have two approaches as there are two use-cases. One is
> manually registering for example during development or when manually
> configuring an application to use Keycloak. Another is scripted. Even for
> scripted you may quite likely want to just add service account credentials
> or initial access token directly to ~/.keycloak/ rather than pass these to
> the commands.
>
> Registration access tokens are associated with a client, not an initial
> access token. Also, remember the registration access token is changed on
> updates.
>
>
> >
> > What alternative mechanism would you suggest for storing 'session' info?
> > We want to support Windows as well so it can't be Unix / Bash specific.
> >
> >
> >
> >>
> >>> * The tool should be idempotent.
> >>>
> >>> * You suggest storing tokens in a cache, how do you plan on handling the
> >>> case where a token expires before all operations are complete?
> >>>
> >>> * We also initially took the approach of caching tokens but discovered
> >>> the complexity did not justify the minimal cost of obtaining a new token
> >>> for each invocation. This greatly simplified the code with very little
> >>> performance impact.
> >>>
> >>> * You do not mention what type of client you're registering. I'm
> >>> assuming it's OpenID but SAML clients (SP) are equally important. The
> >>> tool must be able to handle both.
> >>>
> >>
> >> Marko is probably referring to the Keycloak client representation, which
> >> can be either OpenID or SAML. However, we also need to support OpenID
> >> Connect client descriptions as well as SAML entity descriptors as both are
> >> supported by client reg services.
> >>
> >
> > The CLI needs to know which of the client registration providers (REST
> > endpoints) to use - there are four as described in the Client Registration
> > documentation (
> > http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> > )
> >
> > Ideally the input format of the file could be recognised as only
> > appropriate for one of these providers, and the correct provider then
> > automatically used. But maybe we need a way to explicitly tell the tool
> > what provider to use. For example:
> >
> > kc new --type default --name test-app --enabled true --base-url
> > http://localhost:8480/test-app --redirect-uri '
> > http://localhost:8480/test-app/*' --admin-url
> > http://localhost:8480/test-app/logout --secret password | kc create
> > --type default -f -
> >
> >
> >
> > Having to set --type for both creating a description (kc new), and
> > pushing it to the server (kc create) is not ideal.
> >
>
> We can detect the difference between Keycloak client rep, SAML and OIDC
> json that's pretty trivial and we should do that. However, there needs to
> be a way to specify the provider as well as there could be custom providers
> added.
>
> For getting the client it should by default return Keycloak client
> representation, but we need an option to be able to specify the provider so
> it can return the client installation file instead.
>
> With regards to creating by passing arguments rather than a file that
> should only support client representation files.
>
>
>
> >
> >
> >>
> >>
> >>>
> >>> * I don't see anything in your document on how to specify the SAML
> >>> metadata.
> >>>
> >>
> > Instead of piping in my-client.json, you would pipe in my-client-saml.xml,
> > possibly requiring an extra --type specifier as described above.
> >
> >
> >>
> >>> * I don't see anything in your document on how the user modifies the
> >>> client. It appears as if you are retrieving a ClientRepresentation JSON
> >>> document and expecting the user to edit it in a text editor which will
> >>> then be sent back. That won't work for non-interactive installs. It also
> >>> presumes the user knows how to read and modify the JSON.
> >>>
> >>
> >> It would be nice to be able to set specific fields without having to
> >> modify JSON. We discussed that for the Admin CLI, but we should probably
> >> also add it to the client reg CLI
> >>
> >
> > It would be very valuable to see some of the usecases, what kind of
> > changes people do on existing clients.
> >
>
> We should support anything that is in client representation. It should just
> be a generic way to change json fields. For example:
>
> # kcreg update <client id> --set enabled=false --set baseUrl=
> http://new-url/myapp --remove rootUrl
>
> This would get the KC client rep, change the corresponding fields and send
> it back.
>
>
> >
> >
> >>
> >>
> >>>
> >>> * Keycloak currently has a few problems with client registration and
> >>> it's necessary to modify the client before it will work correctly. We
> >>> currently do this via the REST API. How are you planning on handling
> >>> these issues in your installer? It would be nice if the installer was
> >>> aware of the Keycloak version and could apply "fix-ups" as needed based
> >>> on the version.
> >>>
> >>
> >> AFAIK you have one problem? About not all redirect URI included from the
> >> SAML entity descriptor. Is that what you are referring to or do you have
> >> other problems?
> >>
> >> In either case fix-ups should be performed by the client registration
> >> services, not in the CLI.
> >>
> >>
> >>>
> >>> * Keycloak has two ways to register a client (client registration
> >>> service vs. REST API). The two methods do not produce the same client
> >>> configuration (I suspect because they do not share common code in the
> >>> server). How are you planning on addressing the discrepancies?
> >>>
> >>
> >> The task of the CLI is not to address any discrepancies. It's just
> >> invoking the client reg services. Any discrepancies should be handled by
> >> the client reg services themselves. Have you created JIRA's for these or
> >> can you list them to us?
> >>
> >>
> >>>
> >>> * The tool should be smart enough to produce a working client without
> >>> manual intervention (i.e. the need to run admin cli commands afterwards
> >>> to fix problems). Most admins won't know how to tweak the configuration.
> >>>
> >>
> >> Can you list any you are aware of? Same comment as above applies though,
> >> it's the responsibility of the client reg services to handle this, not the
> >> CLI. Otherwise you'd have different behavior if you invoke client reg
> >> services directly rather than through the CLI.
> >>
> >>
> >>>
> >>> * The tool should not have significant dependencies.
> >>>
> >>
> >> It'll be a fat-jar and will have a single dependency on the JVM.
> >>
> >>
> >>>
> >>> Those are the thoughts off the top of my head, as you fill out the
> >>> details I'll continue to review. Recall the plan of record is for
> >>> Keycloak to provide such tools which we will then utilize. The
> >>> keycloak-httpd-client-install tool is a stop-gap solution until such
> >>> time as "offical" tools become available.
> >>>
> >>>
> >>>
> >>> --
> >>> John
> >>> _______________________________________________
> >>> 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 watson409 at gmail.com  Wed Jun 29 16:26:11 2016
From: watson409 at gmail.com (Brian Watson)
Date: Wed, 29 Jun 2016 16:26:11 -0400
Subject: [keycloak-dev] User updates not reflected in validateAndProxy()
Message-ID: <CAC9D9d9UUuM4TyxdEQ90p5aX_ahs=U7FJgn+T-jOxn8itMumiw@mail.gmail.com>

I think I just answered my question: I should return a delegate from
validateAndProxy() that updates my data store when the delegate receives
updates.

Does this sound like the appropriate approach?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160629/0512e34b/attachment.html 

From mposolda at redhat.com  Wed Jun 29 16:49:05 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 Jun 2016 22:49:05 +0200
Subject: [keycloak-dev] User updates not reflected in validateAndProxy()
In-Reply-To: <CAC9D9d9UUuM4TyxdEQ90p5aX_ahs=U7FJgn+T-jOxn8itMumiw@mail.gmail.com>
References: <CAC9D9d9UUuM4TyxdEQ90p5aX_ahs=U7FJgn+T-jOxn8itMumiw@mail.gmail.com>
Message-ID: <57743441.6060309@redhat.com>

On 29/06/16 22:26, Brian Watson wrote:
> I think I just answered my question: I should return a delegate from 
> validateAndProxy() that updates my data store when the delegate 
> receives updates.
>
> Does this sound like the appropriate approach?
Yes

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

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

From watson409 at gmail.com  Wed Jun 29 17:09:22 2016
From: watson409 at gmail.com (Brian Watson)
Date: Wed, 29 Jun 2016 17:09:22 -0400
Subject: [keycloak-dev] UserFederationProvider.close() not being called
Message-ID: <CAC9D9d-7cfKjn6AFTH0TGk5=mbXqJH3dFmU5m-bgKFgCE3wnHw@mail.gmail.com>

Hi all,

I have set a breakpoint in the close() method of my UserFederationProvider
instance, which is never invoked. I set a breakpoint in the getInstance()
method of my factory, and traced the call to this line:

https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/models/UserFederationManager.java#L146

No where in the stack trace between this line and line 422 of
KeycloakModelUtils (where getInstance() is called) do I see the provider
being stored for later use, such as calling the close() method.

Is this a bug or intended behavior?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160629/e0516809/attachment.html 

From watson409 at gmail.com  Wed Jun 29 17:21:35 2016
From: watson409 at gmail.com (Brian Watson)
Date: Wed, 29 Jun 2016 17:21:35 -0400
Subject: [keycloak-dev] UserFederationProvider.close() not being called
Message-ID: <CAC9D9d9qwozSP3yPvji9HTSeeqWBEW_-Amy0wLGzzEHTWS48Gw@mail.gmail.com>

Would I be correct in thinking that I should call
"session.enlistForClose(provider)" in the getInstance() method of my
factory to ensure close() is called?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160629/a56fb69a/attachment-0001.html 

From sthorger at redhat.com  Thu Jun 30 00:52:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jun 2016 06:52:21 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <20160629194934.GB4141@abstractj.org>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
	<CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>
	<20160629194934.GB4141@abstractj.org>
Message-ID: <CAJgngAeqBDrnSbzGJgrMMFwZbiwj3P7s_t=x_9pDUP=38-Y6kQ@mail.gmail.com>

I don't see the need for that. For the client registration CLI we will
support initial access tokens as well as service accounts with pub/priv key
authentication. For admin cli we'll support service accounts. No one should
be using username/password combined with automated jobs.

On 29 June 2016 at 21:49, Bruno Oliveira <bruno at abstractj.org> wrote:

> I'm not sure if it's part of the scope for now. But
> thinking about situations where you have to automate jobs plus provide
> credentials without exposing them.
>
> My suggestion, even if it's not part of the scope for now is to encrypt it,
> like travis does[1]. I know that our plan is to deal of access token,
> but would be nice to not expose credentials not even a single time.
>
>
> [1] - https://docs.travis-ci.com/user/encryption-keys/
>
> On 2016-06-29, Stian Thorgersen wrote:
> > On 28 June 2016 at 11:40, Marko Strukelj <mstrukel at redhat.com> wrote:
> >
> > >
> > >
> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <sthorger at redhat.com
> >
> > > wrote:
> > >
> > >>
> > >>
> > >> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com> wrote:
> > >>
> > >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
> > >>> > I've started work on Client Registration CLI tool. As a first step,
> > >>> here
> > >>> > is a design document describing how I imagine the tool would be
> used.
> > >>> >
> > >>> >
> > >>> >
> > >>>
> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
> > >>> >
> > >>> >
> > >>> > I'll use this document as a spec / guide as I implement the client
> > >>> tool.
> > >>> >
> > >>> > Within days I'll also send a link to initial ideas for Admin Client
> > >>> tool
> > >>> > which in principle should allow administrator to configure
> everything
> > >>> > that can otherwise be done through Admin Console.
> > >>> >
> > >>> > Any feedback welcome.
> > >>>
> > >>> FWIW we've already written a client registration tool for Keycloak.
> At
> > >>> the moment it is specifically targeted for SAML clients (SP, Service
> > >>> Provider) in Apache HTTPD but we have plans to extend it to OIDC.
> > >>>
> > >>> It is currently in Fedora and will also ship in OSP.
> > >>>
> > >>> It is hosted here:
> > >>> https://github.com/jdennis/keycloak-httpd-client-install
> > >>>
> > >>> The man page for it (formatted for HTML) can be found here:
> > >>>
> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
> > >>>
> > >>> The man page discusses 3 different ways you can authenticate and 2
> > >>> different ways client registration can be performed.
> > >>>
> > >>> I have a lot of experience with Keycloak client registration tools
> and
> > >>> have worked through many issues, I'm happy to share my experience.
> > >>>
> > >>> Here are some thoughts/issues you may want to take into account:
> > >>>
> > >>> * The tool must be capable of running without interactivity as part
> of a
> > >>> scripted installation task.
> > >>>
> > >>> * It should not depend on a home directory being available.
> > >>>
> > >>> * If a home directory is utilized how will you disambiguate any
> stored
> > >>> state belonging to a script that is run by different processes but
> under
> > >>> the same user (possibly simultaneously)? To clarify, many install
> tools
> > >>> run as the root user or some other admin user. Each invocation of
> these
> > >>> install tools can be run with entirely different parameters and may
> > >>> execute either in parallel or partially overlapping in time.
> > >>>
> > >>
> > > Maybe I should have included this link in the design document to make
> it
> > > clear to everyone what Client Registration this tool is for:
> > >
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> > >
> > > It's a REST API defined by specs, and is separate from Admin REST API.
> > >
> > > About using home directory, the way I see it - you either a) specify
> all
> > > the state when executing a command, or b) you have a mechanism that
> allows
> > > the concept of 'session' between command invocations.
> > >
> > > If you use the first approach (a) then on each invocation of the
> command
> > > you have to specify either username:password, or a token. The client
> > > registration specification defines workflow for Initial Access Tokens,
> and
> > > Registration Access Tokens, which require to automatically intercept a
> > > newly issued token after each CRUD operation, and save it for any
> > > subsequent operation on the same client resource. I can't see how this
> > > could be achieved by using the first approach.
> > >
> > > For the second approach (b) you need a way to communicate 'session'
> state.
> > > The state we are saving are just tokens associated with current user or
> > > specific clients, or specific grants. Looks to me that if multiple
> parallel
> > > sessions are in collision about these tokens then the cli tool itself
> might
> > > be used the wrong way. Namely, once the client authenticates with a
> login,
> > > access token and refresh token are cached. Multiple client instances
> can
> > > use the same access token, and the same refresh token. A thing to
> maybe be
> > > careful about is just properly locking the file when making changes to
> it.
> > > For initial access token you have to explicitly add it, and assign it
> an
> > > alias - you can use any random value there if you want. For
> registration
> > > access token they are automatically associated with initial token they
> were
> > > initiated from - again there should be no collision.
> > >
> >
> > I like the option to have two approaches as there are two use-cases. One
> is
> > manually registering for example during development or when manually
> > configuring an application to use Keycloak. Another is scripted. Even for
> > scripted you may quite likely want to just add service account
> credentials
> > or initial access token directly to ~/.keycloak/ rather than pass these
> to
> > the commands.
> >
> > Registration access tokens are associated with a client, not an initial
> > access token. Also, remember the registration access token is changed on
> > updates.
> >
> >
> > >
> > > What alternative mechanism would you suggest for storing 'session'
> info?
> > > We want to support Windows as well so it can't be Unix / Bash specific.
> > >
> > >
> > >
> > >>
> > >>> * The tool should be idempotent.
> > >>>
> > >>> * You suggest storing tokens in a cache, how do you plan on handling
> the
> > >>> case where a token expires before all operations are complete?
> > >>>
> > >>> * We also initially took the approach of caching tokens but
> discovered
> > >>> the complexity did not justify the minimal cost of obtaining a new
> token
> > >>> for each invocation. This greatly simplified the code with very
> little
> > >>> performance impact.
> > >>>
> > >>> * You do not mention what type of client you're registering. I'm
> > >>> assuming it's OpenID but SAML clients (SP) are equally important. The
> > >>> tool must be able to handle both.
> > >>>
> > >>
> > >> Marko is probably referring to the Keycloak client representation,
> which
> > >> can be either OpenID or SAML. However, we also need to support OpenID
> > >> Connect client descriptions as well as SAML entity descriptors as
> both are
> > >> supported by client reg services.
> > >>
> > >
> > > The CLI needs to know which of the client registration providers (REST
> > > endpoints) to use - there are four as described in the Client
> Registration
> > > documentation (
> > >
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> > > )
> > >
> > > Ideally the input format of the file could be recognised as only
> > > appropriate for one of these providers, and the correct provider then
> > > automatically used. But maybe we need a way to explicitly tell the tool
> > > what provider to use. For example:
> > >
> > > kc new --type default --name test-app --enabled true --base-url
> > > http://localhost:8480/test-app --redirect-uri '
> > > http://localhost:8480/test-app/*' --admin-url
> > > http://localhost:8480/test-app/logout --secret password | kc create
> > > --type default -f -
> > >
> > >
> > >
> > > Having to set --type for both creating a description (kc new), and
> > > pushing it to the server (kc create) is not ideal.
> > >
> >
> > We can detect the difference between Keycloak client rep, SAML and OIDC
> > json that's pretty trivial and we should do that. However, there needs to
> > be a way to specify the provider as well as there could be custom
> providers
> > added.
> >
> > For getting the client it should by default return Keycloak client
> > representation, but we need an option to be able to specify the provider
> so
> > it can return the client installation file instead.
> >
> > With regards to creating by passing arguments rather than a file that
> > should only support client representation files.
> >
> >
> >
> > >
> > >
> > >>
> > >>
> > >>>
> > >>> * I don't see anything in your document on how to specify the SAML
> > >>> metadata.
> > >>>
> > >>
> > > Instead of piping in my-client.json, you would pipe in
> my-client-saml.xml,
> > > possibly requiring an extra --type specifier as described above.
> > >
> > >
> > >>
> > >>> * I don't see anything in your document on how the user modifies the
> > >>> client. It appears as if you are retrieving a ClientRepresentation
> JSON
> > >>> document and expecting the user to edit it in a text editor which
> will
> > >>> then be sent back. That won't work for non-interactive installs. It
> also
> > >>> presumes the user knows how to read and modify the JSON.
> > >>>
> > >>
> > >> It would be nice to be able to set specific fields without having to
> > >> modify JSON. We discussed that for the Admin CLI, but we should
> probably
> > >> also add it to the client reg CLI
> > >>
> > >
> > > It would be very valuable to see some of the usecases, what kind of
> > > changes people do on existing clients.
> > >
> >
> > We should support anything that is in client representation. It should
> just
> > be a generic way to change json fields. For example:
> >
> > # kcreg update <client id> --set enabled=false --set baseUrl=
> > http://new-url/myapp --remove rootUrl
> >
> > This would get the KC client rep, change the corresponding fields and
> send
> > it back.
> >
> >
> > >
> > >
> > >>
> > >>
> > >>>
> > >>> * Keycloak currently has a few problems with client registration and
> > >>> it's necessary to modify the client before it will work correctly. We
> > >>> currently do this via the REST API. How are you planning on handling
> > >>> these issues in your installer? It would be nice if the installer was
> > >>> aware of the Keycloak version and could apply "fix-ups" as needed
> based
> > >>> on the version.
> > >>>
> > >>
> > >> AFAIK you have one problem? About not all redirect URI included from
> the
> > >> SAML entity descriptor. Is that what you are referring to or do you
> have
> > >> other problems?
> > >>
> > >> In either case fix-ups should be performed by the client registration
> > >> services, not in the CLI.
> > >>
> > >>
> > >>>
> > >>> * Keycloak has two ways to register a client (client registration
> > >>> service vs. REST API). The two methods do not produce the same client
> > >>> configuration (I suspect because they do not share common code in the
> > >>> server). How are you planning on addressing the discrepancies?
> > >>>
> > >>
> > >> The task of the CLI is not to address any discrepancies. It's just
> > >> invoking the client reg services. Any discrepancies should be handled
> by
> > >> the client reg services themselves. Have you created JIRA's for these
> or
> > >> can you list them to us?
> > >>
> > >>
> > >>>
> > >>> * The tool should be smart enough to produce a working client without
> > >>> manual intervention (i.e. the need to run admin cli commands
> afterwards
> > >>> to fix problems). Most admins won't know how to tweak the
> configuration.
> > >>>
> > >>
> > >> Can you list any you are aware of? Same comment as above applies
> though,
> > >> it's the responsibility of the client reg services to handle this,
> not the
> > >> CLI. Otherwise you'd have different behavior if you invoke client reg
> > >> services directly rather than through the CLI.
> > >>
> > >>
> > >>>
> > >>> * The tool should not have significant dependencies.
> > >>>
> > >>
> > >> It'll be a fat-jar and will have a single dependency on the JVM.
> > >>
> > >>
> > >>>
> > >>> Those are the thoughts off the top of my head, as you fill out the
> > >>> details I'll continue to review. Recall the plan of record is for
> > >>> Keycloak to provide such tools which we will then utilize. The
> > >>> keycloak-httpd-client-install tool is a stop-gap solution until such
> > >>> time as "offical" tools become available.
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> John
> > >>> _______________________________________________
> > >>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/a05359f5/attachment-0001.html 

From sthorger at redhat.com  Thu Jun 30 00:54:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jun 2016 06:54:12 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CAJgngAeqBDrnSbzGJgrMMFwZbiwj3P7s_t=x_9pDUP=38-Y6kQ@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
	<CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>
	<20160629194934.GB4141@abstractj.org>
	<CAJgngAeqBDrnSbzGJgrMMFwZbiwj3P7s_t=x_9pDUP=38-Y6kQ@mail.gmail.com>
Message-ID: <CAJgngAfnrovg=-6++jxOv0yd-P97X1taz7meYtEZr8m5WkvNkQ@mail.gmail.com>

The encryption support in Travis isn't that so you can encrypt sensitive
details that goes into .travis.yaml which is public through the repo?

On 30 June 2016 at 06:52, Stian Thorgersen <sthorger at redhat.com> wrote:

> I don't see the need for that. For the client registration CLI we will
> support initial access tokens as well as service accounts with pub/priv key
> authentication. For admin cli we'll support service accounts. No one should
> be using username/password combined with automated jobs.
>
> On 29 June 2016 at 21:49, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> I'm not sure if it's part of the scope for now. But
>> thinking about situations where you have to automate jobs plus provide
>> credentials without exposing them.
>>
>> My suggestion, even if it's not part of the scope for now is to encrypt
>> it,
>> like travis does[1]. I know that our plan is to deal of access token,
>> but would be nice to not expose credentials not even a single time.
>>
>>
>> [1] - https://docs.travis-ci.com/user/encryption-keys/
>>
>> On 2016-06-29, Stian Thorgersen wrote:
>> > On 28 June 2016 at 11:40, Marko Strukelj <mstrukel at redhat.com> wrote:
>> >
>> > >
>> > >
>> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <
>> sthorger at redhat.com>
>> > > wrote:
>> > >
>> > >>
>> > >>
>> > >> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com> wrote:
>> > >>
>> > >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
>> > >>> > I've started work on Client Registration CLI tool. As a first
>> step,
>> > >>> here
>> > >>> > is a design document describing how I imagine the tool would be
>> used.
>> > >>> >
>> > >>> >
>> > >>> >
>> > >>>
>> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
>> > >>> >
>> > >>> >
>> > >>> > I'll use this document as a spec / guide as I implement the client
>> > >>> tool.
>> > >>> >
>> > >>> > Within days I'll also send a link to initial ideas for Admin
>> Client
>> > >>> tool
>> > >>> > which in principle should allow administrator to configure
>> everything
>> > >>> > that can otherwise be done through Admin Console.
>> > >>> >
>> > >>> > Any feedback welcome.
>> > >>>
>> > >>> FWIW we've already written a client registration tool for Keycloak.
>> At
>> > >>> the moment it is specifically targeted for SAML clients (SP, Service
>> > >>> Provider) in Apache HTTPD but we have plans to extend it to OIDC.
>> > >>>
>> > >>> It is currently in Fedora and will also ship in OSP.
>> > >>>
>> > >>> It is hosted here:
>> > >>> https://github.com/jdennis/keycloak-httpd-client-install
>> > >>>
>> > >>> The man page for it (formatted for HTML) can be found here:
>> > >>>
>> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
>> > >>>
>> > >>> The man page discusses 3 different ways you can authenticate and 2
>> > >>> different ways client registration can be performed.
>> > >>>
>> > >>> I have a lot of experience with Keycloak client registration tools
>> and
>> > >>> have worked through many issues, I'm happy to share my experience.
>> > >>>
>> > >>> Here are some thoughts/issues you may want to take into account:
>> > >>>
>> > >>> * The tool must be capable of running without interactivity as part
>> of a
>> > >>> scripted installation task.
>> > >>>
>> > >>> * It should not depend on a home directory being available.
>> > >>>
>> > >>> * If a home directory is utilized how will you disambiguate any
>> stored
>> > >>> state belonging to a script that is run by different processes but
>> under
>> > >>> the same user (possibly simultaneously)? To clarify, many install
>> tools
>> > >>> run as the root user or some other admin user. Each invocation of
>> these
>> > >>> install tools can be run with entirely different parameters and may
>> > >>> execute either in parallel or partially overlapping in time.
>> > >>>
>> > >>
>> > > Maybe I should have included this link in the design document to make
>> it
>> > > clear to everyone what Client Registration this tool is for:
>> > >
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
>> > >
>> > > It's a REST API defined by specs, and is separate from Admin REST API.
>> > >
>> > > About using home directory, the way I see it - you either a) specify
>> all
>> > > the state when executing a command, or b) you have a mechanism that
>> allows
>> > > the concept of 'session' between command invocations.
>> > >
>> > > If you use the first approach (a) then on each invocation of the
>> command
>> > > you have to specify either username:password, or a token. The client
>> > > registration specification defines workflow for Initial Access
>> Tokens, and
>> > > Registration Access Tokens, which require to automatically intercept a
>> > > newly issued token after each CRUD operation, and save it for any
>> > > subsequent operation on the same client resource. I can't see how this
>> > > could be achieved by using the first approach.
>> > >
>> > > For the second approach (b) you need a way to communicate 'session'
>> state.
>> > > The state we are saving are just tokens associated with current user
>> or
>> > > specific clients, or specific grants. Looks to me that if multiple
>> parallel
>> > > sessions are in collision about these tokens then the cli tool itself
>> might
>> > > be used the wrong way. Namely, once the client authenticates with a
>> login,
>> > > access token and refresh token are cached. Multiple client instances
>> can
>> > > use the same access token, and the same refresh token. A thing to
>> maybe be
>> > > careful about is just properly locking the file when making changes
>> to it.
>> > > For initial access token you have to explicitly add it, and assign it
>> an
>> > > alias - you can use any random value there if you want. For
>> registration
>> > > access token they are automatically associated with initial token
>> they were
>> > > initiated from - again there should be no collision.
>> > >
>> >
>> > I like the option to have two approaches as there are two use-cases.
>> One is
>> > manually registering for example during development or when manually
>> > configuring an application to use Keycloak. Another is scripted. Even
>> for
>> > scripted you may quite likely want to just add service account
>> credentials
>> > or initial access token directly to ~/.keycloak/ rather than pass these
>> to
>> > the commands.
>> >
>> > Registration access tokens are associated with a client, not an initial
>> > access token. Also, remember the registration access token is changed on
>> > updates.
>> >
>> >
>> > >
>> > > What alternative mechanism would you suggest for storing 'session'
>> info?
>> > > We want to support Windows as well so it can't be Unix / Bash
>> specific.
>> > >
>> > >
>> > >
>> > >>
>> > >>> * The tool should be idempotent.
>> > >>>
>> > >>> * You suggest storing tokens in a cache, how do you plan on
>> handling the
>> > >>> case where a token expires before all operations are complete?
>> > >>>
>> > >>> * We also initially took the approach of caching tokens but
>> discovered
>> > >>> the complexity did not justify the minimal cost of obtaining a new
>> token
>> > >>> for each invocation. This greatly simplified the code with very
>> little
>> > >>> performance impact.
>> > >>>
>> > >>> * You do not mention what type of client you're registering. I'm
>> > >>> assuming it's OpenID but SAML clients (SP) are equally important.
>> The
>> > >>> tool must be able to handle both.
>> > >>>
>> > >>
>> > >> Marko is probably referring to the Keycloak client representation,
>> which
>> > >> can be either OpenID or SAML. However, we also need to support OpenID
>> > >> Connect client descriptions as well as SAML entity descriptors as
>> both are
>> > >> supported by client reg services.
>> > >>
>> > >
>> > > The CLI needs to know which of the client registration providers (REST
>> > > endpoints) to use - there are four as described in the Client
>> Registration
>> > > documentation (
>> > >
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
>> > > )
>> > >
>> > > Ideally the input format of the file could be recognised as only
>> > > appropriate for one of these providers, and the correct provider then
>> > > automatically used. But maybe we need a way to explicitly tell the
>> tool
>> > > what provider to use. For example:
>> > >
>> > > kc new --type default --name test-app --enabled true --base-url
>> > > http://localhost:8480/test-app --redirect-uri '
>> > > http://localhost:8480/test-app/*' --admin-url
>> > > http://localhost:8480/test-app/logout --secret password | kc create
>> > > --type default -f -
>> > >
>> > >
>> > >
>> > > Having to set --type for both creating a description (kc new), and
>> > > pushing it to the server (kc create) is not ideal.
>> > >
>> >
>> > We can detect the difference between Keycloak client rep, SAML and OIDC
>> > json that's pretty trivial and we should do that. However, there needs
>> to
>> > be a way to specify the provider as well as there could be custom
>> providers
>> > added.
>> >
>> > For getting the client it should by default return Keycloak client
>> > representation, but we need an option to be able to specify the
>> provider so
>> > it can return the client installation file instead.
>> >
>> > With regards to creating by passing arguments rather than a file that
>> > should only support client representation files.
>> >
>> >
>> >
>> > >
>> > >
>> > >>
>> > >>
>> > >>>
>> > >>> * I don't see anything in your document on how to specify the SAML
>> > >>> metadata.
>> > >>>
>> > >>
>> > > Instead of piping in my-client.json, you would pipe in
>> my-client-saml.xml,
>> > > possibly requiring an extra --type specifier as described above.
>> > >
>> > >
>> > >>
>> > >>> * I don't see anything in your document on how the user modifies the
>> > >>> client. It appears as if you are retrieving a ClientRepresentation
>> JSON
>> > >>> document and expecting the user to edit it in a text editor which
>> will
>> > >>> then be sent back. That won't work for non-interactive installs. It
>> also
>> > >>> presumes the user knows how to read and modify the JSON.
>> > >>>
>> > >>
>> > >> It would be nice to be able to set specific fields without having to
>> > >> modify JSON. We discussed that for the Admin CLI, but we should
>> probably
>> > >> also add it to the client reg CLI
>> > >>
>> > >
>> > > It would be very valuable to see some of the usecases, what kind of
>> > > changes people do on existing clients.
>> > >
>> >
>> > We should support anything that is in client representation. It should
>> just
>> > be a generic way to change json fields. For example:
>> >
>> > # kcreg update <client id> --set enabled=false --set baseUrl=
>> > http://new-url/myapp --remove rootUrl
>> >
>> > This would get the KC client rep, change the corresponding fields and
>> send
>> > it back.
>> >
>> >
>> > >
>> > >
>> > >>
>> > >>
>> > >>>
>> > >>> * Keycloak currently has a few problems with client registration and
>> > >>> it's necessary to modify the client before it will work correctly.
>> We
>> > >>> currently do this via the REST API. How are you planning on handling
>> > >>> these issues in your installer? It would be nice if the installer
>> was
>> > >>> aware of the Keycloak version and could apply "fix-ups" as needed
>> based
>> > >>> on the version.
>> > >>>
>> > >>
>> > >> AFAIK you have one problem? About not all redirect URI included from
>> the
>> > >> SAML entity descriptor. Is that what you are referring to or do you
>> have
>> > >> other problems?
>> > >>
>> > >> In either case fix-ups should be performed by the client registration
>> > >> services, not in the CLI.
>> > >>
>> > >>
>> > >>>
>> > >>> * Keycloak has two ways to register a client (client registration
>> > >>> service vs. REST API). The two methods do not produce the same
>> client
>> > >>> configuration (I suspect because they do not share common code in
>> the
>> > >>> server). How are you planning on addressing the discrepancies?
>> > >>>
>> > >>
>> > >> The task of the CLI is not to address any discrepancies. It's just
>> > >> invoking the client reg services. Any discrepancies should be
>> handled by
>> > >> the client reg services themselves. Have you created JIRA's for
>> these or
>> > >> can you list them to us?
>> > >>
>> > >>
>> > >>>
>> > >>> * The tool should be smart enough to produce a working client
>> without
>> > >>> manual intervention (i.e. the need to run admin cli commands
>> afterwards
>> > >>> to fix problems). Most admins won't know how to tweak the
>> configuration.
>> > >>>
>> > >>
>> > >> Can you list any you are aware of? Same comment as above applies
>> though,
>> > >> it's the responsibility of the client reg services to handle this,
>> not the
>> > >> CLI. Otherwise you'd have different behavior if you invoke client reg
>> > >> services directly rather than through the CLI.
>> > >>
>> > >>
>> > >>>
>> > >>> * The tool should not have significant dependencies.
>> > >>>
>> > >>
>> > >> It'll be a fat-jar and will have a single dependency on the JVM.
>> > >>
>> > >>
>> > >>>
>> > >>> Those are the thoughts off the top of my head, as you fill out the
>> > >>> details I'll continue to review. Recall the plan of record is for
>> > >>> Keycloak to provide such tools which we will then utilize. The
>> > >>> keycloak-httpd-client-install tool is a stop-gap solution until such
>> > >>> time as "offical" tools become available.
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> John
>> > >>> _______________________________________________
>> > >>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/a3fb45d5/attachment-0001.html 

From sthorger at redhat.com  Thu Jun 30 01:00:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jun 2016 07:00:50 +0200
Subject: [keycloak-dev] Code cleanup
In-Reply-To: <CAK-7U1jsvgF7JF3M6Qqzc_u+uuyM8bQvN5UAt_bM6_XBE_5Wiw@mail.gmail.com>
References: <CAK-7U1jsvgF7JF3M6Qqzc_u+uuyM8bQvN5UAt_bM6_XBE_5Wiw@mail.gmail.com>
Message-ID: <CAJgngAc-F2Kpp_W8aTi2B-ej-w9xJ32p9RPdZAt30kUAajwL0w@mail.gmail.com>

On 29 June 2016 at 17:55, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

>
> Hello group,
>
> I just ran findbugs [1] with the find-sec-bugs [0] and found quite a bunch
> of rather
> suspicious places in the Keycloak codebase.
>
> Note that I don't wont to blame anyone but rather try to improve the
> codebase :)
>
> For instance there are some quite prominent (and sensitive) non-final
> public static fields that could
> be easily changed to something else (in case they aren't inlined).
>
> https://github.com/keycloak/keycloak/blob/3c0f7e2ee2140a9e69e4e95eb24d5a122e63e09a/server-spi/src/main/java/org/keycloak/models/AdminRoles.java#L25
>
>

> Further more there seem to be some dead code left-overs from merges spread
> over the codebase e.g:
>
> https://github.com/keycloak/keycloak/blob/3a669ad7d5b4a72a8eb2bbb23e91083b63f59a2f/adapters/saml/tomcat/tomcat-core/src/main/java/org/keycloak/adapters/saml/CatalinaSamlSessionStore.java#L144
>
>

> Question is how to deal with that?
> I could send PRs for those issues - they would contain quite a bunch of
> files
> with minor changes. Would you be open to such contributions and if so,
> what JIRA issue
> should one reference here?
>

Ideally it would be broken into JIRAs and sent PRs for a few changes at a
time. If you send to many changes in one PR/JIRA it would be much more
effort to review the PR.


>
> Cheers,
> Thomas
>
> [0] http://find-sec-bugs.github.io/
> [1]
> https://github.com/find-sec-bugs/find-sec-bugs/wiki/Maven-configuration
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/8d59eb1d/attachment.html 

From bruno at abstractj.org  Thu Jun 30 01:15:32 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 29 Jun 2016 22:15:32 -0700
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CAJgngAfnrovg=-6++jxOv0yd-P97X1taz7meYtEZr8m5WkvNkQ@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
	<CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>
	<20160629194934.GB4141@abstractj.org>
	<CAJgngAeqBDrnSbzGJgrMMFwZbiwj3P7s_t=x_9pDUP=38-Y6kQ@mail.gmail.com>
	<CAJgngAfnrovg=-6++jxOv0yd-P97X1taz7meYtEZr8m5WkvNkQ@mail.gmail.com>
Message-ID: <20160630051532.GA29127@abstractj.org>

Yes, the encrypted data goes into public repository with .travis.yaml file.
Only the Travis server is able to decrypt such data and validate it[1][2].

Like I mentioned, not a blocker, but maybe something to take into
consideration.

[1] - https://docs.travis-ci.com/user/encryption-keys/#Notifications-Example
[2] - https://github.com/twbs/bootstrap/blob/master/.travis.yml#L30-L32

On 2016-06-30, Stian Thorgersen wrote:
> The encryption support in Travis isn't that so you can encrypt sensitive
> details that goes into .travis.yaml which is public through the repo?
>
> On 30 June 2016 at 06:52, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> > I don't see the need for that. For the client registration CLI we will
> > support initial access tokens as well as service accounts with pub/priv key
> > authentication. For admin cli we'll support service accounts. No one should
> > be using username/password combined with automated jobs.
> >
> > On 29 June 2016 at 21:49, Bruno Oliveira <bruno at abstractj.org> wrote:
> >
> >> I'm not sure if it's part of the scope for now. But
> >> thinking about situations where you have to automate jobs plus provide
> >> credentials without exposing them.
> >>
> >> My suggestion, even if it's not part of the scope for now is to encrypt
> >> it,
> >> like travis does[1]. I know that our plan is to deal of access token,
> >> but would be nice to not expose credentials not even a single time.
> >>
> >>
> >> [1] - https://docs.travis-ci.com/user/encryption-keys/
> >>
> >> On 2016-06-29, Stian Thorgersen wrote:
> >> > On 28 June 2016 at 11:40, Marko Strukelj <mstrukel at redhat.com> wrote:
> >> >
> >> > >
> >> > >
> >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <
> >> sthorger at redhat.com>
> >> > > wrote:
> >> > >
> >> > >>
> >> > >>
> >> > >> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com> wrote:
> >> > >>
> >> > >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
> >> > >>> > I've started work on Client Registration CLI tool. As a first
> >> step,
> >> > >>> here
> >> > >>> > is a design document describing how I imagine the tool would be
> >> used.
> >> > >>> >
> >> > >>> >
> >> > >>> >
> >> > >>>
> >> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
> >> > >>> >
> >> > >>> >
> >> > >>> > I'll use this document as a spec / guide as I implement the client
> >> > >>> tool.
> >> > >>> >
> >> > >>> > Within days I'll also send a link to initial ideas for Admin
> >> Client
> >> > >>> tool
> >> > >>> > which in principle should allow administrator to configure
> >> everything
> >> > >>> > that can otherwise be done through Admin Console.
> >> > >>> >
> >> > >>> > Any feedback welcome.
> >> > >>>
> >> > >>> FWIW we've already written a client registration tool for Keycloak.
> >> At
> >> > >>> the moment it is specifically targeted for SAML clients (SP, Service
> >> > >>> Provider) in Apache HTTPD but we have plans to extend it to OIDC.
> >> > >>>
> >> > >>> It is currently in Fedora and will also ship in OSP.
> >> > >>>
> >> > >>> It is hosted here:
> >> > >>> https://github.com/jdennis/keycloak-httpd-client-install
> >> > >>>
> >> > >>> The man page for it (formatted for HTML) can be found here:
> >> > >>>
> >> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
> >> > >>>
> >> > >>> The man page discusses 3 different ways you can authenticate and 2
> >> > >>> different ways client registration can be performed.
> >> > >>>
> >> > >>> I have a lot of experience with Keycloak client registration tools
> >> and
> >> > >>> have worked through many issues, I'm happy to share my experience.
> >> > >>>
> >> > >>> Here are some thoughts/issues you may want to take into account:
> >> > >>>
> >> > >>> * The tool must be capable of running without interactivity as part
> >> of a
> >> > >>> scripted installation task.
> >> > >>>
> >> > >>> * It should not depend on a home directory being available.
> >> > >>>
> >> > >>> * If a home directory is utilized how will you disambiguate any
> >> stored
> >> > >>> state belonging to a script that is run by different processes but
> >> under
> >> > >>> the same user (possibly simultaneously)? To clarify, many install
> >> tools
> >> > >>> run as the root user or some other admin user. Each invocation of
> >> these
> >> > >>> install tools can be run with entirely different parameters and may
> >> > >>> execute either in parallel or partially overlapping in time.
> >> > >>>
> >> > >>
> >> > > Maybe I should have included this link in the design document to make
> >> it
> >> > > clear to everyone what Client Registration this tool is for:
> >> > >
> >> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> >> > >
> >> > > It's a REST API defined by specs, and is separate from Admin REST API.
> >> > >
> >> > > About using home directory, the way I see it - you either a) specify
> >> all
> >> > > the state when executing a command, or b) you have a mechanism that
> >> allows
> >> > > the concept of 'session' between command invocations.
> >> > >
> >> > > If you use the first approach (a) then on each invocation of the
> >> command
> >> > > you have to specify either username:password, or a token. The client
> >> > > registration specification defines workflow for Initial Access
> >> Tokens, and
> >> > > Registration Access Tokens, which require to automatically intercept a
> >> > > newly issued token after each CRUD operation, and save it for any
> >> > > subsequent operation on the same client resource. I can't see how this
> >> > > could be achieved by using the first approach.
> >> > >
> >> > > For the second approach (b) you need a way to communicate 'session'
> >> state.
> >> > > The state we are saving are just tokens associated with current user
> >> or
> >> > > specific clients, or specific grants. Looks to me that if multiple
> >> parallel
> >> > > sessions are in collision about these tokens then the cli tool itself
> >> might
> >> > > be used the wrong way. Namely, once the client authenticates with a
> >> login,
> >> > > access token and refresh token are cached. Multiple client instances
> >> can
> >> > > use the same access token, and the same refresh token. A thing to
> >> maybe be
> >> > > careful about is just properly locking the file when making changes
> >> to it.
> >> > > For initial access token you have to explicitly add it, and assign it
> >> an
> >> > > alias - you can use any random value there if you want. For
> >> registration
> >> > > access token they are automatically associated with initial token
> >> they were
> >> > > initiated from - again there should be no collision.
> >> > >
> >> >
> >> > I like the option to have two approaches as there are two use-cases.
> >> One is
> >> > manually registering for example during development or when manually
> >> > configuring an application to use Keycloak. Another is scripted. Even
> >> for
> >> > scripted you may quite likely want to just add service account
> >> credentials
> >> > or initial access token directly to ~/.keycloak/ rather than pass these
> >> to
> >> > the commands.
> >> >
> >> > Registration access tokens are associated with a client, not an initial
> >> > access token. Also, remember the registration access token is changed on
> >> > updates.
> >> >
> >> >
> >> > >
> >> > > What alternative mechanism would you suggest for storing 'session'
> >> info?
> >> > > We want to support Windows as well so it can't be Unix / Bash
> >> specific.
> >> > >
> >> > >
> >> > >
> >> > >>
> >> > >>> * The tool should be idempotent.
> >> > >>>
> >> > >>> * You suggest storing tokens in a cache, how do you plan on
> >> handling the
> >> > >>> case where a token expires before all operations are complete?
> >> > >>>
> >> > >>> * We also initially took the approach of caching tokens but
> >> discovered
> >> > >>> the complexity did not justify the minimal cost of obtaining a new
> >> token
> >> > >>> for each invocation. This greatly simplified the code with very
> >> little
> >> > >>> performance impact.
> >> > >>>
> >> > >>> * You do not mention what type of client you're registering. I'm
> >> > >>> assuming it's OpenID but SAML clients (SP) are equally important.
> >> The
> >> > >>> tool must be able to handle both.
> >> > >>>
> >> > >>
> >> > >> Marko is probably referring to the Keycloak client representation,
> >> which
> >> > >> can be either OpenID or SAML. However, we also need to support OpenID
> >> > >> Connect client descriptions as well as SAML entity descriptors as
> >> both are
> >> > >> supported by client reg services.
> >> > >>
> >> > >
> >> > > The CLI needs to know which of the client registration providers (REST
> >> > > endpoints) to use - there are four as described in the Client
> >> Registration
> >> > > documentation (
> >> > >
> >> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> >> > > )
> >> > >
> >> > > Ideally the input format of the file could be recognised as only
> >> > > appropriate for one of these providers, and the correct provider then
> >> > > automatically used. But maybe we need a way to explicitly tell the
> >> tool
> >> > > what provider to use. For example:
> >> > >
> >> > > kc new --type default --name test-app --enabled true --base-url
> >> > > http://localhost:8480/test-app --redirect-uri '
> >> > > http://localhost:8480/test-app/*' --admin-url
> >> > > http://localhost:8480/test-app/logout --secret password | kc create
> >> > > --type default -f -
> >> > >
> >> > >
> >> > >
> >> > > Having to set --type for both creating a description (kc new), and
> >> > > pushing it to the server (kc create) is not ideal.
> >> > >
> >> >
> >> > We can detect the difference between Keycloak client rep, SAML and OIDC
> >> > json that's pretty trivial and we should do that. However, there needs
> >> to
> >> > be a way to specify the provider as well as there could be custom
> >> providers
> >> > added.
> >> >
> >> > For getting the client it should by default return Keycloak client
> >> > representation, but we need an option to be able to specify the
> >> provider so
> >> > it can return the client installation file instead.
> >> >
> >> > With regards to creating by passing arguments rather than a file that
> >> > should only support client representation files.
> >> >
> >> >
> >> >
> >> > >
> >> > >
> >> > >>
> >> > >>
> >> > >>>
> >> > >>> * I don't see anything in your document on how to specify the SAML
> >> > >>> metadata.
> >> > >>>
> >> > >>
> >> > > Instead of piping in my-client.json, you would pipe in
> >> my-client-saml.xml,
> >> > > possibly requiring an extra --type specifier as described above.
> >> > >
> >> > >
> >> > >>
> >> > >>> * I don't see anything in your document on how the user modifies the
> >> > >>> client. It appears as if you are retrieving a ClientRepresentation
> >> JSON
> >> > >>> document and expecting the user to edit it in a text editor which
> >> will
> >> > >>> then be sent back. That won't work for non-interactive installs. It
> >> also
> >> > >>> presumes the user knows how to read and modify the JSON.
> >> > >>>
> >> > >>
> >> > >> It would be nice to be able to set specific fields without having to
> >> > >> modify JSON. We discussed that for the Admin CLI, but we should
> >> probably
> >> > >> also add it to the client reg CLI
> >> > >>
> >> > >
> >> > > It would be very valuable to see some of the usecases, what kind of
> >> > > changes people do on existing clients.
> >> > >
> >> >
> >> > We should support anything that is in client representation. It should
> >> just
> >> > be a generic way to change json fields. For example:
> >> >
> >> > # kcreg update <client id> --set enabled=false --set baseUrl=
> >> > http://new-url/myapp --remove rootUrl
> >> >
> >> > This would get the KC client rep, change the corresponding fields and
> >> send
> >> > it back.
> >> >
> >> >
> >> > >
> >> > >
> >> > >>
> >> > >>
> >> > >>>
> >> > >>> * Keycloak currently has a few problems with client registration and
> >> > >>> it's necessary to modify the client before it will work correctly.
> >> We
> >> > >>> currently do this via the REST API. How are you planning on handling
> >> > >>> these issues in your installer? It would be nice if the installer
> >> was
> >> > >>> aware of the Keycloak version and could apply "fix-ups" as needed
> >> based
> >> > >>> on the version.
> >> > >>>
> >> > >>
> >> > >> AFAIK you have one problem? About not all redirect URI included from
> >> the
> >> > >> SAML entity descriptor. Is that what you are referring to or do you
> >> have
> >> > >> other problems?
> >> > >>
> >> > >> In either case fix-ups should be performed by the client registration
> >> > >> services, not in the CLI.
> >> > >>
> >> > >>
> >> > >>>
> >> > >>> * Keycloak has two ways to register a client (client registration
> >> > >>> service vs. REST API). The two methods do not produce the same
> >> client
> >> > >>> configuration (I suspect because they do not share common code in
> >> the
> >> > >>> server). How are you planning on addressing the discrepancies?
> >> > >>>
> >> > >>
> >> > >> The task of the CLI is not to address any discrepancies. It's just
> >> > >> invoking the client reg services. Any discrepancies should be
> >> handled by
> >> > >> the client reg services themselves. Have you created JIRA's for
> >> these or
> >> > >> can you list them to us?
> >> > >>
> >> > >>
> >> > >>>
> >> > >>> * The tool should be smart enough to produce a working client
> >> without
> >> > >>> manual intervention (i.e. the need to run admin cli commands
> >> afterwards
> >> > >>> to fix problems). Most admins won't know how to tweak the
> >> configuration.
> >> > >>>
> >> > >>
> >> > >> Can you list any you are aware of? Same comment as above applies
> >> though,
> >> > >> it's the responsibility of the client reg services to handle this,
> >> not the
> >> > >> CLI. Otherwise you'd have different behavior if you invoke client reg
> >> > >> services directly rather than through the CLI.
> >> > >>
> >> > >>
> >> > >>>
> >> > >>> * The tool should not have significant dependencies.
> >> > >>>
> >> > >>
> >> > >> It'll be a fat-jar and will have a single dependency on the JVM.
> >> > >>
> >> > >>
> >> > >>>
> >> > >>> Those are the thoughts off the top of my head, as you fill out the
> >> > >>> details I'll continue to review. Recall the plan of record is for
> >> > >>> Keycloak to provide such tools which we will then utilize. The
> >> > >>> keycloak-httpd-client-install tool is a stop-gap solution until such
> >> > >>> time as "offical" tools become available.
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> --
> >> > >>> John
> >> > >>> _______________________________________________
> >> > >>> 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
> >>
> >
> >

--

abstractj
PGP: 0x84DC9914

From sthorger at redhat.com  Thu Jun 30 01:41:01 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jun 2016 07:41:01 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <20160630051532.GA29127@abstractj.org>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
	<CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>
	<20160629194934.GB4141@abstractj.org>
	<CAJgngAeqBDrnSbzGJgrMMFwZbiwj3P7s_t=x_9pDUP=38-Y6kQ@mail.gmail.com>
	<CAJgngAfnrovg=-6++jxOv0yd-P97X1taz7meYtEZr8m5WkvNkQ@mail.gmail.com>
	<20160630051532.GA29127@abstractj.org>
Message-ID: <CAJgngAdJxpnSxXV2wjK9u0Vg1DoaBThp4fO=QDEgDyW5mhz2=Q@mail.gmail.com>

I can't see why we should consider it though:

a) We have service account support, initial access tokens, offline tokens,
etc.. All designed so credentials don't need to be stored. Using a user
account directly is horrible as not only are you potentially exposing the
credentials, you're also giving all permissions of the user to the
automation. Using tokens or service account you can limit what permissions
the automation has.
b) If the credentials are encrypted, you'll also need to unlock the
vault/encrypted file. How would you suggest we do that? I can't see the
full flow here.

On 30 June 2016 at 07:15, Bruno Oliveira <bruno at abstractj.org> wrote:

> Yes, the encrypted data goes into public repository with .travis.yaml file.
> Only the Travis server is able to decrypt such data and validate it[1][2].
>
> Like I mentioned, not a blocker, but maybe something to take into
> consideration.
>
> [1] -
> https://docs.travis-ci.com/user/encryption-keys/#Notifications-Example
> [2] - https://github.com/twbs/bootstrap/blob/master/.travis.yml#L30-L32
>
> On 2016-06-30, Stian Thorgersen wrote:
> > The encryption support in Travis isn't that so you can encrypt sensitive
> > details that goes into .travis.yaml which is public through the repo?
> >
> > On 30 June 2016 at 06:52, Stian Thorgersen <sthorger at redhat.com> wrote:
> >
> > > I don't see the need for that. For the client registration CLI we will
> > > support initial access tokens as well as service accounts with
> pub/priv key
> > > authentication. For admin cli we'll support service accounts. No one
> should
> > > be using username/password combined with automated jobs.
> > >
> > > On 29 June 2016 at 21:49, Bruno Oliveira <bruno at abstractj.org> wrote:
> > >
> > >> I'm not sure if it's part of the scope for now. But
> > >> thinking about situations where you have to automate jobs plus provide
> > >> credentials without exposing them.
> > >>
> > >> My suggestion, even if it's not part of the scope for now is to
> encrypt
> > >> it,
> > >> like travis does[1]. I know that our plan is to deal of access token,
> > >> but would be nice to not expose credentials not even a single time.
> > >>
> > >>
> > >> [1] - https://docs.travis-ci.com/user/encryption-keys/
> > >>
> > >> On 2016-06-29, Stian Thorgersen wrote:
> > >> > On 28 June 2016 at 11:40, Marko Strukelj <mstrukel at redhat.com>
> wrote:
> > >> >
> > >> > >
> > >> > >
> > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <
> > >> sthorger at redhat.com>
> > >> > > wrote:
> > >> > >
> > >> > >>
> > >> > >>
> > >> > >> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com>
> wrote:
> > >> > >>
> > >> > >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
> > >> > >>> > I've started work on Client Registration CLI tool. As a first
> > >> step,
> > >> > >>> here
> > >> > >>> > is a design document describing how I imagine the tool would
> be
> > >> used.
> > >> > >>> >
> > >> > >>> >
> > >> > >>> >
> > >> > >>>
> > >>
> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
> > >> > >>> >
> > >> > >>> >
> > >> > >>> > I'll use this document as a spec / guide as I implement the
> client
> > >> > >>> tool.
> > >> > >>> >
> > >> > >>> > Within days I'll also send a link to initial ideas for Admin
> > >> Client
> > >> > >>> tool
> > >> > >>> > which in principle should allow administrator to configure
> > >> everything
> > >> > >>> > that can otherwise be done through Admin Console.
> > >> > >>> >
> > >> > >>> > Any feedback welcome.
> > >> > >>>
> > >> > >>> FWIW we've already written a client registration tool for
> Keycloak.
> > >> At
> > >> > >>> the moment it is specifically targeted for SAML clients (SP,
> Service
> > >> > >>> Provider) in Apache HTTPD but we have plans to extend it to
> OIDC.
> > >> > >>>
> > >> > >>> It is currently in Fedora and will also ship in OSP.
> > >> > >>>
> > >> > >>> It is hosted here:
> > >> > >>> https://github.com/jdennis/keycloak-httpd-client-install
> > >> > >>>
> > >> > >>> The man page for it (formatted for HTML) can be found here:
> > >> > >>>
> > >>
> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
> > >> > >>>
> > >> > >>> The man page discusses 3 different ways you can authenticate
> and 2
> > >> > >>> different ways client registration can be performed.
> > >> > >>>
> > >> > >>> I have a lot of experience with Keycloak client registration
> tools
> > >> and
> > >> > >>> have worked through many issues, I'm happy to share my
> experience.
> > >> > >>>
> > >> > >>> Here are some thoughts/issues you may want to take into account:
> > >> > >>>
> > >> > >>> * The tool must be capable of running without interactivity as
> part
> > >> of a
> > >> > >>> scripted installation task.
> > >> > >>>
> > >> > >>> * It should not depend on a home directory being available.
> > >> > >>>
> > >> > >>> * If a home directory is utilized how will you disambiguate any
> > >> stored
> > >> > >>> state belonging to a script that is run by different processes
> but
> > >> under
> > >> > >>> the same user (possibly simultaneously)? To clarify, many
> install
> > >> tools
> > >> > >>> run as the root user or some other admin user. Each invocation
> of
> > >> these
> > >> > >>> install tools can be run with entirely different parameters and
> may
> > >> > >>> execute either in parallel or partially overlapping in time.
> > >> > >>>
> > >> > >>
> > >> > > Maybe I should have included this link in the design document to
> make
> > >> it
> > >> > > clear to everyone what Client Registration this tool is for:
> > >> > >
> > >>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> > >> > >
> > >> > > It's a REST API defined by specs, and is separate from Admin REST
> API.
> > >> > >
> > >> > > About using home directory, the way I see it - you either a)
> specify
> > >> all
> > >> > > the state when executing a command, or b) you have a mechanism
> that
> > >> allows
> > >> > > the concept of 'session' between command invocations.
> > >> > >
> > >> > > If you use the first approach (a) then on each invocation of the
> > >> command
> > >> > > you have to specify either username:password, or a token. The
> client
> > >> > > registration specification defines workflow for Initial Access
> > >> Tokens, and
> > >> > > Registration Access Tokens, which require to automatically
> intercept a
> > >> > > newly issued token after each CRUD operation, and save it for any
> > >> > > subsequent operation on the same client resource. I can't see how
> this
> > >> > > could be achieved by using the first approach.
> > >> > >
> > >> > > For the second approach (b) you need a way to communicate
> 'session'
> > >> state.
> > >> > > The state we are saving are just tokens associated with current
> user
> > >> or
> > >> > > specific clients, or specific grants. Looks to me that if multiple
> > >> parallel
> > >> > > sessions are in collision about these tokens then the cli tool
> itself
> > >> might
> > >> > > be used the wrong way. Namely, once the client authenticates with
> a
> > >> login,
> > >> > > access token and refresh token are cached. Multiple client
> instances
> > >> can
> > >> > > use the same access token, and the same refresh token. A thing to
> > >> maybe be
> > >> > > careful about is just properly locking the file when making
> changes
> > >> to it.
> > >> > > For initial access token you have to explicitly add it, and
> assign it
> > >> an
> > >> > > alias - you can use any random value there if you want. For
> > >> registration
> > >> > > access token they are automatically associated with initial token
> > >> they were
> > >> > > initiated from - again there should be no collision.
> > >> > >
> > >> >
> > >> > I like the option to have two approaches as there are two use-cases.
> > >> One is
> > >> > manually registering for example during development or when manually
> > >> > configuring an application to use Keycloak. Another is scripted.
> Even
> > >> for
> > >> > scripted you may quite likely want to just add service account
> > >> credentials
> > >> > or initial access token directly to ~/.keycloak/ rather than pass
> these
> > >> to
> > >> > the commands.
> > >> >
> > >> > Registration access tokens are associated with a client, not an
> initial
> > >> > access token. Also, remember the registration access token is
> changed on
> > >> > updates.
> > >> >
> > >> >
> > >> > >
> > >> > > What alternative mechanism would you suggest for storing 'session'
> > >> info?
> > >> > > We want to support Windows as well so it can't be Unix / Bash
> > >> specific.
> > >> > >
> > >> > >
> > >> > >
> > >> > >>
> > >> > >>> * The tool should be idempotent.
> > >> > >>>
> > >> > >>> * You suggest storing tokens in a cache, how do you plan on
> > >> handling the
> > >> > >>> case where a token expires before all operations are complete?
> > >> > >>>
> > >> > >>> * We also initially took the approach of caching tokens but
> > >> discovered
> > >> > >>> the complexity did not justify the minimal cost of obtaining a
> new
> > >> token
> > >> > >>> for each invocation. This greatly simplified the code with very
> > >> little
> > >> > >>> performance impact.
> > >> > >>>
> > >> > >>> * You do not mention what type of client you're registering. I'm
> > >> > >>> assuming it's OpenID but SAML clients (SP) are equally
> important.
> > >> The
> > >> > >>> tool must be able to handle both.
> > >> > >>>
> > >> > >>
> > >> > >> Marko is probably referring to the Keycloak client
> representation,
> > >> which
> > >> > >> can be either OpenID or SAML. However, we also need to support
> OpenID
> > >> > >> Connect client descriptions as well as SAML entity descriptors as
> > >> both are
> > >> > >> supported by client reg services.
> > >> > >>
> > >> > >
> > >> > > The CLI needs to know which of the client registration providers
> (REST
> > >> > > endpoints) to use - there are four as described in the Client
> > >> Registration
> > >> > > documentation (
> > >> > >
> > >>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> > >> > > )
> > >> > >
> > >> > > Ideally the input format of the file could be recognised as only
> > >> > > appropriate for one of these providers, and the correct provider
> then
> > >> > > automatically used. But maybe we need a way to explicitly tell the
> > >> tool
> > >> > > what provider to use. For example:
> > >> > >
> > >> > > kc new --type default --name test-app --enabled true --base-url
> > >> > > http://localhost:8480/test-app --redirect-uri '
> > >> > > http://localhost:8480/test-app/*' --admin-url
> > >> > > http://localhost:8480/test-app/logout --secret password | kc
> create
> > >> > > --type default -f -
> > >> > >
> > >> > >
> > >> > >
> > >> > > Having to set --type for both creating a description (kc new), and
> > >> > > pushing it to the server (kc create) is not ideal.
> > >> > >
> > >> >
> > >> > We can detect the difference between Keycloak client rep, SAML and
> OIDC
> > >> > json that's pretty trivial and we should do that. However, there
> needs
> > >> to
> > >> > be a way to specify the provider as well as there could be custom
> > >> providers
> > >> > added.
> > >> >
> > >> > For getting the client it should by default return Keycloak client
> > >> > representation, but we need an option to be able to specify the
> > >> provider so
> > >> > it can return the client installation file instead.
> > >> >
> > >> > With regards to creating by passing arguments rather than a file
> that
> > >> > should only support client representation files.
> > >> >
> > >> >
> > >> >
> > >> > >
> > >> > >
> > >> > >>
> > >> > >>
> > >> > >>>
> > >> > >>> * I don't see anything in your document on how to specify the
> SAML
> > >> > >>> metadata.
> > >> > >>>
> > >> > >>
> > >> > > Instead of piping in my-client.json, you would pipe in
> > >> my-client-saml.xml,
> > >> > > possibly requiring an extra --type specifier as described above.
> > >> > >
> > >> > >
> > >> > >>
> > >> > >>> * I don't see anything in your document on how the user
> modifies the
> > >> > >>> client. It appears as if you are retrieving a
> ClientRepresentation
> > >> JSON
> > >> > >>> document and expecting the user to edit it in a text editor
> which
> > >> will
> > >> > >>> then be sent back. That won't work for non-interactive
> installs. It
> > >> also
> > >> > >>> presumes the user knows how to read and modify the JSON.
> > >> > >>>
> > >> > >>
> > >> > >> It would be nice to be able to set specific fields without
> having to
> > >> > >> modify JSON. We discussed that for the Admin CLI, but we should
> > >> probably
> > >> > >> also add it to the client reg CLI
> > >> > >>
> > >> > >
> > >> > > It would be very valuable to see some of the usecases, what kind
> of
> > >> > > changes people do on existing clients.
> > >> > >
> > >> >
> > >> > We should support anything that is in client representation. It
> should
> > >> just
> > >> > be a generic way to change json fields. For example:
> > >> >
> > >> > # kcreg update <client id> --set enabled=false --set baseUrl=
> > >> > http://new-url/myapp --remove rootUrl
> > >> >
> > >> > This would get the KC client rep, change the corresponding fields
> and
> > >> send
> > >> > it back.
> > >> >
> > >> >
> > >> > >
> > >> > >
> > >> > >>
> > >> > >>
> > >> > >>>
> > >> > >>> * Keycloak currently has a few problems with client
> registration and
> > >> > >>> it's necessary to modify the client before it will work
> correctly.
> > >> We
> > >> > >>> currently do this via the REST API. How are you planning on
> handling
> > >> > >>> these issues in your installer? It would be nice if the
> installer
> > >> was
> > >> > >>> aware of the Keycloak version and could apply "fix-ups" as
> needed
> > >> based
> > >> > >>> on the version.
> > >> > >>>
> > >> > >>
> > >> > >> AFAIK you have one problem? About not all redirect URI included
> from
> > >> the
> > >> > >> SAML entity descriptor. Is that what you are referring to or do
> you
> > >> have
> > >> > >> other problems?
> > >> > >>
> > >> > >> In either case fix-ups should be performed by the client
> registration
> > >> > >> services, not in the CLI.
> > >> > >>
> > >> > >>
> > >> > >>>
> > >> > >>> * Keycloak has two ways to register a client (client
> registration
> > >> > >>> service vs. REST API). The two methods do not produce the same
> > >> client
> > >> > >>> configuration (I suspect because they do not share common code
> in
> > >> the
> > >> > >>> server). How are you planning on addressing the discrepancies?
> > >> > >>>
> > >> > >>
> > >> > >> The task of the CLI is not to address any discrepancies. It's
> just
> > >> > >> invoking the client reg services. Any discrepancies should be
> > >> handled by
> > >> > >> the client reg services themselves. Have you created JIRA's for
> > >> these or
> > >> > >> can you list them to us?
> > >> > >>
> > >> > >>
> > >> > >>>
> > >> > >>> * The tool should be smart enough to produce a working client
> > >> without
> > >> > >>> manual intervention (i.e. the need to run admin cli commands
> > >> afterwards
> > >> > >>> to fix problems). Most admins won't know how to tweak the
> > >> configuration.
> > >> > >>>
> > >> > >>
> > >> > >> Can you list any you are aware of? Same comment as above applies
> > >> though,
> > >> > >> it's the responsibility of the client reg services to handle
> this,
> > >> not the
> > >> > >> CLI. Otherwise you'd have different behavior if you invoke
> client reg
> > >> > >> services directly rather than through the CLI.
> > >> > >>
> > >> > >>
> > >> > >>>
> > >> > >>> * The tool should not have significant dependencies.
> > >> > >>>
> > >> > >>
> > >> > >> It'll be a fat-jar and will have a single dependency on the JVM.
> > >> > >>
> > >> > >>
> > >> > >>>
> > >> > >>> Those are the thoughts off the top of my head, as you fill out
> the
> > >> > >>> details I'll continue to review. Recall the plan of record is
> for
> > >> > >>> Keycloak to provide such tools which we will then utilize. The
> > >> > >>> keycloak-httpd-client-install tool is a stop-gap solution until
> such
> > >> > >>> time as "offical" tools become available.
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >>> --
> > >> > >>> John
> > >> > >>> _______________________________________________
> > >> > >>> 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
> > >>
> > >
> > >
>
> --
>
> abstractj
> PGP: 0x84DC9914
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/4f65a07c/attachment-0001.html 

From bruno at abstractj.org  Thu Jun 30 02:08:11 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 29 Jun 2016 23:08:11 -0700
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CAJgngAdJxpnSxXV2wjK9u0Vg1DoaBThp4fO=QDEgDyW5mhz2=Q@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
	<CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>
	<20160629194934.GB4141@abstractj.org>
	<CAJgngAeqBDrnSbzGJgrMMFwZbiwj3P7s_t=x_9pDUP=38-Y6kQ@mail.gmail.com>
	<CAJgngAfnrovg=-6++jxOv0yd-P97X1taz7meYtEZr8m5WkvNkQ@mail.gmail.com>
	<20160630051532.GA29127@abstractj.org>
	<CAJgngAdJxpnSxXV2wjK9u0Vg1DoaBThp4fO=QDEgDyW5mhz2=Q@mail.gmail.com>
Message-ID: <20160630060811.GA3893@abstractj.org>

What I suggested was based on what I saw at our current proposal:

$ kcreg login -r master -u manage-client
Server to connect to (http://localhost:8080/auth):
Password:

If you want to automate it for example in a shell script, unless I'm
mistaken, you have to provide user's password or obtain initial access
token through console. If we're assuming that's the default
flow for automated scripts should be obtaining an initial access token
from console first, that's fine.

Flow for encryption:

1. Admin client retrieve the public key from the server
2. Admin client encrypt's whatever data is sensitive
3. Server decrypt's it

On 2016-06-30, Stian Thorgersen wrote:
> I can't see why we should consider it though:
>
> a) We have service account support, initial access tokens, offline tokens,
> etc.. All designed so credentials don't need to be stored. Using a user
> account directly is horrible as not only are you potentially exposing the
> credentials, you're also giving all permissions of the user to the
> automation. Using tokens or service account you can limit what permissions
> the automation has.
> b) If the credentials are encrypted, you'll also need to unlock the
> vault/encrypted file. How would you suggest we do that? I can't see the
> full flow here.
>
> On 30 June 2016 at 07:15, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Yes, the encrypted data goes into public repository with .travis.yaml file.
> > Only the Travis server is able to decrypt such data and validate it[1][2].
> >
> > Like I mentioned, not a blocker, but maybe something to take into
> > consideration.
> >
> > [1] -
> > https://docs.travis-ci.com/user/encryption-keys/#Notifications-Example
> > [2] - https://github.com/twbs/bootstrap/blob/master/.travis.yml#L30-L32
> >
> > On 2016-06-30, Stian Thorgersen wrote:
> > > The encryption support in Travis isn't that so you can encrypt sensitive
> > > details that goes into .travis.yaml which is public through the repo?
> > >
> > > On 30 June 2016 at 06:52, Stian Thorgersen <sthorger at redhat.com> wrote:
> > >
> > > > I don't see the need for that. For the client registration CLI we will
> > > > support initial access tokens as well as service accounts with
> > pub/priv key
> > > > authentication. For admin cli we'll support service accounts. No one
> > should
> > > > be using username/password combined with automated jobs.
> > > >
> > > > On 29 June 2016 at 21:49, Bruno Oliveira <bruno at abstractj.org> wrote:
> > > >
> > > >> I'm not sure if it's part of the scope for now. But
> > > >> thinking about situations where you have to automate jobs plus provide
> > > >> credentials without exposing them.
> > > >>
> > > >> My suggestion, even if it's not part of the scope for now is to
> > encrypt
> > > >> it,
> > > >> like travis does[1]. I know that our plan is to deal of access token,
> > > >> but would be nice to not expose credentials not even a single time.
> > > >>
> > > >>
> > > >> [1] - https://docs.travis-ci.com/user/encryption-keys/
> > > >>
> > > >> On 2016-06-29, Stian Thorgersen wrote:
> > > >> > On 28 June 2016 at 11:40, Marko Strukelj <mstrukel at redhat.com>
> > wrote:
> > > >> >
> > > >> > >
> > > >> > >
> > > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <
> > > >> sthorger at redhat.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > >>
> > > >> > >>
> > > >> > >> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com>
> > wrote:
> > > >> > >>
> > > >> > >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
> > > >> > >>> > I've started work on Client Registration CLI tool. As a first
> > > >> step,
> > > >> > >>> here
> > > >> > >>> > is a design document describing how I imagine the tool would
> > be
> > > >> used.
> > > >> > >>> >
> > > >> > >>> >
> > > >> > >>> >
> > > >> > >>>
> > > >>
> > https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
> > > >> > >>> >
> > > >> > >>> >
> > > >> > >>> > I'll use this document as a spec / guide as I implement the
> > client
> > > >> > >>> tool.
> > > >> > >>> >
> > > >> > >>> > Within days I'll also send a link to initial ideas for Admin
> > > >> Client
> > > >> > >>> tool
> > > >> > >>> > which in principle should allow administrator to configure
> > > >> everything
> > > >> > >>> > that can otherwise be done through Admin Console.
> > > >> > >>> >
> > > >> > >>> > Any feedback welcome.
> > > >> > >>>
> > > >> > >>> FWIW we've already written a client registration tool for
> > Keycloak.
> > > >> At
> > > >> > >>> the moment it is specifically targeted for SAML clients (SP,
> > Service
> > > >> > >>> Provider) in Apache HTTPD but we have plans to extend it to
> > OIDC.
> > > >> > >>>
> > > >> > >>> It is currently in Fedora and will also ship in OSP.
> > > >> > >>>
> > > >> > >>> It is hosted here:
> > > >> > >>> https://github.com/jdennis/keycloak-httpd-client-install
> > > >> > >>>
> > > >> > >>> The man page for it (formatted for HTML) can be found here:
> > > >> > >>>
> > > >>
> > https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
> > > >> > >>>
> > > >> > >>> The man page discusses 3 different ways you can authenticate
> > and 2
> > > >> > >>> different ways client registration can be performed.
> > > >> > >>>
> > > >> > >>> I have a lot of experience with Keycloak client registration
> > tools
> > > >> and
> > > >> > >>> have worked through many issues, I'm happy to share my
> > experience.
> > > >> > >>>
> > > >> > >>> Here are some thoughts/issues you may want to take into account:
> > > >> > >>>
> > > >> > >>> * The tool must be capable of running without interactivity as
> > part
> > > >> of a
> > > >> > >>> scripted installation task.
> > > >> > >>>
> > > >> > >>> * It should not depend on a home directory being available.
> > > >> > >>>
> > > >> > >>> * If a home directory is utilized how will you disambiguate any
> > > >> stored
> > > >> > >>> state belonging to a script that is run by different processes
> > but
> > > >> under
> > > >> > >>> the same user (possibly simultaneously)? To clarify, many
> > install
> > > >> tools
> > > >> > >>> run as the root user or some other admin user. Each invocation
> > of
> > > >> these
> > > >> > >>> install tools can be run with entirely different parameters and
> > may
> > > >> > >>> execute either in parallel or partially overlapping in time.
> > > >> > >>>
> > > >> > >>
> > > >> > > Maybe I should have included this link in the design document to
> > make
> > > >> it
> > > >> > > clear to everyone what Client Registration this tool is for:
> > > >> > >
> > > >>
> > http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> > > >> > >
> > > >> > > It's a REST API defined by specs, and is separate from Admin REST
> > API.
> > > >> > >
> > > >> > > About using home directory, the way I see it - you either a)
> > specify
> > > >> all
> > > >> > > the state when executing a command, or b) you have a mechanism
> > that
> > > >> allows
> > > >> > > the concept of 'session' between command invocations.
> > > >> > >
> > > >> > > If you use the first approach (a) then on each invocation of the
> > > >> command
> > > >> > > you have to specify either username:password, or a token. The
> > client
> > > >> > > registration specification defines workflow for Initial Access
> > > >> Tokens, and
> > > >> > > Registration Access Tokens, which require to automatically
> > intercept a
> > > >> > > newly issued token after each CRUD operation, and save it for any
> > > >> > > subsequent operation on the same client resource. I can't see how
> > this
> > > >> > > could be achieved by using the first approach.
> > > >> > >
> > > >> > > For the second approach (b) you need a way to communicate
> > 'session'
> > > >> state.
> > > >> > > The state we are saving are just tokens associated with current
> > user
> > > >> or
> > > >> > > specific clients, or specific grants. Looks to me that if multiple
> > > >> parallel
> > > >> > > sessions are in collision about these tokens then the cli tool
> > itself
> > > >> might
> > > >> > > be used the wrong way. Namely, once the client authenticates with
> > a
> > > >> login,
> > > >> > > access token and refresh token are cached. Multiple client
> > instances
> > > >> can
> > > >> > > use the same access token, and the same refresh token. A thing to
> > > >> maybe be
> > > >> > > careful about is just properly locking the file when making
> > changes
> > > >> to it.
> > > >> > > For initial access token you have to explicitly add it, and
> > assign it
> > > >> an
> > > >> > > alias - you can use any random value there if you want. For
> > > >> registration
> > > >> > > access token they are automatically associated with initial token
> > > >> they were
> > > >> > > initiated from - again there should be no collision.
> > > >> > >
> > > >> >
> > > >> > I like the option to have two approaches as there are two use-cases.
> > > >> One is
> > > >> > manually registering for example during development or when manually
> > > >> > configuring an application to use Keycloak. Another is scripted.
> > Even
> > > >> for
> > > >> > scripted you may quite likely want to just add service account
> > > >> credentials
> > > >> > or initial access token directly to ~/.keycloak/ rather than pass
> > these
> > > >> to
> > > >> > the commands.
> > > >> >
> > > >> > Registration access tokens are associated with a client, not an
> > initial
> > > >> > access token. Also, remember the registration access token is
> > changed on
> > > >> > updates.
> > > >> >
> > > >> >
> > > >> > >
> > > >> > > What alternative mechanism would you suggest for storing 'session'
> > > >> info?
> > > >> > > We want to support Windows as well so it can't be Unix / Bash
> > > >> specific.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >>
> > > >> > >>> * The tool should be idempotent.
> > > >> > >>>
> > > >> > >>> * You suggest storing tokens in a cache, how do you plan on
> > > >> handling the
> > > >> > >>> case where a token expires before all operations are complete?
> > > >> > >>>
> > > >> > >>> * We also initially took the approach of caching tokens but
> > > >> discovered
> > > >> > >>> the complexity did not justify the minimal cost of obtaining a
> > new
> > > >> token
> > > >> > >>> for each invocation. This greatly simplified the code with very
> > > >> little
> > > >> > >>> performance impact.
> > > >> > >>>
> > > >> > >>> * You do not mention what type of client you're registering. I'm
> > > >> > >>> assuming it's OpenID but SAML clients (SP) are equally
> > important.
> > > >> The
> > > >> > >>> tool must be able to handle both.
> > > >> > >>>
> > > >> > >>
> > > >> > >> Marko is probably referring to the Keycloak client
> > representation,
> > > >> which
> > > >> > >> can be either OpenID or SAML. However, we also need to support
> > OpenID
> > > >> > >> Connect client descriptions as well as SAML entity descriptors as
> > > >> both are
> > > >> > >> supported by client reg services.
> > > >> > >>
> > > >> > >
> > > >> > > The CLI needs to know which of the client registration providers
> > (REST
> > > >> > > endpoints) to use - there are four as described in the Client
> > > >> Registration
> > > >> > > documentation (
> > > >> > >
> > > >>
> > http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> > > >> > > )
> > > >> > >
> > > >> > > Ideally the input format of the file could be recognised as only
> > > >> > > appropriate for one of these providers, and the correct provider
> > then
> > > >> > > automatically used. But maybe we need a way to explicitly tell the
> > > >> tool
> > > >> > > what provider to use. For example:
> > > >> > >
> > > >> > > kc new --type default --name test-app --enabled true --base-url
> > > >> > > http://localhost:8480/test-app --redirect-uri '
> > > >> > > http://localhost:8480/test-app/*' --admin-url
> > > >> > > http://localhost:8480/test-app/logout --secret password | kc
> > create
> > > >> > > --type default -f -
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Having to set --type for both creating a description (kc new), and
> > > >> > > pushing it to the server (kc create) is not ideal.
> > > >> > >
> > > >> >
> > > >> > We can detect the difference between Keycloak client rep, SAML and
> > OIDC
> > > >> > json that's pretty trivial and we should do that. However, there
> > needs
> > > >> to
> > > >> > be a way to specify the provider as well as there could be custom
> > > >> providers
> > > >> > added.
> > > >> >
> > > >> > For getting the client it should by default return Keycloak client
> > > >> > representation, but we need an option to be able to specify the
> > > >> provider so
> > > >> > it can return the client installation file instead.
> > > >> >
> > > >> > With regards to creating by passing arguments rather than a file
> > that
> > > >> > should only support client representation files.
> > > >> >
> > > >> >
> > > >> >
> > > >> > >
> > > >> > >
> > > >> > >>
> > > >> > >>
> > > >> > >>>
> > > >> > >>> * I don't see anything in your document on how to specify the
> > SAML
> > > >> > >>> metadata.
> > > >> > >>>
> > > >> > >>
> > > >> > > Instead of piping in my-client.json, you would pipe in
> > > >> my-client-saml.xml,
> > > >> > > possibly requiring an extra --type specifier as described above.
> > > >> > >
> > > >> > >
> > > >> > >>
> > > >> > >>> * I don't see anything in your document on how the user
> > modifies the
> > > >> > >>> client. It appears as if you are retrieving a
> > ClientRepresentation
> > > >> JSON
> > > >> > >>> document and expecting the user to edit it in a text editor
> > which
> > > >> will
> > > >> > >>> then be sent back. That won't work for non-interactive
> > installs. It
> > > >> also
> > > >> > >>> presumes the user knows how to read and modify the JSON.
> > > >> > >>>
> > > >> > >>
> > > >> > >> It would be nice to be able to set specific fields without
> > having to
> > > >> > >> modify JSON. We discussed that for the Admin CLI, but we should
> > > >> probably
> > > >> > >> also add it to the client reg CLI
> > > >> > >>
> > > >> > >
> > > >> > > It would be very valuable to see some of the usecases, what kind
> > of
> > > >> > > changes people do on existing clients.
> > > >> > >
> > > >> >
> > > >> > We should support anything that is in client representation. It
> > should
> > > >> just
> > > >> > be a generic way to change json fields. For example:
> > > >> >
> > > >> > # kcreg update <client id> --set enabled=false --set baseUrl=
> > > >> > http://new-url/myapp --remove rootUrl
> > > >> >
> > > >> > This would get the KC client rep, change the corresponding fields
> > and
> > > >> send
> > > >> > it back.
> > > >> >
> > > >> >
> > > >> > >
> > > >> > >
> > > >> > >>
> > > >> > >>
> > > >> > >>>
> > > >> > >>> * Keycloak currently has a few problems with client
> > registration and
> > > >> > >>> it's necessary to modify the client before it will work
> > correctly.
> > > >> We
> > > >> > >>> currently do this via the REST API. How are you planning on
> > handling
> > > >> > >>> these issues in your installer? It would be nice if the
> > installer
> > > >> was
> > > >> > >>> aware of the Keycloak version and could apply "fix-ups" as
> > needed
> > > >> based
> > > >> > >>> on the version.
> > > >> > >>>
> > > >> > >>
> > > >> > >> AFAIK you have one problem? About not all redirect URI included
> > from
> > > >> the
> > > >> > >> SAML entity descriptor. Is that what you are referring to or do
> > you
> > > >> have
> > > >> > >> other problems?
> > > >> > >>
> > > >> > >> In either case fix-ups should be performed by the client
> > registration
> > > >> > >> services, not in the CLI.
> > > >> > >>
> > > >> > >>
> > > >> > >>>
> > > >> > >>> * Keycloak has two ways to register a client (client
> > registration
> > > >> > >>> service vs. REST API). The two methods do not produce the same
> > > >> client
> > > >> > >>> configuration (I suspect because they do not share common code
> > in
> > > >> the
> > > >> > >>> server). How are you planning on addressing the discrepancies?
> > > >> > >>>
> > > >> > >>
> > > >> > >> The task of the CLI is not to address any discrepancies. It's
> > just
> > > >> > >> invoking the client reg services. Any discrepancies should be
> > > >> handled by
> > > >> > >> the client reg services themselves. Have you created JIRA's for
> > > >> these or
> > > >> > >> can you list them to us?
> > > >> > >>
> > > >> > >>
> > > >> > >>>
> > > >> > >>> * The tool should be smart enough to produce a working client
> > > >> without
> > > >> > >>> manual intervention (i.e. the need to run admin cli commands
> > > >> afterwards
> > > >> > >>> to fix problems). Most admins won't know how to tweak the
> > > >> configuration.
> > > >> > >>>
> > > >> > >>
> > > >> > >> Can you list any you are aware of? Same comment as above applies
> > > >> though,
> > > >> > >> it's the responsibility of the client reg services to handle
> > this,
> > > >> not the
> > > >> > >> CLI. Otherwise you'd have different behavior if you invoke
> > client reg
> > > >> > >> services directly rather than through the CLI.
> > > >> > >>
> > > >> > >>
> > > >> > >>>
> > > >> > >>> * The tool should not have significant dependencies.
> > > >> > >>>
> > > >> > >>
> > > >> > >> It'll be a fat-jar and will have a single dependency on the JVM.
> > > >> > >>
> > > >> > >>
> > > >> > >>>
> > > >> > >>> Those are the thoughts off the top of my head, as you fill out
> > the
> > > >> > >>> details I'll continue to review. Recall the plan of record is
> > for
> > > >> > >>> Keycloak to provide such tools which we will then utilize. The
> > > >> > >>> keycloak-httpd-client-install tool is a stop-gap solution until
> > such
> > > >> > >>> time as "offical" tools become available.
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> --
> > > >> > >>> John
> > > >> > >>> _______________________________________________
> > > >> > >>> 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
> > > >>
> > > >
> > > >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> >

--

abstractj
PGP: 0x84DC9914

From sthorger at redhat.com  Thu Jun 30 02:21:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jun 2016 08:21:24 +0200
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <20160630060811.GA3893@abstractj.org>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
	<CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>
	<20160629194934.GB4141@abstractj.org>
	<CAJgngAeqBDrnSbzGJgrMMFwZbiwj3P7s_t=x_9pDUP=38-Y6kQ@mail.gmail.com>
	<CAJgngAfnrovg=-6++jxOv0yd-P97X1taz7meYtEZr8m5WkvNkQ@mail.gmail.com>
	<20160630051532.GA29127@abstractj.org>
	<CAJgngAdJxpnSxXV2wjK9u0Vg1DoaBThp4fO=QDEgDyW5mhz2=Q@mail.gmail.com>
	<20160630060811.GA3893@abstractj.org>
Message-ID: <CAJgngAf1VaiUviB3N5Z+EDJVuJA_kX2d00m88i2e__EbuATTCA@mail.gmail.com>

On 30 June 2016 at 08:08, Bruno Oliveira <bruno at abstractj.org> wrote:

> What I suggested was based on what I saw at our current proposal:
>
> $ kcreg login -r master -u manage-client
> Server to connect to (http://localhost:8080/auth):
> Password:
>
> If you want to automate it for example in a shell script, unless I'm
> mistaken, you have to provide user's password or obtain initial access
> token through console. If we're assuming that's the default
> flow for automated scripts should be obtaining an initial access token
> from console first, that's fine.
>

Yes, the password is just for manual use and wouldn't be cached or anything
like that.


>
> Flow for encryption:
>
> 1. Admin client retrieve the public key from the server
> 2. Admin client encrypt's whatever data is sensitive
> 3. Server decrypt's it
>

Isn't that only going to hide the password? The encrypted password could
still be used as the server would accept/decrypt it.


>
> On 2016-06-30, Stian Thorgersen wrote:
> > I can't see why we should consider it though:
> >
> > a) We have service account support, initial access tokens, offline
> tokens,
> > etc.. All designed so credentials don't need to be stored. Using a user
> > account directly is horrible as not only are you potentially exposing the
> > credentials, you're also giving all permissions of the user to the
> > automation. Using tokens or service account you can limit what
> permissions
> > the automation has.
> > b) If the credentials are encrypted, you'll also need to unlock the
> > vault/encrypted file. How would you suggest we do that? I can't see the
> > full flow here.
> >
> > On 30 June 2016 at 07:15, Bruno Oliveira <bruno at abstractj.org> wrote:
> >
> > > Yes, the encrypted data goes into public repository with .travis.yaml
> file.
> > > Only the Travis server is able to decrypt such data and validate
> it[1][2].
> > >
> > > Like I mentioned, not a blocker, but maybe something to take into
> > > consideration.
> > >
> > > [1] -
> > > https://docs.travis-ci.com/user/encryption-keys/#Notifications-Example
> > > [2] -
> https://github.com/twbs/bootstrap/blob/master/.travis.yml#L30-L32
> > >
> > > On 2016-06-30, Stian Thorgersen wrote:
> > > > The encryption support in Travis isn't that so you can encrypt
> sensitive
> > > > details that goes into .travis.yaml which is public through the repo?
> > > >
> > > > On 30 June 2016 at 06:52, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > > >
> > > > > I don't see the need for that. For the client registration CLI we
> will
> > > > > support initial access tokens as well as service accounts with
> > > pub/priv key
> > > > > authentication. For admin cli we'll support service accounts. No
> one
> > > should
> > > > > be using username/password combined with automated jobs.
> > > > >
> > > > > On 29 June 2016 at 21:49, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> > > > >
> > > > >> I'm not sure if it's part of the scope for now. But
> > > > >> thinking about situations where you have to automate jobs plus
> provide
> > > > >> credentials without exposing them.
> > > > >>
> > > > >> My suggestion, even if it's not part of the scope for now is to
> > > encrypt
> > > > >> it,
> > > > >> like travis does[1]. I know that our plan is to deal of access
> token,
> > > > >> but would be nice to not expose credentials not even a single
> time.
> > > > >>
> > > > >>
> > > > >> [1] - https://docs.travis-ci.com/user/encryption-keys/
> > > > >>
> > > > >> On 2016-06-29, Stian Thorgersen wrote:
> > > > >> > On 28 June 2016 at 11:40, Marko Strukelj <mstrukel at redhat.com>
> > > wrote:
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <
> > > > >> sthorger at redhat.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com>
> > > wrote:
> > > > >> > >>
> > > > >> > >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
> > > > >> > >>> > I've started work on Client Registration CLI tool. As a
> first
> > > > >> step,
> > > > >> > >>> here
> > > > >> > >>> > is a design document describing how I imagine the tool
> would
> > > be
> > > > >> used.
> > > > >> > >>> >
> > > > >> > >>> >
> > > > >> > >>> >
> > > > >> > >>>
> > > > >>
> > >
> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
> > > > >> > >>> >
> > > > >> > >>> >
> > > > >> > >>> > I'll use this document as a spec / guide as I implement
> the
> > > client
> > > > >> > >>> tool.
> > > > >> > >>> >
> > > > >> > >>> > Within days I'll also send a link to initial ideas for
> Admin
> > > > >> Client
> > > > >> > >>> tool
> > > > >> > >>> > which in principle should allow administrator to configure
> > > > >> everything
> > > > >> > >>> > that can otherwise be done through Admin Console.
> > > > >> > >>> >
> > > > >> > >>> > Any feedback welcome.
> > > > >> > >>>
> > > > >> > >>> FWIW we've already written a client registration tool for
> > > Keycloak.
> > > > >> At
> > > > >> > >>> the moment it is specifically targeted for SAML clients (SP,
> > > Service
> > > > >> > >>> Provider) in Apache HTTPD but we have plans to extend it to
> > > OIDC.
> > > > >> > >>>
> > > > >> > >>> It is currently in Fedora and will also ship in OSP.
> > > > >> > >>>
> > > > >> > >>> It is hosted here:
> > > > >> > >>> https://github.com/jdennis/keycloak-httpd-client-install
> > > > >> > >>>
> > > > >> > >>> The man page for it (formatted for HTML) can be found here:
> > > > >> > >>>
> > > > >>
> > >
> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
> > > > >> > >>>
> > > > >> > >>> The man page discusses 3 different ways you can authenticate
> > > and 2
> > > > >> > >>> different ways client registration can be performed.
> > > > >> > >>>
> > > > >> > >>> I have a lot of experience with Keycloak client registration
> > > tools
> > > > >> and
> > > > >> > >>> have worked through many issues, I'm happy to share my
> > > experience.
> > > > >> > >>>
> > > > >> > >>> Here are some thoughts/issues you may want to take into
> account:
> > > > >> > >>>
> > > > >> > >>> * The tool must be capable of running without interactivity
> as
> > > part
> > > > >> of a
> > > > >> > >>> scripted installation task.
> > > > >> > >>>
> > > > >> > >>> * It should not depend on a home directory being available.
> > > > >> > >>>
> > > > >> > >>> * If a home directory is utilized how will you disambiguate
> any
> > > > >> stored
> > > > >> > >>> state belonging to a script that is run by different
> processes
> > > but
> > > > >> under
> > > > >> > >>> the same user (possibly simultaneously)? To clarify, many
> > > install
> > > > >> tools
> > > > >> > >>> run as the root user or some other admin user. Each
> invocation
> > > of
> > > > >> these
> > > > >> > >>> install tools can be run with entirely different parameters
> and
> > > may
> > > > >> > >>> execute either in parallel or partially overlapping in time.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > > Maybe I should have included this link in the design document
> to
> > > make
> > > > >> it
> > > > >> > > clear to everyone what Client Registration this tool is for:
> > > > >> > >
> > > > >>
> > >
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> > > > >> > >
> > > > >> > > It's a REST API defined by specs, and is separate from Admin
> REST
> > > API.
> > > > >> > >
> > > > >> > > About using home directory, the way I see it - you either a)
> > > specify
> > > > >> all
> > > > >> > > the state when executing a command, or b) you have a mechanism
> > > that
> > > > >> allows
> > > > >> > > the concept of 'session' between command invocations.
> > > > >> > >
> > > > >> > > If you use the first approach (a) then on each invocation of
> the
> > > > >> command
> > > > >> > > you have to specify either username:password, or a token. The
> > > client
> > > > >> > > registration specification defines workflow for Initial Access
> > > > >> Tokens, and
> > > > >> > > Registration Access Tokens, which require to automatically
> > > intercept a
> > > > >> > > newly issued token after each CRUD operation, and save it for
> any
> > > > >> > > subsequent operation on the same client resource. I can't see
> how
> > > this
> > > > >> > > could be achieved by using the first approach.
> > > > >> > >
> > > > >> > > For the second approach (b) you need a way to communicate
> > > 'session'
> > > > >> state.
> > > > >> > > The state we are saving are just tokens associated with
> current
> > > user
> > > > >> or
> > > > >> > > specific clients, or specific grants. Looks to me that if
> multiple
> > > > >> parallel
> > > > >> > > sessions are in collision about these tokens then the cli tool
> > > itself
> > > > >> might
> > > > >> > > be used the wrong way. Namely, once the client authenticates
> with
> > > a
> > > > >> login,
> > > > >> > > access token and refresh token are cached. Multiple client
> > > instances
> > > > >> can
> > > > >> > > use the same access token, and the same refresh token. A
> thing to
> > > > >> maybe be
> > > > >> > > careful about is just properly locking the file when making
> > > changes
> > > > >> to it.
> > > > >> > > For initial access token you have to explicitly add it, and
> > > assign it
> > > > >> an
> > > > >> > > alias - you can use any random value there if you want. For
> > > > >> registration
> > > > >> > > access token they are automatically associated with initial
> token
> > > > >> they were
> > > > >> > > initiated from - again there should be no collision.
> > > > >> > >
> > > > >> >
> > > > >> > I like the option to have two approaches as there are two
> use-cases.
> > > > >> One is
> > > > >> > manually registering for example during development or when
> manually
> > > > >> > configuring an application to use Keycloak. Another is scripted.
> > > Even
> > > > >> for
> > > > >> > scripted you may quite likely want to just add service account
> > > > >> credentials
> > > > >> > or initial access token directly to ~/.keycloak/ rather than
> pass
> > > these
> > > > >> to
> > > > >> > the commands.
> > > > >> >
> > > > >> > Registration access tokens are associated with a client, not an
> > > initial
> > > > >> > access token. Also, remember the registration access token is
> > > changed on
> > > > >> > updates.
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > > What alternative mechanism would you suggest for storing
> 'session'
> > > > >> info?
> > > > >> > > We want to support Windows as well so it can't be Unix / Bash
> > > > >> specific.
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >>
> > > > >> > >>> * The tool should be idempotent.
> > > > >> > >>>
> > > > >> > >>> * You suggest storing tokens in a cache, how do you plan on
> > > > >> handling the
> > > > >> > >>> case where a token expires before all operations are
> complete?
> > > > >> > >>>
> > > > >> > >>> * We also initially took the approach of caching tokens but
> > > > >> discovered
> > > > >> > >>> the complexity did not justify the minimal cost of
> obtaining a
> > > new
> > > > >> token
> > > > >> > >>> for each invocation. This greatly simplified the code with
> very
> > > > >> little
> > > > >> > >>> performance impact.
> > > > >> > >>>
> > > > >> > >>> * You do not mention what type of client you're
> registering. I'm
> > > > >> > >>> assuming it's OpenID but SAML clients (SP) are equally
> > > important.
> > > > >> The
> > > > >> > >>> tool must be able to handle both.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> Marko is probably referring to the Keycloak client
> > > representation,
> > > > >> which
> > > > >> > >> can be either OpenID or SAML. However, we also need to
> support
> > > OpenID
> > > > >> > >> Connect client descriptions as well as SAML entity
> descriptors as
> > > > >> both are
> > > > >> > >> supported by client reg services.
> > > > >> > >>
> > > > >> > >
> > > > >> > > The CLI needs to know which of the client registration
> providers
> > > (REST
> > > > >> > > endpoints) to use - there are four as described in the Client
> > > > >> Registration
> > > > >> > > documentation (
> > > > >> > >
> > > > >>
> > >
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
> > > > >> > > )
> > > > >> > >
> > > > >> > > Ideally the input format of the file could be recognised as
> only
> > > > >> > > appropriate for one of these providers, and the correct
> provider
> > > then
> > > > >> > > automatically used. But maybe we need a way to explicitly
> tell the
> > > > >> tool
> > > > >> > > what provider to use. For example:
> > > > >> > >
> > > > >> > > kc new --type default --name test-app --enabled true
> --base-url
> > > > >> > > http://localhost:8480/test-app --redirect-uri '
> > > > >> > > http://localhost:8480/test-app/*' --admin-url
> > > > >> > > http://localhost:8480/test-app/logout --secret password | kc
> > > create
> > > > >> > > --type default -f -
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > Having to set --type for both creating a description (kc
> new), and
> > > > >> > > pushing it to the server (kc create) is not ideal.
> > > > >> > >
> > > > >> >
> > > > >> > We can detect the difference between Keycloak client rep, SAML
> and
> > > OIDC
> > > > >> > json that's pretty trivial and we should do that. However, there
> > > needs
> > > > >> to
> > > > >> > be a way to specify the provider as well as there could be
> custom
> > > > >> providers
> > > > >> > added.
> > > > >> >
> > > > >> > For getting the client it should by default return Keycloak
> client
> > > > >> > representation, but we need an option to be able to specify the
> > > > >> provider so
> > > > >> > it can return the client installation file instead.
> > > > >> >
> > > > >> > With regards to creating by passing arguments rather than a file
> > > that
> > > > >> > should only support client representation files.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * I don't see anything in your document on how to specify
> the
> > > SAML
> > > > >> > >>> metadata.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > > Instead of piping in my-client.json, you would pipe in
> > > > >> my-client-saml.xml,
> > > > >> > > possibly requiring an extra --type specifier as described
> above.
> > > > >> > >
> > > > >> > >
> > > > >> > >>
> > > > >> > >>> * I don't see anything in your document on how the user
> > > modifies the
> > > > >> > >>> client. It appears as if you are retrieving a
> > > ClientRepresentation
> > > > >> JSON
> > > > >> > >>> document and expecting the user to edit it in a text editor
> > > which
> > > > >> will
> > > > >> > >>> then be sent back. That won't work for non-interactive
> > > installs. It
> > > > >> also
> > > > >> > >>> presumes the user knows how to read and modify the JSON.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> It would be nice to be able to set specific fields without
> > > having to
> > > > >> > >> modify JSON. We discussed that for the Admin CLI, but we
> should
> > > > >> probably
> > > > >> > >> also add it to the client reg CLI
> > > > >> > >>
> > > > >> > >
> > > > >> > > It would be very valuable to see some of the usecases, what
> kind
> > > of
> > > > >> > > changes people do on existing clients.
> > > > >> > >
> > > > >> >
> > > > >> > We should support anything that is in client representation. It
> > > should
> > > > >> just
> > > > >> > be a generic way to change json fields. For example:
> > > > >> >
> > > > >> > # kcreg update <client id> --set enabled=false --set baseUrl=
> > > > >> > http://new-url/myapp --remove rootUrl
> > > > >> >
> > > > >> > This would get the KC client rep, change the corresponding
> fields
> > > and
> > > > >> send
> > > > >> > it back.
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * Keycloak currently has a few problems with client
> > > registration and
> > > > >> > >>> it's necessary to modify the client before it will work
> > > correctly.
> > > > >> We
> > > > >> > >>> currently do this via the REST API. How are you planning on
> > > handling
> > > > >> > >>> these issues in your installer? It would be nice if the
> > > installer
> > > > >> was
> > > > >> > >>> aware of the Keycloak version and could apply "fix-ups" as
> > > needed
> > > > >> based
> > > > >> > >>> on the version.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> AFAIK you have one problem? About not all redirect URI
> included
> > > from
> > > > >> the
> > > > >> > >> SAML entity descriptor. Is that what you are referring to or
> do
> > > you
> > > > >> have
> > > > >> > >> other problems?
> > > > >> > >>
> > > > >> > >> In either case fix-ups should be performed by the client
> > > registration
> > > > >> > >> services, not in the CLI.
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * Keycloak has two ways to register a client (client
> > > registration
> > > > >> > >>> service vs. REST API). The two methods do not produce the
> same
> > > > >> client
> > > > >> > >>> configuration (I suspect because they do not share common
> code
> > > in
> > > > >> the
> > > > >> > >>> server). How are you planning on addressing the
> discrepancies?
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> The task of the CLI is not to address any discrepancies. It's
> > > just
> > > > >> > >> invoking the client reg services. Any discrepancies should be
> > > > >> handled by
> > > > >> > >> the client reg services themselves. Have you created JIRA's
> for
> > > > >> these or
> > > > >> > >> can you list them to us?
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * The tool should be smart enough to produce a working
> client
> > > > >> without
> > > > >> > >>> manual intervention (i.e. the need to run admin cli commands
> > > > >> afterwards
> > > > >> > >>> to fix problems). Most admins won't know how to tweak the
> > > > >> configuration.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> Can you list any you are aware of? Same comment as above
> applies
> > > > >> though,
> > > > >> > >> it's the responsibility of the client reg services to handle
> > > this,
> > > > >> not the
> > > > >> > >> CLI. Otherwise you'd have different behavior if you invoke
> > > client reg
> > > > >> > >> services directly rather than through the CLI.
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * The tool should not have significant dependencies.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> It'll be a fat-jar and will have a single dependency on the
> JVM.
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> Those are the thoughts off the top of my head, as you fill
> out
> > > the
> > > > >> > >>> details I'll continue to review. Recall the plan of record
> is
> > > for
> > > > >> > >>> Keycloak to provide such tools which we will then utilize.
> The
> > > > >> > >>> keycloak-httpd-client-install tool is a stop-gap solution
> until
> > > such
> > > > >> > >>> time as "offical" tools become available.
> > > > >> > >>>
> > > > >> > >>>
> > > > >> > >>>
> > > > >> > >>> --
> > > > >> > >>> John
> > > > >> > >>> _______________________________________________
> > > > >> > >>> 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
> > > > >>
> > > > >
> > > > >
> > >
> > > --
> > >
> > > abstractj
> > > PGP: 0x84DC9914
> > >
>
> --
>
> abstractj
> PGP: 0x84DC9914
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/a6c2819f/attachment-0001.html 

From thomas.darimont at googlemail.com  Thu Jun 30 04:55:39 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 30 Jun 2016 10:55:39 +0200
Subject: [keycloak-dev] Code cleanup
In-Reply-To: <CAJgngAc-F2Kpp_W8aTi2B-ej-w9xJ32p9RPdZAt30kUAajwL0w@mail.gmail.com>
References: <CAK-7U1jsvgF7JF3M6Qqzc_u+uuyM8bQvN5UAt_bM6_XBE_5Wiw@mail.gmail.com>
	<CAJgngAc-F2Kpp_W8aTi2B-ej-w9xJ32p9RPdZAt30kUAajwL0w@mail.gmail.com>
Message-ID: <CAK-7U1hw7QzWz5fBYGc+n1YxCb53qCYWoY8NwjHayfNQPwO8Bg@mail.gmail.com>

Hello,

okay, then I try to group the PRs appropriately and we see how it goes :)

Cheers,
Thomas

2016-06-30 7:00 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

>
>
> On 29 June 2016 at 17:55, Thomas Darimont <thomas.darimont at googlemail.com>
> wrote:
>
>>
>> Hello group,
>>
>> I just ran findbugs [1] with the find-sec-bugs [0] and found quite a
>> bunch of rather
>> suspicious places in the Keycloak codebase.
>>
>> Note that I don't wont to blame anyone but rather try to improve the
>> codebase :)
>>
>> For instance there are some quite prominent (and sensitive) non-final
>> public static fields that could
>> be easily changed to something else (in case they aren't inlined).
>>
>> https://github.com/keycloak/keycloak/blob/3c0f7e2ee2140a9e69e4e95eb24d5a122e63e09a/server-spi/src/main/java/org/keycloak/models/AdminRoles.java#L25
>>
>>
>
>> Further more there seem to be some dead code left-overs from merges
>> spread over the codebase e.g:
>>
>> https://github.com/keycloak/keycloak/blob/3a669ad7d5b4a72a8eb2bbb23e91083b63f59a2f/adapters/saml/tomcat/tomcat-core/src/main/java/org/keycloak/adapters/saml/CatalinaSamlSessionStore.java#L144
>>
>>
>
>> Question is how to deal with that?
>> I could send PRs for those issues - they would contain quite a bunch of
>> files
>> with minor changes. Would you be open to such contributions and if so,
>> what JIRA issue
>> should one reference here?
>>
>
> Ideally it would be broken into JIRAs and sent PRs for a few changes at a
> time. If you send to many changes in one PR/JIRA it would be much more
> effort to review the PR.
>
>
>>
>> Cheers,
>> Thomas
>>
>> [0] http://find-sec-bugs.github.io/
>> [1]
>> https://github.com/find-sec-bugs/find-sec-bugs/wiki/Maven-configuration
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/c279ae89/attachment.html 

From sthorger at redhat.com  Thu Jun 30 05:36:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 30 Jun 2016 11:36:43 +0200
Subject: [keycloak-dev] Keycloak 2.0.0.Final released
Message-ID: <CAJgngAfPY0TrGw7ZXWMh2VHYXZkhUL_eHOLzWzBX3nfEsxaOxg@mail.gmail.com>

Keycloak 2.0.0.Final has just been released. This release only contains
some minor fixes since 2.0.0.CR1.

For the full list of resolved issues check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%202.0.0.Final>
and
to download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>. Before you upgrade refer to the migration
guide
<https://keycloak.gitbooks.io/server-adminstration-guide/content/v/2.0/topics/MigrationFromOlderVersions.html>
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/61a490f8/attachment.html 

From mposolda at redhat.com  Thu Jun 30 09:56:04 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 30 Jun 2016 15:56:04 +0200
Subject: [keycloak-dev] Scope parameter support
Message-ID: <577524F4.9070803@redhat.com>

It seems that for OIDC certification, we will need more proper support 
for "scope" parameter. There are few tests from OIDC conformance 
testsuite, which end with WARNING because of issues with "scope" parameter.


SUMMARY OF SPECS REQUIREMENTS
-----------------------------

- In OIDC specification, the "scope" parameter is actually REQUIRED. And 
you must add the scope value "openid" to all authorization requests. 
Hence if you don't use "scope=openid", the request is pure OAuth2 
request, but it's not OIDC request.

In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the 
possibility that we should change our adapters and add "scope=openid" to 
all requests, and also the possibility to remove IDToken if it's not 
OIDC request (and maybe other things). However it may be potential issue 
with backward compatibility with older adapters (which don't add 
"scope=openid" at all).


- OIDC also prescribes the "scope=offline_access", which you use if you 
want offline token. We actually support this as we have realm role 
"offline_access", with scopeParamRequired=true . So this role is applied 
just if it's included in scope parameter. This is our only support of 
scope param actually. ATM we reference the realm roles by name (role 
name must match the value of scope parameter) and clientRoles by 
"clientId/roleName" . So it's not very flexible and won't work well in 
the future with role namespaces.


- OIDC defines four other scope values, which we don't support, with the 
meaning like this:

profile
     OPTIONAL. This scope value requests access to the End-User's 
default profile Claims, which are: "name", "family_name", "given_name", 
"middle_name", "nickname", "preferred_username", "profile", "picture", 
"website", "gender", "birthdate", "zoneinfo", "locale", and "updated_at".

email
     OPTIONAL. This scope value requests access to the "email" and 
"email_verified" Claims.

address
     OPTIONAL. This scope value requests access to the "address" Claim.

phone
     OPTIONAL. This scope value requests access to the "phone_number" 
and "phone_number_verified" Claims.


- Not directly related to scopes, however OIDC also has one parameter 
"claims" described in section 
http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter . 
This allows to define some additional claims, which should be included 
in IDToken or UserInfo endpoint in addition to claims specified by 
"scope" parameter.



HOW TO IMPLEMENT?
-----------------

My current thinking is, that we will have 2 kinds of protocolMappers and 
roles.

1) "Always applied" - Those roles/protocolMappers are always applied to 
token even if they are not specified by scope parameter.

2) "Applied on demand" - Those roles/protocolMappers are applied just if 
they are specifically requested by scope parameter

For roles, we already have that with "scope param required" flag defined 
per roleModel. However for protocolMappers we don't have it yet.

IMO We will also need some more flexible way to specify how the value of 
scope parameter will be mapped to roles and protocolMappers. For example 
if I use "scope=foo", it can mean that I want realm role "foo1", client 
role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc.

I can see 2 possibilities:

a) Configure allowed scope param separately per each role / protocolMapper

If some role has "Scope param required" checked, you will have 
possibility to configure list of available values of scope parameter, 
which this role will be applied to. This will be configured per-each 
role separately.

Example: I have realm role "foo" . I check "scope param required" to 
true. Then I will define "scope param values" :  "bar" and "baz". It 
means that if someone uses parameter "scope=bar" or
scope=baz", then role "foo" will be applied to token. Otherwise it won't 
be applied.

Similarly it will be for protocolMappers. We will add switch "Scope 
param required" to protocolMappers and we will use list of available 
values of scope parameter, which is configured per each protocolMapper 
separately.


b) Configure scope parameter in separate place

We will have another tab "Scope parameter config" (or maybe rather 
another sub-tab under existing "Scope" tab). Here you will define the 
allowed values of scope parameter. For each allowed value, you will 
define protocolMappers and roles to apply. Hence for example for 
"profile" scope parameter, you will define all protocolMappers for 
corresponding claims ( name, family_name, ...) here.

We will still need "scope param required" switch for protocolMappers in 
case (b).

My current thinking is to go with (a). So when you go to some role (or 
protocolMapper) in admin console you will see if you need scope 
parameter and what are available values of scope parameter to request it.

WDYT? Another ideas?


Marek


From mposolda at redhat.com  Thu Jun 30 10:00:36 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 30 Jun 2016 16:00:36 +0200
Subject: [keycloak-dev] Backward compatibility of server and adapters
Message-ID: <57752604.9070103@redhat.com>

I am thinking whether to add configuration switch in admin console per 
client, where you can define what is the adapter version the particular 
client is using. In that case, some behaviour can be different/backwards 
compatible.

Example: For new clients, we will include IDToken just if they use 
"scope=openid" . However for clients with adapter "1.9" or older, the 
IDToken will be included even if "scope=openid" is not used.

WDYT?
Marek

From mposolda at redhat.com  Thu Jun 30 10:25:01 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 30 Jun 2016 16:25:01 +0200
Subject: [keycloak-dev] Some OIDC JIRAs to fix?
Message-ID: <57752BBD.2080107@redhat.com>

I am adding some OIDC specs JIRAs with possibility how to fix them. I am 
including those, which will be easy to fix and I can look into them 
later today or tomorrow before PTO :

https://issues.jboss.org/browse/KEYCLOAK-3189 - Add 'typ' to JWT header
https://issues.jboss.org/browse/KEYCLOAK-3190 
<https://issues.jboss.org/browse/KEYCLOAK-3190> - Add 'kid' to JWT header
https://issues.jboss.org/browse/KEYCLOAK-3217 - UserInfo endpoint not 
accessible by POST request secured with Bearer header
https://issues.jboss.org/browse/KEYCLOAK-3147 - OpenID Connect auth 
request redirect_uri behaviour not according to spec
https://issues.jboss.org/browse/KEYCLOAK-3222 
<https://issues.jboss.org/browse/KEYCLOAK-3222> - WellKnown endpoint 
doesn't return supported types of client authentication
https://issues.jboss.org/browse/KEYCLOAK-3219 - WellKnown endpoint 
doesn't support claims_supported


All of those are quite straightforward and easy to fix IMO.


Besides that, there are those 2, which I first rather want to confirm 
what exactly to do:

- https://issues.jboss.org/browse/KEYCLOAK-3221 Tokens not invalidated 
if an attempt to reuse code is made

We have just single-use code (which is good), however OAuth2 specs 
recommends to invalidate existing tokens if an attempt to reuse code is 
done. And one OIDC test is in WARNING state because of it (it tries to 
access UserInfo endpoint with the accessToken issued with the reused code).

I can see 2 possibilities to fix:
a) Invalidate just single clientSession where "code" attempt reuse was made
b) Logout whole userSession

It looks to me that (a) is sufficient solution. The potential issue with 
(b) is, that if attacker can steal code, it gives him the possibility to 
trigger global logout of user from all apps. WDYT?


- https://issues.jboss.org/browse/KEYCLOAK-3218 Support for "max_age" in 
AuthorizationEndpoint and "auth_time" claim on IDToken

The possibility to implement is :
- Add new note AUTH_TIME to UserSessionModel. It will be time when 
authentication of user was fully finished (including requiredActions). 
Session note is used just so we don't need to change the model ;)
- If "max_age" parameter was requested, the "auth_time" will be added to 
IDToken (or I will re-check specs if we should rather always add it to 
IDToken)
- I am also thinking about adding hook to CookieAuthenticator, so that 
if max_age parameter was used and userSession authTime is too "old", the 
CookieAuthenticator will be ignored and user will need to 
re-authenticate with other authenticators (username/password form etc). 
Then authTime will be updated on userSession once authentication is 
finished.

WDYT?

That will leave us with bigger things for OIDC Basic certification ( 
scope parameter support, possibly 'claims' param support and 'acr' support).

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

From bruno at abstractj.org  Thu Jun 30 14:06:21 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 30 Jun 2016 18:06:21 +0000
Subject: [keycloak-dev] Client Registration CLI tool
In-Reply-To: <CAJgngAf1VaiUviB3N5Z+EDJVuJA_kX2d00m88i2e__EbuATTCA@mail.gmail.com>
References: <CA+1OW+hOVwpAhSTQ4Mq+k+5v45PNKZL5cFb-T5HoeOBs99UZxA@mail.gmail.com>
	<a606ab8d-0e45-9762-df81-d9f1c6490f91@redhat.com>
	<CAJgngAeyFDnoVz7HYOGSkOB-QF5Duf+FSw0TRexzX49-ovMzYA@mail.gmail.com>
	<CA+1OW+hE8tL8pRSi5ztwahAUvWN8Of92A72y1Py19V0uCB4cOA@mail.gmail.com>
	<CAJgngAeGbRjfi9TwSLKK0Y7=k6ZVn5SPHk44xUp3-LZrzJcixQ@mail.gmail.com>
	<20160629194934.GB4141@abstractj.org>
	<CAJgngAeqBDrnSbzGJgrMMFwZbiwj3P7s_t=x_9pDUP=38-Y6kQ@mail.gmail.com>
	<CAJgngAfnrovg=-6++jxOv0yd-P97X1taz7meYtEZr8m5WkvNkQ@mail.gmail.com>
	<20160630051532.GA29127@abstractj.org>
	<CAJgngAdJxpnSxXV2wjK9u0Vg1DoaBThp4fO=QDEgDyW5mhz2=Q@mail.gmail.com>
	<20160630060811.GA3893@abstractj.org>
	<CAJgngAf1VaiUviB3N5Z+EDJVuJA_kX2d00m88i2e__EbuATTCA@mail.gmail.com>
Message-ID: <CAM5SUC5PTg0OM0hj0mnR3O5T-Xb-isoKjJUfHEOnDhzdQNTGzA@mail.gmail.com>

Sorry about the duplicated e-mail.

On Wed, Jun 29, 2016, 11:21 PM Stian Thorgersen <sthorger at redhat.com> wrote:

> On 30 June 2016 at 08:08, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> What I suggested was based on what I saw at our current proposal:
>>
>> $ kcreg login -r master -u manage-client
>> Server to connect to (http://localhost:8080/auth):
>> Password:
>>
>> If you want to automate it for example in a shell script, unless I'm
>> mistaken, you have to provide user's password or obtain initial access
>> token through console. If we're assuming that's the default
>> flow for automated scripts should be obtaining an initial access token
>> from console first, that's fine.
>>
>
> Yes, the password is just for manual use and wouldn't be cached or
> anything like that.
>
>
>>
>> Flow for encryption:
>>
>> 1. Admin client retrieve the public key from the server
>> 2. Admin client encrypt's whatever data is sensitive
>> 3. Server decrypt's it
>>
>
> Isn't that only going to hide the password? The encrypted password could
> still be used as the server would accept/decrypt it.
>

Not only passwords, but username as well. Into other words any sensitive
data.

I don't follow you on this. The server will decrypt and validate those
credentials.

Anyways, this is just an idea, if it doesn't worth it, never mind.



>
>>
>> On 2016-06-30, Stian Thorgersen wrote:
>> > I can't see why we should consider it though:
>> >
>> > a) We have service account support, initial access tokens, offline
>> tokens,
>> > etc.. All designed so credentials don't need to be stored. Using a user
>> > account directly is horrible as not only are you potentially exposing
>> the
>> > credentials, you're also giving all permissions of the user to the
>> > automation. Using tokens or service account you can limit what
>> permissions
>> > the automation has.
>> > b) If the credentials are encrypted, you'll also need to unlock the
>> > vault/encrypted file. How would you suggest we do that? I can't see the
>> > full flow here.
>> >
>> > On 30 June 2016 at 07:15, Bruno Oliveira <bruno at abstractj.org> wrote:
>> >
>> > > Yes, the encrypted data goes into public repository with .travis.yaml
>> file.
>> > > Only the Travis server is able to decrypt such data and validate
>> it[1][2].
>> > >
>> > > Like I mentioned, not a blocker, but maybe something to take into
>> > > consideration.
>> > >
>> > > [1] -
>> > >
>> https://docs.travis-ci.com/user/encryption-keys/#Notifications-Example
>> > > [2] -
>> https://github.com/twbs/bootstrap/blob/master/.travis.yml#L30-L32
>> > >
>> > > On 2016-06-30, Stian Thorgersen wrote:
>> > > > The encryption support in Travis isn't that so you can encrypt
>> sensitive
>> > > > details that goes into .travis.yaml which is public through the
>> repo?
>> > > >
>> > > > On 30 June 2016 at 06:52, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > > >
>> > > > > I don't see the need for that. For the client registration CLI we
>> will
>> > > > > support initial access tokens as well as service accounts with
>> > > pub/priv key
>> > > > > authentication. For admin cli we'll support service accounts. No
>> one
>> > > should
>> > > > > be using username/password combined with automated jobs.
>> > > > >
>> > > > > On 29 June 2016 at 21:49, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>> > > > >
>> > > > >> I'm not sure if it's part of the scope for now. But
>> > > > >> thinking about situations where you have to automate jobs plus
>> provide
>> > > > >> credentials without exposing them.
>> > > > >>
>> > > > >> My suggestion, even if it's not part of the scope for now is to
>> > > encrypt
>> > > > >> it,
>> > > > >> like travis does[1]. I know that our plan is to deal of access
>> token,
>> > > > >> but would be nice to not expose credentials not even a single
>> time.
>> > > > >>
>> > > > >>
>> > > > >> [1] - https://docs.travis-ci.com/user/encryption-keys/
>> > > > >>
>> > > > >> On 2016-06-29, Stian Thorgersen wrote:
>> > > > >> > On 28 June 2016 at 11:40, Marko Strukelj <mstrukel at redhat.com>
>> > > wrote:
>> > > > >> >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <
>> > > > >> sthorger at redhat.com>
>> > > > >> > > wrote:
>> > > > >> > >
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com>
>> > > wrote:
>> > > > >> > >>
>> > > > >> > >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
>> > > > >> > >>> > I've started work on Client Registration CLI tool. As a
>> first
>> > > > >> step,
>> > > > >> > >>> here
>> > > > >> > >>> > is a design document describing how I imagine the tool
>> would
>> > > be
>> > > > >> used.
>> > > > >> > >>> >
>> > > > >> > >>> >
>> > > > >> > >>> >
>> > > > >> > >>>
>> > > > >>
>> > >
>> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
>> > > > >> > >>> >
>> > > > >> > >>> >
>> > > > >> > >>> > I'll use this document as a spec / guide as I implement
>> the
>> > > client
>> > > > >> > >>> tool.
>> > > > >> > >>> >
>> > > > >> > >>> > Within days I'll also send a link to initial ideas for
>> Admin
>> > > > >> Client
>> > > > >> > >>> tool
>> > > > >> > >>> > which in principle should allow administrator to
>> configure
>> > > > >> everything
>> > > > >> > >>> > that can otherwise be done through Admin Console.
>> > > > >> > >>> >
>> > > > >> > >>> > Any feedback welcome.
>> > > > >> > >>>
>> > > > >> > >>> FWIW we've already written a client registration tool for
>> > > Keycloak.
>> > > > >> At
>> > > > >> > >>> the moment it is specifically targeted for SAML clients
>> (SP,
>> > > Service
>> > > > >> > >>> Provider) in Apache HTTPD but we have plans to extend it to
>> > > OIDC.
>> > > > >> > >>>
>> > > > >> > >>> It is currently in Fedora and will also ship in OSP.
>> > > > >> > >>>
>> > > > >> > >>> It is hosted here:
>> > > > >> > >>> https://github.com/jdennis/keycloak-httpd-client-install
>> > > > >> > >>>
>> > > > >> > >>> The man page for it (formatted for HTML) can be found here:
>> > > > >> > >>>
>> > > > >>
>> > >
>> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
>> > > > >> > >>>
>> > > > >> > >>> The man page discusses 3 different ways you can
>> authenticate
>> > > and 2
>> > > > >> > >>> different ways client registration can be performed.
>> > > > >> > >>>
>> > > > >> > >>> I have a lot of experience with Keycloak client
>> registration
>> > > tools
>> > > > >> and
>> > > > >> > >>> have worked through many issues, I'm happy to share my
>> > > experience.
>> > > > >> > >>>
>> > > > >> > >>> Here are some thoughts/issues you may want to take into
>> account:
>> > > > >> > >>>
>> > > > >> > >>> * The tool must be capable of running without
>> interactivity as
>> > > part
>> > > > >> of a
>> > > > >> > >>> scripted installation task.
>> > > > >> > >>>
>> > > > >> > >>> * It should not depend on a home directory being available.
>> > > > >> > >>>
>> > > > >> > >>> * If a home directory is utilized how will you
>> disambiguate any
>> > > > >> stored
>> > > > >> > >>> state belonging to a script that is run by different
>> processes
>> > > but
>> > > > >> under
>> > > > >> > >>> the same user (possibly simultaneously)? To clarify, many
>> > > install
>> > > > >> tools
>> > > > >> > >>> run as the root user or some other admin user. Each
>> invocation
>> > > of
>> > > > >> these
>> > > > >> > >>> install tools can be run with entirely different
>> parameters and
>> > > may
>> > > > >> > >>> execute either in parallel or partially overlapping in
>> time.
>> > > > >> > >>>
>> > > > >> > >>
>> > > > >> > > Maybe I should have included this link in the design
>> document to
>> > > make
>> > > > >> it
>> > > > >> > > clear to everyone what Client Registration this tool is for:
>> > > > >> > >
>> > > > >>
>> > >
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
>> > > > >> > >
>> > > > >> > > It's a REST API defined by specs, and is separate from Admin
>> REST
>> > > API.
>> > > > >> > >
>> > > > >> > > About using home directory, the way I see it - you either a)
>> > > specify
>> > > > >> all
>> > > > >> > > the state when executing a command, or b) you have a
>> mechanism
>> > > that
>> > > > >> allows
>> > > > >> > > the concept of 'session' between command invocations.
>> > > > >> > >
>> > > > >> > > If you use the first approach (a) then on each invocation of
>> the
>> > > > >> command
>> > > > >> > > you have to specify either username:password, or a token. The
>> > > client
>> > > > >> > > registration specification defines workflow for Initial
>> Access
>> > > > >> Tokens, and
>> > > > >> > > Registration Access Tokens, which require to automatically
>> > > intercept a
>> > > > >> > > newly issued token after each CRUD operation, and save it
>> for any
>> > > > >> > > subsequent operation on the same client resource. I can't
>> see how
>> > > this
>> > > > >> > > could be achieved by using the first approach.
>> > > > >> > >
>> > > > >> > > For the second approach (b) you need a way to communicate
>> > > 'session'
>> > > > >> state.
>> > > > >> > > The state we are saving are just tokens associated with
>> current
>> > > user
>> > > > >> or
>> > > > >> > > specific clients, or specific grants. Looks to me that if
>> multiple
>> > > > >> parallel
>> > > > >> > > sessions are in collision about these tokens then the cli
>> tool
>> > > itself
>> > > > >> might
>> > > > >> > > be used the wrong way. Namely, once the client authenticates
>> with
>> > > a
>> > > > >> login,
>> > > > >> > > access token and refresh token are cached. Multiple client
>> > > instances
>> > > > >> can
>> > > > >> > > use the same access token, and the same refresh token. A
>> thing to
>> > > > >> maybe be
>> > > > >> > > careful about is just properly locking the file when making
>> > > changes
>> > > > >> to it.
>> > > > >> > > For initial access token you have to explicitly add it, and
>> > > assign it
>> > > > >> an
>> > > > >> > > alias - you can use any random value there if you want. For
>> > > > >> registration
>> > > > >> > > access token they are automatically associated with initial
>> token
>> > > > >> they were
>> > > > >> > > initiated from - again there should be no collision.
>> > > > >> > >
>> > > > >> >
>> > > > >> > I like the option to have two approaches as there are two
>> use-cases.
>> > > > >> One is
>> > > > >> > manually registering for example during development or when
>> manually
>> > > > >> > configuring an application to use Keycloak. Another is
>> scripted.
>> > > Even
>> > > > >> for
>> > > > >> > scripted you may quite likely want to just add service account
>> > > > >> credentials
>> > > > >> > or initial access token directly to ~/.keycloak/ rather than
>> pass
>> > > these
>> > > > >> to
>> > > > >> > the commands.
>> > > > >> >
>> > > > >> > Registration access tokens are associated with a client, not an
>> > > initial
>> > > > >> > access token. Also, remember the registration access token is
>> > > changed on
>> > > > >> > updates.
>> > > > >> >
>> > > > >> >
>> > > > >> > >
>> > > > >> > > What alternative mechanism would you suggest for storing
>> 'session'
>> > > > >> info?
>> > > > >> > > We want to support Windows as well so it can't be Unix / Bash
>> > > > >> specific.
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >>
>> > > > >> > >>> * The tool should be idempotent.
>> > > > >> > >>>
>> > > > >> > >>> * You suggest storing tokens in a cache, how do you plan on
>> > > > >> handling the
>> > > > >> > >>> case where a token expires before all operations are
>> complete?
>> > > > >> > >>>
>> > > > >> > >>> * We also initially took the approach of caching tokens but
>> > > > >> discovered
>> > > > >> > >>> the complexity did not justify the minimal cost of
>> obtaining a
>> > > new
>> > > > >> token
>> > > > >> > >>> for each invocation. This greatly simplified the code with
>> very
>> > > > >> little
>> > > > >> > >>> performance impact.
>> > > > >> > >>>
>> > > > >> > >>> * You do not mention what type of client you're
>> registering. I'm
>> > > > >> > >>> assuming it's OpenID but SAML clients (SP) are equally
>> > > important.
>> > > > >> The
>> > > > >> > >>> tool must be able to handle both.
>> > > > >> > >>>
>> > > > >> > >>
>> > > > >> > >> Marko is probably referring to the Keycloak client
>> > > representation,
>> > > > >> which
>> > > > >> > >> can be either OpenID or SAML. However, we also need to
>> support
>> > > OpenID
>> > > > >> > >> Connect client descriptions as well as SAML entity
>> descriptors as
>> > > > >> both are
>> > > > >> > >> supported by client reg services.
>> > > > >> > >>
>> > > > >> > >
>> > > > >> > > The CLI needs to know which of the client registration
>> providers
>> > > (REST
>> > > > >> > > endpoints) to use - there are four as described in the Client
>> > > > >> Registration
>> > > > >> > > documentation (
>> > > > >> > >
>> > > > >>
>> > >
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
>> > > > >> > > )
>> > > > >> > >
>> > > > >> > > Ideally the input format of the file could be recognised as
>> only
>> > > > >> > > appropriate for one of these providers, and the correct
>> provider
>> > > then
>> > > > >> > > automatically used. But maybe we need a way to explicitly
>> tell the
>> > > > >> tool
>> > > > >> > > what provider to use. For example:
>> > > > >> > >
>> > > > >> > > kc new --type default --name test-app --enabled true
>> --base-url
>> > > > >> > > http://localhost:8480/test-app --redirect-uri '
>> > > > >> > > http://localhost:8480/test-app/*' --admin-url
>> > > > >> > > http://localhost:8480/test-app/logout --secret password | kc
>> > > create
>> > > > >> > > --type default -f -
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > Having to set --type for both creating a description (kc
>> new), and
>> > > > >> > > pushing it to the server (kc create) is not ideal.
>> > > > >> > >
>> > > > >> >
>> > > > >> > We can detect the difference between Keycloak client rep, SAML
>> and
>> > > OIDC
>> > > > >> > json that's pretty trivial and we should do that. However,
>> there
>> > > needs
>> > > > >> to
>> > > > >> > be a way to specify the provider as well as there could be
>> custom
>> > > > >> providers
>> > > > >> > added.
>> > > > >> >
>> > > > >> > For getting the client it should by default return Keycloak
>> client
>> > > > >> > representation, but we need an option to be able to specify the
>> > > > >> provider so
>> > > > >> > it can return the client installation file instead.
>> > > > >> >
>> > > > >> > With regards to creating by passing arguments rather than a
>> file
>> > > that
>> > > > >> > should only support client representation files.
>> > > > >> >
>> > > > >> >
>> > > > >> >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >>>
>> > > > >> > >>> * I don't see anything in your document on how to specify
>> the
>> > > SAML
>> > > > >> > >>> metadata.
>> > > > >> > >>>
>> > > > >> > >>
>> > > > >> > > Instead of piping in my-client.json, you would pipe in
>> > > > >> my-client-saml.xml,
>> > > > >> > > possibly requiring an extra --type specifier as described
>> above.
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >>
>> > > > >> > >>> * I don't see anything in your document on how the user
>> > > modifies the
>> > > > >> > >>> client. It appears as if you are retrieving a
>> > > ClientRepresentation
>> > > > >> JSON
>> > > > >> > >>> document and expecting the user to edit it in a text editor
>> > > which
>> > > > >> will
>> > > > >> > >>> then be sent back. That won't work for non-interactive
>> > > installs. It
>> > > > >> also
>> > > > >> > >>> presumes the user knows how to read and modify the JSON.
>> > > > >> > >>>
>> > > > >> > >>
>> > > > >> > >> It would be nice to be able to set specific fields without
>> > > having to
>> > > > >> > >> modify JSON. We discussed that for the Admin CLI, but we
>> should
>> > > > >> probably
>> > > > >> > >> also add it to the client reg CLI
>> > > > >> > >>
>> > > > >> > >
>> > > > >> > > It would be very valuable to see some of the usecases, what
>> kind
>> > > of
>> > > > >> > > changes people do on existing clients.
>> > > > >> > >
>> > > > >> >
>> > > > >> > We should support anything that is in client representation. It
>> > > should
>> > > > >> just
>> > > > >> > be a generic way to change json fields. For example:
>> > > > >> >
>> > > > >> > # kcreg update <client id> --set enabled=false --set baseUrl=
>> > > > >> > http://new-url/myapp --remove rootUrl
>> > > > >> >
>> > > > >> > This would get the KC client rep, change the corresponding
>> fields
>> > > and
>> > > > >> send
>> > > > >> > it back.
>> > > > >> >
>> > > > >> >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >>>
>> > > > >> > >>> * Keycloak currently has a few problems with client
>> > > registration and
>> > > > >> > >>> it's necessary to modify the client before it will work
>> > > correctly.
>> > > > >> We
>> > > > >> > >>> currently do this via the REST API. How are you planning on
>> > > handling
>> > > > >> > >>> these issues in your installer? It would be nice if the
>> > > installer
>> > > > >> was
>> > > > >> > >>> aware of the Keycloak version and could apply "fix-ups" as
>> > > needed
>> > > > >> based
>> > > > >> > >>> on the version.
>> > > > >> > >>>
>> > > > >> > >>
>> > > > >> > >> AFAIK you have one problem? About not all redirect URI
>> included
>> > > from
>> > > > >> the
>> > > > >> > >> SAML entity descriptor. Is that what you are referring to
>> or do
>> > > you
>> > > > >> have
>> > > > >> > >> other problems?
>> > > > >> > >>
>> > > > >> > >> In either case fix-ups should be performed by the client
>> > > registration
>> > > > >> > >> services, not in the CLI.
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >>>
>> > > > >> > >>> * Keycloak has two ways to register a client (client
>> > > registration
>> > > > >> > >>> service vs. REST API). The two methods do not produce the
>> same
>> > > > >> client
>> > > > >> > >>> configuration (I suspect because they do not share common
>> code
>> > > in
>> > > > >> the
>> > > > >> > >>> server). How are you planning on addressing the
>> discrepancies?
>> > > > >> > >>>
>> > > > >> > >>
>> > > > >> > >> The task of the CLI is not to address any discrepancies.
>> It's
>> > > just
>> > > > >> > >> invoking the client reg services. Any discrepancies should
>> be
>> > > > >> handled by
>> > > > >> > >> the client reg services themselves. Have you created JIRA's
>> for
>> > > > >> these or
>> > > > >> > >> can you list them to us?
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >>>
>> > > > >> > >>> * The tool should be smart enough to produce a working
>> client
>> > > > >> without
>> > > > >> > >>> manual intervention (i.e. the need to run admin cli
>> commands
>> > > > >> afterwards
>> > > > >> > >>> to fix problems). Most admins won't know how to tweak the
>> > > > >> configuration.
>> > > > >> > >>>
>> > > > >> > >>
>> > > > >> > >> Can you list any you are aware of? Same comment as above
>> applies
>> > > > >> though,
>> > > > >> > >> it's the responsibility of the client reg services to handle
>> > > this,
>> > > > >> not the
>> > > > >> > >> CLI. Otherwise you'd have different behavior if you invoke
>> > > client reg
>> > > > >> > >> services directly rather than through the CLI.
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >>>
>> > > > >> > >>> * The tool should not have significant dependencies.
>> > > > >> > >>>
>> > > > >> > >>
>> > > > >> > >> It'll be a fat-jar and will have a single dependency on the
>> JVM.
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >>>
>> > > > >> > >>> Those are the thoughts off the top of my head, as you fill
>> out
>> > > the
>> > > > >> > >>> details I'll continue to review. Recall the plan of record
>> is
>> > > for
>> > > > >> > >>> Keycloak to provide such tools which we will then utilize.
>> The
>> > > > >> > >>> keycloak-httpd-client-install tool is a stop-gap solution
>> until
>> > > such
>> > > > >> > >>> time as "offical" tools become available.
>> > > > >> > >>>
>> > > > >> > >>>
>> > > > >> > >>>
>> > > > >> > >>> --
>> > > > >> > >>> John
>> > > > >> > >>> _______________________________________________
>> > > > >> > >>> 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
>> > > > >>
>> > > > >
>> > > > >
>> > >
>> > > --
>> > >
>> > > abstractj
>> > > PGP: 0x84DC9914
>> > >
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/de8c3773/attachment-0001.html 

From ssilvert at redhat.com  Thu Jun 30 14:27:24 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 30 Jun 2016 14:27:24 -0400
Subject: [keycloak-dev] Please help - need text for SAML
	HttpBasicAuthenticator
Message-ID: <5775648C.2010908@redhat.com>

Working on https://issues.jboss.org/browse/RHSSO-274

The problem is just that getDisplayType() and getHelpText() return null.

What text should these two methods return?

https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/saml/profile/ecp/authenticator/HttpBasicAuthenticator.java

From psilva at redhat.com  Thu Jun 30 15:42:06 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 30 Jun 2016 15:42:06 -0400 (EDT)
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <577524F4.9070803@redhat.com>
References: <577524F4.9070803@redhat.com>
Message-ID: <1831089249.5182643.1467315726423.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, June 30, 2016 10:56:04 AM
> Subject: [keycloak-dev] Scope parameter support
> 
> IMO We will also need some more flexible way to specify how the value of
> scope parameter will be mapped to roles and protocolMappers. For example
> if I use "scope=foo", it can mean that I want realm role "foo1", client
> role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc.

+1. I think I have mentioned something like that on a previous thread, where we should be able to build scopes from attributes (eg.: from user) or even compose a scope based on multiple attributes. The same concept applies to protocol mappers, just like you proposed.

> 
> I can see 2 possibilities:
> 
> a) Configure allowed scope param separately per each role / protocolMapper
> 
> If some role has "Scope param required" checked, you will have
> possibility to configure list of available values of scope parameter,
> which this role will be applied to. This will be configured per-each
> role separately.
> 
> Example: I have realm role "foo" . I check "scope param required" to
> true. Then I will define "scope param values" :  "bar" and "baz". It
> means that if someone uses parameter "scope=bar" or
> scope=baz", then role "foo" will be applied to token. Otherwise it won't
> be applied.
> 
> Similarly it will be for protocolMappers. We will add switch "Scope
> param required" to protocolMappers and we will use list of available
> values of scope parameter, which is configured per each protocolMapper
> separately.

IMO, roles and scopes are separated concepts. Where scopes may also implicate access to the roles granted to an user. Scopes have a pretty broad meaning. 

With that in mind, don't you think that we could just have a scope "roles" ? Which could be used to ask for the roles associated with the user that the client is acting on behalf of ?

I think that the Protocol Mappers (for OIDC) provide pretty much everything you need. The missing part would be to make it capable of grouping other mappers. Actually, the concept behind a protocol mapper is pretty much
related with a scope.

From jdennis at redhat.com  Thu Jun 30 17:29:01 2016
From: jdennis at redhat.com (John Dennis)
Date: Thu, 30 Jun 2016 17:29:01 -0400
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <1831089249.5182643.1467315726423.JavaMail.zimbra@redhat.com>
References: <577524F4.9070803@redhat.com>
	<1831089249.5182643.1467315726423.JavaMail.zimbra@redhat.com>
Message-ID: <a396e2c4-451c-f991-935a-7e25f8843bee@redhat.com>

On 06/30/2016 03:42 PM, Pedro Igor Silva wrote:
> IMO, roles and scopes are separated concepts. Where scopes may also
> implicate access to the roles granted to an user. Scopes have a
> pretty broad meaning.
>
> With that in mind, don't you think that we could just have a scope
> "roles" ? Which could be used to ask for the roles associated with
> the user that the client is acting on behalf of ?
>
> I think that the Protocol Mappers (for OIDC) provide pretty much
> everything you need. The missing part would be to make it capable of
> grouping other mappers. Actually, the concept behind a protocol
> mapper is pretty much related with a scope.

I think it would be valuable for the Keycloak team to define and publish 
what it thinks the terms "scope" and "role" mean and how those values 
propagate through Keycloak (e.g. where do they come from, if they are 
synthesized from other values then how). As well as their intended use.

People may be coming to Keycloak with a different set of assumptions on 
what those terms mean.

At the same time it would be worthwhile to include a discussion of 
groups and how they relate to roles (and scope?). That is because many 
applications define and manage roles themselves and assign roles based 
on group attributes returned in an assertion/claim attribute. Typically 
we have not expected an IdP to assign roles to a user. In an application 
which supports multiple IdP's (other than Keycloak, e.g. federation) you 
simply cannot assume the IdP can map a user into a role. Mapping a user 
into a role is usually application specific logic synthesized from 
attributes bound to the user principal.

-- 
John

From singhrasster at gmail.com  Thu Jun 30 18:26:48 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Thu, 30 Jun 2016 17:26:48 -0500
Subject: [keycloak-dev] How to setup a maven project generating jar
 containing authentication providers in a debug mode in eclipse
Message-ID: <CAJ0vL++h+oyLKLUn6sge6F63NR=SdE+Xv7mFYHoGCGk1=U1QgA@mail.gmail.com>

We have a Maven project setup on Eclipse that uses some keycloak features
and we generate a jar that contains our AuthenticationProvider classes etc.
We use docker for the deployment. We basically run a jboss/keycloak image
there
We have a shell script that has a bunch of commands to copy our project
jars from local to the keycloak image on docker container like:

docker cp /customauthenticator-1.0.0-SNAPSHOT.jar
keycloak:/home/modules/xxx.yyy.zz.keycloak.customizations
....
docker restart keycloak

Running this shell script deploys everything on keycloak on docker.
And so far we are just putting logs throughout our code to debug issues.
We want to be able to setup a debugging environment on our eclipse. I am
not sure how to achieve this when we use keycloak. Because, here we
basically build our modules or authenticator jars etc and copy them to
keycloak directories. So, it's not a standalone project war file that we
are directly deploying to app server as such. So, then how do we put our
maven project (creating jars etc) in a debug mode in eclipse? Is it
possible? How?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/e23819d3/attachment.html 

From thomas.darimont at googlemail.com  Thu Jun 30 19:29:14 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 1 Jul 2016 01:29:14 +0200
Subject: [keycloak-dev] How to setup a maven project generating jar
 containing authentication providers in a debug mode in eclipse
In-Reply-To: <CAJ0vL++h+oyLKLUn6sge6F63NR=SdE+Xv7mFYHoGCGk1=U1QgA@mail.gmail.com>
References: <CAJ0vL++h+oyLKLUn6sge6F63NR=SdE+Xv7mFYHoGCGk1=U1QgA@mail.gmail.com>
Message-ID: <CAK-7U1iUCKjsppVvg-67pA+YgRZWPTih-g+0p8hGAW=XnNPD_w@mail.gmail.com>

Hello,

you could add -debug flag to the standalone.sh command-line or define the
following env variables in your docker container:
set DEBUG_MODE=true
set DEBUG_PORT=8787

this will start keycloak with remote debugging enabled by default on port
8787 which you need to expose on your docker container or use the container
interface...

you can then connect to the keycloak instance inside the docker container
via the remote debugger from your IDE.
For eclipse just go to "Debug configurations..." -> Remote Java Application
-> select your project with the custom authenticator -> adjust hostname and
port and click "debug".

Cheers,
Thomas

2016-07-01 0:26 GMT+02:00 Rashmi Singh <singhrasster at gmail.com>:

> We have a Maven project setup on Eclipse that uses some keycloak features
> and we generate a jar that contains our AuthenticationProvider classes etc.
> We use docker for the deployment. We basically run a jboss/keycloak image
> there
> We have a shell script that has a bunch of commands to copy our project
> jars from local to the keycloak image on docker container like:
>
> docker cp /customauthenticator-1.0.0-SNAPSHOT.jar
> keycloak:/home/modules/xxx.yyy.zz.keycloak.customizations
> ....
> docker restart keycloak
>
> Running this shell script deploys everything on keycloak on docker.
> And so far we are just putting logs throughout our code to debug issues.
> We want to be able to setup a debugging environment on our eclipse. I am
> not sure how to achieve this when we use keycloak. Because, here we
> basically build our modules or authenticator jars etc and copy them to
> keycloak directories. So, it's not a standalone project war file that we
> are directly deploying to app server as such. So, then how do we put our
> maven project (creating jars etc) in a debug mode in eclipse? Is it
> possible? How?
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160701/0b44f4d8/attachment.html 

From singhrasster at gmail.com  Thu Jun 30 20:39:57 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Thu, 30 Jun 2016 19:39:57 -0500
Subject: [keycloak-dev] How to setup a maven project generating jar
 containing authentication providers in a debug mode in eclipse
In-Reply-To: <CAK-7U1iUCKjsppVvg-67pA+YgRZWPTih-g+0p8hGAW=XnNPD_w@mail.gmail.com>
References: <CAJ0vL++h+oyLKLUn6sge6F63NR=SdE+Xv7mFYHoGCGk1=U1QgA@mail.gmail.com>
	<CAK-7U1iUCKjsppVvg-67pA+YgRZWPTih-g+0p8hGAW=XnNPD_w@mail.gmail.com>
Message-ID: <CAJ0vL+JFoaa3qy5k4-UVOZb5xDFBXhTp8bV6xznJpUa88fTUNA@mail.gmail.com>

Thanks Thomas for your reply. I have a few questions on your response. I am
still very new to docker, so please bear with me.
when you say I can set env variables in docker container, would this be
sufficient?

First connect to the docker container as:

docker exec -i -t keycloak bash
Then, once I am in the container, I run the following to set env variables?

set DEBUG_MODE=true
set DEBUG_PORT=8787
exit
Then, restart the container as:
docker restart keycloak    (keycloak is the name of my container)
Also, how can I make sure that the env variable got correctly set in the
docker container? From inside the container, if I run the command "env",
should it list these new env variables if they are added successfully?

Then, when you say "......default on port 8787 which you need to expose on
your docker container or use the container interface...", what exactly do
you mean? Do you mean some sort of port forwarding? Could you tell me w
tohat exactly I need to do with my existing container named as "keycloak"

Then, on eclipse, where you mentioned the settings for the Debug
configurations, what should be the hostname there? would it be localhost?
or the default machine IP of docker which is 192.168.99.100? Or it should
be something else?



On Thu, Jun 30, 2016 at 6:29 PM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello,
>
> you could add -debug flag to the standalone.sh command-line or define the
> following env variables in your docker container:
> set DEBUG_MODE=true
> set DEBUG_PORT=8787
>
> this will start keycloak with remote debugging enabled by default on port
> 8787 which you need to expose on your docker container or use the container
> interface...
>
> you can then connect to the keycloak instance inside the docker container
> via the remote debugger from your IDE.
> For eclipse just go to "Debug configurations..." -> Remote Java
> Application -> select your project with the custom authenticator -> adjust
> hostname and port and click "debug".
>
> Cheers,
> Thomas
>
> 2016-07-01 0:26 GMT+02:00 Rashmi Singh <singhrasster at gmail.com>:
>
>> We have a Maven project setup on Eclipse that uses some keycloak features
>> and we generate a jar that contains our AuthenticationProvider classes etc.
>> We use docker for the deployment. We basically run a jboss/keycloak image
>> there
>> We have a shell script that has a bunch of commands to copy our project
>> jars from local to the keycloak image on docker container like:
>>
>> docker cp /customauthenticator-1.0.0-SNAPSHOT.jar
>> keycloak:/home/modules/xxx.yyy.zz.keycloak.customizations
>> ....
>> docker restart keycloak
>>
>> Running this shell script deploys everything on keycloak on docker.
>> And so far we are just putting logs throughout our code to debug issues.
>> We want to be able to setup a debugging environment on our eclipse. I am
>> not sure how to achieve this when we use keycloak. Because, here we
>> basically build our modules or authenticator jars etc and copy them to
>> keycloak directories. So, it's not a standalone project war file that we
>> are directly deploying to app server as such. So, then how do we put our
>> maven project (creating jars etc) in a debug mode in eclipse? Is it
>> possible? How?
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160630/ebf480cd/attachment-0001.html 

From psilva at redhat.com  Thu Jun 30 20:47:47 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 30 Jun 2016 20:47:47 -0400 (EDT)
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <a396e2c4-451c-f991-935a-7e25f8843bee@redhat.com>
References: <577524F4.9070803@redhat.com>
	<1831089249.5182643.1467315726423.JavaMail.zimbra@redhat.com>
	<a396e2c4-451c-f991-935a-7e25f8843bee@redhat.com>
Message-ID: <1686200532.5344144.1467334067599.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "John Dennis" <jdennis at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, June 30, 2016 6:29:01 PM
> Subject: Re: [keycloak-dev] Scope parameter support
> 
> On 06/30/2016 03:42 PM, Pedro Igor Silva wrote:
> > IMO, roles and scopes are separated concepts. Where scopes may also
> > implicate access to the roles granted to an user. Scopes have a
> > pretty broad meaning.
> >
> > With that in mind, don't you think that we could just have a scope
> > "roles" ? Which could be used to ask for the roles associated with
> > the user that the client is acting on behalf of ?
> >
> > I think that the Protocol Mappers (for OIDC) provide pretty much
> > everything you need. The missing part would be to make it capable of
> > grouping other mappers. Actually, the concept behind a protocol
> > mapper is pretty much related with a scope.
> 
> I think it would be valuable for the Keycloak team to define and publish
> what it thinks the terms "scope" and "role" mean and how those values
> propagate through Keycloak (e.g. where do they come from, if they are
> synthesized from other values then how). As well as their intended use.
> 
> People may be coming to Keycloak with a different set of assumptions on
> what those terms mean.
> 
> At the same time it would be worthwhile to include a discussion of
> groups and how they relate to roles (and scope?). That is because many
> applications define and manage roles themselves and assign roles based
> on group attributes returned in an assertion/claim attribute. Typically
> we have not expected an IdP to assign roles to a user. In an application
> which supports multiple IdP's (other than Keycloak, e.g. federation) you
> simply cannot assume the IdP can map a user into a role. Mapping a user
> into a role is usually application specific logic synthesized from
> attributes bound to the user principal.

I guess we share the same ideas about roles and groups. 

Scopes are heavily mentioned by both OAuth2 and OIDC specs and they usually limit the authorization granted to the client by the resource owner.

Scopes have a pretty broad meaning as they can represent a single attribute, a group of attributes, an action on a particular resource managed by a resource server, etc. Even roles can have a scope, so you are basically saying that a client is allowed to access that info on behalf of the user or resource owner.

In Keycloak, you can grant roles directly to an user or to the group he belongs to. But that doesn't mean that you can't do your own role mapping based on the claims returned within an access token. I share the same opinion about federation and multiple IdP scenarios, but there are a lot of people that also expect the IdP granting roles to an user. Specially when there is an 1:N mapping between IdPs and SPs.

Beside that, you would usually prefer assign roles to a group (group of users) than to each user individually. It makes management easier ...

> 
> --
> John
>