From mposolda at redhat.com  Mon Aug  3 07:36:12 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 03 Aug 2015 13:36:12 +0200
Subject: [keycloak-dev] Kerberos with IE does not work
In-Reply-To: <416acc5a-f78d-47dd-b33a-03912d857fcc@me.com>
References: <416acc5a-f78d-47dd-b33a-03912d857fcc@me.com>
Message-ID: <55BF522C.6050008@redhat.com>

On 29.7.2015 16:37, Michael Gerber wrote:
> The ClearAuthenticationCache command deletes the following data:
> - Session cookies
> - sessionStorage
> - HTTP Authentication (e.g. Digest or Basic HTTP credentials)
> - HTTPS Client Certificates (e.g. sites that use certificates or 
> SmartCards)
>
> But keycloak needs the session cookie, otherwise the user has to 
> relogin after each page reload.
>
> Isn't the clientSecret anyway public if it is send in the 
> Authorization header?
Yes, it is for JS clients. That's why it's better to not use 
clientSecret with javascript based clients, but instead mark those 
clients as "public" in keycloak admin console. In this case keycloak.js 
will use client_id parameter instead of Authorization header. Can this 
work for you?

Thing is, that currently AuthorizeClientUtil will likely automatically 
send 401 if it found "Authorization: Negotiate ..." header even if you 
have public client and you want to use client_id (I did not test it, but 
guessing from looking at the code). So I've created the simple patch to 
avoid it: 
https://github.com/mposolda/keycloak/commit/858882a306cfc66567dedfcb40454354aa891903

So if you do the steps like:
1) make your client as public
2) Apply my patch

will it help?

I am still seeing potential issues if your javascript client needs to 
send REST requests authorized by "Authorization: Bearer" header with 
accessToken. Not sure if IE doesn't again overwrite the header with 
"Authorization: Negotiate". In this case REST request would fail. But 
hopefully not... If you have opportunity to try it, it will be cool.

Thanks,
Marek

>
> Am 29. Juli 2015 um 14:27 schrieb Bill Burke <bburke at redhat.com>:
>
>> The trick you found earlier doesn't work?
>>
>> http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header
>>
>> Also, what if in keycloak.js if kc.clientSecret is null? Just remove
>> the client secret IMO. You shouldn't be exposing the client secret as
>> it is now public to everybody in the world....
>>
>> On 7/29/2015 8:05 AM, Michael Gerber wrote:
>>> I could find a solution for my IE problem.
>>>
>>> IE overwrites the Authorization header in the XMLHttpRequest
>>> (/protocol/openid-connect/token) with "Authorization: Negotiate".
>>>
>>> To solve this problem, I added on the client the client_id
>>> and client_secret to the form and changed the authorizeClient method, so
>>> it checks first the form data instead of the authorization http header.
>>>
>>> Have a look at my code:
>>> https://github.com/gerbermichi/keycloak/commit/32880b210ed27f782a2f9fcd01da4df21ee0953c
>>>
>>> Should I create a pull request for the changes or do you have a better
>>> solution?
>>>
>>> cheers
>>> Michael
>>>
>>>
>>>
>>> Am 22. Juli 2015 um 11:46 schrieb Marek Posolda <mposolda at redhat.com 
>>> <mailto:mposolda at redhat.com>
>>> <mailto:mposolda at redhat.com>>:
>>>
>>>> Hi Michael,
>>>>
>>>> No idea if there is other solution, I've never tried SPNEGO with
>>>> Internet explorer TBH :(
>>>>
>>>> Could you please create JIRA for this?
>>>>
>>>> Thanks,
>>>> Marek
>>>>
>>>> On 22.7.2015 10:07, Michael Gerber wrote:
>>>>> Hi all
>>>>>
>>>>> My kerberos configuration works fine with FireFox and Chrome, but it
>>>>> does not work with IE.
>>>>> It shows a prompt where the user has to enter a username and password.
>>>>>
>>>>> I can successfully get an access code, but I can not get an access
>>>>> token, because IE overwrites the Authorization header in the AJAX
>>>>> request. (see
>>>>> http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header)
>>>>>
>>>>> I can fix this by adding
>>>>> document.execCommand('ClearAuthenticationCache', 'false');
>>>>> above of
>>>>> var req = new XMLHttpRequest();
>>>>> approximately at the line 374 in the keycloack.js file.
>>>>>
>>>>> Is there another solution for this problem?
>>>>>
>>>>> cheers
>>>>> Michael
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> 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/20150803/6515439c/attachment-0001.html 

From Scott.Rehorn at software.dell.com  Mon Aug  3 13:40:08 2015
From: Scott.Rehorn at software.dell.com (Scott Rehorn)
Date: Mon, 3 Aug 2015 17:40:08 +0000
Subject: [keycloak-dev] groups vs. organizations
In-Reply-To: <55BBE79F.5090703@redhat.com>
References: <55BAA513.9090009@redhat.com>
	<D1E1070C.17E19%Scott.Rehorn@software.dell.com>
	<55BBE79F.5090703@redhat.com>
Message-ID: <F893802C2FB19B459F1A54D865A9C95C35DC080D@ALVMBXW02.prod.quest.corp>

Comments below...

> -----Original Message-----
> From: Bill Burke [mailto:bburke at redhat.com]
> Sent: Friday, July 31, 2015 2:25 PM
> To: Scott Rehorn <Scott.Rehorn at software.dell.com>; keycloak-
> dev at lists.jboss.org
> Subject: Re: groups vs. organizations
> 
> 
> 
> On 7/31/2015 2:42 PM, Scott Rehorn wrote:
> > I think it is true that an organization is kind of a special case of a
> > ?group?. We had specific requirements for the concept of what amounted
> > to a single group just to bind a few shared attributes between related
> > relying parties (clients). We decided to deliberately push a group
> > concept for ?later? because there are a bunch of complicating factors with
> groups.
> > One is that groups are often defined in people?s IdPs (esp. with
> > Active Directory), and the policy for mapping or merging those defs
> > dragged in more complexity than we wanted to do right away. Another is
> > that groups often want to be nested and that?s again more complexity
> > than we were willing to bite off for so simple a function as an org.
> >
> 
> You're going to have to explain what this complication is as it relates to
> people's IDPs and AD/LDAP.  Also, we have already dealt with nesting via
> Composite Roles in Keycloak so its not that big a deal.
> 

One of the main attractions for doing federation for us was to help move away from the definition of groups inside AD which is a common occurrence in the world -- even though it doesn't belong in AD in a brokered or federated model. Our main concern was about reconciliation and propagation of IdP-defined groups into a federated model. If people have already defined groups such that the claims returned contained group definitions, then the broker would have to introduce more mapping to make sure all the groups expressed properly in the final claimset. This isn't particularly difficult, but supporting it was going to drag in more code than we wanted to write just to support an entity where we could hang some shared attributes.  


> Maybe we shouldn't call it a "Group" or an "Organization".  Stian floated the
> idea of calling it a Composite.  Maybe that is just too developery/engineery
> and not Opssy/Sys Adminny enough and we need to have "Group" and
> "Organization" even though they are the same concept logically?
> 

Engineery heh, yes. I think the implementation probably doesn't require a separate model (group vs. organization), and it's probably enough just to use 'group' as opposed to 'composite' - an org is would be just another group with a tag to enable 'organization' semantics, whatever that works out to be. Could be rendered in the UI slightly differently, but, under the hood, it's groups. 

Here's a possible summary:
Groups: 
* have names
* can contain other groups
* can carry a 'schema' which represent available attributes (more generally, claims)
* support mapping and aggregation from IdP-defined groups 
* can be assigned roles

So user in a group gets that group's attributes, role associations, sub-group's role associations, sub-group's attributes. 

> 
> > To answer your specific question about the specific common set of
> > attributes - if I?m following your question, we reluctantly call this
> >   ?schema? in that it?s a known, predefined set of attribute keys
> > which can have arbitrary values (and that new attribute keys are not
> > normally added by userland code). We have expectation that defining
> > attributes as enforceable ?schema" (including validation for values)
> > is a feature that will be required for orgs and users but our first cut doesn?t
> go that far.
> >
> 
> Yeah, I guess there would be similar but not necessarily common schema.
>   An organization could be a set of companies who are your customers and
> would have different metadata than organizations that are a divisions and
> teams in your own company.
> 
> One question I have for you guys, is what does it mean for a client to belong
> to a Dell organization/tenant?  What if a broker belongs to an organization?
> Are they inheriting a set of mappers or something?
> 

A client in a Dell 'org' is just a client which would receive attributes defined at the org level. The motivation was to support two (or n) cooperating SaaS applications, each with their own tenancy model. For example: App A creates a 'tenant/custoemr' in its own representation, App B creates its own tenant. Dell has a subscription model so a customer gets access to A and B via subscription with id "2057". The identity broker (DIB/KC) establishes an organization for subscription 2057 with trusted set of IdPs and any user who authenticates through the broker in that org gets the subscription id 2057 in his claimset. We sort of expect mapping to be widely variable - some will need lots of mapping between the broker and IdP and others, less. 

> 
> > So I think that while organizations *could* be implemented as a group
> > with special constraints, it would stretch the abstraction a little too far.
> 
> I don't see how an organization implemented as a group would stretch the
> abstraction too far.  They both can have users as members and users would
> inherit their attributes.  Both let their users inherit metadata.
>   Both have arbitrary attribute schemas.
> 
> While groups and organizations might be different concepts to an admin,
> logically they work in the same exact way.  For example, we used to have a
> distinction between Applications and OAuth Clients.  We merged them
> because it was just a lot of duplicate code and caused a lot of additional
> clutter in the UI and the concepts were almost identical.  I don't want to
> create the same situation with Groups and Organizations then have to go
> back and merge the concepts later on.
> 
> The most important thing is to have a UI that covers most use cases and that
> is easy to understand.  This means we need to constantly improve and
> consolidate the UI.  Make things simpler.  Have intuitive default behavior,
> and so on.  The reason Stian and I founded Keycloak was because we were
> so sick of how complex security was.
> 

Agreed on all counts - having an entity to represent a 'group' construct is robust enough to present to users via UI as groups, and then also surface it as an organization construct so it's easy to see how to collect cooperating clients. 

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


From bburke at redhat.com  Mon Aug  3 14:13:31 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 3 Aug 2015 14:13:31 -0400
Subject: [keycloak-dev] groups vs. organizations
In-Reply-To: <F893802C2FB19B459F1A54D865A9C95C35DC080D@ALVMBXW02.prod.quest.corp>
References: <55BAA513.9090009@redhat.com>
	<D1E1070C.17E19%Scott.Rehorn@software.dell.com>
	<55BBE79F.5090703@redhat.com>
	<F893802C2FB19B459F1A54D865A9C95C35DC080D@ALVMBXW02.prod.quest.corp>
Message-ID: <55BFAF4B.2070908@redhat.com>



On 8/3/2015 1:40 PM, Scott Rehorn wrote:
>
>
> Here's a possible summary:
> Groups:
> * have names
> * can contain other groups
> * can carry a 'schema' which represent available attributes (more generally, claims)
> * support mapping and aggregation from IdP-defined groups
> * can be assigned roles
>
> So user in a group gets that group's attributes, role associations, sub-group's role associations, sub-group's attributes.
>

Can you define "support mapping and aggregation from IdP-defined 
groups"?  Wouldn't this be something configured at each IDP rather than 
in a group?  The IDP would define a mapper that looked at some claim, 
then associate the user with a Keycloak defined group based on the 
claim...right?

I was also thinking that we might remove client roles and just move them 
to groups.  Migration would be that a group is created for each client 
that has a set of roles defined.  We have a few users that want to share 
a set of roles between different clients.


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

From giriraj.sharma27 at gmail.com  Tue Aug  4 01:31:51 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Tue, 4 Aug 2015 11:01:51 +0530
Subject: [keycloak-dev] Resolving cyclic dependency issues while
	implementing new SPI's
Message-ID: <CAB5vuUxdHekU6wM0=Nqo=Moujq6rbbjVDgS6nYS2o1FVwMKYXA@mail.gmail.com>

Hi,

IMHO, it will be good if we move the package (org.keycloak.provider) from
keycloak-model-api to some other module which is used as a common
dependency by most other modules (like keycloak-core) .

org.keycloak.provider.*  from keycloak-model-api  is used by most of the
modules which implement certain Spi.
A module (X) having keycloak-model-api (Y) added as a dependency may in
turn be used by classes or other Spi's in keycloak-model-api (Y) and thus
result into a cyclic dependency.

X dependent on Y for org.keycloak.provider.* classes
Y dependent on X for X specific services/SPI's or classes

keycloak-core is used by many modules but in turn keycloak-core doesn't
uses any of keycloak-* dependency and hence will not result into any issues
like cyclic dependency. So, may be moving org.keycloak.provider.* from
keycloak-model-api to some other(like keycloak-core) will be helpful or may
be a better practice.

If this seems fine, I will be happy to make the required changes :)

Cheers,
-- 

Giriraj Sharma
about.me/girirajsharma
<http://about.me/girirajsharma?promo=email_sig>
 Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150804/2da91972/attachment.html 

From gerbermichi at me.com  Tue Aug  4 01:58:05 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 04 Aug 2015 05:58:05 +0000 (GMT)
Subject: [keycloak-dev] Kerberos with IE does not work
Message-ID: <99ebd612-3c27-4094-87db-27213e4064ff@me.com>

Hi Marek,

Your proposed patch works perfectly fine.
IE only overwrites the header for the keycloak REST services, the other?REST?services work fine.?

Thank you for your help.
Michael

Am 03. August 2015 um 13:36 schrieb Marek Posolda <mposolda at redhat.com>:

On 29.7.2015 16:37, Michael Gerber wrote:
The?ClearAuthenticationCache command deletes the following data:
- Session cookies
- sessionStorage
- HTTP Authentication (e.g. Digest or Basic HTTP credentials)
- HTTPS Client Certificates (e.g. sites that use certificates or SmartCards)

But keycloak needs the session cookie, otherwise the user has to relogin after each page reload.

Isn't the clientSecret anyway public if it is send in the Authorization header? 
Yes, it is for JS clients. That's why it's better to not use clientSecret with javascript based clients, but instead mark those clients as "public" in keycloak admin console. In this case keycloak.js will use client_id parameter instead of Authorization header. Can this work for you?

Thing is, that currently AuthorizeClientUtil will likely automatically send 401 if it found "Authorization: Negotiate ..." header even if you have public client and you want to use client_id (I did not test it, but guessing from looking at the code). So I've created the simple patch to avoid it: https://github.com/mposolda/keycloak/commit/858882a306cfc66567dedfcb40454354aa891903

So if you do the steps like:
1) make your client as public
2) Apply my patch

will it help?

I am still seeing potential issues if your javascript client needs to send REST requests authorized by "Authorization: Bearer" header with accessToken. Not sure if IE doesn't again overwrite the header with "Authorization: Negotiate". In this case REST request would fail. But hopefully not... If you have opportunity to try it, it will be cool.

Thanks,
Marek


Am 29. Juli 2015 um 14:27 schrieb Bill Burke <bburke at redhat.com>:

The trick you found earlier doesn't work?

http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header

Also, what if in keycloak.js if kc.clientSecret is null? Just remove 
the client secret IMO. You shouldn't be exposing the client secret as 
it is now public to everybody in the world....

On 7/29/2015 8:05 AM, Michael Gerber wrote:
I could find a solution for my IE problem.

IE overwrites the Authorization header in the XMLHttpRequest
(/protocol/openid-connect/token) with "Authorization: Negotiate".

To solve this problem, I added on the client the client_id
and client_secret to the form and changed the authorizeClient method, so
it checks first the form data instead of the authorization http header.

Have a look at my code:
https://github.com/gerbermichi/keycloak/commit/32880b210ed27f782a2f9fcd01da4df21ee0953c

Should I create a pull request for the changes or do you have a better
solution?

cheers
Michael



Am 22. Juli 2015 um 11:46 schrieb Marek Posolda <mposolda at redhat.com
<mailto:mposolda at redhat.com>>:

Hi Michael,

No idea if there is other solution, I've never tried SPNEGO with
Internet explorer TBH :(

Could you please create JIRA for this?

Thanks,
Marek

On 22.7.2015 10:07, Michael Gerber wrote:
Hi all

My kerberos configuration works fine with FireFox and Chrome, but it
does not work with IE.
It shows a prompt where the user has to enter a username and password.

I can successfully get an access code, but I can not get an access
token, because IE overwrites the Authorization header in the AJAX
request. (see
http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header)

I can fix this by adding
document.execCommand('ClearAuthenticationCache', 'false');
above of
var req = new XMLHttpRequest();
approximately at the line 374 in the keycloack.js file.

Is there another solution for this problem?

cheers
Michael


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



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


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


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

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

From mposolda at redhat.com  Tue Aug  4 03:46:20 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 04 Aug 2015 09:46:20 +0200
Subject: [keycloak-dev] Resolving cyclic dependency issues while
 implementing new SPI's
In-Reply-To: <CAB5vuUxdHekU6wM0=Nqo=Moujq6rbbjVDgS6nYS2o1FVwMKYXA@mail.gmail.com>
References: <CAB5vuUxdHekU6wM0=Nqo=Moujq6rbbjVDgS6nYS2o1FVwMKYXA@mail.gmail.com>
Message-ID: <55C06DCC.1030000@redhat.com>

I agree that moving providers to separate module might be clearer, but 
not sure if it's easily doable. For example 
org.keycloak.provider.ProviderFactory requires KeycloakSession from 
org.keycloak.models package, which requires access to all model classes 
like RealmProvider, UserProvider etc. So moving might require removing 
'dependency' on RealmProvider and UserProvider from KeycloakSession, 
which will be quite big refactoring...

So I am like 50/50 whether to move or not. Until that, I suggest that 
you put your SPI directly to keycloak-model-api . It already contains 
bunch of other basic SPIs like RealmProvider, UserProvider, 
UserFederationProvider etc.

Marek


On 4.8.2015 07:31, Giriraj Sharma wrote:
> Hi,
>
> IMHO, it will be good if we move the package (org.keycloak.provider) 
> from keycloak-model-api to some other module which is used as a common 
> dependency by most other modules (like keycloak-core) .
>
> org.keycloak.provider.*  from keycloak-model-api  is used by most of 
> the modules which implement certain Spi.
> A module (X) having keycloak-model-api (Y) added as a dependency may 
> in turn be used by classes or other Spi's in keycloak-model-api (Y) 
> and thus result into a cyclic dependency.
>
> X dependent on Y for org.keycloak.provider.* classes
> Y dependent on X for X specific services/SPI's or classes
>
> keycloak-core is used by many modules but in turn keycloak-core 
> doesn't uses any of keycloak-* dependency and hence will not result 
> into any issues like cyclic dependency. So, may be moving 
> org.keycloak.provider.* from keycloak-model-api to some other(like 
> keycloak-core) will be helpful or may be a better practice.
>
> If this seems fine, I will be happy to make the required changes :)
>
> Cheers,
> -- 
> Giriraj Sharma
> about.me/girirajsharma
>
> <http://about.me/girirajsharma?promo=email_sig>
>
> Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India 177005
>
>
> _______________________________________________
> 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/20150804/140fcf87/attachment.html 

From giriraj.sharma27 at gmail.com  Tue Aug  4 04:14:10 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Tue, 4 Aug 2015 13:44:10 +0530
Subject: [keycloak-dev] Resolving cyclic dependency issues while
 implementing new SPI's
In-Reply-To: <55C06DCC.1030000@redhat.com>
References: <CAB5vuUxdHekU6wM0=Nqo=Moujq6rbbjVDgS6nYS2o1FVwMKYXA@mail.gmail.com>
	<55C06DCC.1030000@redhat.com>
Message-ID: <CAB5vuUx3cUJQmQkJHbExdBhYG8eSvrLzrsSp6E=R4ZPbEVRQMA@mail.gmail.com>

Agreed,
For now I managed some work around for PKI/Certificate SPI's to resolve
cyclic dependency issues without moving or refactoring org.keycloak.provider.*
from keycloak-model-api. We may consider moving/refactoring in future.

I am having separate modules for PKI/Certificate SPI's just to keep the
modules structured and independent. But, may be for now I can just put
SPI's directly into keycloak-model-api as you have suggested.

Thanks,

On Tue, Aug 4, 2015 at 1:16 PM, Marek Posolda <mposolda at redhat.com> wrote:

> I agree that moving providers to separate module might be clearer, but not
> sure if it's easily doable. For example
> org.keycloak.provider.ProviderFactory requires KeycloakSession from
> org.keycloak.models package, which requires access to all model classes
> like RealmProvider, UserProvider etc. So moving might require removing
> 'dependency' on RealmProvider and UserProvider from KeycloakSession, which
> will be quite big refactoring...
>
> So I am like 50/50 whether to move or not. Until that, I suggest that you
> put your SPI directly to keycloak-model-api . It already contains bunch of
> other basic SPIs like RealmProvider, UserProvider, UserFederationProvider
> etc.
>
> Marek
>
>
>
> On 4.8.2015 07:31, Giriraj Sharma wrote:
>
> Hi,
>
> IMHO, it will be good if we move the package (org.keycloak.provider) from
> keycloak-model-api to some other module which is used as a common
> dependency by most other modules (like keycloak-core) .
>
> org.keycloak.provider.*  from keycloak-model-api  is used by most of the
> modules which implement certain Spi.
> A module (X) having keycloak-model-api (Y) added as a dependency may in
> turn be used by classes or other Spi's in keycloak-model-api (Y) and thus
> result into a cyclic dependency.
>
> X dependent on Y for org.keycloak.provider.* classes
> Y dependent on X for X specific services/SPI's or classes
>
> keycloak-core is used by many modules but in turn keycloak-core doesn't
> uses any of keycloak-* dependency and hence will not result into any issues
> like cyclic dependency. So, may be moving org.keycloak.provider.* from
> keycloak-model-api to some other(like keycloak-core) will be helpful or may
> be a better practice.
>
> If this seems fine, I will be happy to make the required changes :)
>
> Cheers,
> --
>
> Giriraj Sharma
> about.me/girirajsharma
> <http://about.me/girirajsharma?promo=email_sig>
>   Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India 177005
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>


-- 

Giriraj Sharma
about.me/girirajsharma
<http://about.me/girirajsharma?promo=email_sig>
 Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150804/56a1a811/attachment-0001.html 

From bdawidow at redhat.com  Tue Aug  4 06:57:39 2015
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Tue, 4 Aug 2015 12:57:39 +0200
Subject: [keycloak-dev] Hawkular requirements (was Re: RFC:
	organizations)
In-Reply-To: <353433249.177920.1438153509233.JavaMail.zimbra@redhat.com>
References: <CAHfqrKvMTWDbkFkAkh-+jsS2w9PrQx-OfH8_K9uvNqqVgeJxWQ@mail.gmail.com>
	<96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com>
	<55B73ACD.4080708@redhat.com>
	<2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com>
	<55B746B0.7060604@redhat.com>
	<191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com>
	<55B78A55.4040204@redhat.com> <55B7A8E5.2050308@redhat.com>
	<353433249.177920.1438153509233.JavaMail.zimbra@redhat.com>
Message-ID: <CABbwURGgrSDfriwAJ1+xMU1=nuOcNGNRnyiaV366yLFvjwyeoA@mail.gmail.com>

+1. The more I think about it I lean towards having something
separate. Another component/server to handle more reach robust
authorisation needs while being tightly integrated with authentication
server.

It is a pandora box and when you start collecting requirements you
quickly reach permissions, inheritance or dynamic rule based
resolution. Would have high impact on usability and simplicity.

On Wed, Jul 29, 2015 at 9:05 AM, Stian Thorgersen <stian at redhat.com> wrote:
> Agree, Keycloak (as an authentication server) should be limited to providing roles (and other claims/attributes, maybe we can groups and even roles within groups).
>
> We could look at adding something more of an authorization server (UMA) where a resource provider uses the users token to contact the authorization server to check if a user has a specific permission on a specific resources. It's an interesting challenge and maybe something we can look at in the future, but I think it's going to be mid-end 2016 at least.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 28 July, 2015 6:08:05 PM
>> Subject: Re: [keycloak-dev] Hawkular requirements (was Re: RFC:       organizations)
>>
>> I think it is appropriate to model resource access separately, outside
>> of Keycloak.  The reason for this is basically how SAML/OIDC and single
>> sign in works.  It should be:
>>
>> 1. User visits Hawkular
>> 2. User is redirected to Keycloak to login
>> 3. User logins in
>> 4. User is redirected back to Hawkular with a set of assertions
>>
>> If you were using Keycloak to model resource access, then Hawkular would
>> have to continuously hit Keycloak in the background to
>>
>> * create/destroy/modify resource definitions
>> * enable/disable permissions of the user for each resource
>> * verify permissions of the user for each resource
>>
>> I just don't think an authentication server should be used to manage
>> application data.  Would you require that a company's LDAP store start
>> storing Hawkular specific metadata to manage all these resources?  No.
>> You would not.  Which is why I think Keycloak should only be storing
>> things like does this user belong to this group or organization.  That's
>> it.  Keycloak should not be managing access to the resources of a
>> specific application.
>>
>> On 7/28/2015 9:57 AM, Juraci Paix?o Kr?hling wrote:
>> > Sure. Please, keep in mind that we have two possible deployment
>> > scenarios: SaaS and Hosted.
>> >
>> > For SaaS (and some specific customers on Hosted), we need to have multi
>> > tenancy, so, data from one "organization" should be isolated from
>> > another. At the same time, we need users from one organization to
>> > possibly have access to data from other organizations.
>> >
>> > Note that we use the same role names and semantics as Wildfly:
>> > https://docs.jboss.org/author/display/WFLY9/RBAC
>> >
>> > Case #1, simplest possible scenario:
>> > - a new user registers on Hawkular SaaS and wants to monitor a website.
>> > No one else should have access to the metrics collected for this user.
>> >
>> > Case #2, most complex scenario:
>> > - Acme, Inc has several departments: Marketing, Sales and so on. Each
>> > one has a small operations team, which is responsible for their
>> > day-to-day activities (creating a database, adding an application
>> > server, deploying an application, increasing memory, ...).
>> > - A member of the Marketing department should not be able to view/manage
>> > resources from, say, Sales.
>> > - Acme, Inc has a NOC, which is responsible for the 24x7 monitoring.
>> > They should have read-only access to metrics from all machines of Acme,
>> > Inc, no matter which department.
>> >
>> >
>> > We are currently solving this by having "Hawkular Accounts" to sit
>> > between Keycloak and the Hawkular modules (Alerts, Metrics, Inventory,
>> > ...) and providing a "Current Persona". This "persona" is a
>> > representation of the tenant + the rights that the user has for this
>> > tenant. So, the Persona might be an User acting as Monitor on an
>> > Organization, or might be an User acting on its own Resources as
>> > SuperUser. Permission checking is performed on the business side by the
>> > modules, by calling an API which is similar to PicketLink's Permission API.
>> >
>> > So, we have the following concepts on Hawkular Accounts:
>> >
>> > - Organization
>> >     - "Acme, Inc"
>> >
>> > - Roles
>> >     - SuperUser
>> >     - Monitor
>> >     - Auditor
>> >     - ...
>> >
>> > - User
>> >     - "jmuller"
>> >
>> > - Persona
>> >     - "jmuller"
>> >     - "jmuller" acting as "SuperUser" of "Acme, Inc"
>> >
>> > - Resource
>> >     - "virtual-machine-1"
>> >     - "travel-request-webapp"
>> >
>> > - Operation
>> >     - "add-memory"
>> >     - "monitor-cpu"
>> >     - "deploy-war"
>> >     - "read-datasources"
>> >
>> > - Permission
>> >     - "SuperUser" can "add-memory" to "virtual-machine-1"
>> >
>> > - Organization membership
>> >     - "jmuller" is "SuperUser" on "Acme, Inc"
>> >     - "Acme, Inc" is "SuperUser" on "Acme Sales"
>> >     - "Acme NOC" is "Monitor" on "Acme, Inc"
>> >
>> >
>> > On the simplest case (case 1):
>> > - User is Persona. So, when the user registers and adds the website to
>> > be monitored, the website is owned by the user (ie: SuperUser of
>> > Resource is User).
>> >
>> > On the complex case (case 2):
>> > - User jmuller registers and creates the organization "Acme, Inc" and
>> > is, therefore, the SuperUser of it.
>> > - User jmuller switches the context to "Acme, Inc" on the UI
>> > - Acme Sales is created as an Organization inside Acme, Inc (Acme, Inc
>> > owns it)
>> > - Acme Marketing is created as an Organization inside Acme, Inc (ditto)
>> > - Acme NOC is created as an Organization inside Acme, Inc (ditto)
>> > - User jmuller invites jdoe to be SuperUser of Acme Sales
>> > - User jdoe switches the context to "Acme Sales" on the UI
>> > - Acme Sales (via jdoe) creates the host "acme-sales-prod-1" and is the
>> > SuperUser of it.
>> > - As jdoe is a SuperUser member of Acme Sales, jdoe is therefore
>> > SuperUser of "acme-sales-prod-1"
>> > - User jmuller invites jsmith to be SuperUser of Acme NOC
>> > - Organization Acme NOC is granted Monitor on Acme, Inc
>> > - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme,
>> > Inc, then jsmith is also only Monitor on Acme Sales.
>> > - User jmuller is SuperUser on "Acme, Inc", so, is also a SuperUser of
>> > "Acme Sales", "Acme Marketing", "Acme NOC".
>> > - User jim creates "Red Hat, Inc", which has no access to Acme, Inc data.
>> >
>> > When the user jsmith (SuperUser of NOC) selects "Acme Sales" on the
>> > Hawkular Accounts switcher, an HTTP header is sent with the request,
>> > with the ID of the "Acme Sales" as the Persona-ID. When an operation
>> > needs to be done in a resource that is owned by Acme Sales, the relevant
>> > Hawkular module asks Hawkular Accounts whether the current persona can
>> > perform the Operation on the Resource. On this case, jsmith is only
>> > Monitor on Acme Sales, so, if it's a read only operation, the permission
>> > is granted.
>> >
>> > I realize that there are terms which are specific to Hawkular, but I
>> > tried to make it as clear as possible for those who have no knowledge of
>> > those terms. In case something is not clear, let me know.
>> >
>> > - Juca.
>> >
>> >
>> > On 07/28/2015 02:19 PM, Stian Thorgersen wrote:
>> >> I think we've successfully managed to abstract ourselves completely away
>> >> from your real requirements ;)
>> >>
>> >> Can you start another thread listing your exact requirements? Then we can
>> >> see if it's possible to model it with existing roles, client roles and
>> >> composite roles.
>> >>
>> >> ----- Original Message -----
>> >>> From: "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
>> >>> To: "Stian Thorgersen" <stian at redhat.com>
>> >>> Cc: keycloak-dev at lists.jboss.org
>> >>> Sent: Tuesday, 28 July, 2015 11:09:04 AM
>> >>> Subject: Re: [keycloak-dev] RFC: organizations
>> >>>
>> >>> On 07/28/2015 10:31 AM, Stian Thorgersen wrote:
>> >>>> I'll add a bit to this example:
>> >>>>
>> >>>> Within a realm there's 4 services (bearer-only clients):
>> >>>>
>> >>>> * Acme Email Service
>> >>>> * Acme Monitor Service
>> >>>> * Red Hat Email Service
>> >>>> * Red Hat Monitor Service
>> >>>
>> >>> Is there a way to have a relationship between Acme Email Service and
>> >>> Acme Monitor Service? Are they different clients? We'd need a stable ID
>> >>> between related services, which would be our "tenant". So, if user jdoe
>> >>> creates a resource in our application while acting as SuperUser for
>> >>> Acme, we have to store this resource with the information that it
>> >>> belongs to Acme, so that users of Red Hat wouldn't have access to it.
>> >>>
>> >>>> Each client has one or more roles. For example Acme Email and Red Hat
>> >>>> email
>> >>>> both have view-email, read-email and send-email.
>> >>>>
>> >>>> To model the above super users you'd add two composite realm roles:
>> >>>>
>> >>>> * acme-super - add mapping on all roles for Acme Email and Acme Monitor
>> >>>> * redhat-super - add mapping on all roles for Red Hat Email and Red Hat
>> >>>> Monitor
>> >>>
>> >>> Meaning that for each new "organization", a new set of roles would have
>> >>> to be duplicated. Basically, acme-super and redhat-super are exactly the
>> >>> same, except for the names.
>> >>>
>> >>> But if I get it right, this is how it would look like:
>> >>>
>> >>> - user jdoe registers, is "super" on the realm itself
>> >>> - user jdoe creates Acme, and is acme-super there, effectively being
>> >>> super on the client
>> >>> - user jsmith creates Red Hat, invites jdoe as "monitor" there
>> >>> - user jdoe is now super on the realm, acme-super on the Acme client and
>> >>> redhat-monitor on the Red Hat client.
>> >>>
>> >>> So, if a request comes in to our backend for jdoe while using the UI as
>> >>> Red Hat, our backend would see only "redhat-monitor" as the role, right?
>> >>>
>> >>>> A user can now have a role mapping on acme-super to get all roles for
>> >>>> Acme
>> >>>> clients, or you can add role mappings to individual roles within each
>> >>>> client.
>> >>>
>> >>> This means that I would be able to be Super User on Acme, but only
>> >>> Monitor on Red Hat, right?
>> >>>
>> >>>> That's what you want isn't it?
>> >>>
>> >>> I think it could work, yes, but that doesn't feel right, to be honest.
>> >>> It seems like we'd be doing some workarounds to implement a concept that
>> >>> doesn't quite exist on Keycloak, which would cause a massive data
>> >>> duplication. For one realm containing two clients and 8 roles each, this
>> >>> seems doable, but for one realm containing 2.000 clients (nested or not)
>> >>> and 8 roles each, that *sounds* like a maintenance/migration/performance
>> >>> nightmare.
>> >>>
>> >>>> Further you can also utilize scope on applications (confidential for
>> >>>> server-side web app, or public for client-side web apps) to limit the
>> >>>> roles a application can obtain. For example the HTML5 application 'Acme
>> >>>> Email Reader' could either have a scope on all roles within 'Acme Email
>> >>>> Service' or 'acme-super'. It should probably not have scope on any roles
>> >>>> for 'Red Hat Email'.
>> >>>
>> >>> Sounds like a bonus feature, but I don't think this would bring any
>> >>> benefit for us. We have only one frontend and one backend (with several
>> >>> modules). So, the same application available to Acme is available to Red
>> >>> Hat.
>> >>>
>> >>> - Juca.
>> >>>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
--
Boles?aw Dawidowicz


From bburke at redhat.com  Tue Aug  4 08:59:46 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 4 Aug 2015 08:59:46 -0400
Subject: [keycloak-dev] Hawkular requirements (was Re: RFC:
	organizations)
In-Reply-To: <CABbwURGgrSDfriwAJ1+xMU1=nuOcNGNRnyiaV366yLFvjwyeoA@mail.gmail.com>
References: <CAHfqrKvMTWDbkFkAkh-+jsS2w9PrQx-OfH8_K9uvNqqVgeJxWQ@mail.gmail.com>
	<96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com>
	<55B73ACD.4080708@redhat.com>
	<2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com>
	<55B746B0.7060604@redhat.com>
	<191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com>
	<55B78A55.4040204@redhat.com> <55B7A8E5.2050308@redhat.com>
	<353433249.177920.1438153509233.JavaMail.zimbra@redhat.com>
	<CABbwURGgrSDfriwAJ1+xMU1=nuOcNGNRnyiaV366yLFvjwyeoA@mail.gmail.com>
Message-ID: <55C0B742.7030807@redhat.com>

We still want to have some concept of groups.  I think I'm coming to 
some sort of design for them which I'll post soon.

On 8/4/2015 6:57 AM, Boleslaw Dawidowicz wrote:
> +1. The more I think about it I lean towards having something
> separate. Another component/server to handle more reach robust
> authorisation needs while being tightly integrated with authentication
> server.
>
> It is a pandora box and when you start collecting requirements you
> quickly reach permissions, inheritance or dynamic rule based
> resolution. Would have high impact on usability and simplicity.
>
> On Wed, Jul 29, 2015 at 9:05 AM, Stian Thorgersen <stian at redhat.com> wrote:
>> Agree, Keycloak (as an authentication server) should be limited to providing roles (and other claims/attributes, maybe we can groups and even roles within groups).
>>
>> We could look at adding something more of an authorization server (UMA) where a resource provider uses the users token to contact the authorization server to check if a user has a specific permission on a specific resources. It's an interesting challenge and maybe something we can look at in the future, but I think it's going to be mid-end 2016 at least.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 28 July, 2015 6:08:05 PM
>>> Subject: Re: [keycloak-dev] Hawkular requirements (was Re: RFC:       organizations)
>>>
>>> I think it is appropriate to model resource access separately, outside
>>> of Keycloak.  The reason for this is basically how SAML/OIDC and single
>>> sign in works.  It should be:
>>>
>>> 1. User visits Hawkular
>>> 2. User is redirected to Keycloak to login
>>> 3. User logins in
>>> 4. User is redirected back to Hawkular with a set of assertions
>>>
>>> If you were using Keycloak to model resource access, then Hawkular would
>>> have to continuously hit Keycloak in the background to
>>>
>>> * create/destroy/modify resource definitions
>>> * enable/disable permissions of the user for each resource
>>> * verify permissions of the user for each resource
>>>
>>> I just don't think an authentication server should be used to manage
>>> application data.  Would you require that a company's LDAP store start
>>> storing Hawkular specific metadata to manage all these resources?  No.
>>> You would not.  Which is why I think Keycloak should only be storing
>>> things like does this user belong to this group or organization.  That's
>>> it.  Keycloak should not be managing access to the resources of a
>>> specific application.
>>>
>>> On 7/28/2015 9:57 AM, Juraci Paix?o Kr?hling wrote:
>>>> Sure. Please, keep in mind that we have two possible deployment
>>>> scenarios: SaaS and Hosted.
>>>>
>>>> For SaaS (and some specific customers on Hosted), we need to have multi
>>>> tenancy, so, data from one "organization" should be isolated from
>>>> another. At the same time, we need users from one organization to
>>>> possibly have access to data from other organizations.
>>>>
>>>> Note that we use the same role names and semantics as Wildfly:
>>>> https://docs.jboss.org/author/display/WFLY9/RBAC
>>>>
>>>> Case #1, simplest possible scenario:
>>>> - a new user registers on Hawkular SaaS and wants to monitor a website.
>>>> No one else should have access to the metrics collected for this user.
>>>>
>>>> Case #2, most complex scenario:
>>>> - Acme, Inc has several departments: Marketing, Sales and so on. Each
>>>> one has a small operations team, which is responsible for their
>>>> day-to-day activities (creating a database, adding an application
>>>> server, deploying an application, increasing memory, ...).
>>>> - A member of the Marketing department should not be able to view/manage
>>>> resources from, say, Sales.
>>>> - Acme, Inc has a NOC, which is responsible for the 24x7 monitoring.
>>>> They should have read-only access to metrics from all machines of Acme,
>>>> Inc, no matter which department.
>>>>
>>>>
>>>> We are currently solving this by having "Hawkular Accounts" to sit
>>>> between Keycloak and the Hawkular modules (Alerts, Metrics, Inventory,
>>>> ...) and providing a "Current Persona". This "persona" is a
>>>> representation of the tenant + the rights that the user has for this
>>>> tenant. So, the Persona might be an User acting as Monitor on an
>>>> Organization, or might be an User acting on its own Resources as
>>>> SuperUser. Permission checking is performed on the business side by the
>>>> modules, by calling an API which is similar to PicketLink's Permission API.
>>>>
>>>> So, we have the following concepts on Hawkular Accounts:
>>>>
>>>> - Organization
>>>>      - "Acme, Inc"
>>>>
>>>> - Roles
>>>>      - SuperUser
>>>>      - Monitor
>>>>      - Auditor
>>>>      - ...
>>>>
>>>> - User
>>>>      - "jmuller"
>>>>
>>>> - Persona
>>>>      - "jmuller"
>>>>      - "jmuller" acting as "SuperUser" of "Acme, Inc"
>>>>
>>>> - Resource
>>>>      - "virtual-machine-1"
>>>>      - "travel-request-webapp"
>>>>
>>>> - Operation
>>>>      - "add-memory"
>>>>      - "monitor-cpu"
>>>>      - "deploy-war"
>>>>      - "read-datasources"
>>>>
>>>> - Permission
>>>>      - "SuperUser" can "add-memory" to "virtual-machine-1"
>>>>
>>>> - Organization membership
>>>>      - "jmuller" is "SuperUser" on "Acme, Inc"
>>>>      - "Acme, Inc" is "SuperUser" on "Acme Sales"
>>>>      - "Acme NOC" is "Monitor" on "Acme, Inc"
>>>>
>>>>
>>>> On the simplest case (case 1):
>>>> - User is Persona. So, when the user registers and adds the website to
>>>> be monitored, the website is owned by the user (ie: SuperUser of
>>>> Resource is User).
>>>>
>>>> On the complex case (case 2):
>>>> - User jmuller registers and creates the organization "Acme, Inc" and
>>>> is, therefore, the SuperUser of it.
>>>> - User jmuller switches the context to "Acme, Inc" on the UI
>>>> - Acme Sales is created as an Organization inside Acme, Inc (Acme, Inc
>>>> owns it)
>>>> - Acme Marketing is created as an Organization inside Acme, Inc (ditto)
>>>> - Acme NOC is created as an Organization inside Acme, Inc (ditto)
>>>> - User jmuller invites jdoe to be SuperUser of Acme Sales
>>>> - User jdoe switches the context to "Acme Sales" on the UI
>>>> - Acme Sales (via jdoe) creates the host "acme-sales-prod-1" and is the
>>>> SuperUser of it.
>>>> - As jdoe is a SuperUser member of Acme Sales, jdoe is therefore
>>>> SuperUser of "acme-sales-prod-1"
>>>> - User jmuller invites jsmith to be SuperUser of Acme NOC
>>>> - Organization Acme NOC is granted Monitor on Acme, Inc
>>>> - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme,
>>>> Inc, then jsmith is also only Monitor on Acme Sales.
>>>> - User jmuller is SuperUser on "Acme, Inc", so, is also a SuperUser of
>>>> "Acme Sales", "Acme Marketing", "Acme NOC".
>>>> - User jim creates "Red Hat, Inc", which has no access to Acme, Inc data.
>>>>
>>>> When the user jsmith (SuperUser of NOC) selects "Acme Sales" on the
>>>> Hawkular Accounts switcher, an HTTP header is sent with the request,
>>>> with the ID of the "Acme Sales" as the Persona-ID. When an operation
>>>> needs to be done in a resource that is owned by Acme Sales, the relevant
>>>> Hawkular module asks Hawkular Accounts whether the current persona can
>>>> perform the Operation on the Resource. On this case, jsmith is only
>>>> Monitor on Acme Sales, so, if it's a read only operation, the permission
>>>> is granted.
>>>>
>>>> I realize that there are terms which are specific to Hawkular, but I
>>>> tried to make it as clear as possible for those who have no knowledge of
>>>> those terms. In case something is not clear, let me know.
>>>>
>>>> - Juca.
>>>>
>>>>
>>>> On 07/28/2015 02:19 PM, Stian Thorgersen wrote:
>>>>> I think we've successfully managed to abstract ourselves completely away
>>>>> from your real requirements ;)
>>>>>
>>>>> Can you start another thread listing your exact requirements? Then we can
>>>>> see if it's possible to model it with existing roles, client roles and
>>>>> composite roles.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Tuesday, 28 July, 2015 11:09:04 AM
>>>>>> Subject: Re: [keycloak-dev] RFC: organizations
>>>>>>
>>>>>> On 07/28/2015 10:31 AM, Stian Thorgersen wrote:
>>>>>>> I'll add a bit to this example:
>>>>>>>
>>>>>>> Within a realm there's 4 services (bearer-only clients):
>>>>>>>
>>>>>>> * Acme Email Service
>>>>>>> * Acme Monitor Service
>>>>>>> * Red Hat Email Service
>>>>>>> * Red Hat Monitor Service
>>>>>>
>>>>>> Is there a way to have a relationship between Acme Email Service and
>>>>>> Acme Monitor Service? Are they different clients? We'd need a stable ID
>>>>>> between related services, which would be our "tenant". So, if user jdoe
>>>>>> creates a resource in our application while acting as SuperUser for
>>>>>> Acme, we have to store this resource with the information that it
>>>>>> belongs to Acme, so that users of Red Hat wouldn't have access to it.
>>>>>>
>>>>>>> Each client has one or more roles. For example Acme Email and Red Hat
>>>>>>> email
>>>>>>> both have view-email, read-email and send-email.
>>>>>>>
>>>>>>> To model the above super users you'd add two composite realm roles:
>>>>>>>
>>>>>>> * acme-super - add mapping on all roles for Acme Email and Acme Monitor
>>>>>>> * redhat-super - add mapping on all roles for Red Hat Email and Red Hat
>>>>>>> Monitor
>>>>>>
>>>>>> Meaning that for each new "organization", a new set of roles would have
>>>>>> to be duplicated. Basically, acme-super and redhat-super are exactly the
>>>>>> same, except for the names.
>>>>>>
>>>>>> But if I get it right, this is how it would look like:
>>>>>>
>>>>>> - user jdoe registers, is "super" on the realm itself
>>>>>> - user jdoe creates Acme, and is acme-super there, effectively being
>>>>>> super on the client
>>>>>> - user jsmith creates Red Hat, invites jdoe as "monitor" there
>>>>>> - user jdoe is now super on the realm, acme-super on the Acme client and
>>>>>> redhat-monitor on the Red Hat client.
>>>>>>
>>>>>> So, if a request comes in to our backend for jdoe while using the UI as
>>>>>> Red Hat, our backend would see only "redhat-monitor" as the role, right?
>>>>>>
>>>>>>> A user can now have a role mapping on acme-super to get all roles for
>>>>>>> Acme
>>>>>>> clients, or you can add role mappings to individual roles within each
>>>>>>> client.
>>>>>>
>>>>>> This means that I would be able to be Super User on Acme, but only
>>>>>> Monitor on Red Hat, right?
>>>>>>
>>>>>>> That's what you want isn't it?
>>>>>>
>>>>>> I think it could work, yes, but that doesn't feel right, to be honest.
>>>>>> It seems like we'd be doing some workarounds to implement a concept that
>>>>>> doesn't quite exist on Keycloak, which would cause a massive data
>>>>>> duplication. For one realm containing two clients and 8 roles each, this
>>>>>> seems doable, but for one realm containing 2.000 clients (nested or not)
>>>>>> and 8 roles each, that *sounds* like a maintenance/migration/performance
>>>>>> nightmare.
>>>>>>
>>>>>>> Further you can also utilize scope on applications (confidential for
>>>>>>> server-side web app, or public for client-side web apps) to limit the
>>>>>>> roles a application can obtain. For example the HTML5 application 'Acme
>>>>>>> Email Reader' could either have a scope on all roles within 'Acme Email
>>>>>>> Service' or 'acme-super'. It should probably not have scope on any roles
>>>>>>> for 'Red Hat Email'.
>>>>>>
>>>>>> Sounds like a bonus feature, but I don't think this would bring any
>>>>>> benefit for us. We have only one frontend and one backend (with several
>>>>>> modules). So, the same application available to Acme is available to Red
>>>>>> Hat.
>>>>>>
>>>>>> - Juca.
>>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

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

From satyajit.das at spire2grow.com  Tue Aug  4 09:48:24 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Tue, 4 Aug 2015 19:18:24 +0530
Subject: [keycloak-dev] Queries on Keycloak
Message-ID: <006901d0cebc$3d41f290$b7c5d7b0$@spire2grow.com>

Hi Team,

 

Kindly respond to the below queries.

 

1)What is the limit to the number of realms, roles per realm, and users per
realm or users per role in key cloak.

 

2)what is the expire time of a token id generated in key cloak.(
session.getTokenString()).

 

3) is there any authentication done after successfull login ,if I visit
subsequent pages.

 

 

 

 

Regards,

Satya.

 

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

From bdawidow at redhat.com  Tue Aug  4 09:49:42 2015
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Tue, 4 Aug 2015 15:49:42 +0200
Subject: [keycloak-dev] Hawkular requirements (was Re: RFC:
	organizations)
In-Reply-To: <55C0B742.7030807@redhat.com>
References: <CAHfqrKvMTWDbkFkAkh-+jsS2w9PrQx-OfH8_K9uvNqqVgeJxWQ@mail.gmail.com>
	<96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com>
	<55B73ACD.4080708@redhat.com>
	<2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com>
	<55B746B0.7060604@redhat.com>
	<191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com>
	<55B78A55.4040204@redhat.com> <55B7A8E5.2050308@redhat.com>
	<353433249.177920.1438153509233.JavaMail.zimbra@redhat.com>
	<CABbwURGgrSDfriwAJ1+xMU1=nuOcNGNRnyiaV366yLFvjwyeoA@mail.gmail.com>
	<55C0B742.7030807@redhat.com>
Message-ID: <CABbwURFhFvjPjwr9BHZUKGtz39zhfsP3eHkNgayots=QXOe2+g@mail.gmail.com>

Yes I agree we need them in KC. Was referring to more complex authz
scenarios and reqs.

On Tue, Aug 4, 2015 at 2:59 PM, Bill Burke <bburke at redhat.com> wrote:
> We still want to have some concept of groups.  I think I'm coming to some
> sort of design for them which I'll post soon.
>
>
> On 8/4/2015 6:57 AM, Boleslaw Dawidowicz wrote:
>>
>> +1. The more I think about it I lean towards having something
>> separate. Another component/server to handle more reach robust
>> authorisation needs while being tightly integrated with authentication
>> server.
>>
>> It is a pandora box and when you start collecting requirements you
>> quickly reach permissions, inheritance or dynamic rule based
>> resolution. Would have high impact on usability and simplicity.
>>
>> On Wed, Jul 29, 2015 at 9:05 AM, Stian Thorgersen <stian at redhat.com>
>> wrote:
>>>
>>> Agree, Keycloak (as an authentication server) should be limited to
>>> providing roles (and other claims/attributes, maybe we can groups and even
>>> roles within groups).
>>>
>>> We could look at adding something more of an authorization server (UMA)
>>> where a resource provider uses the users token to contact the authorization
>>> server to check if a user has a specific permission on a specific resources.
>>> It's an interesting challenge and maybe something we can look at in the
>>> future, but I think it's going to be mid-end 2016 at least.
>>>
>>> ----- Original Message -----
>>>>
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 28 July, 2015 6:08:05 PM
>>>> Subject: Re: [keycloak-dev] Hawkular requirements (was Re: RFC:
>>>> organizations)
>>>>
>>>> I think it is appropriate to model resource access separately, outside
>>>> of Keycloak.  The reason for this is basically how SAML/OIDC and single
>>>> sign in works.  It should be:
>>>>
>>>> 1. User visits Hawkular
>>>> 2. User is redirected to Keycloak to login
>>>> 3. User logins in
>>>> 4. User is redirected back to Hawkular with a set of assertions
>>>>
>>>> If you were using Keycloak to model resource access, then Hawkular would
>>>> have to continuously hit Keycloak in the background to
>>>>
>>>> * create/destroy/modify resource definitions
>>>> * enable/disable permissions of the user for each resource
>>>> * verify permissions of the user for each resource
>>>>
>>>> I just don't think an authentication server should be used to manage
>>>> application data.  Would you require that a company's LDAP store start
>>>> storing Hawkular specific metadata to manage all these resources?  No.
>>>> You would not.  Which is why I think Keycloak should only be storing
>>>> things like does this user belong to this group or organization.  That's
>>>> it.  Keycloak should not be managing access to the resources of a
>>>> specific application.
>>>>
>>>> On 7/28/2015 9:57 AM, Juraci Paix?o Kr?hling wrote:
>>>>>
>>>>> Sure. Please, keep in mind that we have two possible deployment
>>>>> scenarios: SaaS and Hosted.
>>>>>
>>>>> For SaaS (and some specific customers on Hosted), we need to have multi
>>>>> tenancy, so, data from one "organization" should be isolated from
>>>>> another. At the same time, we need users from one organization to
>>>>> possibly have access to data from other organizations.
>>>>>
>>>>> Note that we use the same role names and semantics as Wildfly:
>>>>> https://docs.jboss.org/author/display/WFLY9/RBAC
>>>>>
>>>>> Case #1, simplest possible scenario:
>>>>> - a new user registers on Hawkular SaaS and wants to monitor a website.
>>>>> No one else should have access to the metrics collected for this user.
>>>>>
>>>>> Case #2, most complex scenario:
>>>>> - Acme, Inc has several departments: Marketing, Sales and so on. Each
>>>>> one has a small operations team, which is responsible for their
>>>>> day-to-day activities (creating a database, adding an application
>>>>> server, deploying an application, increasing memory, ...).
>>>>> - A member of the Marketing department should not be able to
>>>>> view/manage
>>>>> resources from, say, Sales.
>>>>> - Acme, Inc has a NOC, which is responsible for the 24x7 monitoring.
>>>>> They should have read-only access to metrics from all machines of Acme,
>>>>> Inc, no matter which department.
>>>>>
>>>>>
>>>>> We are currently solving this by having "Hawkular Accounts" to sit
>>>>> between Keycloak and the Hawkular modules (Alerts, Metrics, Inventory,
>>>>> ...) and providing a "Current Persona". This "persona" is a
>>>>> representation of the tenant + the rights that the user has for this
>>>>> tenant. So, the Persona might be an User acting as Monitor on an
>>>>> Organization, or might be an User acting on its own Resources as
>>>>> SuperUser. Permission checking is performed on the business side by the
>>>>> modules, by calling an API which is similar to PicketLink's Permission
>>>>> API.
>>>>>
>>>>> So, we have the following concepts on Hawkular Accounts:
>>>>>
>>>>> - Organization
>>>>>      - "Acme, Inc"
>>>>>
>>>>> - Roles
>>>>>      - SuperUser
>>>>>      - Monitor
>>>>>      - Auditor
>>>>>      - ...
>>>>>
>>>>> - User
>>>>>      - "jmuller"
>>>>>
>>>>> - Persona
>>>>>      - "jmuller"
>>>>>      - "jmuller" acting as "SuperUser" of "Acme, Inc"
>>>>>
>>>>> - Resource
>>>>>      - "virtual-machine-1"
>>>>>      - "travel-request-webapp"
>>>>>
>>>>> - Operation
>>>>>      - "add-memory"
>>>>>      - "monitor-cpu"
>>>>>      - "deploy-war"
>>>>>      - "read-datasources"
>>>>>
>>>>> - Permission
>>>>>      - "SuperUser" can "add-memory" to "virtual-machine-1"
>>>>>
>>>>> - Organization membership
>>>>>      - "jmuller" is "SuperUser" on "Acme, Inc"
>>>>>      - "Acme, Inc" is "SuperUser" on "Acme Sales"
>>>>>      - "Acme NOC" is "Monitor" on "Acme, Inc"
>>>>>
>>>>>
>>>>> On the simplest case (case 1):
>>>>> - User is Persona. So, when the user registers and adds the website to
>>>>> be monitored, the website is owned by the user (ie: SuperUser of
>>>>> Resource is User).
>>>>>
>>>>> On the complex case (case 2):
>>>>> - User jmuller registers and creates the organization "Acme, Inc" and
>>>>> is, therefore, the SuperUser of it.
>>>>> - User jmuller switches the context to "Acme, Inc" on the UI
>>>>> - Acme Sales is created as an Organization inside Acme, Inc (Acme, Inc
>>>>> owns it)
>>>>> - Acme Marketing is created as an Organization inside Acme, Inc (ditto)
>>>>> - Acme NOC is created as an Organization inside Acme, Inc (ditto)
>>>>> - User jmuller invites jdoe to be SuperUser of Acme Sales
>>>>> - User jdoe switches the context to "Acme Sales" on the UI
>>>>> - Acme Sales (via jdoe) creates the host "acme-sales-prod-1" and is the
>>>>> SuperUser of it.
>>>>> - As jdoe is a SuperUser member of Acme Sales, jdoe is therefore
>>>>> SuperUser of "acme-sales-prod-1"
>>>>> - User jmuller invites jsmith to be SuperUser of Acme NOC
>>>>> - Organization Acme NOC is granted Monitor on Acme, Inc
>>>>> - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme,
>>>>> Inc, then jsmith is also only Monitor on Acme Sales.
>>>>> - User jmuller is SuperUser on "Acme, Inc", so, is also a SuperUser of
>>>>> "Acme Sales", "Acme Marketing", "Acme NOC".
>>>>> - User jim creates "Red Hat, Inc", which has no access to Acme, Inc
>>>>> data.
>>>>>
>>>>> When the user jsmith (SuperUser of NOC) selects "Acme Sales" on the
>>>>> Hawkular Accounts switcher, an HTTP header is sent with the request,
>>>>> with the ID of the "Acme Sales" as the Persona-ID. When an operation
>>>>> needs to be done in a resource that is owned by Acme Sales, the
>>>>> relevant
>>>>> Hawkular module asks Hawkular Accounts whether the current persona can
>>>>> perform the Operation on the Resource. On this case, jsmith is only
>>>>> Monitor on Acme Sales, so, if it's a read only operation, the
>>>>> permission
>>>>> is granted.
>>>>>
>>>>> I realize that there are terms which are specific to Hawkular, but I
>>>>> tried to make it as clear as possible for those who have no knowledge
>>>>> of
>>>>> those terms. In case something is not clear, let me know.
>>>>>
>>>>> - Juca.
>>>>>
>>>>>
>>>>> On 07/28/2015 02:19 PM, Stian Thorgersen wrote:
>>>>>>
>>>>>> I think we've successfully managed to abstract ourselves completely
>>>>>> away
>>>>>> from your real requirements ;)
>>>>>>
>>>>>> Can you start another thread listing your exact requirements? Then we
>>>>>> can
>>>>>> see if it's possible to model it with existing roles, client roles and
>>>>>> composite roles.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>>
>>>>>>> From: "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Tuesday, 28 July, 2015 11:09:04 AM
>>>>>>> Subject: Re: [keycloak-dev] RFC: organizations
>>>>>>>
>>>>>>> On 07/28/2015 10:31 AM, Stian Thorgersen wrote:
>>>>>>>>
>>>>>>>> I'll add a bit to this example:
>>>>>>>>
>>>>>>>> Within a realm there's 4 services (bearer-only clients):
>>>>>>>>
>>>>>>>> * Acme Email Service
>>>>>>>> * Acme Monitor Service
>>>>>>>> * Red Hat Email Service
>>>>>>>> * Red Hat Monitor Service
>>>>>>>
>>>>>>>
>>>>>>> Is there a way to have a relationship between Acme Email Service and
>>>>>>> Acme Monitor Service? Are they different clients? We'd need a stable
>>>>>>> ID
>>>>>>> between related services, which would be our "tenant". So, if user
>>>>>>> jdoe
>>>>>>> creates a resource in our application while acting as SuperUser for
>>>>>>> Acme, we have to store this resource with the information that it
>>>>>>> belongs to Acme, so that users of Red Hat wouldn't have access to it.
>>>>>>>
>>>>>>>> Each client has one or more roles. For example Acme Email and Red
>>>>>>>> Hat
>>>>>>>> email
>>>>>>>> both have view-email, read-email and send-email.
>>>>>>>>
>>>>>>>> To model the above super users you'd add two composite realm roles:
>>>>>>>>
>>>>>>>> * acme-super - add mapping on all roles for Acme Email and Acme
>>>>>>>> Monitor
>>>>>>>> * redhat-super - add mapping on all roles for Red Hat Email and Red
>>>>>>>> Hat
>>>>>>>> Monitor
>>>>>>>
>>>>>>>
>>>>>>> Meaning that for each new "organization", a new set of roles would
>>>>>>> have
>>>>>>> to be duplicated. Basically, acme-super and redhat-super are exactly
>>>>>>> the
>>>>>>> same, except for the names.
>>>>>>>
>>>>>>> But if I get it right, this is how it would look like:
>>>>>>>
>>>>>>> - user jdoe registers, is "super" on the realm itself
>>>>>>> - user jdoe creates Acme, and is acme-super there, effectively being
>>>>>>> super on the client
>>>>>>> - user jsmith creates Red Hat, invites jdoe as "monitor" there
>>>>>>> - user jdoe is now super on the realm, acme-super on the Acme client
>>>>>>> and
>>>>>>> redhat-monitor on the Red Hat client.
>>>>>>>
>>>>>>> So, if a request comes in to our backend for jdoe while using the UI
>>>>>>> as
>>>>>>> Red Hat, our backend would see only "redhat-monitor" as the role,
>>>>>>> right?
>>>>>>>
>>>>>>>> A user can now have a role mapping on acme-super to get all roles
>>>>>>>> for
>>>>>>>> Acme
>>>>>>>> clients, or you can add role mappings to individual roles within
>>>>>>>> each
>>>>>>>> client.
>>>>>>>
>>>>>>>
>>>>>>> This means that I would be able to be Super User on Acme, but only
>>>>>>> Monitor on Red Hat, right?
>>>>>>>
>>>>>>>> That's what you want isn't it?
>>>>>>>
>>>>>>>
>>>>>>> I think it could work, yes, but that doesn't feel right, to be
>>>>>>> honest.
>>>>>>> It seems like we'd be doing some workarounds to implement a concept
>>>>>>> that
>>>>>>> doesn't quite exist on Keycloak, which would cause a massive data
>>>>>>> duplication. For one realm containing two clients and 8 roles each,
>>>>>>> this
>>>>>>> seems doable, but for one realm containing 2.000 clients (nested or
>>>>>>> not)
>>>>>>> and 8 roles each, that *sounds* like a
>>>>>>> maintenance/migration/performance
>>>>>>> nightmare.
>>>>>>>
>>>>>>>> Further you can also utilize scope on applications (confidential for
>>>>>>>> server-side web app, or public for client-side web apps) to limit
>>>>>>>> the
>>>>>>>> roles a application can obtain. For example the HTML5 application
>>>>>>>> 'Acme
>>>>>>>> Email Reader' could either have a scope on all roles within 'Acme
>>>>>>>> Email
>>>>>>>> Service' or 'acme-super'. It should probably not have scope on any
>>>>>>>> roles
>>>>>>>> for 'Red Hat Email'.
>>>>>>>
>>>>>>>
>>>>>>> Sounds like a bonus feature, but I don't think this would bring any
>>>>>>> benefit for us. We have only one frontend and one backend (with
>>>>>>> several
>>>>>>> modules). So, the same application available to Acme is available to
>>>>>>> Red
>>>>>>> Hat.
>>>>>>>
>>>>>>> - Juca.
>>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com



-- 
--
Boles?aw Dawidowicz


From bburke at redhat.com  Tue Aug  4 09:55:37 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 4 Aug 2015 09:55:37 -0400
Subject: [keycloak-dev] Queries on Keycloak
In-Reply-To: <006901d0cebc$3d41f290$b7c5d7b0$@spire2grow.com>
References: <006901d0cebc$3d41f290$b7c5d7b0$@spire2grow.com>
Message-ID: <55C0C459.9020907@redhat.com>



On 8/4/2015 9:48 AM, Satyajit Das wrote:
> Hi Team,
>
> Kindly respond to the below queries.
>
> 1)What is the limit to the number of realms, roles per realm, and users
> per realm or users per role in key cloak.
>

We haven't really tested the limits.  Should be pretty large.  I know 
one keycloak user has a database of around 1 million users.

> 2)what is the expire time of a token id generated in key
> cloak.(session.getTokenString()).
>

Its configurable in admin console

> 3) is there any authentication done after successfull login ,if I visit
> subsequent pages.
>

Do you mean is there any authentication with the Keycloak server?
Once a user is logged in, they do not see any more authentication 
screens.  Once you visit one application, you are authenticated for that 
application.  If you visit another application, you are redirected to 
keycloak auth server, auth server will validate the SSO cookie, then 
generate a token for the aplication and send you back there.




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

From mposolda at redhat.com  Tue Aug  4 10:16:39 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 04 Aug 2015 16:16:39 +0200
Subject: [keycloak-dev] Kerberos with IE does not work
In-Reply-To: <99ebd612-3c27-4094-87db-27213e4064ff@me.com>
References: <99ebd612-3c27-4094-87db-27213e4064ff@me.com>
Message-ID: <55C0C947.2090609@redhat.com>

Thanks for the confirm!

I've added the patch to keycloak master and will be available in 1.5. 
I've also resolved jira https://issues.jboss.org/browse/KEYCLOAK-1595 .

Thanks,
Marek

On 4.8.2015 07:58, Michael Gerber wrote:
> Hi Marek,
>
> Your proposed patch works perfectly fine.
> IE only overwrites the header for the keycloak REST services, the 
> other REST services work fine.
>
> Thank you for your help.
> Michael
>
> Am 03. August 2015 um 13:36 schrieb Marek Posolda <mposolda at redhat.com>:
>
>> On 29.7.2015 16:37, Michael Gerber wrote:
>>> The ClearAuthenticationCache command deletes the following data:
>>> - Session cookies
>>> - sessionStorage
>>> - HTTP Authentication (e.g. Digest or Basic HTTP credentials)
>>> - HTTPS Client Certificates (e.g. sites that use certificates or 
>>> SmartCards)
>>>
>>> But keycloak needs the session cookie, otherwise the user has to 
>>> relogin after each page reload.
>>>
>>> Isn't the clientSecret anyway public if it is send in the 
>>> Authorization header?
>> Yes, it is for JS clients. That's why it's better to not use 
>> clientSecret with javascript based clients, but instead mark those 
>> clients as "public" in keycloak admin console. In this case 
>> keycloak.js will use client_id parameter instead of Authorization 
>> header. Can this work for you?
>>
>> Thing is, that currently AuthorizeClientUtil will likely 
>> automatically send 401 if it found "Authorization: Negotiate ..." 
>> header even if you have public client and you want to use client_id 
>> (I did not test it, but guessing from looking at the code). So I've 
>> created the simple patch to avoid it: 
>> https://github.com/mposolda/keycloak/commit/858882a306cfc66567dedfcb40454354aa891903
>>
>> So if you do the steps like:
>> 1) make your client as public
>> 2) Apply my patch
>>
>> will it help?
>>
>> I am still seeing potential issues if your javascript client needs to 
>> send REST requests authorized by "Authorization: Bearer" header with 
>> accessToken. Not sure if IE doesn't again overwrite the header with 
>> "Authorization: Negotiate". In this case REST request would fail. But 
>> hopefully not... If you have opportunity to try it, it will be cool.
>>
>> Thanks,
>> Marek
>>
>>>
>>> Am 29. Juli 2015 um 14:27 schrieb Bill Burke <bburke at redhat.com>:
>>>
>>>> The trick you found earlier doesn't work?
>>>>
>>>> http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header
>>>>
>>>> Also, what if in keycloak.js if kc.clientSecret is null? Just remove
>>>> the client secret IMO. You shouldn't be exposing the client secret as
>>>> it is now public to everybody in the world....
>>>>
>>>> On 7/29/2015 8:05 AM, Michael Gerber wrote:
>>>>> I could find a solution for my IE problem.
>>>>>
>>>>> IE overwrites the Authorization header in the XMLHttpRequest
>>>>> (/protocol/openid-connect/token) with "Authorization: Negotiate".
>>>>>
>>>>> To solve this problem, I added on the client the client_id
>>>>> and client_secret to the form and changed the authorizeClient 
>>>>> method, so
>>>>> it checks first the form data instead of the authorization http 
>>>>> header.
>>>>>
>>>>> Have a look at my code:
>>>>> https://github.com/gerbermichi/keycloak/commit/32880b210ed27f782a2f9fcd01da4df21ee0953c
>>>>>
>>>>> Should I create a pull request for the changes or do you have a better
>>>>> solution?
>>>>>
>>>>> cheers
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>> Am 22. Juli 2015 um 11:46 schrieb Marek Posolda 
>>>>> <mposolda at redhat.com <mailto:mposolda at redhat.com>
>>>>> <mailto:mposolda at redhat.com>>:
>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> No idea if there is other solution, I've never tried SPNEGO with
>>>>>> Internet explorer TBH :(
>>>>>>
>>>>>> Could you please create JIRA for this?
>>>>>>
>>>>>> Thanks,
>>>>>> Marek
>>>>>>
>>>>>> On 22.7.2015 10:07, Michael Gerber wrote:
>>>>>>> Hi all
>>>>>>>
>>>>>>> My kerberos configuration works fine with FireFox and Chrome, but it
>>>>>>> does not work with IE.
>>>>>>> It shows a prompt where the user has to enter a username and 
>>>>>>> password.
>>>>>>>
>>>>>>> I can successfully get an access code, but I can not get an access
>>>>>>> token, because IE overwrites the Authorization header in the AJAX
>>>>>>> request. (see
>>>>>>> http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header)
>>>>>>>
>>>>>>> I can fix this by adding
>>>>>>> document.execCommand('ClearAuthenticationCache', 'false');
>>>>>>> above of
>>>>>>> var req = new XMLHttpRequest();
>>>>>>> approximately at the line 374 in the keycloack.js file.
>>>>>>>
>>>>>>> Is there another solution for this problem?
>>>>>>>
>>>>>>> cheers
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>
>>>> -- 
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> _______________________________________________
>>> 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/20150804/88ca9208/attachment-0001.html 

From bburke at redhat.com  Tue Aug  4 12:57:04 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 4 Aug 2015 12:57:04 -0400
Subject: [keycloak-dev] Would like to deprecate/remove JPA/Mongo UserSessions
Message-ID: <55C0EEE0.9050307@redhat.com>

Hi all,

Keycloak team would like to deprecate and remove the JPA and Mongo 
stores for UserSessions and just provide an Infinispan one.  It is a 
pain to maintain these, and in our opinion, users really shouldn't be 
using JPA or Mongo to store User Sessions.  Infinispan has a wide 
variety of configuration options for internal, external, and cloud networks.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Scott.Rehorn at software.dell.com  Tue Aug  4 20:31:34 2015
From: Scott.Rehorn at software.dell.com (Scott Rehorn)
Date: Wed, 5 Aug 2015 00:31:34 +0000
Subject: [keycloak-dev] groups vs. organizations
In-Reply-To: <55BFAF4B.2070908@redhat.com>
References: <55BAA513.9090009@redhat.com>
	<D1E1070C.17E19%Scott.Rehorn@software.dell.com>
	<55BBE79F.5090703@redhat.com>
	<F893802C2FB19B459F1A54D865A9C95C35DC080D@ALVMBXW02.prod.quest.corp>
	<55BFAF4B.2070908@redhat.com>
Message-ID: <F893802C2FB19B459F1A54D865A9C95C35DC1BBE@ALVMBXW02.prod.quest.corp>

Hi Bill et al, comments below...

> -----Original Message-----
> From: Bill Burke [mailto:bburke at redhat.com]
> Sent: Monday, August 3, 2015 11:14 AM
> To: Scott Rehorn; keycloak-dev at lists.jboss.org
> Subject: Re: groups vs. organizations
> 
> 
> 
> On 8/3/2015 1:40 PM, Scott Rehorn wrote:
> >
> >
> > Here's a possible summary:
> > Groups:
> > * have names
> > * can contain other groups
> > * can carry a 'schema' which represent available attributes (more
> > generally, claims)
> > * support mapping and aggregation from IdP-defined groups
> > * can be assigned roles
> >
> > So user in a group gets that group's attributes, role associations, sub-group's
> role associations, sub-group's attributes.
> >
> 
> Can you define "support mapping and aggregation from IdP-defined groups"?
> Wouldn't this be something configured at each IDP rather than in a group?  The
> IDP would define a mapper that looked at some claim, then associate the user
> with a Keycloak defined group based on the claim...right?
> 

That's true - I mean both things are true :) I believe, in order to properly normalize things like group names in the authoritative location (where KC is the authority),  then the group name must be defined in KC and IdPs would map to that name as part of IdP mapping definitions. Of course, one could also *not* introduce mapping and just let each IdP pass through its own group definitions and let RPs sort it out themselves. 

> I was also thinking that we might remove client roles and just move them to
> groups.  Migration would be that a group is created for each client that has a set
> of roles defined.  We have a few users that want to share a set of roles between
> different clients.
> 

I partially agree with moving client roles to groups, but I think that the pattern that keeps appearing in the authZ department (role-based access control or RBAC) is to have this structure (including slightly different names and semantics):

* there are users
* users can be in groups
* groups can be in groups
* users and groups can be assigned roles
* roles can be assigned permissions (aka claims in this context)
* so a given user has a group, the group has n roles, and each role has m permissions attached to it -- an authenticated user has that little graph attached so an RP can interpret it to establish authZ decisions.
* a user can be assigned roles without using a group

I think your migration thinking is correct - and it opens up the chance to represent good granularity if it's needed, and basically ignored when it's overkill. I'm advocating for a permissions collection associated with a role, but there is an argument to say that having 'permissions' is nutty, since one can model simple authZ with a single-role-per-permission like KC roles do now. 

E.g., once authenticated, I might have a group 'Aliso Viejo R&D' and a set of roles which assert things like can-edit-bamboo-config, can-run-bamboo-build, etc. and I think that overloads the conventional meaning of a 'role' and that it's modeled a bit more tidily by having roles which act as named collections of permissions. 

Finally, where you said above "We have a few users that want to share a set of roles between different clients" then I think that's where the 'organization' type group comes into play. Clients A, B, C are in an 'org' (ok, group :) called 'tenant-20' which has a role called 'tenant-20-role' associated with it. This role, in turn, has claims/permissions. So any user authenticated by KC  into A, B, or C gets the claims expressed in the tenant-20-role. Further, only one of those users might be in an 'admin' group which has additional claims beyond those in the tenant-20-role.

- scott r



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


From satyajit.das at spire2grow.com  Wed Aug  5 02:35:03 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Wed, 5 Aug 2015 12:05:03 +0530
Subject: [keycloak-dev] Queries on Keycloak
In-Reply-To: <55C0C459.9020907@redhat.com>
References: <006901d0cebc$3d41f290$b7c5d7b0$@spire2grow.com>
	<55C0C459.9020907@redhat.com>
Message-ID: <CA+oCsRoGDanO9QGKvfngR0zCTQLk58zY18FCnUYiyH-qM2J1_w@mail.gmail.com>

Hi Bill,

Thanks a lot  for the quick response. Just one more query on the webservice
side.

As per the instruction , I made the webservice access type as bearer.

Lets say. I have a service called http://localhost:8082/candidates/.

This in turn has many webservice operation such as
post: http://localhost:8082/candidates/{candidate}
put: http://localhost:8082/candidates/candidate/{id}
get:http://localhost:8082/candidates/candidate/{id}.

after a successful token verification:
 HttpGet get = new
HttpGet(AdapterUtils.getOriginForRestCalls(req.getRequestURL().toString(),
session) + "/candidate/{some id}");
            get.addHeader("Authorization", "Bearer " +
session.getTokenString());
            try {
                HttpResponse response = client.execute(get);
                if (response.getStatusLine().getStatusCode() != 200) {
                    throw new
Failure(response.getStatusLine().getStatusCode());
                }
                HttpEntity entity = response.getEntity();
                InputStream is = entity.getContent();
                try {
                  //  return JsonSerialization.readValue(is, String.class);
                return "hello";
                } finally {
                    is.close();
                }

do i need to further authenticate each call via the same method for other
restful call.

Do we have any option where in we can say authenticate once and go ahead
with multiple webservice call without further token verification.

Regards,
Satya.

On Tue, Aug 4, 2015 at 7:25 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 8/4/2015 9:48 AM, Satyajit Das wrote:
> > Hi Team,
> >
> > Kindly respond to the below queries.
> >
> > 1)What is the limit to the number of realms, roles per realm, and users
> > per realm or users per role in key cloak.
> >
>
> We haven't really tested the limits.  Should be pretty large.  I know
> one keycloak user has a database of around 1 million users.
>
> > 2)what is the expire time of a token id generated in key
> > cloak.(session.getTokenString()).
> >
>
> Its configurable in admin console
>
> > 3) is there any authentication done after successfull login ,if I visit
> > subsequent pages.
> >
>
> Do you mean is there any authentication with the Keycloak server?
> Once a user is logged in, they do not see any more authentication
> screens.  Once you visit one application, you are authenticated for that
> application.  If you visit another application, you are redirected to
> keycloak auth server, auth server will validate the SSO cookie, then
> generate a token for the aplication and send you back there.
>
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150805/52ca0d49/attachment.html 

From mposolda at redhat.com  Wed Aug  5 04:14:18 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 05 Aug 2015 10:14:18 +0200
Subject: [keycloak-dev] Queries on Keycloak
In-Reply-To: <CA+oCsRoGDanO9QGKvfngR0zCTQLk58zY18FCnUYiyH-qM2J1_w@mail.gmail.com>
References: <006901d0cebc$3d41f290$b7c5d7b0$@spire2grow.com>	<55C0C459.9020907@redhat.com>
	<CA+oCsRoGDanO9QGKvfngR0zCTQLk58zY18FCnUYiyH-qM2J1_w@mail.gmail.com>
Message-ID: <55C1C5DA.8080101@redhat.com>

Yes, you're supposed to add the "Authorization: Bearer 
access-token-here" header in each REST or WebService request from your 
frontend application. The adapter on webservice side will always 
validate the accessToken in each request and it allows it to pass just 
if it's valid.

Marek

On 5.8.2015 08:35, Satyajit Das wrote:
> Hi Bill,
>
> Thanks a lot  for the quick response. Just one more query on the 
> webservice side.
>
> As per the instruction , I made the webservice access type as bearer.
>
> Lets say. I have a service called http://localhost:8082/candidates/.
>
> This in turn has many webservice operation such as
> post: http://localhost:8082/candidates/{candidate} 
> <http://localhost:8082/candidates/%7Bcandidate%7D>
> put: http://localhost:8082/candidates/candidate/{id} 
> <http://localhost:8082/candidates/candidate/%7Bid%7D>
> get:http://localhost:8082/candidates/candidate/{id} 
> <http://localhost:8082/candidates/candidate/%7Bid%7D>.
>
> after a successful token verification:
>  HttpGet get = new 
> HttpGet(AdapterUtils.getOriginForRestCalls(req.getRequestURL().toString(), 
> session) + "/candidate/{some id}");
>             get.addHeader("Authorization", "Bearer " + 
> session.getTokenString());
>             try {
>                 HttpResponse response = client.execute(get);
>                 if (response.getStatusLine().getStatusCode() != 200) {
>                     throw new 
> Failure(response.getStatusLine().getStatusCode());
>                 }
>                 HttpEntity entity = response.getEntity();
>                 InputStream is = entity.getContent();
>                 try {
>                   //  return JsonSerialization.readValue(is, 
> String.class);
> return "hello";
>                 } finally {
>                     is.close();
>                 }
>
> do i need to further authenticate each call via the same method for 
> other restful call.
>
> Do we have any option where in we can say authenticate once and go 
> ahead with multiple webservice call without further token verification.
>
> Regards,
> Satya.
>
> On Tue, Aug 4, 2015 at 7:25 PM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 8/4/2015 9:48 AM, Satyajit Das wrote:
>     > Hi Team,
>     >
>     > Kindly respond to the below queries.
>     >
>     > 1)What is the limit to the number of realms, roles per realm,
>     and users
>     > per realm or users per role in key cloak.
>     >
>
>     We haven't really tested the limits.  Should be pretty large.  I know
>     one keycloak user has a database of around 1 million users.
>
>     > 2)what is the expire time of a token id generated in key
>     > cloak.(session.getTokenString()).
>     >
>
>     Its configurable in admin console
>
>     > 3) is there any authentication done after successfull login ,if
>     I visit
>     > subsequent pages.
>     >
>
>     Do you mean is there any authentication with the Keycloak server?
>     Once a user is logged in, they do not see any more authentication
>     screens.  Once you visit one application, you are authenticated
>     for that
>     application.  If you visit another application, you are redirected to
>     keycloak auth server, auth server will validate the SSO cookie, then
>     generate a token for the aplication and send you back there.
>
>
>
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> 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/20150805/6312d7a9/attachment-0001.html 

From bburke at redhat.com  Wed Aug  5 08:40:25 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 5 Aug 2015 08:40:25 -0400
Subject: [keycloak-dev] Queries on Keycloak
In-Reply-To: <CA+oCsRoGDanO9QGKvfngR0zCTQLk58zY18FCnUYiyH-qM2J1_w@mail.gmail.com>
References: <006901d0cebc$3d41f290$b7c5d7b0$@spire2grow.com>
	<55C0C459.9020907@redhat.com>
	<CA+oCsRoGDanO9QGKvfngR0zCTQLk58zY18FCnUYiyH-qM2J1_w@mail.gmail.com>
Message-ID: <55C20439.8010000@redhat.com>

Why don't you just try it out or read the documentation? :)

Yes, you can use the token to invoke on other rest services so long as 
the token has the appropriate permissions each rest service requires for 
access.  The token is actually a Json Web Signature (JWS).  The rest 
endpoints validate the signature using the public key of the realm. 
Tokens have a timeout, but are automatically updated for web apps. 
Otherwise you ahve to use the refresh token to obtain a new access token.
On 8/5/2015 2:35 AM, Satyajit Das wrote:
> Hi Bill,
>
> Thanks a lot  for the quick response. Just one more query on the
> webservice side.
>
> As per the instruction , I made the webservice access type as bearer.
>
> Lets say. I have a service called http://localhost:8082/candidates/.
>
> This in turn has many webservice operation such as
> post: http://localhost:8082/candidates/{candidate}
> put: http://localhost:8082/candidates/candidate/{id}
> get:http://localhost:8082/candidates/candidate/{id}.
>
> after a successful token verification:
>   HttpGet get = new
> HttpGet(AdapterUtils.getOriginForRestCalls(req.getRequestURL().toString(),
> session) + "/candidate/{some id}");
>              get.addHeader("Authorization", "Bearer " +
> session.getTokenString());
>              try {
>                  HttpResponse response = client.execute(get);
>                  if (response.getStatusLine().getStatusCode() != 200) {
>                      throw new
> Failure(response.getStatusLine().getStatusCode());
>                  }
>                  HttpEntity entity = response.getEntity();
>                  InputStream is = entity.getContent();
>                  try {
>                    //  return JsonSerialization.readValue(is, String.class);
> return "hello";
>                  } finally {
>                      is.close();
>                  }
>
> do i need to further authenticate each call via the same method for
> other restful call.
>
> Do we have any option where in we can say authenticate once and go ahead
> with multiple webservice call without further token verification.
>
> Regards,
> Satya.
>
> On Tue, Aug 4, 2015 at 7:25 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 8/4/2015 9:48 AM, Satyajit Das wrote:
>     > Hi Team,
>     >
>     > Kindly respond to the below queries.
>     >
>     > 1)What is the limit to the number of realms, roles per realm, and users
>     > per realm or users per role in key cloak.
>     >
>
>     We haven't really tested the limits.  Should be pretty large.  I know
>     one keycloak user has a database of around 1 million users.
>
>     > 2)what is the expire time of a token id generated in key
>     > cloak.(session.getTokenString()).
>     >
>
>     Its configurable in admin console
>
>     > 3) is there any authentication done after successfull login ,if I visit
>     > subsequent pages.
>     >
>
>     Do you mean is there any authentication with the Keycloak server?
>     Once a user is logged in, they do not see any more authentication
>     screens.  Once you visit one application, you are authenticated for that
>     application.  If you visit another application, you are redirected to
>     keycloak auth server, auth server will validate the SSO cookie, then
>     generate a token for the aplication and send you back there.
>
>
>
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From velias at redhat.com  Thu Aug  6 07:52:25 2015
From: velias at redhat.com (Vlastimil Elias)
Date: Thu, 06 Aug 2015 13:52:25 +0200
Subject: [keycloak-dev] Blocker bug in KC 1.4 -> next release plans?
Message-ID: <55C34A79.3020000@redhat.com>

Hi KC team,

we started work to update Red Hat Developers KC instance from 1.2 to 
1.4, but I found one regression blocker (at least for us) 
https://issues.jboss.org/browse/KEYCLOAK-1739 unfortunately.

There are also few smaller bugs like 
https://issues.jboss.org/browse/KEYCLOAK-1741 and 
https://issues.jboss.org/browse/KEYCLOAK-1731 but they are not blocking.

Any chance this should be patched in some 1.4.1 minor bugfix release or 
should we wait for 1.5?  What is expected/raw release date for 1.5? We 
would like to upgrade ASAP as 1.3 and 1.4 brought bunch of features we 
are waiting for and we do not want to stay too much behind latest release.

I can try to help and prepare PR for KEYCLOAK-1739 and others, but need 
to know what to use as a base (master or 1.4.x branch).

Thanks in advance

Vlastimil

-- 
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team


From satyajit.das at spire2grow.com  Thu Aug  6 08:15:26 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Thu, 6 Aug 2015 17:45:26 +0530
Subject: [keycloak-dev] Queries on Custom Authorization
Message-ID: <011301d0d041$95266f00$bf734d00$@spire2grow.com>

Hi Team,

 

Kindly explain the below query:

 

I want to have custom authorization, i.e a user can view certain pages but
not some other pages. Certain components on a screen should be invisible and
navigation to certain screens to be restricted.

 

Does key cloak provide any such custom authorization api. I went through the
document but could not find any explanation on this topic.

 

Any help will be highly appreciated.

 

 

Regards,

Satya.

 

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

From bburke at redhat.com  Thu Aug  6 08:55:51 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 6 Aug 2015 08:55:51 -0400
Subject: [keycloak-dev] Blocker bug in KC 1.4 -> next release plans?
In-Reply-To: <55C34A79.3020000@redhat.com>
References: <55C34A79.3020000@redhat.com>
Message-ID: <55C35957.9040203@redhat.com>



On 8/6/2015 7:52 AM, Vlastimil Elias wrote:
> Hi KC team,
>
> we started work to update Red Hat Developers KC instance from 1.2 to
> 1.4, but I found one regression blocker (at least for us)
> https://issues.jboss.org/browse/KEYCLOAK-1739 unfortunately.
>

How was this fixed before?

> I can try to help and prepare PR for KEYCLOAK-1739 and others, but need
> to know what to use as a base (master or 1.4.x branch).
>

Use 1.5.0.  I think we can release 1.5 at end of month.


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

From bburke at redhat.com  Thu Aug  6 08:53:04 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 6 Aug 2015 08:53:04 -0400
Subject: [keycloak-dev] Queries on Custom Authorization
In-Reply-To: <011301d0d041$95266f00$bf734d00$@spire2grow.com>
References: <011301d0d041$95266f00$bf734d00$@spire2grow.com>
Message-ID: <55C358B0.80205@redhat.com>

You mean with your application?  No, we have nothing.  All we do is 
propagate user claims and role mappings.  it is up to your application 
to show/hide information based on this data.  Keycloak is not a web 
application framework...

On 8/6/2015 8:15 AM, Satyajit Das wrote:
> Hi Team,
>
> Kindly explain the below query:
>
> I want to have custom authorization, i.e a user can view certain pages
> but not some other pages. Certain components on a screen should be
> invisible and navigation to certain screens to be restricted.
>
> Does key cloak provide any such custom authorization api. I went through
> the document but could not find any explanation on this topic.
>
> Any help will be highly appreciated.
>
> Regards,
>
> Satya.
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From lennart.jorelid at gmail.com  Sun Aug  9 07:38:43 2015
From: lennart.jorelid at gmail.com (=?UTF-8?Q?Lennart_J=C3=B6relid?=)
Date: Sun, 9 Aug 2015 13:38:43 +0200
Subject: [keycloak-dev] Concept structure in the VCS?
Message-ID: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>

Hello all,

A month or so ago, I got curious about Keycloak. Downloaded, set up in a
dev environment, created some custom themes and took a look at the
codebase. I have a few questions, likely because I have missed some
developer documentation:


   - *Codebase concepts*: I frequently try to structure codebases to
   highlight its big concepts. For example, if we consider 'themes' to be such
   a concept in KeyCloak we might create a folder called 'themes", with some
   project wihtin it: (themes-model, themes-spi, themes-impl-jpa,
   themes-impl-freemarker, ....). Is there a description of the codebase
   structure or concepts currently? ("mini-SAD")
   - *Codebase javadoc:* Do we have a policy for JavaDoc'ing the
   Model/API/SPI but perhaps not the implementation classes, other than with
   implementation details?
   - *Configuration:* Some of the descriptions in the docbook are really
   good, and some are more shallow. If we create a standard way of configuring
   the parts of keycloak, we could likely generate standard
   setup/configuration documentation (somewhat similar to maven plugins where
   certain parts of a site documentation is generated from annotations or
   JavaDocs). Are there such plans?


-- 

--
+==============================+
| B?sta h?lsningar,
| [sw. "Best regards"]
|
| Lennart J?relid
| EAI Architect & Integrator
|
| jGuru Europe AB
| M?lnlycke - Kista
|
| Email: lj at jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150809/11fe4435/attachment.html 

From bburke at redhat.com  Sun Aug  9 11:25:50 2015
From: bburke at redhat.com (Bill Burke)
Date: Sun, 9 Aug 2015 11:25:50 -0400
Subject: [keycloak-dev] Concept structure in the VCS?
In-Reply-To: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>
References: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>
Message-ID: <55C770FE.3090909@redhat.com>

Only plans right now are to separate our public SPIs and APIs from our 
private ones.  This is a requirement by Red hat before we go into product.

Also, a massive backlog of requirements and feature requests has made us 
rush documentation.  The screencast videos haven't been updated since 
January.  It is what it is.  Over the next 3-6 months we will catch up 
on this stuff becuase we are required to before we go into Product.

FYI, we already autogenerate REST docs.

On 8/9/2015 7:38 AM, Lennart J?relid wrote:
> Hello all,
>
> A month or so ago, I got curious about Keycloak. Downloaded, set up in a
> dev environment, created some custom themes and took a look at the
> codebase. I have a few questions, likely because I have missed some
> developer documentation:
>
>   * *Codebase concepts*: I frequently try to structure codebases to
>     highlight its big concepts. For example, if we consider 'themes' to
>     be such a concept in KeyCloak we might create a folder called
>     'themes", with some project wihtin it: (themes-model, themes-spi,
>     themes-impl-jpa, themes-impl-freemarker, ....). Is there a
>     description of the codebase structure or concepts currently?
>     ("mini-SAD")
>   * *Codebase javadoc:* Do we have a policy for JavaDoc'ing the
>     Model/API/SPI but perhaps not the implementation classes, other than
>     with implementation details?
>   * *Configuration:* Some of the descriptions in the docbook are really
>     good, and some are more shallow. If we create a standard way of
>     configuring the parts of keycloak, we could likely generate standard
>     setup/configuration documentation (somewhat similar to maven plugins
>     where certain parts of a site documentation is generated from
>     annotations or JavaDocs). Are there such plans?
>
>
> --
>
> --
> +==============================+
> | B?sta h?lsningar,
> | [sw. "Best regards"]
> |
> | Lennart J?relid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | M?lnlycke - Kista
> |
> | Email:lj at jguru.se <mailto:lj at jguru.se>
> | URL:www.jguru.se <http://www.jguru.se>
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From lennart.jorelid at gmail.com  Sun Aug  9 13:00:59 2015
From: lennart.jorelid at gmail.com (=?UTF-8?Q?Lennart_J=C3=B6relid?=)
Date: Sun, 9 Aug 2015 19:00:59 +0200
Subject: [keycloak-dev] Fwd:  Concept structure in the VCS?
In-Reply-To: <CAJ1fz83k=Mrk1utmp4RAbWCYLBLMj21ihrj4oqZ_w2ESgKFVFA@mail.gmail.com>
References: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>
	<55C770FE.3090909@redhat.com>
	<CAJ1fz83k=Mrk1utmp4RAbWCYLBLMj21ihrj4oqZ_w2ESgKFVFA@mail.gmail.com>
Message-ID: <CAJ1fz80ecbsjMnnKYDFOWFfOC+wZkzciiSS4onDa=DiWCKoX-Q@mail.gmail.com>

Ah - by mistake, I replied only to Bill. Cross-posting to the list as well.
Sorry for the spam.

======

Hello there,

First - I found the current screencasts massively helpful in getting
started, to be honest. They are something I really have not seen in most
projects, and they contributed a lot to me making sense of the Keycloak
codebase and usage scenarios. Kudos.

Sedond - I think it would be quite helpful to add additional modularization
and also harmonize some configuration to make it more evident in how it is
interpreted. Let me clarify the last bit here (I'll take themes as an
example, but I believe that the same conclusion stands for other parts of
the Keycloak codebase):

# Import and extend definitions
parent=base
import=common/keycloak
styles=lib/patternfly/css/patternfly.css lib/zocial/zocial.css
stylesheets/login.css stylesheets/yourOwn.css


   1. The documentation and examples provides something roughly similar to
   the above.
   2. Turning the attention to the "import" parameter, one could jump to
   the conclusion that there would be directory called "common/keycloak" and
   that this directory should contain a lib directory containing the styles
   css documents from the "styles" configuration.
   3. Reading the codebase, it seems that the semantics of the "import"
   property is something completetly different. From the
   ExtendingThemeManager::loadTheme, I can see that the '/' is instead used as
   a list separator implying that we should attempt loading resources from
   several sources. (Snippet pasted below).

if (theme.getImportName() != null) {
    String[] s = theme.getImportName().split("/");
    themes.add(findTheme(s[1], Theme.Type.valueOf(s[0].toUpperCase())));
}

So ... I would believe that the configuration in this case would be clearer
on a Java Object, JSON or XML form, where one can provide somewhat better
semantics than what is possible in a properties file (one could use a List
of theme names instead of a single string value to be parsed and
interpreted, for example).

Mind if I take a stab at implementing a suggestion here?


2015-08-09 17:25 GMT+02:00 Bill Burke <bburke at redhat.com>:

> Only plans right now are to separate our public SPIs and APIs from our
> private ones.  This is a requirement by Red hat before we go into product.
>
> Also, a massive backlog of requirements and feature requests has made us
> rush documentation.  The screencast videos haven't been updated since
> January.  It is what it is.  Over the next 3-6 months we will catch up
> on this stuff becuase we are required to before we go into Product.
>
> FYI, we already autogenerate REST docs.
>
> On 8/9/2015 7:38 AM, Lennart J?relid wrote:
> > Hello all,
> >
> > A month or so ago, I got curious about Keycloak. Downloaded, set up in a
> > dev environment, created some custom themes and took a look at the
> > codebase. I have a few questions, likely because I have missed some
> > developer documentation:
> >
> >   * *Codebase concepts*: I frequently try to structure codebases to
> >     highlight its big concepts. For example, if we consider 'themes' to
> >     be such a concept in KeyCloak we might create a folder called
> >     'themes", with some project wihtin it: (themes-model, themes-spi,
> >     themes-impl-jpa, themes-impl-freemarker, ....). Is there a
> >     description of the codebase structure or concepts currently?
> >     ("mini-SAD")
> >   * *Codebase javadoc:* Do we have a policy for JavaDoc'ing the
> >     Model/API/SPI but perhaps not the implementation classes, other than
> >     with implementation details?
> >   * *Configuration:* Some of the descriptions in the docbook are really
> >     good, and some are more shallow. If we create a standard way of
> >     configuring the parts of keycloak, we could likely generate standard
> >     setup/configuration documentation (somewhat similar to maven plugins
> >     where certain parts of a site documentation is generated from
> >     annotations or JavaDocs). Are there such plans?
> >
> >
> > --
> >
> > --
> > +==============================+
> > | B?sta h?lsningar,
> > | [sw. "Best regards"]
> > |
> > | Lennart J?relid
> > | EAI Architect & Integrator
> > |
> > | jGuru Europe AB
> > | M?lnlycke - Kista
> > |
> > | Email:lj at jguru.se <mailto:lj at jguru.se>
> > | URL:www.jguru.se <http://www.jguru.se>
> > | Phone
> > | (skype):    jgurueurope
> > | (intl):     +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 

--
+==============================+
| B?sta h?lsningar,
| [sw. "Best regards"]
|
| Lennart J?relid
| EAI Architect & Integrator
|
| jGuru Europe AB
| M?lnlycke - Kista
|
| Email: lj at jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150809/e6e10652/attachment.html 

From bburke at redhat.com  Sun Aug  9 19:53:08 2015
From: bburke at redhat.com (Bill Burke)
Date: Sun, 9 Aug 2015 19:53:08 -0400
Subject: [keycloak-dev] Fwd: Concept structure in the VCS?
In-Reply-To: <CAJ1fz80ecbsjMnnKYDFOWFfOC+wZkzciiSS4onDa=DiWCKoX-Q@mail.gmail.com>
References: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>
	<55C770FE.3090909@redhat.com>
	<CAJ1fz83k=Mrk1utmp4RAbWCYLBLMj21ihrj4oqZ_w2ESgKFVFA@mail.gmail.com>
	<CAJ1fz80ecbsjMnnKYDFOWFfOC+wZkzciiSS4onDa=DiWCKoX-Q@mail.gmail.com>
Message-ID: <55C7E7E4.1070604@redhat.com>

You'll have to talk to Stian about the structure of themes as he 
implemented all that stuff.

On 8/9/2015 1:00 PM, Lennart J?relid wrote:
> Ah - by mistake, I replied only to Bill. Cross-posting to the list as
> well. Sorry for the spam.
>
> ======
>
> Hello there,
>
> First - I found the current screencasts massively helpful in getting
> started, to be honest. They are something I really have not seen in most
> projects, and they contributed a lot to me making sense of the Keycloak
> codebase and usage scenarios. Kudos.
>
> Sedond - I think it would be quite helpful to add additional
> modularization and also harmonize some configuration to make it more
> evident in how it is interpreted. Let me clarify the last bit here (I'll
> take themes as an example, but I believe that the same conclusion stands
> for other parts of the Keycloak codebase):
>
> # Import and extend definitions
> parent=base
> import=common/keycloak
> styles=lib/patternfly/css/patternfly.css lib/zocial/zocial.css
> stylesheets/login.css stylesheets/yourOwn.css
>
>  1. The documentation and examples provides something roughly similar to
>     the above.
>  2. Turning the attention to the "import" parameter, one could jump to
>     the conclusion that there would be directory called
>     "common/keycloak" and that this directory should contain a lib
>     directory containing the styles css documents from the "styles"
>     configuration.
>  3. Reading the codebase, it seems that the semantics of the "import"
>     property is something completetly different. From the
>     ExtendingThemeManager::loadTheme, I can see that the '/' is instead
>     used as a list separator implying that we should attempt loading
>     resources from several sources. (Snippet pasted below).
>
> if (theme.getImportName() !=null) {
>      String[] s = theme.getImportName().split("/");
>      themes.add(findTheme(s[1], Theme.Type.valueOf(s[0].toUpperCase())));
> }
>
> So ... I would believe that the configuration in this case would be
> clearer on a Java Object, JSON or XML form, where one can provide
> somewhat better semantics than what is possible in a properties file
> (one could use a List of theme names instead of a single string value to
> be parsed and interpreted, for example).
>
> Mind if I take a stab at implementing a suggestion here?
>
>
> 2015-08-09 17:25 GMT+02:00 Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>>:
>
>     Only plans right now are to separate our public SPIs and APIs from our
>     private ones.  This is a requirement by Red hat before we go into
>     product.
>
>     Also, a massive backlog of requirements and feature requests has made us
>     rush documentation.  The screencast videos haven't been updated since
>     January.  It is what it is.  Over the next 3-6 months we will catch up
>     on this stuff becuase we are required to before we go into Product.
>
>     FYI, we already autogenerate REST docs.
>
>     On 8/9/2015 7:38 AM, Lennart J?relid wrote:
>     > Hello all,
>     >
>     > A month or so ago, I got curious about Keycloak. Downloaded, set up in a
>     > dev environment, created some custom themes and took a look at the
>     > codebase. I have a few questions, likely because I have missed some
>     > developer documentation:
>     >
>      >   * *Codebase concepts*: I frequently try to structure codebases to
>     >     highlight its big concepts. For example, if we consider 'themes' to
>     >     be such a concept in KeyCloak we might create a folder called
>     >     'themes", with some project wihtin it: (themes-model, themes-spi,
>     >     themes-impl-jpa, themes-impl-freemarker, ....). Is there a
>     >     description of the codebase structure or concepts currently?
>     >     ("mini-SAD")
>      >   * *Codebase javadoc:* Do we have a policy for JavaDoc'ing the
>     >     Model/API/SPI but perhaps not the implementation classes, other than
>     >     with implementation details?
>      >   * *Configuration:* Some of the descriptions in the docbook are
>     really
>     >     good, and some are more shallow. If we create a standard way of
>     >     configuring the parts of keycloak, we could likely generate standard
>     >     setup/configuration documentation (somewhat similar to maven plugins
>     >     where certain parts of a site documentation is generated from
>     >     annotations or JavaDocs). Are there such plans?
>     >
>     >
>     > --
>     >
>     > --
>     > +==============================+
>     > | B?sta h?lsningar,
>     > | [sw. "Best regards"]
>     > |
>     > | Lennart J?relid
>     > | EAI Architect & Integrator
>     > |
>     > | jGuru Europe AB
>     > | M?lnlycke - Kista
>     > |
>      > | Email:lj at jguru.se <mailto:Email%3Alj at jguru.se>
>     <mailto:lj at jguru.se <mailto:lj at jguru.se>>
>      > | URL:www.jguru.se <http://www.jguru.se> <http://www.jguru.se>
>     > | Phone
>     > | (skype):    jgurueurope
>     > | (intl):+46 708 507 603 <tel:%2B46%20708%20507%20603>
>     > | (domestic): 0708 - 507 603
>     > +==============================+
>     >
>     >
>     >
>      > _______________________________________________
>      > 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
>      >
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
>
> --
> +==============================+
> | B?sta h?lsningar,
> | [sw. "Best regards"]
> |
> | Lennart J?relid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | M?lnlycke - Kista
> |
> | Email:lj at jguru.se <mailto:lj at jguru.se>
> | URL:www.jguru.se <http://www.jguru.se>
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Mon Aug 10 02:56:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 10 Aug 2015 02:56:54 -0400 (EDT)
Subject: [keycloak-dev] Fwd:  Concept structure in the VCS?
In-Reply-To: <CAJ1fz80ecbsjMnnKYDFOWFfOC+wZkzciiSS4onDa=DiWCKoX-Q@mail.gmail.com>
References: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>
	<55C770FE.3090909@redhat.com>
	<CAJ1fz83k=Mrk1utmp4RAbWCYLBLMj21ihrj4oqZ_w2ESgKFVFA@mail.gmail.com>
	<CAJ1fz80ecbsjMnnKYDFOWFfOC+wZkzciiSS4onDa=DiWCKoX-Q@mail.gmail.com>
Message-ID: <1215050410.7609751.1439189814266.JavaMail.zimbra@redhat.com>

Is the main issue here that "import" can be a list in theme.properties? If so that's really a documentation issue, not organization of code-base.

BTW Keycloak is an OOTB solution so you should refer to documentation and examples (I know it's lacking in some places) not the code base. We are targeting non-Java developers and others that just wants something that works without coding. For extending/customization of Keycloak we plan to improve on documentation and clean-up Java APIs that are public.

----- Original Message -----
> From: "Lennart J?relid" <lennart.jorelid at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, 9 August, 2015 7:00:59 PM
> Subject: [keycloak-dev] Fwd:  Concept structure in the VCS?
> 
> Ah - by mistake, I replied only to Bill. Cross-posting to the list as well.
> Sorry for the spam.
> 
> ======
> 
> Hello there,
> 
> First - I found the current screencasts massively helpful in getting started,
> to be honest. They are something I really have not seen in most projects,
> and they contributed a lot to me making sense of the Keycloak codebase and
> usage scenarios. Kudos.
> 
> Sedond - I think it would be quite helpful to add additional modularization
> and also harmonize some configuration to make it more evident in how it is
> interpreted. Let me clarify the last bit here (I'll take themes as an
> example, but I believe that the same conclusion stands for other parts of
> the Keycloak codebase):
> 
> # Import and extend definitions
> parent = base
> import = common/keycloak
> styles = lib/patternfly/css/patternfly.css lib/zocial/zocial.css
> stylesheets/login.css stylesheets/yourOwn.css
> 
> 
>     1. The documentation and examples provides something roughly similar to
>     the above.
>     2. Turning the attention to the "import" parameter, one could jump to the
>     conclusion that there would be directory called "common/keycloak" and
>     that this directory should contain a lib directory containing the styles
>     css documents from the "styles" configuration.
>     3. Reading the codebase, it seems that the semantics of the "import"
>     property is something completetly different. From the
>     ExtendingThemeManager::loadTheme, I can see that the '/' is instead used
>     as a list separator implying that we should attempt loading resources
>     from several sources. (Snippet pasted below).
> 
> if (theme.getImportName() != null ) {
> String[] s = theme.getImportName().split( "/" );
> themes.add(findTheme(s[ 1 ], Theme.Type. valueOf (s[ 0 ].toUpperCase())));
> }
> So ... I would believe that the configuration in this case would be clearer
> on a Java Object, JSON or XML form, where one can provide somewhat better
> semantics than what is possible in a properties file (one could use a List
> of theme names instead of a single string value to be parsed and
> interpreted, for example).
> 
> Mind if I take a stab at implementing a suggestion here?
> 
> 
> 2015-08-09 17:25 GMT+02:00 Bill Burke < bburke at redhat.com > :
> 
> 
> Only plans right now are to separate our public SPIs and APIs from our
> private ones. This is a requirement by Red hat before we go into product.
> 
> Also, a massive backlog of requirements and feature requests has made us
> rush documentation. The screencast videos haven't been updated since
> January. It is what it is. Over the next 3-6 months we will catch up
> on this stuff becuase we are required to before we go into Product.
> 
> FYI, we already autogenerate REST docs.
> 
> On 8/9/2015 7:38 AM, Lennart J?relid wrote:
> > Hello all,
> > 
> > A month or so ago, I got curious about Keycloak. Downloaded, set up in a
> > dev environment, created some custom themes and took a look at the
> > codebase. I have a few questions, likely because I have missed some
> > developer documentation:
> > 
> > * *Codebase concepts*: I frequently try to structure codebases to
> > highlight its big concepts. For example, if we consider 'themes' to
> > be such a concept in KeyCloak we might create a folder called
> > 'themes", with some project wihtin it: (themes-model, themes-spi,
> > themes-impl-jpa, themes-impl-freemarker, ....). Is there a
> > description of the codebase structure or concepts currently?
> > ("mini-SAD")
> > * *Codebase javadoc:* Do we have a policy for JavaDoc'ing the
> > Model/API/SPI but perhaps not the implementation classes, other than
> > with implementation details?
> > * *Configuration:* Some of the descriptions in the docbook are really
> > good, and some are more shallow. If we create a standard way of
> > configuring the parts of keycloak, we could likely generate standard
> > setup/configuration documentation (somewhat similar to maven plugins
> > where certain parts of a site documentation is generated from
> > annotations or JavaDocs). Are there such plans?
> > 
> > 
> > --
> > 
> > --
> > +==============================+
> > | B?sta h?lsningar,
> > | [sw. "Best regards"]
> > | 
> > | Lennart J?relid
> > | EAI Architect & Integrator
> > | 
> > | jGuru Europe AB
> > | M?lnlycke - Kista
> > | 
> > | Email:lj at jguru.se <mailto: lj at jguru.se >
> > | URL: www.jguru.se < http://www.jguru.se >
> > | Phone
> > | (skype): jgurueurope
> > | (intl): +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
> > 
> > 
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> --
> +==============================+
> | B?sta h?lsningar,
> | [sw. "Best regards"]
> |
> | Lennart J?relid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | M?lnlycke - Kista
> |
> | Email: lj at jguru.se | URL: www.jguru.se | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From lennart.jorelid at gmail.com  Mon Aug 10 03:43:55 2015
From: lennart.jorelid at gmail.com (=?UTF-8?Q?Lennart_J=C3=B6relid?=)
Date: Mon, 10 Aug 2015 09:43:55 +0200
Subject: [keycloak-dev] Fwd: Concept structure in the VCS?
In-Reply-To: <1215050410.7609751.1439189814266.JavaMail.zimbra@redhat.com>
References: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>
	<55C770FE.3090909@redhat.com>
	<CAJ1fz83k=Mrk1utmp4RAbWCYLBLMj21ihrj4oqZ_w2ESgKFVFA@mail.gmail.com>
	<CAJ1fz80ecbsjMnnKYDFOWFfOC+wZkzciiSS4onDa=DiWCKoX-Q@mail.gmail.com>
	<1215050410.7609751.1439189814266.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ1fz82MtR47nmwTJiKMrnw_=7q+R8ksCNX=KHocjaiXOua3vw@mail.gmail.com>

Hello Stian,

I believe it is a bit of both; documentation can assist to a certain degree
but the codebase holds the

I find it considerably simpler to make a concept (read "themes", "roles",
"workflow") usable if its implementation is somewhat centered in a module,
potentially with several subprojects. I was planning to use KeyCloak as an
OOTB solution, but found it simpler to dig into the codebase to see how
things are implemented to get it going. I can elaborate - if you wish - in
another email (private or to the list).

... and while digging into the codebase, I found some things that I wanted
to share and possibly contribute, partly because I found it somewhat
difficult to understand how the configuration related to the file system.
Also, some best practises were not touched upon in documentation or
examples - and while that is understandable considering that KeyCloak is a
project, I figured I could perhaps submit a suggestion [in the form of a
GitHub pull request] for simplifying somewhat.


2015-08-10 8:56 GMT+02:00 Stian Thorgersen <stian at redhat.com>:

> Is the main issue here that "import" can be a list in theme.properties? If
> so that's really a documentation issue, not organization of code-base.
>
> BTW Keycloak is an OOTB solution so you should refer to documentation and
> examples (I know it's lacking in some places) not the code base. We are
> targeting non-Java developers and others that just wants something that
> works without coding. For extending/customization of Keycloak we plan to
> improve on documentation and clean-up Java APIs that are public.
>
> ----- Original Message -----
> > From: "Lennart J?relid" <lennart.jorelid at gmail.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Sunday, 9 August, 2015 7:00:59 PM
> > Subject: [keycloak-dev] Fwd:  Concept structure in the VCS?
> >
> > Ah - by mistake, I replied only to Bill. Cross-posting to the list as
> well.
> > Sorry for the spam.
> >
> > ======
> >
> > Hello there,
> >
> > First - I found the current screencasts massively helpful in getting
> started,
> > to be honest. They are something I really have not seen in most projects,
> > and they contributed a lot to me making sense of the Keycloak codebase
> and
> > usage scenarios. Kudos.
> >
> > Sedond - I think it would be quite helpful to add additional
> modularization
> > and also harmonize some configuration to make it more evident in how it
> is
> > interpreted. Let me clarify the last bit here (I'll take themes as an
> > example, but I believe that the same conclusion stands for other parts of
> > the Keycloak codebase):
> >
> > # Import and extend definitions
> > parent = base
> > import = common/keycloak
> > styles = lib/patternfly/css/patternfly.css lib/zocial/zocial.css
> > stylesheets/login.css stylesheets/yourOwn.css
> >
> >
> >     1. The documentation and examples provides something roughly similar
> to
> >     the above.
> >     2. Turning the attention to the "import" parameter, one could jump
> to the
> >     conclusion that there would be directory called "common/keycloak" and
> >     that this directory should contain a lib directory containing the
> styles
> >     css documents from the "styles" configuration.
> >     3. Reading the codebase, it seems that the semantics of the "import"
> >     property is something completetly different. From the
> >     ExtendingThemeManager::loadTheme, I can see that the '/' is instead
> used
> >     as a list separator implying that we should attempt loading resources
> >     from several sources. (Snippet pasted below).
> >
> > if (theme.getImportName() != null ) {
> > String[] s = theme.getImportName().split( "/" );
> > themes.add(findTheme(s[ 1 ], Theme.Type. valueOf (s[ 0
> ].toUpperCase())));
> > }
> > So ... I would believe that the configuration in this case would be
> clearer
> > on a Java Object, JSON or XML form, where one can provide somewhat better
> > semantics than what is possible in a properties file (one could use a
> List
> > of theme names instead of a single string value to be parsed and
> > interpreted, for example).
> >
> > Mind if I take a stab at implementing a suggestion here?
> >
> >
> > 2015-08-09 17:25 GMT+02:00 Bill Burke < bburke at redhat.com > :
> >
> >
> > Only plans right now are to separate our public SPIs and APIs from our
> > private ones. This is a requirement by Red hat before we go into product.
> >
> > Also, a massive backlog of requirements and feature requests has made us
> > rush documentation. The screencast videos haven't been updated since
> > January. It is what it is. Over the next 3-6 months we will catch up
> > on this stuff becuase we are required to before we go into Product.
> >
> > FYI, we already autogenerate REST docs.
> >
> > On 8/9/2015 7:38 AM, Lennart J?relid wrote:
> > > Hello all,
> > >
> > > A month or so ago, I got curious about Keycloak. Downloaded, set up in
> a
> > > dev environment, created some custom themes and took a look at the
> > > codebase. I have a few questions, likely because I have missed some
> > > developer documentation:
> > >
> > > * *Codebase concepts*: I frequently try to structure codebases to
> > > highlight its big concepts. For example, if we consider 'themes' to
> > > be such a concept in KeyCloak we might create a folder called
> > > 'themes", with some project wihtin it: (themes-model, themes-spi,
> > > themes-impl-jpa, themes-impl-freemarker, ....). Is there a
> > > description of the codebase structure or concepts currently?
> > > ("mini-SAD")
> > > * *Codebase javadoc:* Do we have a policy for JavaDoc'ing the
> > > Model/API/SPI but perhaps not the implementation classes, other than
> > > with implementation details?
> > > * *Configuration:* Some of the descriptions in the docbook are really
> > > good, and some are more shallow. If we create a standard way of
> > > configuring the parts of keycloak, we could likely generate standard
> > > setup/configuration documentation (somewhat similar to maven plugins
> > > where certain parts of a site documentation is generated from
> > > annotations or JavaDocs). Are there such plans?
> > >
> > >
> > > --
> > >
> > > --
> > > +==============================+
> > > | B?sta h?lsningar,
> > > | [sw. "Best regards"]
> > > |
> > > | Lennart J?relid
> > > | EAI Architect & Integrator
> > > |
> > > | jGuru Europe AB
> > > | M?lnlycke - Kista
> > > |
> > > | Email:lj at jguru.se <mailto: lj at jguru.se >
> > > | URL: www.jguru.se < http://www.jguru.se >
> > > | Phone
> > > | (skype): jgurueurope
> > > | (intl): +46 708 507 603
> > > | (domestic): 0708 - 507 603
> > > +==============================+
> > >
> > >
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > --
> > --
> > +==============================+
> > | B?sta h?lsningar,
> > | [sw. "Best regards"]
> > |
> > | Lennart J?relid
> > | EAI Architect & Integrator
> > |
> > | jGuru Europe AB
> > | M?lnlycke - Kista
> > |
> > | Email: lj at jguru.se | URL: www.jguru.se | Phone
> > | (skype):    jgurueurope
> > | (intl):     +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

--
+==============================+
| B?sta h?lsningar,
| [sw. "Best regards"]
|
| Lennart J?relid
| EAI Architect & Integrator
|
| jGuru Europe AB
| M?lnlycke - Kista
|
| Email: lj at jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150810/10222aed/attachment.html 

From stian at redhat.com  Mon Aug 10 04:04:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 10 Aug 2015 04:04:54 -0400 (EDT)
Subject: [keycloak-dev] Fwd: Concept structure in the VCS?
In-Reply-To: <CAJ1fz82MtR47nmwTJiKMrnw_=7q+R8ksCNX=KHocjaiXOua3vw@mail.gmail.com>
References: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>
	<55C770FE.3090909@redhat.com>
	<CAJ1fz83k=Mrk1utmp4RAbWCYLBLMj21ihrj4oqZ_w2ESgKFVFA@mail.gmail.com>
	<CAJ1fz80ecbsjMnnKYDFOWFfOC+wZkzciiSS4onDa=DiWCKoX-Q@mail.gmail.com>
	<1215050410.7609751.1439189814266.JavaMail.zimbra@redhat.com>
	<CAJ1fz82MtR47nmwTJiKMrnw_=7q+R8ksCNX=KHocjaiXOua3vw@mail.gmail.com>
Message-ID: <683092781.7641615.1439193894687.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Lennart J?relid" <lennart.jorelid at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 10 August, 2015 9:43:55 AM
> Subject: Re: [keycloak-dev] Fwd: Concept structure in the VCS?
> 
> Hello Stian,
> 
> I believe it is a bit of both; documentation can assist to a certain degree
> but the codebase holds the
> 
> I find it considerably simpler to make a concept (read "themes", "roles",
> "workflow") usable if its implementation is somewhat centered in a module,
> potentially with several subprojects. I was planning to use KeyCloak as an
> OOTB solution, but found it simpler to dig into the codebase to see how
> things are implemented to get it going. I can elaborate - if you wish - in
> another email (private or to the list).

The code base is already centered as modules, but we'll probably change things somewhat to make public api/spis stand out more. We won't document or add Javadoc to any parts of the code base that aren't public api/spis.

> 
> ... and while digging into the codebase, I found some things that I wanted
> to share and possibly contribute, partly because I found it somewhat
> difficult to understand how the configuration related to the file system.
> Also, some best practises were not touched upon in documentation or
> examples - and while that is understandable considering that KeyCloak is a
> project, I figured I could perhaps submit a suggestion [in the form of a
> GitHub pull request] for simplifying somewhat.

Sure - I'd welcome improvements, but please write an email top keycloak-dev mailing list outlining each improvement before working on a PR. Refactoring of the code should be done with great consideration as it makes life hard for existing developers and contributors when things change.

> 
> 
> 2015-08-10 8:56 GMT+02:00 Stian Thorgersen <stian at redhat.com>:
> 
> > Is the main issue here that "import" can be a list in theme.properties? If
> > so that's really a documentation issue, not organization of code-base.
> >
> > BTW Keycloak is an OOTB solution so you should refer to documentation and
> > examples (I know it's lacking in some places) not the code base. We are
> > targeting non-Java developers and others that just wants something that
> > works without coding. For extending/customization of Keycloak we plan to
> > improve on documentation and clean-up Java APIs that are public.
> >
> > ----- Original Message -----
> > > From: "Lennart J?relid" <lennart.jorelid at gmail.com>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Sunday, 9 August, 2015 7:00:59 PM
> > > Subject: [keycloak-dev] Fwd:  Concept structure in the VCS?
> > >
> > > Ah - by mistake, I replied only to Bill. Cross-posting to the list as
> > well.
> > > Sorry for the spam.
> > >
> > > ======
> > >
> > > Hello there,
> > >
> > > First - I found the current screencasts massively helpful in getting
> > started,
> > > to be honest. They are something I really have not seen in most projects,
> > > and they contributed a lot to me making sense of the Keycloak codebase
> > and
> > > usage scenarios. Kudos.
> > >
> > > Sedond - I think it would be quite helpful to add additional
> > modularization
> > > and also harmonize some configuration to make it more evident in how it
> > is
> > > interpreted. Let me clarify the last bit here (I'll take themes as an
> > > example, but I believe that the same conclusion stands for other parts of
> > > the Keycloak codebase):
> > >
> > > # Import and extend definitions
> > > parent = base
> > > import = common/keycloak
> > > styles = lib/patternfly/css/patternfly.css lib/zocial/zocial.css
> > > stylesheets/login.css stylesheets/yourOwn.css
> > >
> > >
> > >     1. The documentation and examples provides something roughly similar
> > to
> > >     the above.
> > >     2. Turning the attention to the "import" parameter, one could jump
> > to the
> > >     conclusion that there would be directory called "common/keycloak" and
> > >     that this directory should contain a lib directory containing the
> > styles
> > >     css documents from the "styles" configuration.
> > >     3. Reading the codebase, it seems that the semantics of the "import"
> > >     property is something completetly different. From the
> > >     ExtendingThemeManager::loadTheme, I can see that the '/' is instead
> > used
> > >     as a list separator implying that we should attempt loading resources
> > >     from several sources. (Snippet pasted below).
> > >
> > > if (theme.getImportName() != null ) {
> > > String[] s = theme.getImportName().split( "/" );
> > > themes.add(findTheme(s[ 1 ], Theme.Type. valueOf (s[ 0
> > ].toUpperCase())));
> > > }
> > > So ... I would believe that the configuration in this case would be
> > clearer
> > > on a Java Object, JSON or XML form, where one can provide somewhat better
> > > semantics than what is possible in a properties file (one could use a
> > List
> > > of theme names instead of a single string value to be parsed and
> > > interpreted, for example).
> > >
> > > Mind if I take a stab at implementing a suggestion here?
> > >
> > >
> > > 2015-08-09 17:25 GMT+02:00 Bill Burke < bburke at redhat.com > :
> > >
> > >
> > > Only plans right now are to separate our public SPIs and APIs from our
> > > private ones. This is a requirement by Red hat before we go into product.
> > >
> > > Also, a massive backlog of requirements and feature requests has made us
> > > rush documentation. The screencast videos haven't been updated since
> > > January. It is what it is. Over the next 3-6 months we will catch up
> > > on this stuff becuase we are required to before we go into Product.
> > >
> > > FYI, we already autogenerate REST docs.
> > >
> > > On 8/9/2015 7:38 AM, Lennart J?relid wrote:
> > > > Hello all,
> > > >
> > > > A month or so ago, I got curious about Keycloak. Downloaded, set up in
> > a
> > > > dev environment, created some custom themes and took a look at the
> > > > codebase. I have a few questions, likely because I have missed some
> > > > developer documentation:
> > > >
> > > > * *Codebase concepts*: I frequently try to structure codebases to
> > > > highlight its big concepts. For example, if we consider 'themes' to
> > > > be such a concept in KeyCloak we might create a folder called
> > > > 'themes", with some project wihtin it: (themes-model, themes-spi,
> > > > themes-impl-jpa, themes-impl-freemarker, ....). Is there a
> > > > description of the codebase structure or concepts currently?
> > > > ("mini-SAD")
> > > > * *Codebase javadoc:* Do we have a policy for JavaDoc'ing the
> > > > Model/API/SPI but perhaps not the implementation classes, other than
> > > > with implementation details?
> > > > * *Configuration:* Some of the descriptions in the docbook are really
> > > > good, and some are more shallow. If we create a standard way of
> > > > configuring the parts of keycloak, we could likely generate standard
> > > > setup/configuration documentation (somewhat similar to maven plugins
> > > > where certain parts of a site documentation is generated from
> > > > annotations or JavaDocs). Are there such plans?
> > > >
> > > >
> > > > --
> > > >
> > > > --
> > > > +==============================+
> > > > | B?sta h?lsningar,
> > > > | [sw. "Best regards"]
> > > > |
> > > > | Lennart J?relid
> > > > | EAI Architect & Integrator
> > > > |
> > > > | jGuru Europe AB
> > > > | M?lnlycke - Kista
> > > > |
> > > > | Email:lj at jguru.se <mailto: lj at jguru.se >
> > > > | URL: www.jguru.se < http://www.jguru.se >
> > > > | Phone
> > > > | (skype): jgurueurope
> > > > | (intl): +46 708 507 603
> > > > | (domestic): 0708 - 507 603
> > > > +==============================+
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > >
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > > --
> > > --
> > > +==============================+
> > > | B?sta h?lsningar,
> > > | [sw. "Best regards"]
> > > |
> > > | Lennart J?relid
> > > | EAI Architect & Integrator
> > > |
> > > | jGuru Europe AB
> > > | M?lnlycke - Kista
> > > |
> > > | Email: lj at jguru.se | URL: www.jguru.se | Phone
> > > | (skype):    jgurueurope
> > > | (intl):     +46 708 507 603
> > > | (domestic): 0708 - 507 603
> > > +==============================+
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> 
> 
> --
> 
> --
> +==============================+
> | B?sta h?lsningar,
> | [sw. "Best regards"]
> |
> | Lennart J?relid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | M?lnlycke - Kista
> |
> | Email: lj at jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
> 


From lennart.jorelid at gmail.com  Mon Aug 10 05:57:34 2015
From: lennart.jorelid at gmail.com (=?UTF-8?Q?Lennart_J=C3=B6relid?=)
Date: Mon, 10 Aug 2015 11:57:34 +0200
Subject: [keycloak-dev] Fwd: Concept structure in the VCS?
In-Reply-To: <683092781.7641615.1439193894687.JavaMail.zimbra@redhat.com>
References: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>
	<55C770FE.3090909@redhat.com>
	<CAJ1fz83k=Mrk1utmp4RAbWCYLBLMj21ihrj4oqZ_w2ESgKFVFA@mail.gmail.com>
	<CAJ1fz80ecbsjMnnKYDFOWFfOC+wZkzciiSS4onDa=DiWCKoX-Q@mail.gmail.com>
	<1215050410.7609751.1439189814266.JavaMail.zimbra@redhat.com>
	<CAJ1fz82MtR47nmwTJiKMrnw_=7q+R8ksCNX=KHocjaiXOua3vw@mail.gmail.com>
	<683092781.7641615.1439193894687.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ1fz82OjOhct2Rn82NkBDXbo9bZrZSDks4JvzpBnMHo5n4VFw@mail.gmail.com>

Hello there,

2015-08-10 10:04 GMT+02:00 Stian Thorgersen <stian at redhat.com>:

>
> The code base is already centered as modules, but we'll probably change
> things somewhat to make public api/spis stand out more. We won't document
> or add Javadoc to any parts of the code base that aren't public api/spis.
>

I believe that some implementation details which carry over into the
model/configuration domain (i.e. semantics of configuration or
implementation details) should likely be documented for clarity - even if
they are not part of APIs or SPIs. However, I can appreciate that these
types of changes or documentation have less priority than other tasks. We
all work in some kind of sprint context where priorities have to be made.

:)

> ... and while digging into the codebase, I found some things that I wanted
> > to share and possibly contribute, partly because I found it somewhat
> > difficult to understand how the configuration related to the file system.
> > Also, some best practises were not touched upon in documentation or
> > examples - and while that is understandable considering that KeyCloak is
> a
> > project, I figured I could perhaps submit a suggestion [in the form of a
> > GitHub pull request] for simplifying somewhat.
>
> Sure - I'd welcome improvements, but please write an email top
> keycloak-dev mailing list outlining each improvement before working on a
> PR. Refactoring of the code should be done with great consideration as it
> makes life hard for existing developers and contributors when things change.
>

I agree; it is important that changes constitute improvements overall.

I'll ponder, create a JIRA issue and do the changes in my private KeyCloak
fork - it can be discussed and dissected there rather than in the KeyCloak
standard repository.

-- 

--
+==============================+
| B?sta h?lsningar,
| [sw. "Best regards"]
|
| Lennart J?relid
| EAI Architect & Integrator
|
| jGuru Europe AB
| M?lnlycke - Kista
|
| Email: lj at jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150810/844c9e48/attachment.html 

From stian at redhat.com  Mon Aug 10 06:56:42 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 10 Aug 2015 06:56:42 -0400 (EDT)
Subject: [keycloak-dev] Fwd: Concept structure in the VCS?
In-Reply-To: <CAJ1fz82OjOhct2Rn82NkBDXbo9bZrZSDks4JvzpBnMHo5n4VFw@mail.gmail.com>
References: <CAJ1fz83cEVYkqT7Fhgbx3-P8Wi2e19g4=_cZvXvaVRMO_H3AJQ@mail.gmail.com>
	<55C770FE.3090909@redhat.com>
	<CAJ1fz83k=Mrk1utmp4RAbWCYLBLMj21ihrj4oqZ_w2ESgKFVFA@mail.gmail.com>
	<CAJ1fz80ecbsjMnnKYDFOWFfOC+wZkzciiSS4onDa=DiWCKoX-Q@mail.gmail.com>
	<1215050410.7609751.1439189814266.JavaMail.zimbra@redhat.com>
	<CAJ1fz82MtR47nmwTJiKMrnw_=7q+R8ksCNX=KHocjaiXOua3vw@mail.gmail.com>
	<683092781.7641615.1439193894687.JavaMail.zimbra@redhat.com>
	<CAJ1fz82OjOhct2Rn82NkBDXbo9bZrZSDks4JvzpBnMHo5n4VFw@mail.gmail.com>
Message-ID: <173427388.7786389.1439204202699.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Lennart J?relid" <lennart.jorelid at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 10 August, 2015 11:57:34 AM
> Subject: Re: [keycloak-dev] Fwd: Concept structure in the VCS?
> 
> Hello there,
> 
> 2015-08-10 10:04 GMT+02:00 Stian Thorgersen <stian at redhat.com>:
> 
> >
> > The code base is already centered as modules, but we'll probably change
> > things somewhat to make public api/spis stand out more. We won't document
> > or add Javadoc to any parts of the code base that aren't public api/spis.
> >
> 
> I believe that some implementation details which carry over into the
> model/configuration domain (i.e. semantics of configuration or
> implementation details) should likely be documented for clarity - even if
> they are not part of APIs or SPIs. However, I can appreciate that these
> types of changes or documentation have less priority than other tasks. We
> all work in some kind of sprint context where priorities have to be made.

-1000 Implementation is documented in the form of code. JavaDoc and other types of documenting implementations are never maintained.

> 
> :)
> 
> > ... and while digging into the codebase, I found some things that I wanted
> > > to share and possibly contribute, partly because I found it somewhat
> > > difficult to understand how the configuration related to the file system.
> > > Also, some best practises were not touched upon in documentation or
> > > examples - and while that is understandable considering that KeyCloak is
> > a
> > > project, I figured I could perhaps submit a suggestion [in the form of a
> > > GitHub pull request] for simplifying somewhat.
> >
> > Sure - I'd welcome improvements, but please write an email top
> > keycloak-dev mailing list outlining each improvement before working on a
> > PR. Refactoring of the code should be done with great consideration as it
> > makes life hard for existing developers and contributors when things
> > change.
> >
> 
> I agree; it is important that changes constitute improvements overall.
> 
> I'll ponder, create a JIRA issue and do the changes in my private KeyCloak
> fork - it can be discussed and dissected there rather than in the KeyCloak
> standard repository.

Please discuss proposed changes on developer mailing list first.

> 
> --
> 
> --
> +==============================+
> | B?sta h?lsningar,
> | [sw. "Best regards"]
> |
> | Lennart J?relid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | M?lnlycke - Kista
> |
> | Email: lj at jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
> 


From ssilvert at redhat.com  Mon Aug 10 13:45:28 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 10 Aug 2015 13:45:28 -0400
Subject: [keycloak-dev] Evaluation of i18n/i10n tools
Message-ID: <55C8E338.1010104@redhat.com>

I've been evaluating tools to help us localize Keycloak.  The tools I 
looked at were angular-translate, angular-localization, and 
angular-gettext.  All use the MIT license.

I took a static version of our login page and localized with 
angular-translate.  Then I did the same thing using 
angular-localization.  Both worked well and it was pretty cool to see 
the language change between English and French with the click of a 
button.  Both use ordinary JSON files for the translations.

In doing this, I was able to explore the features, strengths, and 
weaknesses of each library.  Of the two, I prefer angular-translate.  
The reason mostly has to do with a greater feature set, maturity, and a 
larger community.  I can go into much greater detail if anyone is 
interested.

For angular-gettext, it seems to be somewhat popular, but it takes a 
very different approach.  I'm rejecting it based on the fact that it 
relies a great deal on tools and automation.  I don't think that 
translators and developers want to learn new tools and a new file format 
for the translations (.po files vs. JSON).  Plus, angular-gettext 
automatically uses the English version of the word or phrase to generate 
keys in the .po files.  The whole process looks error-prone.

If you have any experience using these or other packages please let me 
know.  In researching this topic, I've found that some people even roll 
their own angular translation tools.  So let me know if you have 
experience with that as well.

Stan

From bburke at redhat.com  Mon Aug 10 13:55:42 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 10 Aug 2015 13:55:42 -0400
Subject: [keycloak-dev] Evaluation of i18n/i10n tools
In-Reply-To: <55C8E338.1010104@redhat.com>
References: <55C8E338.1010104@redhat.com>
Message-ID: <55C8E59E.6050300@redhat.com>

Our translation team is used to message bundles/property files.  Don't 
know if that is an issue or not.

On 8/10/2015 1:45 PM, Stan Silvert wrote:
> I've been evaluating tools to help us localize Keycloak.  The tools I
> looked at were angular-translate, angular-localization, and
> angular-gettext.  All use the MIT license.
>
> I took a static version of our login page and localized with
> angular-translate.  Then I did the same thing using
> angular-localization.  Both worked well and it was pretty cool to see
> the language change between English and French with the click of a
> button.  Both use ordinary JSON files for the translations.
>
> In doing this, I was able to explore the features, strengths, and
> weaknesses of each library.  Of the two, I prefer angular-translate.
> The reason mostly has to do with a greater feature set, maturity, and a
> larger community.  I can go into much greater detail if anyone is
> interested.
>
> For angular-gettext, it seems to be somewhat popular, but it takes a
> very different approach.  I'm rejecting it based on the fact that it
> relies a great deal on tools and automation.  I don't think that
> translators and developers want to learn new tools and a new file format
> for the translations (.po files vs. JSON).  Plus, angular-gettext
> automatically uses the English version of the word or phrase to generate
> keys in the .po files.  The whole process looks error-prone.
>
> If you have any experience using these or other packages please let me
> know.  In researching this topic, I've found that some people even roll
> their own angular translation tools.  So let me know if you have
> experience with that as well.
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From ssilvert at redhat.com  Mon Aug 10 16:25:39 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 10 Aug 2015 16:25:39 -0400
Subject: [keycloak-dev] Evaluation of i18n/i10n tools
In-Reply-To: <55C8E59E.6050300@redhat.com>
References: <55C8E338.1010104@redhat.com> <55C8E59E.6050300@redhat.com>
Message-ID: <55C908C3.3020304@redhat.com>

On 8/10/2015 1:55 PM, Bill Burke wrote:
> Our translation team is used to message bundles/property files.  Don't
> know if that is an issue or not.
We would use message bundles/property files if we did i18n/l10n on the 
server side with Java and Freemarker.  It's a possibility.

The default way Freemarker solves the problem is to have you create 
localized versions of each template.  So there would be lots of 
duplication and a maintenance nightmare.  According to [1], you would 
have login_en.ftl, login_fr.ftl, login_es.ftl, etc.   So you've just 
multiplied the number of template files by the number of languages 
supported.

Another approach using Freemarker would be to use Freemarker itself as a 
localization tool.  Then you only need a single template for all 
languages and you use Freemarker and Java to do the substitutions.  But 
it looks like this solution gets complicated very quickly[2][3].

That being said, I'm not very familiar with Freemarker.  If you guys 
think I should look into a server-side solution let me know and I'll 
give it a try.

[1] 
http://freemarker.org/docs/ref_directive_include.html#ref_directive_include_localized
[2] http://sourceforge.net/p/freemarker/discussion/2346/thread/5a29eee0/
[3] http://mnmlst-dvlpr.blogspot.com/2012/06/know-your-library-i18n.html
>
> On 8/10/2015 1:45 PM, Stan Silvert wrote:
>> I've been evaluating tools to help us localize Keycloak.  The tools I
>> looked at were angular-translate, angular-localization, and
>> angular-gettext.  All use the MIT license.
>>
>> I took a static version of our login page and localized with
>> angular-translate.  Then I did the same thing using
>> angular-localization.  Both worked well and it was pretty cool to see
>> the language change between English and French with the click of a
>> button.  Both use ordinary JSON files for the translations.
>>
>> In doing this, I was able to explore the features, strengths, and
>> weaknesses of each library.  Of the two, I prefer angular-translate.
>> The reason mostly has to do with a greater feature set, maturity, and a
>> larger community.  I can go into much greater detail if anyone is
>> interested.
>>
>> For angular-gettext, it seems to be somewhat popular, but it takes a
>> very different approach.  I'm rejecting it based on the fact that it
>> relies a great deal on tools and automation.  I don't think that
>> translators and developers want to learn new tools and a new file format
>> for the translations (.po files vs. JSON).  Plus, angular-gettext
>> automatically uses the English version of the word or phrase to generate
>> keys in the .po files.  The whole process looks error-prone.
>>
>> If you have any experience using these or other packages please let me
>> know.  In researching this topic, I've found that some people even roll
>> their own angular translation tools.  So let me know if you have
>> experience with that as well.
>>
>> Stan
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Tue Aug 11 01:31:21 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 11 Aug 2015 01:31:21 -0400 (EDT)
Subject: [keycloak-dev] Evaluation of i18n/i10n tools
In-Reply-To: <55C908C3.3020304@redhat.com>
References: <55C8E338.1010104@redhat.com> <55C8E59E.6050300@redhat.com>
	<55C908C3.3020304@redhat.com>
Message-ID: <425902089.8484553.1439271081474.JavaMail.zimbra@redhat.com>

-1000 To using FreeMarker for this - we don't want all pages to be templated

If you prefer angular-translate I'd go for that. With regards to messages I'd have the bundles as regular message bundles on the file system, but have an endpoint on the admin console that exposes it as json.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 10 August, 2015 10:25:39 PM
> Subject: Re: [keycloak-dev] Evaluation of i18n/i10n tools
> 
> On 8/10/2015 1:55 PM, Bill Burke wrote:
> > Our translation team is used to message bundles/property files.  Don't
> > know if that is an issue or not.
> We would use message bundles/property files if we did i18n/l10n on the
> server side with Java and Freemarker.  It's a possibility.
> 
> The default way Freemarker solves the problem is to have you create
> localized versions of each template.  So there would be lots of
> duplication and a maintenance nightmare.  According to [1], you would
> have login_en.ftl, login_fr.ftl, login_es.ftl, etc.   So you've just
> multiplied the number of template files by the number of languages
> supported.
> 
> Another approach using Freemarker would be to use Freemarker itself as a
> localization tool.  Then you only need a single template for all
> languages and you use Freemarker and Java to do the substitutions.  But
> it looks like this solution gets complicated very quickly[2][3].
> 
> That being said, I'm not very familiar with Freemarker.  If you guys
> think I should look into a server-side solution let me know and I'll
> give it a try.
> 
> [1]
> http://freemarker.org/docs/ref_directive_include.html#ref_directive_include_localized
> [2] http://sourceforge.net/p/freemarker/discussion/2346/thread/5a29eee0/
> [3] http://mnmlst-dvlpr.blogspot.com/2012/06/know-your-library-i18n.html
> >
> > On 8/10/2015 1:45 PM, Stan Silvert wrote:
> >> I've been evaluating tools to help us localize Keycloak.  The tools I
> >> looked at were angular-translate, angular-localization, and
> >> angular-gettext.  All use the MIT license.
> >>
> >> I took a static version of our login page and localized with
> >> angular-translate.  Then I did the same thing using
> >> angular-localization.  Both worked well and it was pretty cool to see
> >> the language change between English and French with the click of a
> >> button.  Both use ordinary JSON files for the translations.
> >>
> >> In doing this, I was able to explore the features, strengths, and
> >> weaknesses of each library.  Of the two, I prefer angular-translate.
> >> The reason mostly has to do with a greater feature set, maturity, and a
> >> larger community.  I can go into much greater detail if anyone is
> >> interested.
> >>
> >> For angular-gettext, it seems to be somewhat popular, but it takes a
> >> very different approach.  I'm rejecting it based on the fact that it
> >> relies a great deal on tools and automation.  I don't think that
> >> translators and developers want to learn new tools and a new file format
> >> for the translations (.po files vs. JSON).  Plus, angular-gettext
> >> automatically uses the English version of the word or phrase to generate
> >> keys in the .po files.  The whole process looks error-prone.
> >>
> >> If you have any experience using these or other packages please let me
> >> know.  In researching this topic, I've found that some people even roll
> >> their own angular translation tools.  So let me know if you have
> >> experience with that as well.
> >>
> >> Stan
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.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 Aug 11 04:55:09 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 11 Aug 2015 10:55:09 +0200
Subject: [keycloak-dev] Keep client private keys in Keycloak DB?
Message-ID: <55C9B86D.3030804@redhat.com>

For the client authentication with signed JWT, I am wondering if we 
should keep client private key in Keycloak DB?

TBH I am more keen to not keep the copies, but just the certificate with 
public key, so the private key is owned exclusively by client and saved 
just on client side. Looks better to me from security perspective and 
that's how Google is doing it - 
https://developers.google.com/identity/protocols/OAuth2ServiceAccount .

But now I notice that for the SAML clients, we keep the private keys in 
Keycloak DB (the private key for sign SAML requests or the private key, 
which client needs to verify SAML assertions encrypted by it's public 
key). Is it ok from the security perspective?

Marek

From stian at redhat.com  Tue Aug 11 05:26:01 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 11 Aug 2015 05:26:01 -0400 (EDT)
Subject: [keycloak-dev] Keep client private keys in Keycloak DB?
In-Reply-To: <55C9B86D.3030804@redhat.com>
References: <55C9B86D.3030804@redhat.com>
Message-ID: <1805667270.8579135.1439285161520.JavaMail.zimbra@redhat.com>


----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 11 August, 2015 10:55:09 AM
> Subject: [keycloak-dev] Keep client private keys in Keycloak DB?
> 
> For the client authentication with signed JWT, I am wondering if we
> should keep client private key in Keycloak DB?
> 
> TBH I am more keen to not keep the copies, but just the certificate with
> public key, so the private key is owned exclusively by client and saved
> just on client side. Looks better to me from security perspective and
> that's how Google is doing it -
> https://developers.google.com/identity/protocols/OAuth2ServiceAccount .

+1 The private key shouldn't even be sent to the server

> 
> But now I notice that for the SAML clients, we keep the private keys in
> Keycloak DB (the private key for sign SAML requests or the private key,
> which client needs to verify SAML assertions encrypted by it's public
> key). Is it ok from the security perspective?

Do we need the private keys for SAML clients? If not my vote is that we do the same as what you suggest above for openid

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

From mposolda at redhat.com  Tue Aug 11 06:48:16 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 11 Aug 2015 12:48:16 +0200
Subject: [keycloak-dev] Keep client private keys in Keycloak DB?
In-Reply-To: <1805667270.8579135.1439285161520.JavaMail.zimbra@redhat.com>
References: <55C9B86D.3030804@redhat.com>
	<1805667270.8579135.1439285161520.JavaMail.zimbra@redhat.com>
Message-ID: <55C9D2F0.40104@redhat.com>

On 11.8.2015 11:26, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 11 August, 2015 10:55:09 AM
>> Subject: [keycloak-dev] Keep client private keys in Keycloak DB?
>>
>> For the client authentication with signed JWT, I am wondering if we
>> should keep client private key in Keycloak DB?
>>
>> TBH I am more keen to not keep the copies, but just the certificate with
>> public key, so the private key is owned exclusively by client and saved
>> just on client side. Looks better to me from security perspective and
>> that's how Google is doing it -
>> https://developers.google.com/identity/protocols/OAuth2ServiceAccount .
> +1 The private key shouldn't even be sent to the server
>
>> But now I notice that for the SAML clients, we keep the private keys in
>> Keycloak DB (the private key for sign SAML requests or the private key,
>> which client needs to verify SAML assertions encrypted by it's public
>> key). Is it ok from the security perspective?
> Do we need the private keys for SAML clients? If not my vote is that we do the same as what you suggest above for openid
I think not (Bill can correct me ). For SAML, there are 2 usecases when 
private key is needed just by client and server needs just 
certificate+publicKey:
1) SAMLRequest is signed by client and keycloak needs to verify it with 
the client public key
2) SAML Assertion is signed by Keycloak by client public key, so client 
can decrypt by it's private key

Actually you can either generate keys by Keycloak or import the 
certificate for SAML client. If you just upload the certificate, the 
private key is not stored on Keycloak side, that looks ok to me. But if 
you generate them, keycloak stores private key in DB and you can later 
export it to keystore (JKS or PKCS12).

For signed JWT, I would like to support generate public/private keypair 
by Keycloak as well, but not store the private key in DB. So key will be 
generated and downloaded in same request and client will just have 
possibility to choose the format (JKS, PKCS12 or PEM text)

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


From stian at redhat.com  Tue Aug 11 07:19:51 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 11 Aug 2015 07:19:51 -0400 (EDT)
Subject: [keycloak-dev] Keep client private keys in Keycloak DB?
In-Reply-To: <55C9D2F0.40104@redhat.com>
References: <55C9B86D.3030804@redhat.com>
	<1805667270.8579135.1439285161520.JavaMail.zimbra@redhat.com>
	<55C9D2F0.40104@redhat.com>
Message-ID: <1368292099.8623649.1439291991674.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 11 August, 2015 12:48:16 PM
> Subject: Re: [keycloak-dev] Keep client private keys in Keycloak DB?
> 
> On 11.8.2015 11:26, Stian Thorgersen wrote:
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 11 August, 2015 10:55:09 AM
> >> Subject: [keycloak-dev] Keep client private keys in Keycloak DB?
> >>
> >> For the client authentication with signed JWT, I am wondering if we
> >> should keep client private key in Keycloak DB?
> >>
> >> TBH I am more keen to not keep the copies, but just the certificate with
> >> public key, so the private key is owned exclusively by client and saved
> >> just on client side. Looks better to me from security perspective and
> >> that's how Google is doing it -
> >> https://developers.google.com/identity/protocols/OAuth2ServiceAccount .
> > +1 The private key shouldn't even be sent to the server
> >
> >> But now I notice that for the SAML clients, we keep the private keys in
> >> Keycloak DB (the private key for sign SAML requests or the private key,
> >> which client needs to verify SAML assertions encrypted by it's public
> >> key). Is it ok from the security perspective?
> > Do we need the private keys for SAML clients? If not my vote is that we do
> > the same as what you suggest above for openid
> I think not (Bill can correct me ). For SAML, there are 2 usecases when
> private key is needed just by client and server needs just
> certificate+publicKey:
> 1) SAMLRequest is signed by client and keycloak needs to verify it with
> the client public key
> 2) SAML Assertion is signed by Keycloak by client public key, so client
> can decrypt by it's private key
> 
> Actually you can either generate keys by Keycloak or import the
> certificate for SAML client. If you just upload the certificate, the
> private key is not stored on Keycloak side, that looks ok to me. But if
> you generate them, keycloak stores private key in DB and you can later
> export it to keystore (JKS or PKCS12).
> 
> For signed JWT, I would like to support generate public/private keypair
> by Keycloak as well, but not store the private key in DB. So key will be
> generated and downloaded in same request and client will just have
> possibility to choose the format (JKS, PKCS12 or PEM text)

+1 If someone has lost the private key, they should generate a new one, not fetch the old one from KC

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

From ssilvert at redhat.com  Tue Aug 11 07:53:01 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 11 Aug 2015 07:53:01 -0400
Subject: [keycloak-dev] Evaluation of i18n/i10n tools
In-Reply-To: <425902089.8484553.1439271081474.JavaMail.zimbra@redhat.com>
References: <55C8E338.1010104@redhat.com> <55C8E59E.6050300@redhat.com>
	<55C908C3.3020304@redhat.com>
	<425902089.8484553.1439271081474.JavaMail.zimbra@redhat.com>
Message-ID: <55C9E21D.8010103@redhat.com>

On 8/11/2015 1:31 AM, Stian Thorgersen wrote:
> -1000 To using FreeMarker for this - we don't want all pages to be templated
I thought we used FreeMarker for all pages?  What is currently not 
templated?
>
> If you prefer angular-translate I'd go for that. With regards to messages I'd have the bundles as regular message bundles on the file system, but have an endpoint on the admin console that exposes it as json.
You are saying to store them as property files then expose them as 
JSON?   Why not store them as JSON and expose them directly?
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 10 August, 2015 10:25:39 PM
>> Subject: Re: [keycloak-dev] Evaluation of i18n/i10n tools
>>
>> On 8/10/2015 1:55 PM, Bill Burke wrote:
>>> Our translation team is used to message bundles/property files.  Don't
>>> know if that is an issue or not.
>> We would use message bundles/property files if we did i18n/l10n on the
>> server side with Java and Freemarker.  It's a possibility.
>>
>> The default way Freemarker solves the problem is to have you create
>> localized versions of each template.  So there would be lots of
>> duplication and a maintenance nightmare.  According to [1], you would
>> have login_en.ftl, login_fr.ftl, login_es.ftl, etc.   So you've just
>> multiplied the number of template files by the number of languages
>> supported.
>>
>> Another approach using Freemarker would be to use Freemarker itself as a
>> localization tool.  Then you only need a single template for all
>> languages and you use Freemarker and Java to do the substitutions.  But
>> it looks like this solution gets complicated very quickly[2][3].
>>
>> That being said, I'm not very familiar with Freemarker.  If you guys
>> think I should look into a server-side solution let me know and I'll
>> give it a try.
>>
>> [1]
>> http://freemarker.org/docs/ref_directive_include.html#ref_directive_include_localized
>> [2] http://sourceforge.net/p/freemarker/discussion/2346/thread/5a29eee0/
>> [3] http://mnmlst-dvlpr.blogspot.com/2012/06/know-your-library-i18n.html
>>> On 8/10/2015 1:45 PM, Stan Silvert wrote:
>>>> I've been evaluating tools to help us localize Keycloak.  The tools I
>>>> looked at were angular-translate, angular-localization, and
>>>> angular-gettext.  All use the MIT license.
>>>>
>>>> I took a static version of our login page and localized with
>>>> angular-translate.  Then I did the same thing using
>>>> angular-localization.  Both worked well and it was pretty cool to see
>>>> the language change between English and French with the click of a
>>>> button.  Both use ordinary JSON files for the translations.
>>>>
>>>> In doing this, I was able to explore the features, strengths, and
>>>> weaknesses of each library.  Of the two, I prefer angular-translate.
>>>> The reason mostly has to do with a greater feature set, maturity, and a
>>>> larger community.  I can go into much greater detail if anyone is
>>>> interested.
>>>>
>>>> For angular-gettext, it seems to be somewhat popular, but it takes a
>>>> very different approach.  I'm rejecting it based on the fact that it
>>>> relies a great deal on tools and automation.  I don't think that
>>>> translators and developers want to learn new tools and a new file format
>>>> for the translations (.po files vs. JSON).  Plus, angular-gettext
>>>> automatically uses the English version of the word or phrase to generate
>>>> keys in the .po files.  The whole process looks error-prone.
>>>>
>>>> If you have any experience using these or other packages please let me
>>>> know.  In researching this topic, I've found that some people even roll
>>>> their own angular translation tools.  So let me know if you have
>>>> experience with that as well.
>>>>
>>>> Stan
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Tue Aug 11 08:02:27 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 11 Aug 2015 08:02:27 -0400 (EDT)
Subject: [keycloak-dev] Evaluation of i18n/i10n tools
In-Reply-To: <55C9E21D.8010103@redhat.com>
References: <55C8E338.1010104@redhat.com> <55C8E59E.6050300@redhat.com>
	<55C908C3.3020304@redhat.com>
	<425902089.8484553.1439271081474.JavaMail.zimbra@redhat.com>
	<55C9E21D.8010103@redhat.com>
Message-ID: <125733732.8669975.1439294547988.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 11 August, 2015 1:53:01 PM
> Subject: Re: [keycloak-dev] Evaluation of i18n/i10n tools
> 
> On 8/11/2015 1:31 AM, Stian Thorgersen wrote:
> > -1000 To using FreeMarker for this - we don't want all pages to be
> > templated
> I thought we used FreeMarker for all pages?  What is currently not
> templated?

No, admin pages are not FreeMarker templates. The only page that is templated is index.html which is templated to add the correct resource versions (css, js, etc..).

> >
> > If you prefer angular-translate I'd go for that. With regards to messages
> > I'd have the bundles as regular message bundles on the file system, but
> > have an endpoint on the admin console that exposes it as json.
> You are saying to store them as property files then expose them as
> JSON?   Why not store them as JSON and expose them directly?

Because we want all messages in the same format. Login and account management is already internationalized using standard message bundles. For now we'll have a separate message bundle for admin console, but in the future we should merge everything into a single message bundle. This makes it easier to do translations.

Besides a properties file (key=value) is easier to create than a json doc ({ "key" : "value" }). There's just no need to use json for a simple list of key->value.

> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 10 August, 2015 10:25:39 PM
> >> Subject: Re: [keycloak-dev] Evaluation of i18n/i10n tools
> >>
> >> On 8/10/2015 1:55 PM, Bill Burke wrote:
> >>> Our translation team is used to message bundles/property files.  Don't
> >>> know if that is an issue or not.
> >> We would use message bundles/property files if we did i18n/l10n on the
> >> server side with Java and Freemarker.  It's a possibility.
> >>
> >> The default way Freemarker solves the problem is to have you create
> >> localized versions of each template.  So there would be lots of
> >> duplication and a maintenance nightmare.  According to [1], you would
> >> have login_en.ftl, login_fr.ftl, login_es.ftl, etc.   So you've just
> >> multiplied the number of template files by the number of languages
> >> supported.
> >>
> >> Another approach using Freemarker would be to use Freemarker itself as a
> >> localization tool.  Then you only need a single template for all
> >> languages and you use Freemarker and Java to do the substitutions.  But
> >> it looks like this solution gets complicated very quickly[2][3].
> >>
> >> That being said, I'm not very familiar with Freemarker.  If you guys
> >> think I should look into a server-side solution let me know and I'll
> >> give it a try.
> >>
> >> [1]
> >> http://freemarker.org/docs/ref_directive_include.html#ref_directive_include_localized
> >> [2] http://sourceforge.net/p/freemarker/discussion/2346/thread/5a29eee0/
> >> [3] http://mnmlst-dvlpr.blogspot.com/2012/06/know-your-library-i18n.html
> >>> On 8/10/2015 1:45 PM, Stan Silvert wrote:
> >>>> I've been evaluating tools to help us localize Keycloak.  The tools I
> >>>> looked at were angular-translate, angular-localization, and
> >>>> angular-gettext.  All use the MIT license.
> >>>>
> >>>> I took a static version of our login page and localized with
> >>>> angular-translate.  Then I did the same thing using
> >>>> angular-localization.  Both worked well and it was pretty cool to see
> >>>> the language change between English and French with the click of a
> >>>> button.  Both use ordinary JSON files for the translations.
> >>>>
> >>>> In doing this, I was able to explore the features, strengths, and
> >>>> weaknesses of each library.  Of the two, I prefer angular-translate.
> >>>> The reason mostly has to do with a greater feature set, maturity, and a
> >>>> larger community.  I can go into much greater detail if anyone is
> >>>> interested.
> >>>>
> >>>> For angular-gettext, it seems to be somewhat popular, but it takes a
> >>>> very different approach.  I'm rejecting it based on the fact that it
> >>>> relies a great deal on tools and automation.  I don't think that
> >>>> translators and developers want to learn new tools and a new file format
> >>>> for the translations (.po files vs. JSON).  Plus, angular-gettext
> >>>> automatically uses the English version of the word or phrase to generate
> >>>> keys in the .po files.  The whole process looks error-prone.
> >>>>
> >>>> If you have any experience using these or other packages please let me
> >>>> know.  In researching this topic, I've found that some people even roll
> >>>> their own angular translation tools.  So let me know if you have
> >>>> experience with that as well.
> >>>>
> >>>> Stan
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From bburke at redhat.com  Wed Aug 12 08:50:49 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Aug 2015 08:50:49 -0400
Subject: [keycloak-dev] public/private api module structure
Message-ID: <55CB4129.5050009@redhat.com>

I was thinking we'd have a more course-grain module structure for public 
apis.  We have a crap load of SPIs and having a module for each of them 
is a pain for the user and us in creating/maintaining poms as well as 
creating maintaing JBoss modules.  Something like:

keycloak-core-api
keycloak-server-api
keycloak-client-api

and

keycloak-saml-api
keycloak-oidc-api

protocol APIs would be for the case where users need to access the raw 
SAML document or JWT.

These API modules would only contain public APIs and helper classes.  we 
can consolidate and/or separate internal implementation classes into any 
structure we want with the thought process being that we would organize 
these modules so that we have the option to remove features as needed to 
make a smaller distro.

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

From stian at redhat.com  Wed Aug 12 09:04:26 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Aug 2015 09:04:26 -0400 (EDT)
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <55CB4129.5050009@redhat.com>
References: <55CB4129.5050009@redhat.com>
Message-ID: <916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>

I'm not convinced..

We'd still have to have separate modules for implementations of an SPI, so it would only reduce the amount of modules somewhat. Besides how often do we create new SPIs?

For users I think having it separate is better as they can more easily see what classes are relevant to the provider they are implementing.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 August, 2015 2:50:49 PM
> Subject: [keycloak-dev] public/private api module structure
> 
> I was thinking we'd have a more course-grain module structure for public
> apis.  We have a crap load of SPIs and having a module for each of them
> is a pain for the user and us in creating/maintaining poms as well as
> creating maintaing JBoss modules.  Something like:
> 
> keycloak-core-api
> keycloak-server-api
> keycloak-client-api
> 
> and
> 
> keycloak-saml-api
> keycloak-oidc-api
> 
> protocol APIs would be for the case where users need to access the raw
> SAML document or JWT.
> 
> These API modules would only contain public APIs and helper classes.  we
> can consolidate and/or separate internal implementation classes into any
> structure we want with the thought process being that we would organize
> these modules so that we have the option to remove features as needed to
> make a smaller distro.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Wed Aug 12 09:38:31 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Aug 2015 09:38:31 -0400
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
Message-ID: <55CB4C57.2050301@redhat.com>

Users then have to figure out and know which modules/artifacts to 
import.  We have Authentication SPI, Event SPI, Model, Federation SPI, 
core API, LoginFormProvider SPI, and possibly Protocol Mapper SPI, 
Identity Broker Mapper SPI.  8 different modules/artifacts.  If we add 
the protocol mapper SPI, then we also need to include SAML and OIDC 
public APIs too.  Our total is 10 now.  Then we might eventually want to 
make our Login Protocol and Identity Broker SPI public, and add an SPI 
for Account extensions which would force us to add the 
AccoutnFormProvider SPI too.

That's potentially 14 different public modules.

Finally, it is a pain in the ass for us to add any new SPIs as we have 
to wade through all the wildfly module dependencies in the 3 different 
places they are defined.  We've been creating new SPIs at least once a 
month, sometimes more.

On 8/12/2015 9:04 AM, Stian Thorgersen wrote:
> I'm not convinced..
>
> We'd still have to have separate modules for implementations of an SPI, so it would only reduce the amount of modules somewhat. Besides how often do we create new SPIs?
>
> For users I think having it separate is better as they can more easily see what classes are relevant to the provider they are implementing.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 12 August, 2015 2:50:49 PM
>> Subject: [keycloak-dev] public/private api module structure
>>
>> I was thinking we'd have a more course-grain module structure for public
>> apis.  We have a crap load of SPIs and having a module for each of them
>> is a pain for the user and us in creating/maintaining poms as well as
>> creating maintaing JBoss modules.  Something like:
>>
>> keycloak-core-api
>> keycloak-server-api
>> keycloak-client-api
>>
>> and
>>
>> keycloak-saml-api
>> keycloak-oidc-api
>>
>> protocol APIs would be for the case where users need to access the raw
>> SAML document or JWT.
>>
>> These API modules would only contain public APIs and helper classes.  we
>> can consolidate and/or separate internal implementation classes into any
>> structure we want with the thought process being that we would organize
>> these modules so that we have the option to remove features as needed to
>> make a smaller distro.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bburke at redhat.com  Wed Aug 12 09:50:21 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Aug 2015 09:50:21 -0400
Subject: [keycloak-dev] Groups design
Message-ID: <55CB4F1D.3000909@redhat.com>

I would like to nail down what we want Groups to look like in Keycloak. 
  And also propose a separate RoleGroups structure.

GROUPS:

* Groups have an id, name, and description
* Groups have an arbitrary set of name/value pair attributes
* Realm/Client roles can be associated with a Group.  This is like a 
UserRoleMapping, except it is a GroupRoleMapping.
* Groups can be members of one or more groups
* Users can be members of one or more groups
* Users inherit attributes of the groups they belong to.
* UserModel now has a getGroups(), hasGroup(), grantGroup(), deleteGroup()
* Similar to default roles, we also have default groups.

Features we probably want:
* Groups can have a set of protocol Mappers organized by protocol.
* Clients inherit protocol Mappers from the groups a user belongs to.

Questions:
* Do we want to expand the concept of a Group so that clients and 
identity brokers can belong to a Group? Or just create a separate 
composite structure for this?


ROLEGROUPS:

RoleGroups are just a namespace for Roles.  I want to remove the concept 
of realm level and client level roles and just have the concept of a 
RoleGroup.  The reasoning for this is that I've seen people ask for it. 
  They want to share a set of roles between clients and realm-level 
roles might end up having name clashes, if you are following me.

* RoleGroups have an id, name and description.
* RoleGroups define a set of roles.
* Users are *NOT* members of RoleGroups
* For migration, a "realm" RoleGroup is created.  a RoleGroup for each 
client that has defined roles is created.  The name will be the clientId 
of the client.
* I want to deprecate the "use-resource-role-mappings" switch in the 
adapter.
* I want to deprecate the JWT extension we made for roles and have 
something completely flat (like SAML) with a URI that identifies each 
role (like in UMA spec).
* We will remove these deprecated features in the final cut of community 
that we fork to move into product.


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

From stian at redhat.com  Wed Aug 12 10:20:44 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Aug 2015 10:20:44 -0400 (EDT)
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <55CB4C57.2050301@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
	<55CB4C57.2050301@redhat.com>
Message-ID: <913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 August, 2015 3:38:31 PM
> Subject: Re: [keycloak-dev] public/private api module structure
> 
> Users then have to figure out and know which modules/artifacts to
> import.  We have Authentication SPI, Event SPI, Model, Federation SPI,
> core API, LoginFormProvider SPI, and possibly Protocol Mapper SPI,
> Identity Broker Mapper SPI.  8 different modules/artifacts.  If we add
> the protocol mapper SPI, then we also need to include SAML and OIDC
> public APIs too.  Our total is 10 now.  Then we might eventually want to
> make our Login Protocol and Identity Broker SPI public, and add an SPI
> for Account extensions which would force us to add the
> AccoutnFormProvider SPI too.
> 
> That's potentially 14 different public modules.

For users if they included a single module/jar with the apis for all SPIs they would then have to figure out what belongs to what. That's where I think it's cleaner to split it up.

> 
> Finally, it is a pain in the ass for us to add any new SPIs as we have
> to wade through all the wildfly module dependencies in the 3 different
> places they are defined.  We've been creating new SPIs at least once a
> month, sometimes more.

We would still need to create separate modules for implementations of the SPIs.

Another thing is that by combining lots of things into one place you make the code less modular and harder to use, especially for those less familiar with the code.

> 
> On 8/12/2015 9:04 AM, Stian Thorgersen wrote:
> > I'm not convinced..
> >
> > We'd still have to have separate modules for implementations of an SPI, so
> > it would only reduce the amount of modules somewhat. Besides how often do
> > we create new SPIs?
> >
> > For users I think having it separate is better as they can more easily see
> > what classes are relevant to the provider they are implementing.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 12 August, 2015 2:50:49 PM
> >> Subject: [keycloak-dev] public/private api module structure
> >>
> >> I was thinking we'd have a more course-grain module structure for public
> >> apis.  We have a crap load of SPIs and having a module for each of them
> >> is a pain for the user and us in creating/maintaining poms as well as
> >> creating maintaing JBoss modules.  Something like:
> >>
> >> keycloak-core-api
> >> keycloak-server-api
> >> keycloak-client-api
> >>
> >> and
> >>
> >> keycloak-saml-api
> >> keycloak-oidc-api
> >>
> >> protocol APIs would be for the case where users need to access the raw
> >> SAML document or JWT.
> >>
> >> These API modules would only contain public APIs and helper classes.  we
> >> can consolidate and/or separate internal implementation classes into any
> >> structure we want with the thought process being that we would organize
> >> these modules so that we have the option to remove features as needed to
> >> make a smaller distro.
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Wed Aug 12 10:45:36 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Aug 2015 10:45:36 -0400 (EDT)
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
	<55CB4C57.2050301@redhat.com>
	<913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
Message-ID: <939449983.9379604.1439390736239.JavaMail.zimbra@redhat.com>

Thinking about it some more we do have an insane amount of modules so we should probably slim it down.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 August, 2015 4:20:44 PM
> Subject: Re: [keycloak-dev] public/private api module structure
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 12 August, 2015 3:38:31 PM
> > Subject: Re: [keycloak-dev] public/private api module structure
> > 
> > Users then have to figure out and know which modules/artifacts to
> > import.  We have Authentication SPI, Event SPI, Model, Federation SPI,
> > core API, LoginFormProvider SPI, and possibly Protocol Mapper SPI,
> > Identity Broker Mapper SPI.  8 different modules/artifacts.  If we add
> > the protocol mapper SPI, then we also need to include SAML and OIDC
> > public APIs too.  Our total is 10 now.  Then we might eventually want to
> > make our Login Protocol and Identity Broker SPI public, and add an SPI
> > for Account extensions which would force us to add the
> > AccoutnFormProvider SPI too.
> > 
> > That's potentially 14 different public modules.
> 
> For users if they included a single module/jar with the apis for all SPIs
> they would then have to figure out what belongs to what. That's where I
> think it's cleaner to split it up.
> 
> > 
> > Finally, it is a pain in the ass for us to add any new SPIs as we have
> > to wade through all the wildfly module dependencies in the 3 different
> > places they are defined.  We've been creating new SPIs at least once a
> > month, sometimes more.
> 
> We would still need to create separate modules for implementations of the
> SPIs.
> 
> Another thing is that by combining lots of things into one place you make the
> code less modular and harder to use, especially for those less familiar with
> the code.
> 
> > 
> > On 8/12/2015 9:04 AM, Stian Thorgersen wrote:
> > > I'm not convinced..
> > >
> > > We'd still have to have separate modules for implementations of an SPI,
> > > so
> > > it would only reduce the amount of modules somewhat. Besides how often do
> > > we create new SPIs?
> > >
> > > For users I think having it separate is better as they can more easily
> > > see
> > > what classes are relevant to the provider they are implementing.
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: keycloak-dev at lists.jboss.org
> > >> Sent: Wednesday, 12 August, 2015 2:50:49 PM
> > >> Subject: [keycloak-dev] public/private api module structure
> > >>
> > >> I was thinking we'd have a more course-grain module structure for public
> > >> apis.  We have a crap load of SPIs and having a module for each of them
> > >> is a pain for the user and us in creating/maintaining poms as well as
> > >> creating maintaing JBoss modules.  Something like:
> > >>
> > >> keycloak-core-api
> > >> keycloak-server-api
> > >> keycloak-client-api
> > >>
> > >> and
> > >>
> > >> keycloak-saml-api
> > >> keycloak-oidc-api
> > >>
> > >> protocol APIs would be for the case where users need to access the raw
> > >> SAML document or JWT.
> > >>
> > >> These API modules would only contain public APIs and helper classes.  we
> > >> can consolidate and/or separate internal implementation classes into any
> > >> structure we want with the thought process being that we would organize
> > >> these modules so that we have the option to remove features as needed to
> > >> make a smaller distro.
> > >>
> > >> --
> > >> Bill Burke
> > >> JBoss, a division of Red Hat
> > >> http://bill.burkecentral.com
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mstrukel at redhat.com  Wed Aug 12 12:07:14 2015
From: mstrukel at redhat.com (Marko Strukelj)
Date: Wed, 12 Aug 2015 12:07:14 -0400 (EDT)
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
	<55CB4C57.2050301@redhat.com>
	<913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
Message-ID: <1901279284.11532157.1439395634120.JavaMail.zimbra@redhat.com>


> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 12 August, 2015 3:38:31 PM
> > Subject: Re: [keycloak-dev] public/private api module structure
> > 
> > Users then have to figure out and know which modules/artifacts to
> > import.  We have Authentication SPI, Event SPI, Model, Federation SPI,
> > core API, LoginFormProvider SPI, and possibly Protocol Mapper SPI,
> > Identity Broker Mapper SPI.  8 different modules/artifacts.  If we add
> > the protocol mapper SPI, then we also need to include SAML and OIDC
> > public APIs too.  Our total is 10 now.  Then we might eventually want to
> > make our Login Protocol and Identity Broker SPI public, and add an SPI
> > for Account extensions which would force us to add the
> > AccoutnFormProvider SPI too.
> > 
> > That's potentially 14 different public modules.
> 
> For users if they included a single module/jar with the apis for all SPIs
> they would then have to figure out what belongs to what. That's where I
> think it's cleaner to split it up.
> 

One way to split is through package names. 

If that could bring some confusion when using IDEs quick assist / find class for typical classes with same names we could make sure that we prefix common names - instead every SPI having Factory for example we could then have EventFactory, AuthenticationFactory, SAMLFactory ... 

> > 
> > Finally, it is a pain in the ass for us to add any new SPIs as we have
> > to wade through all the wildfly module dependencies in the 3 different
> > places they are defined.  We've been creating new SPIs at least once a
> > month, sometimes more.
> 
> We would still need to create separate modules for implementations of the
> SPIs.
> 
> Another thing is that by combining lots of things into one place you make the
> code less modular and harder to use, especially for those less familiar with
> the code.
> 
> > 
> > On 8/12/2015 9:04 AM, Stian Thorgersen wrote:
> > > I'm not convinced..
> > >
> > > We'd still have to have separate modules for implementations of an SPI,
> > > so
> > > it would only reduce the amount of modules somewhat. Besides how often do
> > > we create new SPIs?
> > >
> > > For users I think having it separate is better as they can more easily
> > > see
> > > what classes are relevant to the provider they are implementing.
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: keycloak-dev at lists.jboss.org
> > >> Sent: Wednesday, 12 August, 2015 2:50:49 PM
> > >> Subject: [keycloak-dev] public/private api module structure
> > >>
> > >> I was thinking we'd have a more course-grain module structure for public
> > >> apis.  We have a crap load of SPIs and having a module for each of them
> > >> is a pain for the user and us in creating/maintaining poms as well as
> > >> creating maintaing JBoss modules.  Something like:
> > >>
> > >> keycloak-core-api
> > >> keycloak-server-api
> > >> keycloak-client-api
> > >>
> > >> and
> > >>
> > >> keycloak-saml-api
> > >> keycloak-oidc-api
> > >>
> > >> protocol APIs would be for the case where users need to access the raw
> > >> SAML document or JWT.
> > >>
> > >> These API modules would only contain public APIs and helper classes.  we
> > >> can consolidate and/or separate internal implementation classes into any
> > >> structure we want with the thought process being that we would organize
> > >> these modules so that we have the option to remove features as needed to
> > >> make a smaller distro.
> > >>
> > >> --
> > >> Bill Burke
> > >> JBoss, a division of Red Hat
> > >> http://bill.burkecentral.com
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Wed Aug 12 12:58:35 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Aug 2015 12:58:35 -0400
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
	<55CB4C57.2050301@redhat.com>
	<913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
Message-ID: <55CB7B3B.1040307@redhat.com>



On 8/12/2015 10:20 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 12 August, 2015 3:38:31 PM
>> Subject: Re: [keycloak-dev] public/private api module structure
>>
>> Users then have to figure out and know which modules/artifacts to
>> import.  We have Authentication SPI, Event SPI, Model, Federation SPI,
>> core API, LoginFormProvider SPI, and possibly Protocol Mapper SPI,
>> Identity Broker Mapper SPI.  8 different modules/artifacts.  If we add
>> the protocol mapper SPI, then we also need to include SAML and OIDC
>> public APIs too.  Our total is 10 now.  Then we might eventually want to
>> make our Login Protocol and Identity Broker SPI public, and add an SPI
>> for Account extensions which would force us to add the
>> AccoutnFormProvider SPI too.
>>
>> That's potentially 14 different public modules.
>
> For users if they included a single module/jar with the apis for all SPIs they would then have to figure out what belongs to what. That's where I think it's cleaner to split it up.
>

This is an honest question.  Why do they have to figure out what belongs 
to what?  And why do they care?  They will be looking at documentation 
and javadocs.


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

From vinayan3 at gmail.com  Wed Aug 12 18:21:01 2015
From: vinayan3 at gmail.com (Vinay Anantharaman)
Date: Wed, 12 Aug 2015 18:21:01 -0400
Subject: [keycloak-dev] Implementing database-service example in Python
Message-ID: <CANWAcaUP3jXVGY+cmAsnyEp0AiHYoBENucf4XO0cbPq3Ef89bg@mail.gmail.com>

Hi,
I'm trying to implement the example database service from Python.  The
description is here:

https://github.com/keycloak/keycloak/tree/master/examples/demo-template

Our backend service is contacted directly by clients with an access token
from the Keycloak server. We would like to verify access tokens are and
then return some data they need. I was looking at the code here:

https://github.com/keycloak/keycloak/blob/master/examples/demo-template/database-
service/src/main/java/org/keycloak/example/oauth/CustomerService.java

In Java this seems quite trivial with the support of Keycloak libraries. In
Python I won't have them. What are the APIs on Keycloak I can use to verify
an access token? Furthermore, are you aware of any classes like
RSATokenVerifier
for python? I saw it being used here:

https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/OAuthClient.java#L319


Thanks,


Vinay Anantharaman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150812/49758f7e/attachment.html 

From stian at redhat.com  Thu Aug 13 01:47:26 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Aug 2015 01:47:26 -0400 (EDT)
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <55CB7B3B.1040307@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
	<55CB4C57.2050301@redhat.com>
	<913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
	<55CB7B3B.1040307@redhat.com>
Message-ID: <188045680.9690767.1439444846572.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 August, 2015 6:58:35 PM
> Subject: Re: [keycloak-dev] public/private api module structure
> 
> 
> 
> On 8/12/2015 10:20 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 12 August, 2015 3:38:31 PM
> >> Subject: Re: [keycloak-dev] public/private api module structure
> >>
> >> Users then have to figure out and know which modules/artifacts to
> >> import.  We have Authentication SPI, Event SPI, Model, Federation SPI,
> >> core API, LoginFormProvider SPI, and possibly Protocol Mapper SPI,
> >> Identity Broker Mapper SPI.  8 different modules/artifacts.  If we add
> >> the protocol mapper SPI, then we also need to include SAML and OIDC
> >> public APIs too.  Our total is 10 now.  Then we might eventually want to
> >> make our Login Protocol and Identity Broker SPI public, and add an SPI
> >> for Account extensions which would force us to add the
> >> AccoutnFormProvider SPI too.
> >>
> >> That's potentially 14 different public modules.
> >
> > For users if they included a single module/jar with the apis for all SPIs
> > they would then have to figure out what belongs to what. That's where I
> > think it's cleaner to split it up.
> >
> 
> This is an honest question.  Why do they have to figure out what belongs
> to what?  And why do they care?  They will be looking at documentation
> and javadocs.

There's two types of devs those that reads docs and javadocs and does that don't. Personally I'm a bit of both I refer to javadocs sometimes, but quite frequently I look through the source code and that's much simpler if it's modularized. However, I've thought about it a bit and I think we can achieve the same modularity with packages and by making sure "keycloak-server-api" mainly contains interfaces.

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

From stian at redhat.com  Thu Aug 13 01:49:28 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Aug 2015 01:49:28 -0400 (EDT)
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <1901279284.11532157.1439395634120.JavaMail.zimbra@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
	<55CB4C57.2050301@redhat.com>
	<913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
	<1901279284.11532157.1439395634120.JavaMail.zimbra@redhat.com>
Message-ID: <957855626.9690959.1439444968145.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marko Strukelj" <mstrukel at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 August, 2015 6:07:14 PM
> Subject: Re: [keycloak-dev] public/private api module structure
> 
> 
> > 
> > 
> > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Wednesday, 12 August, 2015 3:38:31 PM
> > > Subject: Re: [keycloak-dev] public/private api module structure
> > > 
> > > Users then have to figure out and know which modules/artifacts to
> > > import.  We have Authentication SPI, Event SPI, Model, Federation SPI,
> > > core API, LoginFormProvider SPI, and possibly Protocol Mapper SPI,
> > > Identity Broker Mapper SPI.  8 different modules/artifacts.  If we add
> > > the protocol mapper SPI, then we also need to include SAML and OIDC
> > > public APIs too.  Our total is 10 now.  Then we might eventually want to
> > > make our Login Protocol and Identity Broker SPI public, and add an SPI
> > > for Account extensions which would force us to add the
> > > AccoutnFormProvider SPI too.
> > > 
> > > That's potentially 14 different public modules.
> > 
> > For users if they included a single module/jar with the apis for all SPIs
> > they would then have to figure out what belongs to what. That's where I
> > think it's cleaner to split it up.
> > 
> 
> One way to split is through package names.
> 
> If that could bring some confusion when using IDEs quick assist / find class
> for typical classes with same names we could make sure that we prefix common
> names - instead every SPI having Factory for example we could then have
> EventFactory, AuthenticationFactory, SAMLFactory ...

I believe all spis, factories and provider interfacers are already prefixed.

> 
> > > 
> > > Finally, it is a pain in the ass for us to add any new SPIs as we have
> > > to wade through all the wildfly module dependencies in the 3 different
> > > places they are defined.  We've been creating new SPIs at least once a
> > > month, sometimes more.
> > 
> > We would still need to create separate modules for implementations of the
> > SPIs.
> > 
> > Another thing is that by combining lots of things into one place you make
> > the
> > code less modular and harder to use, especially for those less familiar
> > with
> > the code.
> > 
> > > 
> > > On 8/12/2015 9:04 AM, Stian Thorgersen wrote:
> > > > I'm not convinced..
> > > >
> > > > We'd still have to have separate modules for implementations of an SPI,
> > > > so
> > > > it would only reduce the amount of modules somewhat. Besides how often
> > > > do
> > > > we create new SPIs?
> > > >
> > > > For users I think having it separate is better as they can more easily
> > > > see
> > > > what classes are relevant to the provider they are implementing.
> > > >
> > > > ----- Original Message -----
> > > >> From: "Bill Burke" <bburke at redhat.com>
> > > >> To: keycloak-dev at lists.jboss.org
> > > >> Sent: Wednesday, 12 August, 2015 2:50:49 PM
> > > >> Subject: [keycloak-dev] public/private api module structure
> > > >>
> > > >> I was thinking we'd have a more course-grain module structure for
> > > >> public
> > > >> apis.  We have a crap load of SPIs and having a module for each of
> > > >> them
> > > >> is a pain for the user and us in creating/maintaining poms as well as
> > > >> creating maintaing JBoss modules.  Something like:
> > > >>
> > > >> keycloak-core-api
> > > >> keycloak-server-api
> > > >> keycloak-client-api
> > > >>
> > > >> and
> > > >>
> > > >> keycloak-saml-api
> > > >> keycloak-oidc-api
> > > >>
> > > >> protocol APIs would be for the case where users need to access the raw
> > > >> SAML document or JWT.
> > > >>
> > > >> These API modules would only contain public APIs and helper classes.
> > > >> we
> > > >> can consolidate and/or separate internal implementation classes into
> > > >> any
> > > >> structure we want with the thought process being that we would
> > > >> organize
> > > >> these modules so that we have the option to remove features as needed
> > > >> to
> > > >> make a smaller distro.
> > > >>
> > > >> --
> > > >> Bill Burke
> > > >> JBoss, a division of Red Hat
> > > >> http://bill.burkecentral.com
> > > >> _______________________________________________
> > > >> keycloak-dev mailing list
> > > >> keycloak-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>
> > > 
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> > > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From stian at redhat.com  Thu Aug 13 02:00:53 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Aug 2015 02:00:53 -0400 (EDT)
Subject: [keycloak-dev] Implementing database-service example in Python
In-Reply-To: <CANWAcaUP3jXVGY+cmAsnyEp0AiHYoBENucf4XO0cbPq3Ef89bg@mail.gmail.com>
References: <CANWAcaUP3jXVGY+cmAsnyEp0AiHYoBENucf4XO0cbPq3Ef89bg@mail.gmail.com>
Message-ID: <826281598.9693806.1439445653118.JavaMail.zimbra@redhat.com>

Afraid we don't have any libraries for Python yet.

Simply verifying the token should be relatively straight forward though. It's a standard JWT token (base64 encoded json) with a JWS signature. You can look at RSATokenVerifier to see what details should be verified (expiration date, issuer, etc..). You also need to verify the signature. There may quite likely be JWT libraries for Python you can use.

----- Original Message -----
> From: "Vinay Anantharaman" <vinayan3 at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 12:21:01 AM
> Subject: [keycloak-dev] Implementing database-service example in Python
> 
> Hi,
> I'm trying to implement the example database service from Python. The
> description is here:
> 
> 
> 
> https://github.com/keycloak/keycloak/tree/master/examples/demo-template
> 
> Our backend service is contacted directly by clients with an access token
> from the Keycloak server. We would like to verify access tokens are and then
> return some data they need. I was looking at the code here:
> 
> 
> 
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/database-
> service/src/main/java/org/keycloak/example/oauth/CustomerService.java
> 
> In Java this seems quite trivial with the support of Keycloak libraries. In
> Python I won't have them. What are the APIs on Keycloak I can use to verify
> an access token? Furthermore, are you aware of any classes like
> RSATokenVerifier for python? I saw it being used here:
> 
> 
> 
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/OAuthClient.java#L319
> 
> Thanks,
> 
> 
> Vinay Anantharaman
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Thu Aug 13 02:23:59 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Aug 2015 02:23:59 -0400 (EDT)
Subject: [keycloak-dev] Groups design
In-Reply-To: <55CB4F1D.3000909@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
Message-ID: <1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 August, 2015 3:50:21 PM
> Subject: [keycloak-dev] Groups design
> 
> I would like to nail down what we want Groups to look like in Keycloak.
>   And also propose a separate RoleGroups structure.
> 
> GROUPS:
> 
> * Groups have an id, name, and description
> * Groups have an arbitrary set of name/value pair attributes
> * Realm/Client roles can be associated with a Group.  This is like a
> UserRoleMapping, except it is a GroupRoleMapping.

With this concept we don't need composite roles and should remove them.

> * Groups can be members of one or more groups
> * Users can be members of one or more groups
> * Users inherit attributes of the groups they belong to.
> * UserModel now has a getGroups(), hasGroup(), grantGroup(), deleteGroup()
> * Similar to default roles, we also have default groups.

If we add default groups we don't need default roles and should remove them.

> 
> Features we probably want:
> * Groups can have a set of protocol Mappers organized by protocol.
> * Clients inherit protocol Mappers from the groups a user belongs to.

I'm not sure groups should be the way to "share" protocol mappers. It would be better to have realm level "protocol mapper definitions" that can be re-used in clients. What you are suggesting raises a lot of questions:

* What happens when a user belongs to multiple groups that all have protocol mappers associated. Seems like it would be very unclear in this case what the token would actually look like. Especially if different groups have conflicting mappings (for example one maps first-name to name and another maps first+last name to name.
* Shouldn't token format be defined by a client, not by groups? A client will expect a token is a certain format, but if it's dependent on what group a user belongs to all bets is off.

> 
> Questions:
> * Do we want to expand the concept of a Group so that clients and
> identity brokers can belong to a Group? Or just create a separate
> composite structure for this?

Not sure we need that at all. Can't identity brokers and clients just use mappings to achieve the required effect? Or am I confusing what effect this would have.

> 
> 
> ROLEGROUPS:
> 
> RoleGroups are just a namespace for Roles.  I want to remove the concept
> of realm level and client level roles and just have the concept of a
> RoleGroup.  The reasoning for this is that I've seen people ask for it.
>   They want to share a set of roles between clients and realm-level
> roles might end up having name clashes, if you are following me.

+100000000000 I've wanted this from the start ;)

> 
> * RoleGroups have an id, name and description.
> * RoleGroups define a set of roles.
> * Users are *NOT* members of RoleGroups
> * For migration, a "realm" RoleGroup is created.  a RoleGroup for each
> client that has defined roles is created.  The name will be the clientId
> of the client.
> * I want to deprecate the "use-resource-role-mappings" switch in the
> adapter.
> * I want to deprecate the JWT extension we made for roles and have
> something completely flat (like SAML) with a URI that identifies each
> role (like in UMA spec).

Would that be added to the scope field? Or something else? Scope allows clients to request what goes into a token and there's a set of standard things we need to support to achieve OIDC compliance.

How about JEE? It and other framework generally except simple names for roles. We could make it configurable with the following options (assuming the roles role://acme.org/role-group-a/role-a, role://acme.org/role-group-b/role-b):

* Full - roles would be the full uris (role://acme.org/role-group-a/role-a, role://acme.org/role-group-b/role-b)
* Simple - specify the "role-group" uri and only roles in that group are included (if set to role://acme.org/role-group-a the roles are role://acme.org/role-group-a/role-a)
* Stripped - includes roles that have a set prefix and removes the prefix (if set to role://acme.org/ the roles are role-group-a/role-a and role-group-b/role-b)

> * We will remove these deprecated features in the final cut of community
> that we fork to move into product.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Aug 13 09:03:27 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Aug 2015 09:03:27 -0400
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <188045680.9690767.1439444846572.JavaMail.zimbra@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
	<55CB4C57.2050301@redhat.com>
	<913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
	<55CB7B3B.1040307@redhat.com>
	<188045680.9690767.1439444846572.JavaMail.zimbra@redhat.com>
Message-ID: <55CC959F.8080206@redhat.com>



On 8/13/2015 1:47 AM, Stian Thorgersen wrote:
>>> For users if they included a single module/jar with the apis for all SPIs
>>> they would then have to figure out what belongs to what. That's where I
>>> think it's cleaner to split it up.
>>>
>>
>> This is an honest question.  Why do they have to figure out what belongs
>> to what?  And why do they care?  They will be looking at documentation
>> and javadocs.
>
> There's two types of devs those that reads docs and javadocs and does that don't. Personally I'm a bit of both I refer to javadocs sometimes, but quite frequently I look through the source code and that's much simpler if it's modularized. However, I've thought about it a bit and I think we can achieve the same modularity with packages and by making sure "keycloak-server-api" mainly contains interfaces.
>

Interfaces and simple helper or abstract classes.


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

From bburke at redhat.com  Thu Aug 13 09:05:01 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Aug 2015 09:05:01 -0400
Subject: [keycloak-dev] Implementing database-service example in Python
In-Reply-To: <826281598.9693806.1439445653118.JavaMail.zimbra@redhat.com>
References: <CANWAcaUP3jXVGY+cmAsnyEp0AiHYoBENucf4XO0cbPq3Ef89bg@mail.gmail.com>
	<826281598.9693806.1439445653118.JavaMail.zimbra@redhat.com>
Message-ID: <55CC95FD.6050601@redhat.com>

If you're interested in becoming a contributor Vinay, this would be a 
very useful extension!

BTW, we also have a "lightweight" Java Security HTTP Proxy based on 
Undertow that you can use to secure python apps.

On 8/13/2015 2:00 AM, Stian Thorgersen wrote:
> Afraid we don't have any libraries for Python yet.
>
> Simply verifying the token should be relatively straight forward though. It's a standard JWT token (base64 encoded json) with a JWS signature. You can look at RSATokenVerifier to see what details should be verified (expiration date, issuer, etc..). You also need to verify the signature. There may quite likely be JWT libraries for Python you can use.
>
> ----- Original Message -----
>> From: "Vinay Anantharaman" <vinayan3 at gmail.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 13 August, 2015 12:21:01 AM
>> Subject: [keycloak-dev] Implementing database-service example in Python
>>
>> Hi,
>> I'm trying to implement the example database service from Python. The
>> description is here:
>>
>>
>>
>> https://github.com/keycloak/keycloak/tree/master/examples/demo-template
>>
>> Our backend service is contacted directly by clients with an access token
>> from the Keycloak server. We would like to verify access tokens are and then
>> return some data they need. I was looking at the code here:
>>
>>
>>
>> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/database-
>> service/src/main/java/org/keycloak/example/oauth/CustomerService.java
>>
>> In Java this seems quite trivial with the support of Keycloak libraries. In
>> Python I won't have them. What are the APIs on Keycloak I can use to verify
>> an access token? Furthermore, are you aware of any classes like
>> RSATokenVerifier for python? I saw it being used here:
>>
>>
>>
>> https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/OAuthClient.java#L319
>>
>> Thanks,
>>
>>
>> Vinay Anantharaman
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Thu Aug 13 09:07:58 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Aug 2015 09:07:58 -0400 (EDT)
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <55CC959F.8080206@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
	<55CB4C57.2050301@redhat.com>
	<913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
	<55CB7B3B.1040307@redhat.com>
	<188045680.9690767.1439444846572.JavaMail.zimbra@redhat.com>
	<55CC959F.8080206@redhat.com>
Message-ID: <1427692500.9969907.1439471278082.JavaMail.zimbra@redhat.com>

I'm happy with:

keycloak-core-api
keycloak-client-api
keycloak-server-api

With regards to the protocol specific parts are you thinking those would be client specific things for each protocol? For example JWT utils?

Further I think we should put core provider implementations into keycloak-services or maybe keycloak-default-providers or something. Then only have separate modules for those providers that need to be pluggable (jpa, mongo, etc..).

Not sure if the way I counted it is accurate, but we seem to have 200 maven modules!!

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 3:03:27 PM
> Subject: Re: [keycloak-dev] public/private api module structure
> 
> 
> 
> On 8/13/2015 1:47 AM, Stian Thorgersen wrote:
> >>> For users if they included a single module/jar with the apis for all SPIs
> >>> they would then have to figure out what belongs to what. That's where I
> >>> think it's cleaner to split it up.
> >>>
> >>
> >> This is an honest question.  Why do they have to figure out what belongs
> >> to what?  And why do they care?  They will be looking at documentation
> >> and javadocs.
> >
> > There's two types of devs those that reads docs and javadocs and does that
> > don't. Personally I'm a bit of both I refer to javadocs sometimes, but
> > quite frequently I look through the source code and that's much simpler if
> > it's modularized. However, I've thought about it a bit and I think we can
> > achieve the same modularity with packages and by making sure
> > "keycloak-server-api" mainly contains interfaces.
> >
> 
> Interfaces and simple helper or abstract classes.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Aug 13 09:18:43 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Aug 2015 09:18:43 -0400
Subject: [keycloak-dev] Groups design
In-Reply-To: <1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>
Message-ID: <55CC9933.6010405@redhat.com>



On 8/13/2015 2:23 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 12 August, 2015 3:50:21 PM
>> Subject: [keycloak-dev] Groups design
>>
>> I would like to nail down what we want Groups to look like in Keycloak.
>>    And also propose a separate RoleGroups structure.
>>
>> GROUPS:
>>
>> * Groups have an id, name, and description
>> * Groups have an arbitrary set of name/value pair attributes
>> * Realm/Client roles can be associated with a Group.  This is like a
>> UserRoleMapping, except it is a GroupRoleMapping.
>
> With this concept we don't need composite roles and should remove them.
>

We'd have to deprecate composite roles and remove them before product 
release.

>> * Groups can be members of one or more groups
>> * Users can be members of one or more groups
>> * Users inherit attributes of the groups they belong to.
>> * UserModel now has a getGroups(), hasGroup(), grantGroup(), deleteGroup()
>> * Similar to default roles, we also have default groups.
>
> If we add default groups we don't need default roles and should remove them.
>

Not sure I agree.  Users may not want roles.

>>
>> Features we probably want:
>> * Groups can have a set of protocol Mappers organized by protocol.
>> * Clients inherit protocol Mappers from the groups a user belongs to.
>
> I'm not sure groups should be the way to "share" protocol mappers. It would be better to have realm level "protocol mapper definitions" that can be re-used in clients. What you are suggesting raises a lot of questions:
>

Basically a group or a role becomes a trigger for more behavior.

This is what Dell does if I understood them correctly.  They assign an 
"organization" based on the IDP that is logged in from.  Then populate 
the saml assertion/token based on what organization the user belongs to. 
  I you don't do something like this then you end up having to duplicate 
each mapper type or adding a "if group set" config option.

If user belongs to group and the attribute exists, add it to the 
assertion.  Rather than if attribute exists, add it to the assertion.

Conceivably might make sense to allow associating mappers with roles too.




> * What happens when a user belongs to multiple groups that all have protocol mappers associated. Seems like it would be very unclear in this case what the token would actually look like. Especially if different groups have conflicting mappings (for example one maps first-name to name and another maps first+last name to name.

Not really our problem.  If somebody does an overcomplicated design, 
that's their problem.

> * Shouldn't token format be defined by a client, not by groups? A client will expect a token is a certain format, but if it's dependent on what group a user belongs to all bets is off.
>

Probably depends on the app.  But that's a good point.  Just seem cool 
to be able to assign behavior to a group or even a role, rather than 
assigning behavior to the client.

>>
>> Questions:
>> * Do we want to expand the concept of a Group so that clients and
>> identity brokers can belong to a Group? Or just create a separate
>> composite structure for this?
>
> Not sure we need that at all. Can't identity brokers and clients just use mappings to achieve the required effect? Or am I confusing what effect this would have.
>

The concept of associating mappers to a Group isn't required, its just a 
different way of attacking the problem.

>>
>>
>> ROLEGROUPS:
>>
>> RoleGroups are just a namespace for Roles.  I want to remove the concept
>> of realm level and client level roles and just have the concept of a
>> RoleGroup.  The reasoning for this is that I've seen people ask for it.
>>    They want to share a set of roles between clients and realm-level
>> roles might end up having name clashes, if you are following me.
>
> +100000000000 I've wanted this from the start ;)
>
>>
>> * RoleGroups have an id, name and description.
>> * RoleGroups define a set of roles.
>> * Users are *NOT* members of RoleGroups
>> * For migration, a "realm" RoleGroup is created.  a RoleGroup for each
>> client that has defined roles is created.  The name will be the clientId
>> of the client.
>> * I want to deprecate the "use-resource-role-mappings" switch in the
>> adapter.
>> * I want to deprecate the JWT extension we made for roles and have
>> something completely flat (like SAML) with a URI that identifies each
>> role (like in UMA spec).
>
> Would that be added to the scope field? Or something else? Scope allows clients to request what goes into a token and there's a set of standard things we need to support to achieve OIDC compliance.
>

I don't see why it wouldn't be added to the scope field.

> How about JEE? It and other framework generally except simple names for roles. We could make it configurable with the following options (assuming the roles role://acme.org/role-group-a/role-a, role://acme.org/role-group-b/role-b):
>

We could add role-name mapping at the adapter level.  I wanted to avoid 
that as it would all have to be done in config files.

> * Full - roles would be the full uris (role://acme.org/role-group-a/role-a, role://acme.org/role-group-b/role-b)
> * Simple - specify the "role-group" uri and only roles in that group are included (if set to role://acme.org/role-group-a the roles are role://acme.org/role-group-a/role-a)
> * Stripped - includes roles that have a set prefix and removes the prefix (if set to role://acme.org/ the roles are role-group-a/role-a and role-group-b/role-b)
>

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

From bburke at redhat.com  Thu Aug 13 09:22:14 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Aug 2015 09:22:14 -0400
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <1427692500.9969907.1439471278082.JavaMail.zimbra@redhat.com>
References: <55CB4129.5050009@redhat.com>
	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>
	<55CB4C57.2050301@redhat.com>
	<913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>
	<55CB7B3B.1040307@redhat.com>
	<188045680.9690767.1439444846572.JavaMail.zimbra@redhat.com>
	<55CC959F.8080206@redhat.com>
	<1427692500.9969907.1439471278082.JavaMail.zimbra@redhat.com>
Message-ID: <55CC9A06.3020705@redhat.com>



On 8/13/2015 9:07 AM, Stian Thorgersen wrote:
> I'm happy with:
>
> keycloak-core-api
> keycloak-client-api
> keycloak-server-api
>
> With regards to the protocol specific parts are you thinking those would be client specific things for each protocol? For example JWT utils?

Everything.  For example, I have a helper abstract base class for 
Authenticator and RequireActionProvider.  Mappers can get access to the 
SAML Document model.



>
> Further I think we should put core provider implementations into keycloak-services or maybe keycloak-default-providers or something. Then only have separate modules for those providers that need to be pluggable (jpa, mongo, etc..).
>
> Not sure if the way I counted it is accurate, but we seem to have 200 maven modules!!
>

Yeah, its insane...Its pretty much why I punted on converting from a WAR 
to modules :)

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

From stian at redhat.com  Thu Aug 13 09:32:07 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Aug 2015 09:32:07 -0400 (EDT)
Subject: [keycloak-dev] Groups design
In-Reply-To: <55CC9933.6010405@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>
	<55CC9933.6010405@redhat.com>
Message-ID: <1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 3:18:43 PM
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> On 8/13/2015 2:23 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 12 August, 2015 3:50:21 PM
> >> Subject: [keycloak-dev] Groups design
> >>
> >> I would like to nail down what we want Groups to look like in Keycloak.
> >>    And also propose a separate RoleGroups structure.
> >>
> >> GROUPS:
> >>
> >> * Groups have an id, name, and description
> >> * Groups have an arbitrary set of name/value pair attributes
> >> * Realm/Client roles can be associated with a Group.  This is like a
> >> UserRoleMapping, except it is a GroupRoleMapping.
> >
> > With this concept we don't need composite roles and should remove them.
> >
> 
> We'd have to deprecate composite roles and remove them before product
> release.
> 
> >> * Groups can be members of one or more groups
> >> * Users can be members of one or more groups
> >> * Users inherit attributes of the groups they belong to.
> >> * UserModel now has a getGroups(), hasGroup(), grantGroup(), deleteGroup()
> >> * Similar to default roles, we also have default groups.
> >
> > If we add default groups we don't need default roles and should remove
> > them.
> >
> 
> Not sure I agree.  Users may not want roles.

You mean may not want groups? I just don't like maintaining multiple ways to achieve the same thing - extra work for us and complicates documentation, etc..

Why not just have a default group? Then users can add whatever roles and other groups they want to it?

> 
> >>
> >> Features we probably want:
> >> * Groups can have a set of protocol Mappers organized by protocol.
> >> * Clients inherit protocol Mappers from the groups a user belongs to.
> >
> > I'm not sure groups should be the way to "share" protocol mappers. It would
> > be better to have realm level "protocol mapper definitions" that can be
> > re-used in clients. What you are suggesting raises a lot of questions:
> >
> 
> Basically a group or a role becomes a trigger for more behavior.
> 
> This is what Dell does if I understood them correctly.  They assign an
> "organization" based on the IDP that is logged in from.  Then populate
> the saml assertion/token based on what organization the user belongs to.
>   I you don't do something like this then you end up having to duplicate
> each mapper type or adding a "if group set" config option.
> 
> If user belongs to group and the attribute exists, add it to the
> assertion.  Rather than if attribute exists, add it to the assertion.
> 
> Conceivably might make sense to allow associating mappers with roles too.
> 
> 
> 
> 
> > * What happens when a user belongs to multiple groups that all have
> > protocol mappers associated. Seems like it would be very unclear in this
> > case what the token would actually look like. Especially if different
> > groups have conflicting mappings (for example one maps first-name to name
> > and another maps first+last name to name.
> 
> Not really our problem.  If somebody does an overcomplicated design,
> that's their problem.

I think it is. It would be very hard for a user to interpret what would end up in the token even with relatively simple groups.

> 
> > * Shouldn't token format be defined by a client, not by groups? A client
> > will expect a token is a certain format, but if it's dependent on what
> > group a user belongs to all bets is off.
> >
> 
> Probably depends on the app.  But that's a good point.  Just seem cool
> to be able to assign behavior to a group or even a role, rather than
> assigning behavior to the client.

I'd rather think that groups are the source of the information. So the available claims are:

* Users roles and attributes
* Groups roles and attributes

But, then you still have a set of protocol mappers (either specified on a per-client as now, or ability to share these) that takes these claims and adds it to the token. 

> 
> >>
> >> Questions:
> >> * Do we want to expand the concept of a Group so that clients and
> >> identity brokers can belong to a Group? Or just create a separate
> >> composite structure for this?
> >
> > Not sure we need that at all. Can't identity brokers and clients just use
> > mappings to achieve the required effect? Or am I confusing what effect
> > this would have.
> >
> 
> The concept of associating mappers to a Group isn't required, its just a
> different way of attacking the problem.

I don't like alternatives ;)

> 
> >>
> >>
> >> ROLEGROUPS:
> >>
> >> RoleGroups are just a namespace for Roles.  I want to remove the concept
> >> of realm level and client level roles and just have the concept of a
> >> RoleGroup.  The reasoning for this is that I've seen people ask for it.
> >>    They want to share a set of roles between clients and realm-level
> >> roles might end up having name clashes, if you are following me.
> >
> > +100000000000 I've wanted this from the start ;)
> >
> >>
> >> * RoleGroups have an id, name and description.
> >> * RoleGroups define a set of roles.
> >> * Users are *NOT* members of RoleGroups
> >> * For migration, a "realm" RoleGroup is created.  a RoleGroup for each
> >> client that has defined roles is created.  The name will be the clientId
> >> of the client.
> >> * I want to deprecate the "use-resource-role-mappings" switch in the
> >> adapter.
> >> * I want to deprecate the JWT extension we made for roles and have
> >> something completely flat (like SAML) with a URI that identifies each
> >> role (like in UMA spec).
> >
> > Would that be added to the scope field? Or something else? Scope allows
> > clients to request what goes into a token and there's a set of standard
> > things we need to support to achieve OIDC compliance.
> >
> 
> I don't see why it wouldn't be added to the scope field.
> 
> > How about JEE? It and other framework generally except simple names for
> > roles. We could make it configurable with the following options (assuming
> > the roles role://acme.org/role-group-a/role-a,
> > role://acme.org/role-group-b/role-b):
> >
> 
> We could add role-name mapping at the adapter level.  I wanted to avoid
> that as it would all have to be done in config files.

True, but I think it's needed. With the client endpoints I'm adding the plan was that clients can self-register, discover their config as well as update their config. Once we have that it would be nice to have adapters retrieve config from KC.

> 
> > * Full - roles would be the full uris (role://acme.org/role-group-a/role-a,
> > role://acme.org/role-group-b/role-b)
> > * Simple - specify the "role-group" uri and only roles in that group are
> > included (if set to role://acme.org/role-group-a the roles are
> > role://acme.org/role-group-a/role-a)
> > * Stripped - includes roles that have a set prefix and removes the prefix
> > (if set to role://acme.org/ the roles are role-group-a/role-a and
> > role-group-b/role-b)
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu Aug 13 09:49:24 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Aug 2015 09:49:24 -0400 (EDT)
Subject: [keycloak-dev] Remove address from registration and account
	management by default
Message-ID: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>

As highlighted by the UXP team the registration screen is not very nice. I propose we remove the address fields from the registration and account management. Instead we should have an example theme that shows adding additional fields to the screens.

From bburke at redhat.com  Thu Aug 13 10:03:18 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Aug 2015 10:03:18 -0400
Subject: [keycloak-dev] Groups design
In-Reply-To: <1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>
	<55CC9933.6010405@redhat.com>
	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
Message-ID: <55CCA3A6.8040002@redhat.com>



On 8/13/2015 9:32 AM, Stian Thorgersen wrote:

>>>> * Groups can be members of one or more groups
>>>> * Users can be members of one or more groups
>>>> * Users inherit attributes of the groups they belong to.
>>>> * UserModel now has a getGroups(), hasGroup(), grantGroup(), deleteGroup()
>>>> * Similar to default roles, we also have default groups.
>>>
>>> If we add default groups we don't need default roles and should remove
>>> them.
>>>
>>
>> Not sure I agree.  Users may not want roles.
>
> You mean may not want groups? I just don't like maintaining multiple ways to achieve the same thing - extra work for us and complicates documentation, etc..
>

Yeah, sorry, users just might not create any groups, plus its backward 
compatible to keep default roles.  The extra work to add default groups 
is simple.  Its just duplication of the equivalent role code.

> Why not just have a default group? Then users can add whatever roles and other groups they want to it?
>

I don't like a "default group" for the same reason I don't like these 
pseudo "built in" clients.


>> Not really our problem.  If somebody does an overcomplicated design,
>> that's their problem.
>
> I think it is. It would be very hard for a user to interpret what would end up in the token even with relatively simple groups.
>

Still, I dont think its our problem.  They can choose not to use the 
feature.

>>
>>> * Shouldn't token format be defined by a client, not by groups? A client
>>> will expect a token is a certain format, but if it's dependent on what
>>> group a user belongs to all bets is off.
>>>
>>
>> Probably depends on the app.  But that's a good point.  Just seem cool
>> to be able to assign behavior to a group or even a role, rather than
>> assigning behavior to the client.
>
> I'd rather think that groups are the source of the information. So the available claims are:
>
> * Users roles and attributes
> * Groups roles and attributes
>
> But, then you still have a set of protocol mappers (either specified on a per-client as now, or ability to share these) that takes these claims and adds it to the token.
>

Another way of looking at it is that the group defines of how attributes 
and roles look inside the claim/assertion, rather than the client 
defining how an attribute looks.

I'm not entirely convinced is a great thing to have, but it does seem 
like it would be useful.


>>
>>>>
>>>> Questions:
>>>> * Do we want to expand the concept of a Group so that clients and
>>>> identity brokers can belong to a Group? Or just create a separate
>>>> composite structure for this?
>>>
>>> Not sure we need that at all. Can't identity brokers and clients just use
>>> mappings to achieve the required effect? Or am I confusing what effect
>>> this would have.
>>>
>>
>> The concept of associating mappers to a Group isn't required, its just a
>> different way of attacking the problem.
>
> I don't like alternatives ;)
>

I don't think it is an alternative.  It is just allowing the Group 
decide how to map things.


>> We could add role-name mapping at the adapter level.  I wanted to avoid
>> that as it would all have to be done in config files.
>
> True, but I think it's needed. With the client endpoints I'm adding the plan was that clients can self-register, discover their config as well as update their config. Once we have that it would be nice to have adapters retrieve config from KC.
>

I guess role-name mapping on the client side would be pretty simple if 
each role has a URI.


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

From stian at redhat.com  Thu Aug 13 10:17:51 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Aug 2015 10:17:51 -0400 (EDT)
Subject: [keycloak-dev] Groups design
In-Reply-To: <55CCA3A6.8040002@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>
	<55CC9933.6010405@redhat.com>
	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
	<55CCA3A6.8040002@redhat.com>
Message-ID: <1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 4:03:18 PM
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> On 8/13/2015 9:32 AM, Stian Thorgersen wrote:
> 
> >>>> * Groups can be members of one or more groups
> >>>> * Users can be members of one or more groups
> >>>> * Users inherit attributes of the groups they belong to.
> >>>> * UserModel now has a getGroups(), hasGroup(), grantGroup(),
> >>>> deleteGroup()
> >>>> * Similar to default roles, we also have default groups.
> >>>
> >>> If we add default groups we don't need default roles and should remove
> >>> them.
> >>>
> >>
> >> Not sure I agree.  Users may not want roles.
> >
> > You mean may not want groups? I just don't like maintaining multiple ways
> > to achieve the same thing - extra work for us and complicates
> > documentation, etc..
> >
> 
> Yeah, sorry, users just might not create any groups, plus its backward
> compatible to keep default roles.  The extra work to add default groups
> is simple.  Its just duplication of the equivalent role code.

It's still extra stuff that needs documenting/explaining and for users to understand. Having multiple things that does the "same thing" is a good way of making software complicated IMO.

> 
> > Why not just have a default group? Then users can add whatever roles and
> > other groups they want to it?
> >
> 
> I don't like a "default group" for the same reason I don't like these
> pseudo "built in" clients.

I agree

But, if someone wants to add some default roles to a user, why would they care if it's done through adding a default group and adding roles to that, rather than adding default roles directly? If we remove composite roles, it more or less makes the default roles feature a bit useless in either case, so would be better to use groups for it.

> 
> 
> >> Not really our problem.  If somebody does an overcomplicated design,
> >> that's their problem.
> >
> > I think it is. It would be very hard for a user to interpret what would end
> > up in the token even with relatively simple groups.
> >
> 
> Still, I dont think its our problem.  They can choose not to use the
> feature.

I disagree - KC is supposed to be easy to use, that should include the advanced features as well. We shouldn't create something that by design would potential be hard to use.

> 
> >>
> >>> * Shouldn't token format be defined by a client, not by groups? A client
> >>> will expect a token is a certain format, but if it's dependent on what
> >>> group a user belongs to all bets is off.
> >>>
> >>
> >> Probably depends on the app.  But that's a good point.  Just seem cool
> >> to be able to assign behavior to a group or even a role, rather than
> >> assigning behavior to the client.
> >
> > I'd rather think that groups are the source of the information. So the
> > available claims are:
> >
> > * Users roles and attributes
> > * Groups roles and attributes
> >
> > But, then you still have a set of protocol mappers (either specified on a
> > per-client as now, or ability to share these) that takes these claims and
> > adds it to the token.
> >
> 
> Another way of looking at it is that the group defines of how attributes
> and roles look inside the claim/assertion, rather than the client
> defining how an attribute looks.
> 
> I'm not entirely convinced is a great thing to have, but it does seem
> like it would be useful.

I'm not at all convinced ;)

It'll be more important to be able to share a set of protocol mappers between clients. So a client should be able to define it's own protocol mappers, and it should be possible to define protocol mappers groups (or whatever it's called) at the realm level and re-use those. One issue with a shared protocol mappers group is that would define the "token format", but you then loose the ability to define what attributes/claims each client should retrieve.

> 
> 
> >>
> >>>>
> >>>> Questions:
> >>>> * Do we want to expand the concept of a Group so that clients and
> >>>> identity brokers can belong to a Group? Or just create a separate
> >>>> composite structure for this?
> >>>
> >>> Not sure we need that at all. Can't identity brokers and clients just use
> >>> mappings to achieve the required effect? Or am I confusing what effect
> >>> this would have.
> >>>
> >>
> >> The concept of associating mappers to a Group isn't required, its just a
> >> different way of attacking the problem.
> >
> > I don't like alternatives ;)
> >
> 
> I don't think it is an alternative.  It is just allowing the Group
> decide how to map things.

Can you elaborate on it a bit more then? As I see it:

* Identity brokers should be able to add a mapper that defines what groups a user belongs to
* Clients should be able to use a "group" mapper to add a group to the token. The group mapper would add the attributes and roles associated with the group to the token.

> 
> 
> >> We could add role-name mapping at the adapter level.  I wanted to avoid
> >> that as it would all have to be done in config files.
> >
> > True, but I think it's needed. With the client endpoints I'm adding the
> > plan was that clients can self-register, discover their config as well as
> > update their config. Once we have that it would be nice to have adapters
> > retrieve config from KC.
> >
> 
> I guess role-name mapping on the client side would be pretty simple if
> each role has a URI.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Aug 13 10:17:56 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Aug 2015 10:17:56 -0400
Subject: [keycloak-dev] Remove address from registration and account
 management by default
In-Reply-To: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
Message-ID: <55CCA714.4050006@redhat.com>

Go for it.  I think the ldap tests depend on it though :)

On 8/13/2015 9:49 AM, Stian Thorgersen wrote:
> As highlighted by the UXP team the registration screen is not very nice. I propose we remove the address fields from the registration and account management. Instead we should have an example theme that shows adding additional fields to the screens.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Thu Aug 13 10:35:50 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Aug 2015 10:35:50 -0400
Subject: [keycloak-dev] Groups design
In-Reply-To: <1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>
	<55CC9933.6010405@redhat.com>
	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
	<55CCA3A6.8040002@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
Message-ID: <55CCAB46.7060602@redhat.com>



On 8/13/2015 10:17 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 13 August, 2015 4:03:18 PM
>> Subject: Re: [keycloak-dev] Groups design
>>
>>
>>
>> On 8/13/2015 9:32 AM, Stian Thorgersen wrote:
>>
>>>>>> * Groups can be members of one or more groups
>>>>>> * Users can be members of one or more groups
>>>>>> * Users inherit attributes of the groups they belong to.
>>>>>> * UserModel now has a getGroups(), hasGroup(), grantGroup(),
>>>>>> deleteGroup()
>>>>>> * Similar to default roles, we also have default groups.
>>>>>
>>>>> If we add default groups we don't need default roles and should remove
>>>>> them.
>>>>>
>>>>
>>>> Not sure I agree.  Users may not want roles.
>>>
>>> You mean may not want groups? I just don't like maintaining multiple ways
>>> to achieve the same thing - extra work for us and complicates
>>> documentation, etc..
>>>
>>
>> Yeah, sorry, users just might not create any groups, plus its backward
>> compatible to keep default roles.  The extra work to add default groups
>> is simple.  Its just duplication of the equivalent role code.
>
> It's still extra stuff that needs documenting/explaining and for users to understand. Having multiple things that does the "same thing" is a good way of making software complicated IMO.
>

Its not the same thing.  Its a convenience thing as with your proposal 
you have the extra step of creating the default group.

>>
>>> Why not just have a default group? Then users can add whatever roles and
>>> other groups they want to it?
>>>
>>
>> I don't like a "default group" for the same reason I don't like these
>> pseudo "built in" clients.
>
> I agree
>
> But, if someone wants to add some default roles to a user, why would they care if it's done through adding a default group and adding roles to that, rather than adding default roles directly? If we remove composite roles, it more or less makes the default roles feature a bit useless in either case, so would be better to use groups for it.
>

Why would they care?  Its an extra step.

>>
>>
>>>> Not really our problem.  If somebody does an overcomplicated design,
>>>> that's their problem.
>>>
>>> I think it is. It would be very hard for a user to interpret what would end
>>> up in the token even with relatively simple groups.
>>>
>>
>> Still, I dont think its our problem.  They can choose not to use the
>> feature.
>
> I disagree - KC is supposed to be easy to use, that should include the advanced features as well. We shouldn't create something that by design would potential be hard to use.
>

I don't think a Group mapper would conflict with other Group mappers as 
they would generally be concerned with mapping attribute and roles that 
are defined within the Group.

>>
>>>>
>>>>> * Shouldn't token format be defined by a client, not by groups? A client
>>>>> will expect a token is a certain format, but if it's dependent on what
>>>>> group a user belongs to all bets is off.
>>>>>
>>>>
>>>> Probably depends on the app.  But that's a good point.  Just seem cool
>>>> to be able to assign behavior to a group or even a role, rather than
>>>> assigning behavior to the client.
>>>
>>> I'd rather think that groups are the source of the information. So the
>>> available claims are:
>>>
>>> * Users roles and attributes
>>> * Groups roles and attributes
>>>
>>> But, then you still have a set of protocol mappers (either specified on a
>>> per-client as now, or ability to share these) that takes these claims and
>>> adds it to the token.
>>>
>>
>> Another way of looking at it is that the group defines of how attributes
>> and roles look inside the claim/assertion, rather than the client
>> defining how an attribute looks.
>>
>> I'm not entirely convinced is a great thing to have, but it does seem
>> like it would be useful.
>
> I'm not at all convinced ;)
>
> It'll be more important to be able to share a set of protocol mappers between clients. So a client should be able to define it's own protocol mappers, and it should be possible to define protocol mappers groups (or whatever it's called) at the realm level and re-use those. One issue with a shared protocol mappers group is that would define the "token format", but you then loose the ability to define what attributes/claims each client should retrieve.
>

I think defining a MapperGroup that could be shared between clients is a 
good thing.  Maybe a better name would be a ClientTemplate or something 
in which you could define not only mappers, but also protocol settings 
and scope.  I think this is orthogonal to Group mappers though...

Again, I don't think a Group mapper would conflict with other Group 
mappers as they would generally be concerned with mapping attribute and 
roles that are defined within the Group.

Group mappers are just a different type of association.  Again, allowing 
you to trigger behavior via a Group than by a Client.


>>
>>
>>>>
>>>>>>
>>>>>> Questions:
>>>>>> * Do we want to expand the concept of a Group so that clients and
>>>>>> identity brokers can belong to a Group? Or just create a separate
>>>>>> composite structure for this?
>>>>>
>>>>> Not sure we need that at all. Can't identity brokers and clients just use
>>>>> mappings to achieve the required effect? Or am I confusing what effect
>>>>> this would have.
>>>>>
>>>>
>>>> The concept of associating mappers to a Group isn't required, its just a
>>>> different way of attacking the problem.
>>>
>>> I don't like alternatives ;)
>>>
>>
>> I don't think it is an alternative.  It is just allowing the Group
>> decide how to map things.
>
> Can you elaborate on it a bit more then? As I see it:
>
> * Identity brokers should be able to add a mapper that defines what groups a user belongs to
> * Clients should be able to use a "group" mapper to add a group to the token. The group mapper would add the attributes and roles associated with the group to the token.
>

You would have to define a mapper like

Has Group:
Attribute name:
Maps to claim name:

Instead of just creating a mapper on the Group of

Attribute name:
Mapps to Claim Name:



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

From mposolda at redhat.com  Thu Aug 13 10:40:29 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 13 Aug 2015 16:40:29 +0200
Subject: [keycloak-dev] Remove address from registration and account
 management by default
In-Reply-To: <55CCA714.4050006@redhat.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
	<55CCA714.4050006@redhat.com>
Message-ID: <55CCAC5D.1030401@redhat.com>

I think not. Ldap tests are using some custom attributes like street or 
postalCode, but AFAIR don't depend on fields available in UI in account 
management or registration screen.

IMO will be good to show also multivalued attributes in the theme 
example ( plus, minus buttons - something similar like we have for 
"redirect uris" or "web origins" in client details screen in admin console).

Marek

On 13.8.2015 16:17, Bill Burke wrote:
> Go for it.  I think the ldap tests depend on it though :)
>
> On 8/13/2015 9:49 AM, Stian Thorgersen wrote:
>> As highlighted by the UXP team the registration screen is not very nice. I propose we remove the address fields from the registration and account management. Instead we should have an example theme that shows adding additional fields to the screens.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From mposolda at redhat.com  Thu Aug 13 10:56:53 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 13 Aug 2015 16:56:53 +0200
Subject: [keycloak-dev] public/private api module structure
In-Reply-To: <55CC9A06.3020705@redhat.com>
References: <55CB4129.5050009@redhat.com>	<916438427.9296844.1439384666723.JavaMail.zimbra@redhat.com>	<55CB4C57.2050301@redhat.com>	<913457544.9365979.1439389244155.JavaMail.zimbra@redhat.com>	<55CB7B3B.1040307@redhat.com>	<188045680.9690767.1439444846572.JavaMail.zimbra@redhat.com>	<55CC959F.8080206@redhat.com>	<1427692500.9969907.1439471278082.JavaMail.zimbra@redhat.com>
	<55CC9A06.3020705@redhat.com>
Message-ID: <55CCB035.4050605@redhat.com>

On 13.8.2015 15:22, Bill Burke wrote:
>
> On 8/13/2015 9:07 AM, Stian Thorgersen wrote:
>> I'm happy with:
>>
>> keycloak-core-api
>> keycloak-client-api
>> keycloak-server-api
>>
>> With regards to the protocol specific parts are you thinking those would be client specific things for each protocol? For example JWT utils?
> Everything.  For example, I have a helper abstract base class for
> Authenticator and RequireActionProvider.  Mappers can get access to the
> SAML Document model.
>
>
>
>> Further I think we should put core provider implementations into keycloak-services or maybe keycloak-default-providers or something. Then only have separate modules for those providers that need to be pluggable (jpa, mongo, etc..).
>>
>> Not sure if the way I counted it is accurate, but we seem to have 200 maven modules!!
>>
> Yeah, its insane...Its pretty much why I punted on converting from a WAR
> to modules :)
>
It looks to me that for the server, we have "just" around 50-60 modules :-)

Many maven modules are needed for adapters and their tests (For example 
there is jetty-core, jetty8, jetty91, jetty92 and each of them also has 
separate testsuite module etc) . Not sure how we can improve on it, but 
looks to me that not much as each app-server version we want to support 
needs separate adapter with the classes related to that version. There 
are also quite many maven modules for examples.

Marek

From brmeyer at redhat.com  Thu Aug 13 11:02:58 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 13 Aug 2015 11:02:58 -0400 (EDT)
Subject: [keycloak-dev] Operational monitoring of Keycloak server
In-Reply-To: <760752165.39790007.1437029396675.JavaMail.zimbra@redhat.com>
References: <55A3BA5C.2090906@redhat.com>
	<2071278650.37809022.1436856157015.JavaMail.zimbra@redhat.com>
	<55A4B2AB.9080508@redhat.com>
	<383530390.37875127.1436858054281.JavaMail.zimbra@redhat.com>
	<55A4C12C.8070305@redhat.com>
	<1137820905.37901015.1436861190539.JavaMail.zimbra@redhat.com>
	<55A74C01.4020104@redhat.com>
	<760752165.39790007.1437029396675.JavaMail.zimbra@redhat.com>
Message-ID: <1441019523.10050535.1439478178607.JavaMail.zimbra@redhat.com>

Sorry for the late response.

Potentially, integration with Hawkular might be an option.  http://www.hawkular.org/

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Vlastimil Elias" <velias at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, July 16, 2015 2:49:56 AM
> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server
> 
> 
> 
> ----- Original Message -----
> > From: "Vlastimil Elias" <velias at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 16 July, 2015 8:15:29 AM
> > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server
> > 
> > Hi,
> > 
> > OK, if DB is "realm" and "users" then it have to be well documented as
> > it is not obvious for people without deeper knowledge of KC.
> 
> We could always call it realm-database or something, but we have 3 different
> stores so should be separate status for them
> 
> > 
> > Do we have JIRA issue for this or should I create one?
> 
> Nope, so please create one
> 
> > 
> > Vl.
> > 
> > 
> > On 14.7.2015 10:06, Stian Thorgersen wrote:
> > >
> > > ----- Original Message -----
> > >> From: "Vlastimil Elias" <velias at redhat.com>
> > >> To: "Stian Thorgersen" <stian at redhat.com>
> > >> Cc: "Scott Rossillo" <srossillo at smartling.com>,
> > >> keycloak-dev at lists.jboss.org
> > >> Sent: Tuesday, 14 July, 2015 9:58:36 AM
> > >> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server
> > >>
> > >> On 14.7.2015 09:14, Stian Thorgersen wrote:
> > >>> ----- Original Message -----
> > >>>> From: "Vlastimil Elias" <velias at redhat.com>
> > >>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>> Cc: "Scott Rossillo" <srossillo at smartling.com>,
> > >>>> keycloak-dev at lists.jboss.org
> > >>>> Sent: Tuesday, 14 July, 2015 8:56:43 AM
> > >>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 14.7.2015 08:42, Stian Thorgersen wrote:
> > >>>>> Ok so we add one that just returns OK or ERROR which doesn't require
> > >>>>> authentication, but then we add another that can return more details,
> > >>>>> including stats and what the error is.
> > >>>> Yep. Simple http endpoinds for now, later all this info may be expose
> > >>>> over DMR or some other mechanism if necessary.
> > >>>>> For full health we should check all external services that are used
> > >>>>> (db,
> > >>>>> identity providers and user federation providers). Cluster sync will
> > >>>>> depend on what Infinispan exposes, but I imagine they'll have the
> > >>>>> required
> > >>>>> details avail.
> > >>>> Beside endpoint for full health check (which should summarize all
> > >>>> services into one flag if I understand correctly, which is good for
> > >>>> loadbalancer) we should expose separate endpoint for each service
> > >>>> health, as it is better for operational monitoring systems like
> > >>>> Nagios.
> > >>>> Admins are better informed what is going wrong and they can resolve
> > >>>> situation more quickly without necessity to search cause of general
> > >>>> failure flag somewhere else.
> > >>> We could have a single health endpoint that returns a 200 or 500 and
> > >>> also
> > >>> returns a json doc with details. Something like:
> > >>>
> > >>> {
> > >>>     realm: ok,
> > >>>     users: ok,
> > >>>     realmCache: error,
> > >>>     userCache: error,
> > >>>     identity-providers: {
> > >>>       google: ok,
> > >>>       facebook: error
> > >>>     },
> > >>>     user-federation: {
> > >>>       ldap: ok
> > >>>     }
> > >>> }
> > >>>
> > >>> I wonder if that's to much details to expose without authentication.
> > >> This should work, but I miss info about DB connection here. It is
> > >> crucial from operational point of view as this allows sysadmins quickly
> > >> detect that connection to DB is broken.
> > >>
> > >> I believe this kind of info can be safely exposed without
> > >> authentication. If the endpoint is clearly documented then access can be
> > >> always restricted on some network infra (webserver/proxy) ahead of KC.
> > > DB is "realm" and "users".
> > >
> > >>>> Vl.
> > >>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Vlastimil Elias" <velias at redhat.com>
> > >>>>>> To: "Scott Rossillo" <srossillo at smartling.com>, "Stian Thorgersen"
> > >>>>>> <stian at redhat.com>
> > >>>>>> Cc: keycloak-dev at lists.jboss.org
> > >>>>>> Sent: Tuesday, 14 July, 2015 8:34:29 AM
> > >>>>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak
> > >>>>>> server
> > >>>>>>
> > >>>>>> Yap, beside server-stat endpoint Stian talked about we should add
> > >>>>>> some
> > >>>>>> server-health endpoint also to be used for remote health monitoring
> > >>>>>> by
> > >>>>>> load balancers or systems like Nagios.
> > >>>>>> Simple http endpoint without authentication (as it doesn't leak any
> > >>>>>> sensitive information) is typically simplest way how to do this
> > >>>>>> monitoring.
> > >>>>>>
> > >>>>>> Vl.
> > >>>>>>
> > >>>>>> On 14.7.2015 05:13, Scott Rossillo wrote:
> > >>>>>>> Some type of health page would be great too for load balancers to
> > >>>>>>> monitor. Something that doesn't leak internal information but
> > >>>>>>> checks
> > >>>>>>> behind the scenes that:
> > >>>>>>> 1. Server can reach its databas(es)
> > >>>>>>> 2. Server cluster sync is working
> > >>>>>>> 3. Server can reach federation providers, etc.
> > >>>>>>> Endpoint should respond to get requests and return an http status
> > >>>>>>> reflective of server state.
> > >>>>>>>
> > >>>>>>> On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen <stian at redhat.com
> > >>>>>>> <mailto:stian at redhat.com>> wrote:
> > >>>>>>>
> > >>>>>>>        So looks like we're at agreement to add the additional info
> > >>>>>>>        you
> > >>>>>>>        wanted to server info page.
> > >>>>>>>
> > >>>>>>>        How about we add an additional endpoint server-stat that can
> > >>>>>>>        collect some stats about the server?
> > >>>>>>>
> > >>>>>>>        ----- Original Message -----
> > >>>>>>>        > From: "Vlastimil Elias" <velias at redhat.com
> > >>>>>>>        <mailto:velias at redhat.com>>
> > >>>>>>>        > To: "Stian Thorgersen" <stian at redhat.com
> > >>>>>>>        > <mailto:stian at redhat.com>>
> > >>>>>>>        > Cc: keycloak-dev at lists.jboss.org
> > >>>>>>>        <mailto:keycloak-dev at lists.jboss.org>
> > >>>>>>>        > Sent: Monday, 13 July, 2015 5:06:34 PM
> > >>>>>>>        > Subject: Re: [keycloak-dev] Operational monitoring of
> > >>>>>>>        > Keycloak
> > >>>>>>>        server
> > >>>>>>>        >
> > >>>>>>>        > Looks like I have to look at WildFly/EAP DMR to see what
> > >>>>>>>        > is
> > >>>>>>>        possible to
> > >>>>>>>        > do with it, as I'm not sure if it is about remote
> > >>>>>>>        > monitoring
> > >>>>>>>        also and
> > >>>>>>>        > if/how it can be use from monitoring systems like Splunk.
> > >>>>>>>        >
> > >>>>>>>        > Vl.
> > >>>>>>>        >
> > >>>>>>>        > On 13.7.2015 15:26, Stian Thorgersen wrote:
> > >>>>>>>        > > In WildFly/EAP that's DMR right? We're planning to make
> > >>>>>>>        Keycloak managable
> > >>>>>>>        > > through that as well. For example everything that goes
> > >>>>>>>        > > into
> > >>>>>>>        > > keycloak-server.json will eventually be moved to
> > >>>>>>>        standalone.xml. Same with
> > >>>>>>>        > > admin endpoints, everything you can do there you'll
> > >>>>>>>        > > eventually
> > >>>>>>>        be able to
> > >>>>>>>        > > do through DMR and jboss-cli as well.
> > >>>>>>>        > >
> > >>>>>>>        > > However, IMO it would make sense to at least expose
> > >>>>>>>        > > Keycloak
> > >>>>>>>        specific
> > >>>>>>>        > > information through the admin endpoints and console as
> > >>>>>>>        > > well.
> > >>>>>>>        Such number
> > >>>>>>>        > > of sessions, etc..
> > >>>>>>>        > >
> > >>>>>>>        > > ----- Original Message -----
> > >>>>>>>        > >> From: "Vlastimil Elias" <velias at redhat.com
> > >>>>>>>        <mailto:velias at redhat.com>>
> > >>>>>>>        > >> To: keycloak-dev at lists.jboss.org
> > >>>>>>>        <mailto:keycloak-dev at lists.jboss.org>
> > >>>>>>>        > >> Sent: Monday, 13 July, 2015 3:17:16 PM
> > >>>>>>>        > >> Subject: [keycloak-dev] Operational monitoring of
> > >>>>>>>        > >> Keycloak
> > >>>>>>>        > >> server
> > >>>>>>>        > >>
> > >>>>>>>        > >> Hi,
> > >>>>>>>        > >>
> > >>>>>>>        > >> as we deployed KC to production mode for
> > >>>>>>>        https://developers.redhat.com
> > >>>>>>>        > >> we started to think about operational monitoring, for
> > >>>>>>>        > >> example
> > >>>>>>>        from
> > >>>>>>>        > >> Nagios or other systems of this type.
> > >>>>>>>        > >>
> > >>>>>>>        > >> KC user guide doesn't contain any chapter covering this
> > >>>>>>>        topic, also no
> > >>>>>>>        > >> any success over google search, so looks like KC
> > >>>>>>>        > >> doesn't
> > >>>>>>>        > >> have
> > >>>>>>>        > >> any
> > >>>>>>>        > >> solution for this yet.
> > >>>>>>>        > >> But I believe this is an important area which must be
> > >>>>>>>        > >> solved
> > >>>>>>>        when KC is
> > >>>>>>>        > >> used for production.
> > >>>>>>>        > >>
> > >>>>>>>        > >> I can imagine monitoring of JDBC connection if JPA is
> > >>>>>>>        > >> used,
> > >>>>>>>        monitoring
> > >>>>>>>        > >> of Mongo connection if used as store, monitoring of
> > >>>>>>>        > >> LDAP
> > >>>>>>>        connection if
> > >>>>>>>        > >> LDAP federation is used etc.
> > >>>>>>>        > >> Also some statistics like numbers of active sso
> > >>>>>>>        > >> session,
> > >>>>>>>        number of
> > >>>>>>>        > >> logins per minute etc should be provided there.
> > >>>>>>>        > >>
> > >>>>>>>        > >> Monitoring is not about Keycloak core itself, it should
> > >>>>>>>        > >> be
> > >>>>>>>        available for
> > >>>>>>>        > >> extension developers also. For example we implemented
> > >>>>>>>        > >> own
> > >>>>>>>        > >> UserFederationProvider which calls backend REST
> > >>>>>>>        > >> services.
> > >>>>>>>        > >> We should be able to add info about this integration
> > >>>>>>>        > >> into
> > >>>>>>>        monitoring
> > >>>>>>>        > >> endpoint to be able to catch problems with this REST
> > >>>>>>>        > >> API.
> > >>>>>>>        > >>
> > >>>>>>>        > >> It should be probably implemented same way as used by
> > >>>>>>>        > >> underlying
> > >>>>>>>        > >> WildFly/EAP (JPA/JDBC is probably available for
> > >>>>>>>        > >> monitoring
> > >>>>>>>        there). I'm
> > >>>>>>>        > >> not sure if JMX is used there still or if some new
> > >>>>>>>        > >> framework
> > >>>>>>>        > >> is
> > >>>>>>>        > >> available for it.
> > >>>>>>>        > >> Or KC should use some form of KC REST API for this,
> > >>>>>>>        > >> which
> > >>>>>>>        should be
> > >>>>>>>        > >> extended by additional info from KC extensions?
> > >>>>>>>        > >>
> > >>>>>>>        > >> What do you think?
> > >>>>>>>        > >>
> > >>>>>>>        > >> Vlastimil
> > >>>>>>>        > >>
> > >>>>>>>        > >> P.S we have https://issues.jboss.org/browse/RHD-552 for
> > >>>>>>>        > >> Red
> > >>>>>>>        > >> Hat
> > >>>>>>>        > >> Developer instance of KC
> > >>>>>>>        > >>
> > >>>>>>>        > >> --
> > >>>>>>>        > >> Vlastimil Elias
> > >>>>>>>        > >> Principal Software Engineer
> > >>>>>>>        > >> jboss.org <http://jboss.org> Development Team
> > >>>>>>>        > >>
> > >>>>>>>        > >> _______________________________________________
> > >>>>>>>        > >> 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
> > >>>>>>>        > jboss.org <http://jboss.org> Development Team
> > >>>>>>>        >
> > >>>>>>>        >
> > >>>>>>>        _______________________________________________
> > >>>>>>>        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
> > >>>>>> jboss.org Development Team
> > >>>>>>
> > >>>>>>
> > >>>> --
> > >>>> Vlastimil Elias
> > >>>> Principal Software Engineer
> > >>>> jboss.org Development Team
> > >>>>
> > >>>>
> > >> --
> > >> Vlastimil Elias
> > >> Principal Software Engineer
> > >> jboss.org Development Team
> > >>
> > >>
> > 
> > --
> > Vlastimil Elias
> > Principal Software Engineer
> > jboss.org Development Team
> > 
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Thu Aug 13 11:29:20 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 13 Aug 2015 17:29:20 +0200
Subject: [keycloak-dev] Groups design
In-Reply-To: <55CCAB46.7060602@redhat.com>
References: <55CB4F1D.3000909@redhat.com>	<1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>	<55CC9933.6010405@redhat.com>	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>	<55CCA3A6.8040002@redhat.com>	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
Message-ID: <55CCB7D0.3050204@redhat.com>

On 13.8.2015 16:35, Bill Burke wrote:
>
> On 8/13/2015 10:17 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 13 August, 2015 4:03:18 PM
>>> Subject: Re: [keycloak-dev] Groups design
>>>
>>>
>>>
>>> On 8/13/2015 9:32 AM, Stian Thorgersen wrote:
>>>
>>>>>>> * Groups can be members of one or more groups
>>>>>>> * Users can be members of one or more groups
>>>>>>> * Users inherit attributes of the groups they belong to.
>>>>>>> * UserModel now has a getGroups(), hasGroup(), grantGroup(),
>>>>>>> deleteGroup()
>>>>>>> * Similar to default roles, we also have default groups.
>>>>>> If we add default groups we don't need default roles and should remove
>>>>>> them.
>>>>>>
>>>>> Not sure I agree.  Users may not want roles.
>>>> You mean may not want groups? I just don't like maintaining multiple ways
>>>> to achieve the same thing - extra work for us and complicates
>>>> documentation, etc..
>>>>
>>> Yeah, sorry, users just might not create any groups, plus its backward
>>> compatible to keep default roles.  The extra work to add default groups
>>> is simple.  Its just duplication of the equivalent role code.
>> It's still extra stuff that needs documenting/explaining and for users to understand. Having multiple things that does the "same thing" is a good way of making software complicated IMO.
>>
> Its not the same thing.  Its a convenience thing as with your proposal
> you have the extra step of creating the default group.
>
>>>> Why not just have a default group? Then users can add whatever roles and
>>>> other groups they want to it?
>>>>
>>> I don't like a "default group" for the same reason I don't like these
>>> pseudo "built in" clients.
>> I agree
>>
>> But, if someone wants to add some default roles to a user, why would they care if it's done through adding a default group and adding roles to that, rather than adding default roles directly? If we remove composite roles, it more or less makes the default roles feature a bit useless in either case, so would be better to use groups for it.
>>
> Why would they care?  Its an extra step.
>
>>>
>>>>> Not really our problem.  If somebody does an overcomplicated design,
>>>>> that's their problem.
>>>> I think it is. It would be very hard for a user to interpret what would end
>>>> up in the token even with relatively simple groups.
>>>>
>>> Still, I dont think its our problem.  They can choose not to use the
>>> feature.
>> I disagree - KC is supposed to be easy to use, that should include the advanced features as well. We shouldn't create something that by design would potential be hard to use.
>>
> I don't think a Group mapper would conflict with other Group mappers as
> they would generally be concerned with mapping attribute and roles that
> are defined within the Group.
-1 from me for this as well. What if user is member of "groupA", which 
has 10 protocol mappers for adding 10 attributes to the token. Then I 
have clientA where I want these attributes, but another clientB where I 
don't want them. Do I have a possibility to disable having those 10 
attributes in the token for clientB?
>
>>>>>> * Shouldn't token format be defined by a client, not by groups? A client
>>>>>> will expect a token is a certain format, but if it's dependent on what
>>>>>> group a user belongs to all bets is off.
>>>>>>
>>>>> Probably depends on the app.  But that's a good point.  Just seem cool
>>>>> to be able to assign behavior to a group or even a role, rather than
>>>>> assigning behavior to the client.
>>>> I'd rather think that groups are the source of the information. So the
>>>> available claims are:
>>>>
>>>> * Users roles and attributes
>>>> * Groups roles and attributes
>>>>
>>>> But, then you still have a set of protocol mappers (either specified on a
>>>> per-client as now, or ability to share these) that takes these claims and
>>>> adds it to the token.
>>>>
>>> Another way of looking at it is that the group defines of how attributes
>>> and roles look inside the claim/assertion, rather than the client
>>> defining how an attribute looks.
>>>
>>> I'm not entirely convinced is a great thing to have, but it does seem
>>> like it would be useful.
>> I'm not at all convinced ;)
>>
>> It'll be more important to be able to share a set of protocol mappers between clients. So a client should be able to define it's own protocol mappers, and it should be possible to define protocol mappers groups (or whatever it's called) at the realm level and re-use those. One issue with a shared protocol mappers group is that would define the "token format", but you then loose the ability to define what attributes/claims each client should retrieve.
>>
> I think defining a MapperGroup that could be shared between clients is a
> good thing.  Maybe a better name would be a ClientTemplate or something
> in which you could define not only mappers, but also protocol settings
> and scope.  I think this is orthogonal to Group mappers though...
+1 for ClientTemplate .

Marek
>
> Again, I don't think a Group mapper would conflict with other Group
> mappers as they would generally be concerned with mapping attribute and
> roles that are defined within the Group.
>
> Group mappers are just a different type of association.  Again, allowing
> you to trigger behavior via a Group than by a Client.
>
>
>>>
>>>>>>> Questions:
>>>>>>> * Do we want to expand the concept of a Group so that clients and
>>>>>>> identity brokers can belong to a Group? Or just create a separate
>>>>>>> composite structure for this?
>>>>>> Not sure we need that at all. Can't identity brokers and clients just use
>>>>>> mappings to achieve the required effect? Or am I confusing what effect
>>>>>> this would have.
>>>>>>
>>>>> The concept of associating mappers to a Group isn't required, its just a
>>>>> different way of attacking the problem.
>>>> I don't like alternatives ;)
>>>>
>>> I don't think it is an alternative.  It is just allowing the Group
>>> decide how to map things.
>> Can you elaborate on it a bit more then? As I see it:
>>
>> * Identity brokers should be able to add a mapper that defines what groups a user belongs to
>> * Clients should be able to use a "group" mapper to add a group to the token. The group mapper would add the attributes and roles associated with the group to the token.
>>
> You would have to define a mapper like
>
> Has Group:
> Attribute name:
> Maps to claim name:
>
> Instead of just creating a mapper on the Group of
>
> Attribute name:
> Mapps to Claim Name:
>
>
>


From ssilvert at redhat.com  Thu Aug 13 11:33:28 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 13 Aug 2015 11:33:28 -0400
Subject: [keycloak-dev] Remove address from registration and account
 management by default
In-Reply-To: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
Message-ID: <55CCB8C8.4000008@redhat.com>

On 8/13/2015 9:49 AM, Stian Thorgersen wrote:
> As highlighted by the UXP team the registration screen is not very nice. I propose we remove the address fields from the registration and account management. Instead we should have an example theme that shows adding additional fields to the screens.
Could you also get rid of First Name and Last Name?  Why are they 
required fields?

Incidentally, to properly localize the account management screen to 
China, you would put the Last Name before the First Name.   As I 
understand it, putting the given name before the family name can be 
considered disrespectful.  So it might be a bad thing to have those 
fields hard-coded anyway.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Thu Aug 13 13:00:34 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 13 Aug 2015 19:00:34 +0200
Subject: [keycloak-dev] Remove address from registration and account
 management by default
In-Reply-To: <55CCB8C8.4000008@redhat.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
	<55CCB8C8.4000008@redhat.com>
Message-ID: <55CCCD32.2010302@redhat.com>

On 13.8.2015 17:33, Stan Silvert wrote:
> On 8/13/2015 9:49 AM, Stian Thorgersen wrote:
>> As highlighted by the UXP team the registration screen is not very nice. I propose we remove the address fields from the registration and account management. Instead we should have an example theme that shows adding additional fields to the screens.
> Could you also get rid of First Name and Last Name?  Why are they
> required fields?
>
> Incidentally, to properly localize the account management screen to
> China, you would put the Last Name before the First Name.   As I
> understand it, putting the given name before the family name can be
> considered disrespectful.  So it might be a bad thing to have those
> fields hard-coded anyway.
Question is where exactly is the border between "basic" and "advanced" 
info :-)

To me, first name and last name belongs to "basic" info and 90% of 
deployments want it here IMO. If someone really doesn't want firstName 
and lastName or he wants them in different order, he can edit theme file 
by himself and do whatever he want.

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


From ssilvert at redhat.com  Thu Aug 13 13:27:37 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 13 Aug 2015 13:27:37 -0400
Subject: [keycloak-dev] Remove address from registration and account
 management by default
In-Reply-To: <55CCCD32.2010302@redhat.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
	<55CCB8C8.4000008@redhat.com> <55CCCD32.2010302@redhat.com>
Message-ID: <55CCD389.9080400@redhat.com>

On 8/13/2015 1:00 PM, Marek Posolda wrote:
> On 13.8.2015 17:33, Stan Silvert wrote:
>> On 8/13/2015 9:49 AM, Stian Thorgersen wrote:
>>> As highlighted by the UXP team the registration screen is not very 
>>> nice. I propose we remove the address fields from the registration 
>>> and account management. Instead we should have an example theme that 
>>> shows adding additional fields to the screens.
>> Could you also get rid of First Name and Last Name?  Why are they
>> required fields?
>>
>> Incidentally, to properly localize the account management screen to
>> China, you would put the Last Name before the First Name.   As I
>> understand it, putting the given name before the family name can be
>> considered disrespectful.  So it might be a bad thing to have those
>> fields hard-coded anyway.
> Question is where exactly is the border between "basic" and "advanced" 
> info :-)
>
> To me, first name and last name belongs to "basic" info and 90% of 
> deployments want it here IMO. If someone really doesn't want firstName 
> and lastName or he wants them in different order, he can edit theme 
> file by himself and do whatever he want.
That's probably reasonable, but why are they required fields? Sometimes 
a user is not a person.

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


From lennart.jorelid at gmail.com  Thu Aug 13 14:18:37 2015
From: lennart.jorelid at gmail.com (=?UTF-8?Q?Lennart_J=C3=B6relid?=)
Date: Thu, 13 Aug 2015 20:18:37 +0200
Subject: [keycloak-dev] Fwd: Remove address from registration and account
 management by default
In-Reply-To: <CAJ1fz81+YsRejVf3rhNO_Up1JQaYfRS-3y5cuQwekK7TJaXoBg@mail.gmail.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
	<CAJ1fz81+YsRejVf3rhNO_Up1JQaYfRS-3y5cuQwekK7TJaXoBg@mail.gmail.com>
Message-ID: <CAJ1fz839Avyv+La4V67nOCwcRW+6CMx2=gFVsCFBX6eYtJBrbg@mail.gmail.com>

[Forwarding to the list; not meant as a personal reply.]

Hello there,

This is exacly what I am struggling with at the moment. I have found a
number of things which would need clarification in documentation as well as
in examples:

   1. *Custom user data properties/fields*. It seems that one has to/ought
   to add custom properties to three places in the theme files: account, admin
   and registration. However, the ways to add them differ greatly, as each FTL
   template structure is quite different. (Account uses account.ftl; Admin
   uses partials/user-attribute-entry.ftl). Pattern definitions and
   explanations are missing from examples and documentation, as far as I can
   tell.
   2. *Editable properties per role*. Realm admins/editors could perhaps be
   able to edit all properties (except primary key/ID value) for all the users
   in a realm - but we would typically like to restrict which properties (both
   basic and custom attributes) are editable depending on the roles/privileges
   a user has in the realm. (For example, it would likely be a bad ide to
   permit users to change their names and birthday arbitrarily after
   registration). How do we restrict editability of normaly and custom user
   properteis - both in terms of the data and the forms required to interact
   with keycloak? Pattern definitions and explanations are missing from
   examples and documentation, as far as I can tell.
   3. *Linking users to roles/privileges in other realms.* How should one
   construct realms to grant roles & privileges automatically to users in
   other realms? (For example: All Users in Literary Society A can register
   for a party hosted by Literary Society B. Hence, how does realm admin B
   grant role KnownGuest to all users in realm A, to permit them to access
   Society B's register-to-the-event-page? Assume, of course, that both A and
   B are managed by the same Keycloak DB, so basic identity attributes should
   be extracted normally from Keycloak. Neither realm admins from A or B have
   master realm access.) Pattern definitions and explanations are missing from
   examples and documentation, as far as I can tell.


2015-08-13 15:49 GMT+02:00 Stian Thorgersen <stian at redhat.com>:

> As highlighted by the UXP team the registration screen is not very nice. I
> propose we remove the address fields from the registration and account
> management. Instead we should have an example theme that shows adding
> additional fields to the screens.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

--
+==============================+
| B?sta h?lsningar,
| [sw. "Best regards"]
|
| Lennart J?relid
| EAI Architect & Integrator
|
| jGuru Europe AB
| M?lnlycke - Kista
|
| Email: lj at jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




-- 

--
+==============================+
| B?sta h?lsningar,
| [sw. "Best regards"]
|
| Lennart J?relid
| EAI Architect & Integrator
|
| jGuru Europe AB
| M?lnlycke - Kista
|
| Email: lj at jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150813/639f2a2b/attachment.html 

From bburke at redhat.com  Thu Aug 13 14:47:56 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Aug 2015 14:47:56 -0400
Subject: [keycloak-dev] Fwd: Remove address from registration and
 account management by default
In-Reply-To: <CAJ1fz839Avyv+La4V67nOCwcRW+6CMx2=gFVsCFBX6eYtJBrbg@mail.gmail.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
	<CAJ1fz81+YsRejVf3rhNO_Up1JQaYfRS-3y5cuQwekK7TJaXoBg@mail.gmail.com>
	<CAJ1fz839Avyv+La4V67nOCwcRW+6CMx2=gFVsCFBX6eYtJBrbg@mail.gmail.com>
Message-ID: <55CCE65C.9050202@redhat.com>



On 8/13/2015 2:18 PM, Lennart J?relid wrote:
> [Forwarding to the list; not meant as a personal reply.]
>
> Hello there,
>
> This is exacly what I am struggling with at the moment. I have found a
> number of things which would need clarification in documentation as well
> as in examples:
>
>  1. *Custom user data properties/fields*. It seems that one has to/ought
>     to add custom properties to three places in the theme files:
>     account, admin and registration. However, the ways to add them
>     differ greatly, as each FTL template structure is quite different.
>     (Account uses account.ftl; Admin uses
>     partials/user-attribute-entry.ftl). Pattern definitions and
>     explanations are missing from examples and documentation, as far as
>     I can tell.

Stian wants a generic service.  I disagree because I don't think it will 
be used.  I just look at developers.redhat.com for example, and they 
have differing formatting requirements.  You would end up recreating cSS 
and HTML within the admin console.  Not something I'm kean on doing.

>  2. *Editable properties per role*. Realm admins/editors could perhaps
>     be able to edit all properties (except primary key/ID value) for all
>     the users in a realm - but we would typically like to restrict which
>     properties (both basic and custom attributes) are editable depending
>     on the roles/privileges a user has in the realm. (For example, it
>     would likely be a bad ide to permit users to change their names and
>     birthday arbitrarily after registration). How do we restrict
>     editability of normaly and custom user properteis - both in terms of
>     the data and the forms required to interact with keycloak? Pattern
>     definitions and explanations are missing from examples and
>     documentation, as far as I can tell.

We don't have a way to do this in the account service yet.  You can 
modify the forms to display whatever you want, but a rogue user would be 
able to modify any attribute they wanted.  Ugh, we probably need to fix 
this.

>  3. *Linking users to roles/privileges in other realms.* How should one
>     construct realms to grant roles & privileges automatically to users
>     in other realms? (For example: All Users in Literary Society A can
>     register for a party hosted by Literary Society B. Hence, how does
>     realm admin B grant role KnownGuest to all users in realm A, to
>     permit them to access Society B's register-to-the-event-page?
>     Assume, of course, that both A and B are managed by the same
>     Keycloak DB, so basic identity attributes should be extracted
>     normally from Keycloak. Neither realm admins from A or B have master
>     realm access.) Pattern definitions and explanations are missing from
>     examples and documentation, as far as I can tell.
>

I don't think we'll ever have the ability to link realms.  If we did 
ever add it it would be next year.  Too much in queue at the moment.



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

From lennart.jorelid at gmail.com  Thu Aug 13 17:34:58 2015
From: lennart.jorelid at gmail.com (=?UTF-8?Q?Lennart_J=C3=B6relid?=)
Date: Thu, 13 Aug 2015 23:34:58 +0200
Subject: [keycloak-dev] Fwd: Remove address from registration and
 account management by default
In-Reply-To: <55CCE65C.9050202@redhat.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
	<CAJ1fz81+YsRejVf3rhNO_Up1JQaYfRS-3y5cuQwekK7TJaXoBg@mail.gmail.com>
	<CAJ1fz839Avyv+La4V67nOCwcRW+6CMx2=gFVsCFBX6eYtJBrbg@mail.gmail.com>
	<55CCE65C.9050202@redhat.com>
Message-ID: <CAJ1fz80fUg6tBLdga87SiX3POsLrGRGn-xD6fBpyqLvn3vEDdA@mail.gmail.com>

OK; I hear you.

I do believe, however, that the things above - and quite a few other things
- are really required to get
the usability of an "Out Of The Box" product. Let me suggest some things
below:

2015-08-13 20:47 GMT+02:00 Bill Burke <bburke at redhat.com>:

>
> On 8/13/2015 2:18 PM, Lennart J?relid wrote:
> > [Forwarding to the list; not meant as a personal reply.]
> >
> > Hello there,
> >
> > This is exacly what I am struggling with at the moment. I have found a
> > number of things which would need clarification in documentation as well
> > as in examples:
> >
> >  1. *Custom user data properties/fields*. It seems that one has to/ought
> >     to add custom properties to three places in the theme files:
> >     account, admin and registration. However, the ways to add them
> >     differ greatly, as each FTL template structure is quite different.
> >     (Account uses account.ftl; Admin uses
> >     partials/user-attribute-entry.ftl). Pattern definitions and
> >     explanations are missing from examples and documentation, as far as
> >     I can tell.
>
> Stian wants a generic service.  I disagree because I don't think it will
> be used.  I just look at developers.redhat.com for example, and they
> have differing formatting requirements.  You would end up recreating cSS
> and HTML within the admin console.  Not something I'm kean on doing.
>

This is a tricky task to create in a simple manner; I agree with that.
The model and view could be created separately, and joined to a result
using DI. So ...

   1. *Model - from a Dev perspective*: Defining entity classes (JPA and
   JAXB to combine storage and transport) is pretty common for developers, as
   is extending specified interfaces. If you simplify the model for users to a
   standard Entity and include a setter/getter pair for something which is an
   interface (instead of today's mapping between unvalidateable string and
   unvalidateable string), developers can simply implement their own custom
   metadata class which can include Validation on any of the fields - not only
   passwords. Today, we cannot validate the content of any custom properties,
   as they are stored as Strings.
   2. *Model - from a Non-Dev perspective*: Non-developers require quite a
   lot of tooling to create the model classes. Is it your idea of an "Out of
   the Box" solution that non-devs should be able to define the custom
   properties of each user? If so, I believe that the "generate-the-model"
   tooling is currently missing from the codebase.
   3. *Model - performance: *The current solution ought to give really poor
   performance when the number of users in the keycloak database rises; the
   JPA implementation of custom attributes stashes all of them in a single
   table with a String containing an UUID for primary key... at least with an
   integer, custom attributes for a single user will be stored at similar
   locations. Your UUID approach guarantees that each user attribtue is
   scattered evenly across the table, and re-indexing will happen every time a
   new value is inserted. There are quite a few other options to implement
   this functionality that would improve performance compared to the current
   solution - but these require some form of development backround from a
   user. Which approach will KeyCloak take?
   4. *View - from a Dev perspective*: We architects and developers like
   standards that we have encountered before, and creating a complete theme
   with the level of control you envision above is, quite frankly, *really
   difficult* today. Not only is the documentation lacking on theme basic
   semantics, but you need to understand how quite a lot of fragments are
   joined together by Freemarker to a live page. While Freemarker is not
   unheard of, it is an oddball (i.e. not part of the standard JavaEE
   platform).
   5. *View - usability*: Usability is king. If you would like to improve
   usability for people trying to create custom user properties, I believe
   that you must use standard JavaScript frameworks or JavaEE tech. A
   suggestion: create a KeyCloak AngularJS module which contains a set of
   custom directives - this implies that users can create complete pages
   containing keycloak-specific tags. This implies that we can see all views
   in a theme, including the directives for custom attributes. I believe this
   would be considerably simpler than understanding which Freemarker fragments
   are used in a particular use case, as is the case today. With improved
   usability comes reduced burden of documentation, which should please quite
   a lot of you KeyCloak devs.
   6. *View - conclusion:* I don't think that today's freemarker approach
   works - and while I can certainly create another ProviderFactory than the
   Freemarker one, I don't know the end result which I should target. What
   pages should be done, and in which order are they called?

>  2. *Editable properties per role*. Realm admins/editors could perhaps
> >     be able to edit all properties (except primary key/ID value) for all
> >     the users in a realm - but we would typically like to restrict which
> >     properties (both basic and custom attributes) are editable depending
> >     on the roles/privileges a user has in the realm. (For example, it
> >     would likely be a bad ide to permit users to change their names and
> >     birthday arbitrarily after registration). How do we restrict
> >     editability of normaly and custom user properteis - both in terms of
> >     the data and the forms required to interact with keycloak? Pattern
> >     definitions and explanations are missing from examples and
> >     documentation, as far as I can tell.
>
> We don't have a way to do this in the account service yet.  You can
> modify the forms to display whatever you want, but a rogue user would be
> able to modify any attribute they wanted.  Ugh, we probably need to fix
> this.
>

I think that this is core functionality, if KeyCloak should really work as
an out-of-the-box solution.
In particular, since you folks have taken the approach that KeyCloak should
hold a set of base
properties for each user, and supply means to extend those base properties
with custom properties.

This means that using KeyCloak should really imply 3 initial steps after
installation:


   1. Define your set of custom user properties.
   2. Create a theme in order to be able to handle your custom user
   properties (store, manage, etc.)
   3. Migrate (or Federate) all users from the current IDM
   database/application to KeyCloak. This means that it must be a trivial (and
   well-example'd/well-documented) task to develop a Class which reads the
   currnet IDM data and makes instances of KeyCloak UserModel instances,
   including all its extra properties.

This means that the KeyCloak documentation must walk users/developers
through these steps. In some detail. Right?

>
>
> >  3. *Linking users to roles/privileges in other realms.* How should one
> >     construct realms to grant roles & privileges automatically to users
> >     in other realms? (For example: All Users in Literary Society A can
> >     register for a party hosted by Literary Society B. Hence, how does
> >     realm admin B grant role KnownGuest to all users in realm A, to
> >     permit them to access Society B's register-to-the-event-page?
> >     Assume, of course, that both A and B are managed by the same
> >     Keycloak DB, so basic identity attributes should be extracted
> >     normally from Keycloak. Neither realm admins from A or B have master
> >     realm access.) Pattern definitions and explanations are missing from
> >     examples and documentation, as far as I can tell.
> >
>
> I don't think we'll ever have the ability to link realms.  If we did
> ever add it it would be next year.  Too much in queue at the moment.
>

Hm. This feasture is really important to me.
I can certainly summon up some JIRAs for it, and suggest some compliant
solution and PRs.
If you wish, ping me on Skype to discuss.


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



-- 

--
+==============================+
| B?sta h?lsningar,
| [sw. "Best regards"]
|
| Lennart J?relid
| EAI Architect & Integrator
|
| jGuru Europe AB
| M?lnlycke - Kista
|
| Email: lj at jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150813/38e84eca/attachment.html 

From satyajit.das at spire2grow.com  Thu Aug 13 23:32:31 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Fri, 14 Aug 2015 09:02:31 +0530
Subject: [keycloak-dev] key cloak findings
Message-ID: <CA+oCsRosc=TFMEOOK_ucEAaMUeVt++D==gwyGf1zALQHN7DOcA@mail.gmail.com>

Hi kindly see the below mentioned scenario and result. please advise
whether the findings is as per expectations.

1) I created a new service copied the keycloak.json from an existing
(registered at keycloak server) webservice project.
I didn't register the new service at key cloak , deployed it on tomcat and
executed the program. The new service gets called even if it is not
registered at keycloak server.

2) I changed the public shared key.here the new service failed saying token
mismatch.


Kindly let me know your thoughts.

Regards,
Satya.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150814/0026c5de/attachment.html 

From bburke at redhat.com  Fri Aug 14 09:07:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Aug 2015 09:07:41 -0400
Subject: [keycloak-dev] key cloak findings
In-Reply-To: <CA+oCsRosc=TFMEOOK_ucEAaMUeVt++D==gwyGf1zALQHN7DOcA@mail.gmail.com>
References: <CA+oCsRosc=TFMEOOK_ucEAaMUeVt++D==gwyGf1zALQHN7DOcA@mail.gmail.com>
Message-ID: <55CDE81D.1030206@redhat.com>

I have no idea what you are saying...

On 8/13/2015 11:32 PM, Satyajit Das wrote:
> Hi kindly see the below mentioned scenario and result. please advise
> whether the findings is as per expectations.
>
> 1) I created a new service copied the keycloak.json from an existing
> (registered at keycloak server) webservice project.
> I didn't register the new service at key cloak , deployed it on tomcat
> and executed the program. The new service gets called even if it is not
> registered at keycloak server.
>
> 2) I changed the public shared key.here the new service failed saying
> token mismatch.
>
>
> Kindly let me know your thoughts.
>
> Regards,
> Satya.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Fri Aug 14 09:12:12 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Aug 2015 09:12:12 -0400
Subject: [keycloak-dev] [keycloak-user] Would like to deprecate/remove
 JPA/Mongo UserSessions
In-Reply-To: <CA+E3Fw2Lhn5uOSE-V2gyh+cut-OMS_zFoaunKLFQi2gfY0+45g@mail.gmail.com>
References: <55C0EEE0.9050307@redhat.com>
	<CA+E3Fw2Lhn5uOSE-V2gyh+cut-OMS_zFoaunKLFQi2gfY0+45g@mail.gmail.com>
Message-ID: <55CDE92C.2070802@redhat.com>

The abstraction will still againt and it will still be possible to plug 
in your own session implementation.  But we don't think using JPA or 
Mongo is a good solution for manganging UserSessionModel.  That's the 
biggest reason we are deprecating it.

FYI, not sure what you mean by "JavaEE style clustering".  Infinispan is 
just a distributed cache/data grid and nothing to do with Java EE.  I 
don't see how Infinispan is any different than Redis.

On 8/14/2015 3:42 AM, David Illsley wrote:
> I'd really like to be able to run Keycloak without relying on JavaEE
> style clustering, and instead rely on modern 12-factor approaches. I was
> planning to do that by implementing a bunch of interfaces to use redis
> rather than JPA/Mongo/Infinispan, so I'm keen that you don't tie things
> too tightly to infinispan (not that I think you would. infinispan and
> redis effectively provide simple key/value stores).
>
> On Tue, Aug 4, 2015 at 5:57 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     Hi all,
>
>     Keycloak team would like to deprecate and remove the JPA and Mongo
>     stores for UserSessions and just provide an Infinispan one.  It is a
>     pain to maintain these, and in our opinion, users really shouldn't be
>     using JPA or Mongo to store User Sessions.  Infinispan has a wide
>     variety of configuration options for internal, external, and cloud
>     networks.
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

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

From bburke at redhat.com  Fri Aug 14 15:18:28 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Aug 2015 15:18:28 -0400
Subject: [keycloak-dev] auth spi docs/examples available in master
Message-ID: <55CE3F04.3020505@redhat.com>

WRote about 15 pages of docs.  Created an example under 
examples/providers/authenticator.  It is both a required action and 
authenticator example.

If you have time, please review.  If you don't...oh well...

Refactored the SPI a bit when I created the examples.  Hopefully it is a 
lot simpler.



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

From vinayan3 at gmail.com  Fri Aug 14 15:42:39 2015
From: vinayan3 at gmail.com (Vinay Anantharaman)
Date: Fri, 14 Aug 2015 15:42:39 -0400
Subject: [keycloak-dev] Implementing database-service example in Python
In-Reply-To: <55CC95FD.6050601@redhat.com>
References: <CANWAcaUP3jXVGY+cmAsnyEp0AiHYoBENucf4XO0cbPq3Ef89bg@mail.gmail.com>
	<826281598.9693806.1439445653118.JavaMail.zimbra@redhat.com>
	<55CC95FD.6050601@redhat.com>
Message-ID: <CANWAcaVnBSaF22bHAXyyT8roMTD7pNLP6GVtOFyedixhzOP8zQ@mail.gmail.com>

I'll be looking into this and will report back if a library exists for
Python to read JWT tokens.

I was wondering is there an API on the KeyCloak server for doing JWT token
verification? Or rather should we decode the token and use the REST admin
endpoints if we need to query more information?


Vinay

On Thu, Aug 13, 2015 at 9:05 AM, Bill Burke <bburke at redhat.com> wrote:

> If you're interested in becoming a contributor Vinay, this would be a
> very useful extension!
>
> BTW, we also have a "lightweight" Java Security HTTP Proxy based on
> Undertow that you can use to secure python apps.
>
> On 8/13/2015 2:00 AM, Stian Thorgersen wrote:
> > Afraid we don't have any libraries for Python yet.
> >
> > Simply verifying the token should be relatively straight forward though.
> It's a standard JWT token (base64 encoded json) with a JWS signature. You
> can look at RSATokenVerifier to see what details should be verified
> (expiration date, issuer, etc..). You also need to verify the signature.
> There may quite likely be JWT libraries for Python you can use.
> >
> > ----- Original Message -----
> >> From: "Vinay Anantharaman" <vinayan3 at gmail.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 13 August, 2015 12:21:01 AM
> >> Subject: [keycloak-dev] Implementing database-service example in Python
> >>
> >> Hi,
> >> I'm trying to implement the example database service from Python. The
> >> description is here:
> >>
> >>
> >>
> >> https://github.com/keycloak/keycloak/tree/master/examples/demo-template
> >>
> >> Our backend service is contacted directly by clients with an access
> token
> >> from the Keycloak server. We would like to verify access tokens are and
> then
> >> return some data they need. I was looking at the code here:
> >>
> >>
> >>
> >>
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/database-
> >> service/src/main/java/org/keycloak/example/oauth/CustomerService.java
> >>
> >> In Java this seems quite trivial with the support of Keycloak
> libraries. In
> >> Python I won't have them. What are the APIs on Keycloak I can use to
> verify
> >> an access token? Furthermore, are you aware of any classes like
> >> RSATokenVerifier for python? I saw it being used here:
> >>
> >>
> >>
> >>
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/OAuthClient.java#L319
> >>
> >> Thanks,
> >>
> >>
> >> Vinay Anantharaman
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Vinay Anantharaman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150814/e3c6eae2/attachment.html 

From vinayan3 at gmail.com  Fri Aug 14 16:22:41 2015
From: vinayan3 at gmail.com (Vinay Anantharaman)
Date: Fri, 14 Aug 2015 16:22:41 -0400
Subject: [keycloak-dev] API for Registering users / Flow for registration on
	iOS
Message-ID: <CANWAcaXQ9TsUj-4UHRyyBgksq6AEsyDEgNy8AyD+Sxy2DVd9GQ@mail.gmail.com>

Hi,
I would like to make an iOS app which uses social login using Facebook. I
don't want to have the user's register using Keycloak's HTML form to
register. I've made an app before where we had a native UI for social login
for Facebook. I passed the FB Access token to my  backend and was able to
create a user from there.

How can I get this workflow with Keycloak? I dug around the docs and
couldn't find anything. I assume that Keycloak's HTML registration forms
must be submitting and accept social login tokens to create users.


Thanks,



Vinay Anantharamann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150814/18e93739/attachment.html 

From bburke at redhat.com  Sat Aug 15 11:38:02 2015
From: bburke at redhat.com (Bill Burke)
Date: Sat, 15 Aug 2015 11:38:02 -0400
Subject: [keycloak-dev] QE tests failing
Message-ID: <55CF5CDA.5080602@redhat.com>

QE tests are failing in build.  I've been merging anyways because the 
normal build tests pass.

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

From bburke at redhat.com  Sat Aug 15 18:05:30 2015
From: bburke at redhat.com (Bill Burke)
Date: Sat, 15 Aug 2015 18:05:30 -0400
Subject: [keycloak-dev] Abstract SMS support
Message-ID: <55CFB7AA.3080406@redhat.com>

I was thinking that we would create abstract support for SMS support for 
Keycloak.  We would define a simple Provider interface for sending text 
messages.  We would not provide anything out of the box for now.  We 
would require users to implement their own SMS provider and plug it in.

Basically, we'd have an SMS OTP Authenticator for both the browser login 
and reset-credentials flows.  Keycloak would just send an SMS with a 
one-time secret code that you have to enter in.  We also would implement 
a validate mobile number required action too.

I don't think any of this would take very long (a day or two?) once I 
get the reset-credential pluggable-flow support done.

Later on, maybe its something we could integrate with Aerogear UPS out 
of the box?



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

From bburke at redhat.com  Sat Aug 15 19:15:17 2015
From: bburke at redhat.com (Bill Burke)
Date: Sat, 15 Aug 2015 19:15:17 -0400
Subject: [keycloak-dev] refactoring reset password
Message-ID: <55CFC805.5000002@redhat.com>

I'm refactoring reset password.  I'll be adding a pluggable 
"reset-credentials" flow so that users can add things like answering 
secret questions before they are sent the email.  They will also be able 
to remove/disable sending an email and implement their own mechanism, 
i.e. SMS.

Our old implementation would just reset the user's password, they would 
then have to click back to application and restart the login process. 
With flows, I can log the user in.  Isn't that a better approach?

The only issue with automatic login is OTP.  What should be the default 
behavior be here?:

1) If OTP is set up for the user or if required by realm, automatically 
set the OTP required action.
2) If OTP is set up for the user and not required by realm, disable 
their OTP, let them log in.
3) If OTP is set up for the user or if required by realm, don't 
automatically set the OTP required action, let the user login after 
successful email
4) If OTP is set up for the user or required by realm, don't set OTP 
required action, after successful email, require them to enter in the otp

I think the default behavior should be #1.  Without coding, users would 
still be able to configure any option above in the admin console by 
adding various authenticators to the flow.

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

From thomas.raehalme at aitiofinland.com  Sun Aug 16 06:41:06 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Sun, 16 Aug 2015 13:41:06 +0300
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <55CFB7AA.3080406@redhat.com>
References: <55CFB7AA.3080406@redhat.com>
Message-ID: <CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>

Hi!

Sounds good!

However it might be a good idea to include a generic HTTP/REST
implementation which you could configure through the admin interface to
deliver SMS messages to any service supporting HTTP? I'm pretty sure this
would satisfy most users.

What do you think?

Best regards,
Thomas
On Aug 16, 2015 1:06 AM, "Bill Burke" <bburke at redhat.com> wrote:

> I was thinking that we would create abstract support for SMS support for
> Keycloak.  We would define a simple Provider interface for sending text
> messages.  We would not provide anything out of the box for now.  We
> would require users to implement their own SMS provider and plug it in.
>
> Basically, we'd have an SMS OTP Authenticator for both the browser login
> and reset-credentials flows.  Keycloak would just send an SMS with a
> one-time secret code that you have to enter in.  We also would implement
> a validate mobile number required action too.
>
> I don't think any of this would take very long (a day or two?) once I
> get the reset-credential pluggable-flow support done.
>
> Later on, maybe its something we could integrate with Aerogear UPS out
> of the box?
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150816/3b843be4/attachment-0001.html 

From ssilvert at redhat.com  Sun Aug 16 15:05:46 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Sun, 16 Aug 2015 15:05:46 -0400
Subject: [keycloak-dev] auth spi docs/examples available in master
In-Reply-To: <55CE3F04.3020505@redhat.com>
References: <55CE3F04.3020505@redhat.com>
Message-ID: <55D0DF0A.5070202@redhat.com>

On 8/14/2015 3:18 PM, Bill Burke wrote:
> WRote about 15 pages of docs.  Created an example under
> examples/providers/authenticator.  It is both a required action and
> authenticator example.
>
> If you have time, please review.  If you don't...oh well...
>
> Refactored the SPI a bit when I created the examples.  Hopefully it is a
> lot simpler.
>
>
>
Good stuff.  I read the doc and sent a PR for typos I found.

I do have a couple of questions:

Section 33.3.4, Adding Authenticator Form, says, "This file should be 
placed in the login theme with all the other .ftl files you see for 
login."  Where, exactly, would that be?

It would be great if this could be placed within the provider jar. That 
way, a third party authentication provider could be easily distributed 
in a single jar.

Section 33.4.3, Implement the RequiredActionFactory, shows the 
getDisplayText() method.   Can this text be localized?  How?

From bburke at redhat.com  Sun Aug 16 17:26:54 2015
From: bburke at redhat.com (Bill Burke)
Date: Sun, 16 Aug 2015 17:26:54 -0400
Subject: [keycloak-dev] Reset Password changes complete needs review
Message-ID: <55D1001E.8010906@redhat.com>

Here's what I did, I can change things based on questions I asked in 
other emails, but here's how it works.

There's now the concept of "reset password" and a different one "change 
password".

* Reset password is something the user initiates.  This will start an 
Authentication Flow and success will login the user and bring them to 
their application
* Change password is something initiated by an admin.  This just sends 
an email to the user to reset their password and does not start an 
authentcation flow.

Reset Password changes:
* A Temporary Code is included in the Email in addition to a clickable 
link.
* When a user requests to be sent an email, they are brought to a new 
screen.  This screen allows the user to alternatively enter in the code 
from the email rather than clicking on a link.
* Temporary codes can only be entered once.  If it is entered wrong, 
user has to start login process all over again.
* Links can only be clicked once.
* The "Enter code" screen is shown with a success message even if a bad 
username or email is entered.  This is how it worked before.  I'm 
guessing this is here to avoid guessing email/usernames?


Change Password changes:
* It is a different email than Reset Password as there is no code


Questions:
* Should we get rid of the "back to login" links and instead have a 
"Cancel" button?  This applies to registration
* Should "Enter code" screen show a success even if the username/email 
was invalid?  Do we need to protect hackers from guessing usernames?


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

From stian at redhat.com  Mon Aug 17 03:57:06 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 03:57:06 -0400 (EDT)
Subject: [keycloak-dev] Operational monitoring of Keycloak server
In-Reply-To: <1441019523.10050535.1439478178607.JavaMail.zimbra@redhat.com>
References: <55A3BA5C.2090906@redhat.com> <55A4B2AB.9080508@redhat.com>
	<383530390.37875127.1436858054281.JavaMail.zimbra@redhat.com>
	<55A4C12C.8070305@redhat.com>
	<1137820905.37901015.1436861190539.JavaMail.zimbra@redhat.com>
	<55A74C01.4020104@redhat.com>
	<760752165.39790007.1437029396675.JavaMail.zimbra@redhat.com>
	<1441019523.10050535.1439478178607.JavaMail.zimbra@redhat.com>
Message-ID: <1623048509.11648090.1439798226750.JavaMail.zimbra@redhat.com>

Not sure how Hawkular would help. All we want is some basic info about a single KC server, or a cluster of KC servers. We're not monitoring multiple servers. I would more imagine that what we produce would be something Hawkular would be able to consume rather than us integrating/embedding Hawkular.

----- Original Message -----
> From: "Brett Meyer" <brmeyer at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 5:02:58 PM
> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server
> 
> Sorry for the late response.
> 
> Potentially, integration with Hawkular might be an option.
> http://www.hawkular.org/
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Vlastimil Elias" <velias at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, July 16, 2015 2:49:56 AM
> > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Vlastimil Elias" <velias at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Thursday, 16 July, 2015 8:15:29 AM
> > > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server
> > > 
> > > Hi,
> > > 
> > > OK, if DB is "realm" and "users" then it have to be well documented as
> > > it is not obvious for people without deeper knowledge of KC.
> > 
> > We could always call it realm-database or something, but we have 3
> > different
> > stores so should be separate status for them
> > 
> > > 
> > > Do we have JIRA issue for this or should I create one?
> > 
> > Nope, so please create one
> > 
> > > 
> > > Vl.
> > > 
> > > 
> > > On 14.7.2015 10:06, Stian Thorgersen wrote:
> > > >
> > > > ----- Original Message -----
> > > >> From: "Vlastimil Elias" <velias at redhat.com>
> > > >> To: "Stian Thorgersen" <stian at redhat.com>
> > > >> Cc: "Scott Rossillo" <srossillo at smartling.com>,
> > > >> keycloak-dev at lists.jboss.org
> > > >> Sent: Tuesday, 14 July, 2015 9:58:36 AM
> > > >> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server
> > > >>
> > > >> On 14.7.2015 09:14, Stian Thorgersen wrote:
> > > >>> ----- Original Message -----
> > > >>>> From: "Vlastimil Elias" <velias at redhat.com>
> > > >>>> To: "Stian Thorgersen" <stian at redhat.com>
> > > >>>> Cc: "Scott Rossillo" <srossillo at smartling.com>,
> > > >>>> keycloak-dev at lists.jboss.org
> > > >>>> Sent: Tuesday, 14 July, 2015 8:56:43 AM
> > > >>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak
> > > >>>> server
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On 14.7.2015 08:42, Stian Thorgersen wrote:
> > > >>>>> Ok so we add one that just returns OK or ERROR which doesn't
> > > >>>>> require
> > > >>>>> authentication, but then we add another that can return more
> > > >>>>> details,
> > > >>>>> including stats and what the error is.
> > > >>>> Yep. Simple http endpoinds for now, later all this info may be
> > > >>>> expose
> > > >>>> over DMR or some other mechanism if necessary.
> > > >>>>> For full health we should check all external services that are used
> > > >>>>> (db,
> > > >>>>> identity providers and user federation providers). Cluster sync
> > > >>>>> will
> > > >>>>> depend on what Infinispan exposes, but I imagine they'll have the
> > > >>>>> required
> > > >>>>> details avail.
> > > >>>> Beside endpoint for full health check (which should summarize all
> > > >>>> services into one flag if I understand correctly, which is good for
> > > >>>> loadbalancer) we should expose separate endpoint for each service
> > > >>>> health, as it is better for operational monitoring systems like
> > > >>>> Nagios.
> > > >>>> Admins are better informed what is going wrong and they can resolve
> > > >>>> situation more quickly without necessity to search cause of general
> > > >>>> failure flag somewhere else.
> > > >>> We could have a single health endpoint that returns a 200 or 500 and
> > > >>> also
> > > >>> returns a json doc with details. Something like:
> > > >>>
> > > >>> {
> > > >>>     realm: ok,
> > > >>>     users: ok,
> > > >>>     realmCache: error,
> > > >>>     userCache: error,
> > > >>>     identity-providers: {
> > > >>>       google: ok,
> > > >>>       facebook: error
> > > >>>     },
> > > >>>     user-federation: {
> > > >>>       ldap: ok
> > > >>>     }
> > > >>> }
> > > >>>
> > > >>> I wonder if that's to much details to expose without authentication.
> > > >> This should work, but I miss info about DB connection here. It is
> > > >> crucial from operational point of view as this allows sysadmins
> > > >> quickly
> > > >> detect that connection to DB is broken.
> > > >>
> > > >> I believe this kind of info can be safely exposed without
> > > >> authentication. If the endpoint is clearly documented then access can
> > > >> be
> > > >> always restricted on some network infra (webserver/proxy) ahead of KC.
> > > > DB is "realm" and "users".
> > > >
> > > >>>> Vl.
> > > >>>>
> > > >>>>> ----- Original Message -----
> > > >>>>>> From: "Vlastimil Elias" <velias at redhat.com>
> > > >>>>>> To: "Scott Rossillo" <srossillo at smartling.com>, "Stian Thorgersen"
> > > >>>>>> <stian at redhat.com>
> > > >>>>>> Cc: keycloak-dev at lists.jboss.org
> > > >>>>>> Sent: Tuesday, 14 July, 2015 8:34:29 AM
> > > >>>>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak
> > > >>>>>> server
> > > >>>>>>
> > > >>>>>> Yap, beside server-stat endpoint Stian talked about we should add
> > > >>>>>> some
> > > >>>>>> server-health endpoint also to be used for remote health
> > > >>>>>> monitoring
> > > >>>>>> by
> > > >>>>>> load balancers or systems like Nagios.
> > > >>>>>> Simple http endpoint without authentication (as it doesn't leak
> > > >>>>>> any
> > > >>>>>> sensitive information) is typically simplest way how to do this
> > > >>>>>> monitoring.
> > > >>>>>>
> > > >>>>>> Vl.
> > > >>>>>>
> > > >>>>>> On 14.7.2015 05:13, Scott Rossillo wrote:
> > > >>>>>>> Some type of health page would be great too for load balancers to
> > > >>>>>>> monitor. Something that doesn't leak internal information but
> > > >>>>>>> checks
> > > >>>>>>> behind the scenes that:
> > > >>>>>>> 1. Server can reach its databas(es)
> > > >>>>>>> 2. Server cluster sync is working
> > > >>>>>>> 3. Server can reach federation providers, etc.
> > > >>>>>>> Endpoint should respond to get requests and return an http status
> > > >>>>>>> reflective of server state.
> > > >>>>>>>
> > > >>>>>>> On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen
> > > >>>>>>> <stian at redhat.com
> > > >>>>>>> <mailto:stian at redhat.com>> wrote:
> > > >>>>>>>
> > > >>>>>>>        So looks like we're at agreement to add the additional
> > > >>>>>>>        info
> > > >>>>>>>        you
> > > >>>>>>>        wanted to server info page.
> > > >>>>>>>
> > > >>>>>>>        How about we add an additional endpoint server-stat that
> > > >>>>>>>        can
> > > >>>>>>>        collect some stats about the server?
> > > >>>>>>>
> > > >>>>>>>        ----- Original Message -----
> > > >>>>>>>        > From: "Vlastimil Elias" <velias at redhat.com
> > > >>>>>>>        <mailto:velias at redhat.com>>
> > > >>>>>>>        > To: "Stian Thorgersen" <stian at redhat.com
> > > >>>>>>>        > <mailto:stian at redhat.com>>
> > > >>>>>>>        > Cc: keycloak-dev at lists.jboss.org
> > > >>>>>>>        <mailto:keycloak-dev at lists.jboss.org>
> > > >>>>>>>        > Sent: Monday, 13 July, 2015 5:06:34 PM
> > > >>>>>>>        > Subject: Re: [keycloak-dev] Operational monitoring of
> > > >>>>>>>        > Keycloak
> > > >>>>>>>        server
> > > >>>>>>>        >
> > > >>>>>>>        > Looks like I have to look at WildFly/EAP DMR to see what
> > > >>>>>>>        > is
> > > >>>>>>>        possible to
> > > >>>>>>>        > do with it, as I'm not sure if it is about remote
> > > >>>>>>>        > monitoring
> > > >>>>>>>        also and
> > > >>>>>>>        > if/how it can be use from monitoring systems like
> > > >>>>>>>        > Splunk.
> > > >>>>>>>        >
> > > >>>>>>>        > Vl.
> > > >>>>>>>        >
> > > >>>>>>>        > On 13.7.2015 15:26, Stian Thorgersen wrote:
> > > >>>>>>>        > > In WildFly/EAP that's DMR right? We're planning to
> > > >>>>>>>        > > make
> > > >>>>>>>        Keycloak managable
> > > >>>>>>>        > > through that as well. For example everything that goes
> > > >>>>>>>        > > into
> > > >>>>>>>        > > keycloak-server.json will eventually be moved to
> > > >>>>>>>        standalone.xml. Same with
> > > >>>>>>>        > > admin endpoints, everything you can do there you'll
> > > >>>>>>>        > > eventually
> > > >>>>>>>        be able to
> > > >>>>>>>        > > do through DMR and jboss-cli as well.
> > > >>>>>>>        > >
> > > >>>>>>>        > > However, IMO it would make sense to at least expose
> > > >>>>>>>        > > Keycloak
> > > >>>>>>>        specific
> > > >>>>>>>        > > information through the admin endpoints and console as
> > > >>>>>>>        > > well.
> > > >>>>>>>        Such number
> > > >>>>>>>        > > of sessions, etc..
> > > >>>>>>>        > >
> > > >>>>>>>        > > ----- Original Message -----
> > > >>>>>>>        > >> From: "Vlastimil Elias" <velias at redhat.com
> > > >>>>>>>        <mailto:velias at redhat.com>>
> > > >>>>>>>        > >> To: keycloak-dev at lists.jboss.org
> > > >>>>>>>        <mailto:keycloak-dev at lists.jboss.org>
> > > >>>>>>>        > >> Sent: Monday, 13 July, 2015 3:17:16 PM
> > > >>>>>>>        > >> Subject: [keycloak-dev] Operational monitoring of
> > > >>>>>>>        > >> Keycloak
> > > >>>>>>>        > >> server
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> Hi,
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> as we deployed KC to production mode for
> > > >>>>>>>        https://developers.redhat.com
> > > >>>>>>>        > >> we started to think about operational monitoring, for
> > > >>>>>>>        > >> example
> > > >>>>>>>        from
> > > >>>>>>>        > >> Nagios or other systems of this type.
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> KC user guide doesn't contain any chapter covering
> > > >>>>>>>        > >> this
> > > >>>>>>>        topic, also no
> > > >>>>>>>        > >> any success over google search, so looks like KC
> > > >>>>>>>        > >> doesn't
> > > >>>>>>>        > >> have
> > > >>>>>>>        > >> any
> > > >>>>>>>        > >> solution for this yet.
> > > >>>>>>>        > >> But I believe this is an important area which must be
> > > >>>>>>>        > >> solved
> > > >>>>>>>        when KC is
> > > >>>>>>>        > >> used for production.
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> I can imagine monitoring of JDBC connection if JPA is
> > > >>>>>>>        > >> used,
> > > >>>>>>>        monitoring
> > > >>>>>>>        > >> of Mongo connection if used as store, monitoring of
> > > >>>>>>>        > >> LDAP
> > > >>>>>>>        connection if
> > > >>>>>>>        > >> LDAP federation is used etc.
> > > >>>>>>>        > >> Also some statistics like numbers of active sso
> > > >>>>>>>        > >> session,
> > > >>>>>>>        number of
> > > >>>>>>>        > >> logins per minute etc should be provided there.
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> Monitoring is not about Keycloak core itself, it
> > > >>>>>>>        > >> should
> > > >>>>>>>        > >> be
> > > >>>>>>>        available for
> > > >>>>>>>        > >> extension developers also. For example we implemented
> > > >>>>>>>        > >> own
> > > >>>>>>>        > >> UserFederationProvider which calls backend REST
> > > >>>>>>>        > >> services.
> > > >>>>>>>        > >> We should be able to add info about this integration
> > > >>>>>>>        > >> into
> > > >>>>>>>        monitoring
> > > >>>>>>>        > >> endpoint to be able to catch problems with this REST
> > > >>>>>>>        > >> API.
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> It should be probably implemented same way as used by
> > > >>>>>>>        > >> underlying
> > > >>>>>>>        > >> WildFly/EAP (JPA/JDBC is probably available for
> > > >>>>>>>        > >> monitoring
> > > >>>>>>>        there). I'm
> > > >>>>>>>        > >> not sure if JMX is used there still or if some new
> > > >>>>>>>        > >> framework
> > > >>>>>>>        > >> is
> > > >>>>>>>        > >> available for it.
> > > >>>>>>>        > >> Or KC should use some form of KC REST API for this,
> > > >>>>>>>        > >> which
> > > >>>>>>>        should be
> > > >>>>>>>        > >> extended by additional info from KC extensions?
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> What do you think?
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> Vlastimil
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> P.S we have https://issues.jboss.org/browse/RHD-552
> > > >>>>>>>        > >> for
> > > >>>>>>>        > >> Red
> > > >>>>>>>        > >> Hat
> > > >>>>>>>        > >> Developer instance of KC
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> --
> > > >>>>>>>        > >> Vlastimil Elias
> > > >>>>>>>        > >> Principal Software Engineer
> > > >>>>>>>        > >> jboss.org <http://jboss.org> Development Team
> > > >>>>>>>        > >>
> > > >>>>>>>        > >> _______________________________________________
> > > >>>>>>>        > >> 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
> > > >>>>>>>        > jboss.org <http://jboss.org> Development Team
> > > >>>>>>>        >
> > > >>>>>>>        >
> > > >>>>>>>        _______________________________________________
> > > >>>>>>>        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
> > > >>>>>> jboss.org Development Team
> > > >>>>>>
> > > >>>>>>
> > > >>>> --
> > > >>>> Vlastimil Elias
> > > >>>> Principal Software Engineer
> > > >>>> jboss.org Development Team
> > > >>>>
> > > >>>>
> > > >> --
> > > >> Vlastimil Elias
> > > >> Principal Software Engineer
> > > >> jboss.org Development Team
> > > >>
> > > >>
> > > 
> > > --
> > > Vlastimil Elias
> > > Principal Software Engineer
> > > jboss.org Development Team
> > > 
> > > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Aug 17 04:01:04 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 04:01:04 -0400 (EDT)
Subject: [keycloak-dev] Implementing database-service example in Python
In-Reply-To: <CANWAcaVnBSaF22bHAXyyT8roMTD7pNLP6GVtOFyedixhzOP8zQ@mail.gmail.com>
References: <CANWAcaUP3jXVGY+cmAsnyEp0AiHYoBENucf4XO0cbPq3Ef89bg@mail.gmail.com>
	<826281598.9693806.1439445653118.JavaMail.zimbra@redhat.com>
	<55CC95FD.6050601@redhat.com>
	<CANWAcaVnBSaF22bHAXyyT8roMTD7pNLP6GVtOFyedixhzOP8zQ@mail.gmail.com>
Message-ID: <852029863.11652841.1439798464060.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Vinay Anantharaman" <vinayan3 at gmail.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 14 August, 2015 9:42:39 PM
> Subject: Re: [keycloak-dev] Implementing database-service example in Python
> 
> I'll be looking into this and will report back if a library exists for Python
> to read JWT tokens.
> 
> I was wondering is there an API on the KeyCloak server for doing JWT token
> verification? Or rather should we decode the token and use the REST admin
> endpoints if we need to query more information?

There is a rest endpoint that can be used to verify a token, but that requires a request to KC. As the token is signed it's better to just check it locally as it reduces the amount of request to Keycloak.

> 
> 
> Vinay
> 
> On Thu, Aug 13, 2015 at 9:05 AM, Bill Burke < bburke at redhat.com > wrote:
> 
> 
> If you're interested in becoming a contributor Vinay, this would be a
> very useful extension!
> 
> BTW, we also have a "lightweight" Java Security HTTP Proxy based on
> Undertow that you can use to secure python apps.
> 
> On 8/13/2015 2:00 AM, Stian Thorgersen wrote:
> > Afraid we don't have any libraries for Python yet.
> > 
> > Simply verifying the token should be relatively straight forward though.
> > It's a standard JWT token (base64 encoded json) with a JWS signature. You
> > can look at RSATokenVerifier to see what details should be verified
> > (expiration date, issuer, etc..). You also need to verify the signature.
> > There may quite likely be JWT libraries for Python you can use.
> > 
> > ----- Original Message -----
> >> From: "Vinay Anantharaman" < vinayan3 at gmail.com >
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 13 August, 2015 12:21:01 AM
> >> Subject: [keycloak-dev] Implementing database-service example in Python
> >> 
> >> Hi,
> >> I'm trying to implement the example database service from Python. The
> >> description is here:
> >> 
> >> 
> >> 
> >> https://github.com/keycloak/keycloak/tree/master/examples/demo-template
> >> 
> >> Our backend service is contacted directly by clients with an access token
> >> from the Keycloak server. We would like to verify access tokens are and
> >> then
> >> return some data they need. I was looking at the code here:
> >> 
> >> 
> >> 
> >> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/database-
> >> service/src/main/java/org/keycloak/example/oauth/CustomerService.java
> >> 
> >> In Java this seems quite trivial with the support of Keycloak libraries.
> >> In
> >> Python I won't have them. What are the APIs on Keycloak I can use to
> >> verify
> >> an access token? Furthermore, are you aware of any classes like
> >> RSATokenVerifier for python? I saw it being used here:
> >> 
> >> 
> >> 
> >> https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/OAuthClient.java#L319
> >> 
> >> Thanks,
> >> 
> >> 
> >> Vinay Anantharaman
> >> 
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> 
> --
> Vinay Anantharaman
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Mon Aug 17 05:16:09 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 05:16:09 -0400 (EDT)
Subject: [keycloak-dev] QE tests failing
In-Reply-To: <55CF5CDA.5080602@redhat.com>
References: <55CF5CDA.5080602@redhat.com>
Message-ID: <714969246.11741004.1439802969390.JavaMail.zimbra@redhat.com>

There's an issue with the tests sometimes timing out on Travis. Hopefully this will be resolved shortly, but in the mean time when this happens please re-run the tests (there's an option on Travis to re-run the tests)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, 15 August, 2015 5:38:02 PM
> Subject: [keycloak-dev] QE tests failing
> 
> QE tests are failing in build.  I've been merging anyways because the
> normal build tests pass.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Aug 17 05:18:08 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 05:18:08 -0400 (EDT)
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
References: <55CFB7AA.3080406@redhat.com>
	<CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
Message-ID: <1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Thomas Raehalme" <thomas.raehalme at aitiofinland.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Sunday, 16 August, 2015 12:41:06 PM
> Subject: Re: [keycloak-dev] Abstract SMS support
> 
> 
> 
> Hi!
> 
> Sounds good!
> 
> However it might be a good idea to include a generic HTTP/REST implementation
> which you could configure through the admin interface to deliver SMS
> messages to any service supporting HTTP? I'm pretty sure this would satisfy
> most users.

Not sure how that would work. AFAIK SMS providers have their own proprietary rest endpoints as well as authentication mechanisms so I don't see how we could create a generic implementation. 

> 
> What do you think?
> 
> Best regards,
> Thomas
> On Aug 16, 2015 1:06 AM, "Bill Burke" < bburke at redhat.com > wrote:
> 
> 
> I was thinking that we would create abstract support for SMS support for
> Keycloak. We would define a simple Provider interface for sending text
> messages. We would not provide anything out of the box for now. We
> would require users to implement their own SMS provider and plug it in.
> 
> Basically, we'd have an SMS OTP Authenticator for both the browser login
> and reset-credentials flows. Keycloak would just send an SMS with a
> one-time secret code that you have to enter in. We also would implement
> a validate mobile number required action too.
> 
> I don't think any of this would take very long (a day or two?) once I
> get the reset-credential pluggable-flow support done.
> 
> Later on, maybe its something we could integrate with Aerogear UPS out
> of the box?
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Mon Aug 17 05:19:17 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 05:19:17 -0400 (EDT)
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <55CFB7AA.3080406@redhat.com>
References: <55CFB7AA.3080406@redhat.com>
Message-ID: <368921155.11742440.1439803157084.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, 16 August, 2015 12:05:30 AM
> Subject: [keycloak-dev] Abstract SMS support
> 
> I was thinking that we would create abstract support for SMS support for
> Keycloak.  We would define a simple Provider interface for sending text
> messages.  We would not provide anything out of the box for now.  We
> would require users to implement their own SMS provider and plug it in.
> 
> Basically, we'd have an SMS OTP Authenticator for both the browser login
> and reset-credentials flows.  Keycloak would just send an SMS with a
> one-time secret code that you have to enter in.  We also would implement
> a validate mobile number required action too.
> 
> I don't think any of this would take very long (a day or two?) once I
> get the reset-credential pluggable-flow support done.

Sounds good, would be good to have an example SMS provider for one popular SMS service so we have something to test/show.

> 
> Later on, maybe its something we could integrate with Aerogear UPS out
> of the box?

AeroGear UPS doesn't do SMS, they do notifications only.

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

From stian at redhat.com  Mon Aug 17 05:28:56 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 05:28:56 -0400 (EDT)
Subject: [keycloak-dev] Fwd: Remove address from registration and
 account management by default
In-Reply-To: <CAJ1fz80fUg6tBLdga87SiX3POsLrGRGn-xD6fBpyqLvn3vEDdA@mail.gmail.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
	<CAJ1fz81+YsRejVf3rhNO_Up1JQaYfRS-3y5cuQwekK7TJaXoBg@mail.gmail.com>
	<CAJ1fz839Avyv+La4V67nOCwcRW+6CMx2=gFVsCFBX6eYtJBrbg@mail.gmail.com>
	<55CCE65C.9050202@redhat.com>
	<CAJ1fz80fUg6tBLdga87SiX3POsLrGRGn-xD6fBpyqLvn3vEDdA@mail.gmail.com>
Message-ID: <624735347.11750044.1439803736044.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Lennart J?relid" <lennart.jorelid at gmail.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 11:34:58 PM
> Subject: Re: [keycloak-dev] Fwd: Remove address from registration and account management by default
> 
> OK; I hear you.
> 
> I do believe, however, that the things above - and quite a few other things -
> are really required to get
> the usability of an "Out Of The Box" product. Let me suggest some things
> below:
> 
> 2015-08-13 20:47 GMT+02:00 Bill Burke < bburke at redhat.com > :
> 
> 
> 
> On 8/13/2015 2:18 PM, Lennart J?relid wrote:
> > [Forwarding to the list; not meant as a personal reply.]
> > 
> > Hello there,
> > 
> > This is exacly what I am struggling with at the moment. I have found a
> > number of things which would need clarification in documentation as well
> > as in examples:
> > 
> > 1. *Custom user data properties/fields*. It seems that one has to/ought
> > to add custom properties to three places in the theme files:
> > account, admin and registration. However, the ways to add them
> > differ greatly, as each FTL template structure is quite different.
> > (Account uses account.ftl; Admin uses
> > partials/user-attribute-entry.ftl). Pattern definitions and
> > explanations are missing from examples and documentation, as far as
> > I can tell.
> 
> Stian wants a generic service. I disagree because I don't think it will
> be used. I just look at developers.redhat.com for example, and they
> have differing formatting requirements. You would end up recreating cSS
> and HTML within the admin console. Not something I'm kean on doing.
> 
> This is a tricky task to create in a simple manner; I agree with that.
> The model and view could be created separately, and joined to a result using
> DI. So ...
> 
>     1. Model - from a Dev perspective : Defining entity classes (JPA and JAXB
>     to combine storage and transport) is pretty common for developers, as is
>     extending specified interfaces. If you simplify the model for users to a
>     standard Entity and include a setter/getter pair for something which is
>     an interface (instead of today's mapping between unvalidateable string
>     and unvalidateable string), developers can simply implement their own
>     custom metadata class which can include Validation on any of the fields
>     - not only passwords. Today, we cannot validate the content of any
>     custom properties, as they are stored as Strings.
>     2. Model - from a Non-Dev perspective : Non-developers require quite a
>     lot of tooling to create the model classes. Is it your idea of an "Out
>     of the Box" solution that non-devs should be able to define the custom
>     properties of each user? If so, I believe that the "generate-the-model"
>     tooling is currently missing from the codebase.
>     3. Model - performance: The current solution ought to give really poor
>     performance when the number of users in the keycloak database rises; the
>     JPA implementation of custom attributes stashes all of them in a single
>     table with a String containing an UUID for primary key... at least with
>     an integer, custom attributes for a single user will be stored at
>     similar locations. Your UUID approach guarantees that each user
>     attribtue is scattered evenly across the table, and re-indexing will
>     happen every time a new value is inserted. There are quite a few other
>     options to implement this functionality that would improve performance
>     compared to the current solution - but these require some form of
>     development backround from a user. Which approach will KeyCloak take?
>     4. View - from a Dev perspective : We architects and developers like
>     standards that we have encountered before, and creating a complete theme
>     with the level of control you envision above is, quite frankly, really
>     difficult today. Not only is the documentation lacking on theme basic
>     semantics, but you need to understand how quite a lot of fragments are
>     joined together by Freemarker to a live page. While Freemarker is not
>     unheard of, it is an oddball (i.e. not part of the standard JavaEE
>     platform).
>     5. View - usability : Usability is king. If you would like to improve
>     usability for people trying to create custom user properties, I believe
>     that you must use standard JavaScript frameworks or JavaEE tech. A
>     suggestion: create a KeyCloak AngularJS module which contains a set of
>     custom directives - this implies that users can create complete pages
>     containing keycloak-specific tags. This implies that we can see all
>     views in a theme, including the directives for custom attributes. I
>     believe this would be considerably simpler than understanding which
>     Freemarker fragments are used in a particular use case, as is the case
>     today. With improved usability comes reduced burden of documentation,
>     which should please quite a lot of you KeyCloak devs.
>     6. View - conclusion: I don't think that today's freemarker approach
>     works - and while I can certainly create another ProviderFactory than
>     the Freemarker one, I don't know the end result which I should target.
>     What pages should be done, and in which order are they called?
> 
> 
> > 2. *Editable properties per role*. Realm admins/editors could perhaps
> > be able to edit all properties (except primary key/ID value) for all
> > the users in a realm - but we would typically like to restrict which
> > properties (both basic and custom attributes) are editable depending
> > on the roles/privileges a user has in the realm. (For example, it
> > would likely be a bad ide to permit users to change their names and
> > birthday arbitrarily after registration). How do we restrict
> > editability of normaly and custom user properteis - both in terms of
> > the data and the forms required to interact with keycloak? Pattern
> > definitions and explanations are missing from examples and
> > documentation, as far as I can tell.
> 
> We don't have a way to do this in the account service yet. You can
> modify the forms to display whatever you want, but a rogue user would be
> able to modify any attribute they wanted. Ugh, we probably need to fix
> this.
> 
> I think that this is core functionality, if KeyCloak should really work as an
> out-of-the-box solution.
> In particular, since you folks have taken the approach that KeyCloak should
> hold a set of base
> properties for each user, and supply means to extend those base properties
> with custom properties.
> 
> This means that using KeyCloak should really imply 3 initial steps after
> installation:
> 
> 
> 
>     1. Define your set of custom user properties.
>     2. Create a theme in order to be able to handle your custom user
>     properties (store, manage, etc.)
>     3. Migrate (or Federate) all users from the current IDM
>     database/application to KeyCloak. This means that it must be a trivial
>     (and well-example'd/well-documented) task to develop a Class which reads
>     the currnet IDM data and makes instances of KeyCloak UserModel
>     instances, including all its extra properties.
> This means that the KeyCloak documentation must walk users/developers through
> these steps. In some detail. Right?
> 
> 
> 
> > 3. *Linking users to roles/privileges in other realms.* How should one
> > construct realms to grant roles & privileges automatically to users
> > in other realms? (For example: All Users in Literary Society A can
> > register for a party hosted by Literary Society B. Hence, how does
> > realm admin B grant role KnownGuest to all users in realm A, to
> > permit them to access Society B's register-to-the-event-page?
> > Assume, of course, that both A and B are managed by the same
> > Keycloak DB, so basic identity attributes should be extracted
> > normally from Keycloak. Neither realm admins from A or B have master
> > realm access.) Pattern definitions and explanations are missing from
> > examples and documentation, as far as I can tell.
> > 
> 
> I don't think we'll ever have the ability to link realms. If we did
> ever add it it would be next year. Too much in queue at the moment.
> 
> Hm. This feasture is really important to me.
> I can certainly summon up some JIRAs for it, and suggest some compliant
> solution and PRs.
> If you wish, ping me on Skype to discuss.

Assuming you want users in realm "Society A" to be able to login to applications in realm "Society B" you can use identity brokering for that. Through mappers you can then control what roles users from Society A is given in Society B.

There's no cross-linking between users in different realms at the moment beyond identity brokering. We would probably not add this either, as identity brokering already provides this capability.

> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> 
> --
> --
> +==============================+
> | B?sta h?lsningar,
> | [sw. "Best regards"]
> |
> | Lennart J?relid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | M?lnlycke - Kista
> |
> | Email: lj at jguru.se | URL: www.jguru.se | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From thomas.raehalme at aitiofinland.com  Mon Aug 17 05:29:34 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Mon, 17 Aug 2015 12:29:34 +0300
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>
References: <55CFB7AA.3080406@redhat.com>
	<CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
	<1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>
Message-ID: <CAPyAMoaEJ4unWzLhugeNyQ=oFK2yV1u4iuLHVdT0+UxQxFUgOQ@mail.gmail.com>

On Mon, Aug 17, 2015 at 12:18 PM, Stian Thorgersen <stian at redhat.com> wrote:

> > However it might be a good idea to include a generic HTTP/REST
> implementation
> > which you could configure through the admin interface to deliver SMS
> > messages to any service supporting HTTP? I'm pretty sure this would
> satisfy
> > most users.
>
> Not sure how that would work. AFAIK SMS providers have their own
> proprietary rest endpoints as well as authentication mechanisms so I don't
> see how we could create a generic implementation.
>
>

You would need to implement a template mechanism where the Keycloak data
(for example the recipient number and message text) is provided as
keywords, and the admin defines the template utilizing those keywords. It
would be a good idea to allow choosing between POST and GET.

For example Twilio supports a simple HTTP POST operation to delivery SMS
messages through their API:
https://www.twilio.com/docs/api/rest/sending-messages

Many operators and service providers use a similar mechanism. Often the
authentication is just a simple token which needs to be included in the
request.

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

From stian at redhat.com  Mon Aug 17 05:31:28 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 05:31:28 -0400 (EDT)
Subject: [keycloak-dev] Fwd: Remove address from registration and
 account management by default
In-Reply-To: <55CCE65C.9050202@redhat.com>
References: <521149077.10000094.1439473764023.JavaMail.zimbra@redhat.com>
	<CAJ1fz81+YsRejVf3rhNO_Up1JQaYfRS-3y5cuQwekK7TJaXoBg@mail.gmail.com>
	<CAJ1fz839Avyv+La4V67nOCwcRW+6CMx2=gFVsCFBX6eYtJBrbg@mail.gmail.com>
	<55CCE65C.9050202@redhat.com>
Message-ID: <1841185389.11752412.1439803888095.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 8:47:56 PM
> Subject: Re: [keycloak-dev] Fwd: Remove address from registration and account management by default
> 
> 
> 
> On 8/13/2015 2:18 PM, Lennart J?relid wrote:
> > [Forwarding to the list; not meant as a personal reply.]
> >
> > Hello there,
> >
> > This is exacly what I am struggling with at the moment. I have found a
> > number of things which would need clarification in documentation as well
> > as in examples:
> >
> >  1. *Custom user data properties/fields*. It seems that one has to/ought
> >     to add custom properties to three places in the theme files:
> >     account, admin and registration. However, the ways to add them
> >     differ greatly, as each FTL template structure is quite different.
> >     (Account uses account.ftl; Admin uses
> >     partials/user-attribute-entry.ftl). Pattern definitions and
> >     explanations are missing from examples and documentation, as far as
> >     I can tell.
> 
> Stian wants a generic service.  I disagree because I don't think it will
> be used.  I just look at developers.redhat.com for example, and they
> have differing formatting requirements.  You would end up recreating cSS
> and HTML within the admin console.  Not something I'm kean on doing.

No, that's not true - what I've proposed does not at all re-create CSS/HTML within the admin console. It would just provide the users the ability to define what attributes goes into a user, what type they are, some validation, which can be edited, which are required etc. Beyond basic "label - input" users would need to define a template themselves for how it is displayed in the login screen. Users would still define the html/template, but they would do it on a per-input level instead of for a full form.

> 
> >  2. *Editable properties per role*. Realm admins/editors could perhaps
> >     be able to edit all properties (except primary key/ID value) for all
> >     the users in a realm - but we would typically like to restrict which
> >     properties (both basic and custom attributes) are editable depending
> >     on the roles/privileges a user has in the realm. (For example, it
> >     would likely be a bad ide to permit users to change their names and
> >     birthday arbitrarily after registration). How do we restrict
> >     editability of normaly and custom user properteis - both in terms of
> >     the data and the forms required to interact with keycloak? Pattern
> >     definitions and explanations are missing from examples and
> >     documentation, as far as I can tell.
> 
> We don't have a way to do this in the account service yet.  You can
> modify the forms to display whatever you want, but a rogue user would be
> able to modify any attribute they wanted.  Ugh, we probably need to fix
> this.
> 
> >  3. *Linking users to roles/privileges in other realms.* How should one
> >     construct realms to grant roles & privileges automatically to users
> >     in other realms? (For example: All Users in Literary Society A can
> >     register for a party hosted by Literary Society B. Hence, how does
> >     realm admin B grant role KnownGuest to all users in realm A, to
> >     permit them to access Society B's register-to-the-event-page?
> >     Assume, of course, that both A and B are managed by the same
> >     Keycloak DB, so basic identity attributes should be extracted
> >     normally from Keycloak. Neither realm admins from A or B have master
> >     realm access.) Pattern definitions and explanations are missing from
> >     examples and documentation, as far as I can tell.
> >
> 
> I don't think we'll ever have the ability to link realms.  If we did
> ever add it it would be next year.  Too much in queue at the moment.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From stian at redhat.com  Mon Aug 17 05:35:38 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 05:35:38 -0400 (EDT)
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <CAPyAMoaEJ4unWzLhugeNyQ=oFK2yV1u4iuLHVdT0+UxQxFUgOQ@mail.gmail.com>
References: <55CFB7AA.3080406@redhat.com>
	<CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
	<1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>
	<CAPyAMoaEJ4unWzLhugeNyQ=oFK2yV1u4iuLHVdT0+UxQxFUgOQ@mail.gmail.com>
Message-ID: <462408759.11756368.1439804138850.JavaMail.zimbra@redhat.com>

I'm not convinced about this approach, I think it would end up being complex and we'd continuously get request on tweaking it to support other providers.

Having a simple Java interface with something like (just a quick mock, not the suggested interface):

SMSProvider:

* Status sendMessage(String message, String phoneNumber)

Would be fairly easy for users to implement and would work for all services.

----- Original Message -----
> From: "Thomas Raehalme" <thomas.raehalme at aitiofinland.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, 17 August, 2015 11:29:34 AM
> Subject: Re: [keycloak-dev] Abstract SMS support
> 
> On Mon, Aug 17, 2015 at 12:18 PM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > > However it might be a good idea to include a generic HTTP/REST
> > implementation
> > > which you could configure through the admin interface to deliver SMS
> > > messages to any service supporting HTTP? I'm pretty sure this would
> > satisfy
> > > most users.
> >
> > Not sure how that would work. AFAIK SMS providers have their own
> > proprietary rest endpoints as well as authentication mechanisms so I don't
> > see how we could create a generic implementation.
> >
> >
> 
> You would need to implement a template mechanism where the Keycloak data
> (for example the recipient number and message text) is provided as
> keywords, and the admin defines the template utilizing those keywords. It
> would be a good idea to allow choosing between POST and GET.
> 
> For example Twilio supports a simple HTTP POST operation to delivery SMS
> messages through their API:
> https://www.twilio.com/docs/api/rest/sending-messages
> 
> Many operators and service providers use a similar mechanism. Often the
> authentication is just a simple token which needs to be included in the
> request.
> 
> Best regards,
> Thomas
> 

From thomas.raehalme at aitiofinland.com  Mon Aug 17 05:39:27 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Mon, 17 Aug 2015 12:39:27 +0300
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <462408759.11756368.1439804138850.JavaMail.zimbra@redhat.com>
References: <55CFB7AA.3080406@redhat.com>
	<CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
	<1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>
	<CAPyAMoaEJ4unWzLhugeNyQ=oFK2yV1u4iuLHVdT0+UxQxFUgOQ@mail.gmail.com>
	<462408759.11756368.1439804138850.JavaMail.zimbra@redhat.com>
Message-ID: <CAPyAMoaJzqs8fKNFDDU7ZjsbFRbdU1ObaHCimJN+f85t=B1TEA@mail.gmail.com>

On Mon, Aug 17, 2015 at 12:35 PM, Stian Thorgersen <stian at redhat.com> wrote:

> I'm not convinced about this approach, I think it would end up being
> complex and we'd continuously get request on tweaking it to support other
> providers.
>
> Having a simple Java interface with something like (just a quick mock, not
> the suggested interface):
>
> SMSProvider:
>
> * Status sendMessage(String message, String phoneNumber)
>
> Would be fairly easy for users to implement and would work for all
> services.
>

Sure, the interface would be simple to implement, but nevertheless it
requires a customization to the install and Keycloak no longer works
out-of-the-box.

I'm not saying the interface should not be there, but that it would be
great to also have a simple HTTP implementation available.

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

From stian at redhat.com  Mon Aug 17 05:45:41 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 05:45:41 -0400 (EDT)
Subject: [keycloak-dev] API for Registering users / Flow for
 registration on	iOS
In-Reply-To: <CANWAcaXQ9TsUj-4UHRyyBgksq6AEsyDEgNy8AyD+Sxy2DVd9GQ@mail.gmail.com>
References: <CANWAcaXQ9TsUj-4UHRyyBgksq6AEsyDEgNy8AyD+Sxy2DVd9GQ@mail.gmail.com>
Message-ID: <372556024.11804692.1439804741197.JavaMail.zimbra@redhat.com>

Just configure the Facebook social provider for the realm and the users would now have a option to login with Facebook. First time the user logs in with Facebook a user is created internally.

----- Original Message -----
> From: "Vinay Anantharaman" <vinayan3 at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 14 August, 2015 10:22:41 PM
> Subject: [keycloak-dev] API for Registering users / Flow for registration on	iOS
> 
> Hi,
> I would like to make an iOS app which uses social login using Facebook. I
> don't want to have the user's register using Keycloak's HTML form to
> register. I've made an app before where we had a native UI for social login
> for Facebook. I passed the FB Access token to my backend and was able to
> create a user from there.
> 
> How can I get this workflow with Keycloak? I dug around the docs and couldn't
> find anything. I assume that Keycloak's HTML registration forms must be
> submitting and accept social login tokens to create users.
> 
> 
> Thanks,
> 
> 
> 
> Vinay Anantharamann
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Mon Aug 17 05:47:01 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 05:47:01 -0400 (EDT)
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <CAPyAMoaJzqs8fKNFDDU7ZjsbFRbdU1ObaHCimJN+f85t=B1TEA@mail.gmail.com>
References: <55CFB7AA.3080406@redhat.com>
	<CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
	<1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>
	<CAPyAMoaEJ4unWzLhugeNyQ=oFK2yV1u4iuLHVdT0+UxQxFUgOQ@mail.gmail.com>
	<462408759.11756368.1439804138850.JavaMail.zimbra@redhat.com>
	<CAPyAMoaJzqs8fKNFDDU7ZjsbFRbdU1ObaHCimJN+f85t=B1TEA@mail.gmail.com>
Message-ID: <1477513538.11806448.1439804821385.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Thomas Raehalme" <thomas.raehalme at aitiofinland.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, 17 August, 2015 11:39:27 AM
> Subject: Re: [keycloak-dev] Abstract SMS support
> 
> On Mon, Aug 17, 2015 at 12:35 PM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > I'm not convinced about this approach, I think it would end up being
> > complex and we'd continuously get request on tweaking it to support other
> > providers.
> >
> > Having a simple Java interface with something like (just a quick mock, not
> > the suggested interface):
> >
> > SMSProvider:
> >
> > * Status sendMessage(String message, String phoneNumber)
> >
> > Would be fairly easy for users to implement and would work for all
> > services.
> >
> 
> Sure, the interface would be simple to implement, but nevertheless it
> requires a customization to the install and Keycloak no longer works
> out-of-the-box.
> 
> I'm not saying the interface should not be there, but that it would be
> great to also have a simple HTTP implementation available.

I full appreciate that and it would be great to have what you are proposing. Sadly we have to many things to implement at the moment. If you'd like to contribute something that'd be more than welcome ;)

> 
> Best regards,
> Thomas
> 

From satyajit.das at spire2grow.com  Mon Aug 17 06:04:07 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Mon, 17 Aug 2015 15:34:07 +0530
Subject: [keycloak-dev] Query on Keycloak Setup
Message-ID: <CA+oCsRpxYzDxH5H32GoKMb0RNDuH3UiH2S-bHdMj2P8MRrXxHA@mail.gmail.com>

Hi team,

Kindly respond to my below query. My queries can be trivial because i am
new to webapplication.

I have a webapplication which is on angular js. I want that to get
authenticated and redirected to keycloak page for SSO authentication, when
i hit the application URL.

In you document and demo i saw you have configured that using web.xml,
context.xml and keycloak.json.(These all files were true and working for
JSP and servlets and html pages) but how to configure this for angular js
project . it doesnt have any web.xml or context.xml.

I saw your example in
https://github.com/keycloak/keycloak/tree/master/examples/demo-template/customer-app-js

there is only a keycloak.json configuration with public-client as true.
Cant I have this as confidential where it will accept the user id and
password. How will i map the roles where there is no web.xml

Looking forward to your response.

Regards,
Satya.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150817/bfe6f688/attachment.html 

From thomas.raehalme at aitiofinland.com  Mon Aug 17 06:07:07 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Mon, 17 Aug 2015 13:07:07 +0300
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <1477513538.11806448.1439804821385.JavaMail.zimbra@redhat.com>
References: <55CFB7AA.3080406@redhat.com>
	<CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
	<1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>
	<CAPyAMoaEJ4unWzLhugeNyQ=oFK2yV1u4iuLHVdT0+UxQxFUgOQ@mail.gmail.com>
	<462408759.11756368.1439804138850.JavaMail.zimbra@redhat.com>
	<CAPyAMoaJzqs8fKNFDDU7ZjsbFRbdU1ObaHCimJN+f85t=B1TEA@mail.gmail.com>
	<1477513538.11806448.1439804821385.JavaMail.zimbra@redhat.com>
Message-ID: <CAPyAMoa_E4WLtZCgYgQ00SxvVaBTJCvtTMW-JNNTuBR0RQcnMg@mail.gmail.com>

On Mon, Aug 17, 2015 at 12:47 PM, Stian Thorgersen <stian at redhat.com> wrote:

> > Sure, the interface would be simple to implement, but nevertheless it
> > requires a customization to the install and Keycloak no longer works
> > out-of-the-box.
> >
> > I'm not saying the interface should not be there, but that it would be
> > great to also have a simple HTTP implementation available.
>
> I full appreciate that and it would be great to have what you are
> proposing. Sadly we have to many things to implement at the moment. If
> you'd like to contribute something that'd be more than welcome ;)
>
>
No worries, having the interface is a great first step. I'll see if there's
anything I can do to help with the implementation. I need to get myself
familiar with the admin UI first.

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

From stian at redhat.com  Mon Aug 17 06:09:30 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Aug 2015 06:09:30 -0400 (EDT)
Subject: [keycloak-dev] Query on Keycloak Setup
In-Reply-To: <CA+oCsRpxYzDxH5H32GoKMb0RNDuH3UiH2S-bHdMj2P8MRrXxHA@mail.gmail.com>
References: <CA+oCsRpxYzDxH5H32GoKMb0RNDuH3UiH2S-bHdMj2P8MRrXxHA@mail.gmail.com>
Message-ID: <185928993.11816437.1439806170877.JavaMail.zimbra@redhat.com>

Please use the user mailing list for support questions

----- Original Message -----
> From: "Satyajit Das" <satyajit.das at spire2grow.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 17 August, 2015 12:04:07 PM
> Subject: [keycloak-dev] Query on Keycloak Setup
> 
> Hi team,
> 
> Kindly respond to my below query. My queries can be trivial because i am new
> to webapplication.
> 
> I have a webapplication which is on angular js. I want that to get
> authenticated and redirected to keycloak page for SSO authentication, when i
> hit the application URL.
> 
> In you document and demo i saw you have configured that using web.xml,
> context.xml and keycloak.json.(These all files were true and working for JSP
> and servlets and html pages) but how to configure this for angular js
> project . it doesnt have any web.xml or context.xml.
> 
> I saw your example in
> https://github.com/keycloak/keycloak/tree/master/examples/demo-template/customer-app-js
> 
> there is only a keycloak.json configuration with public-client as true. Cant
> I have this as confidential where it will accept the user id and password.
> How will i map the roles where there is no web.xml
> 
> Looking forward to your response.
> 
> Regards,
> Satya.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From vinayan3 at gmail.com  Mon Aug 17 10:39:48 2015
From: vinayan3 at gmail.com (Vinay Anantharaman)
Date: Mon, 17 Aug 2015 10:39:48 -0400
Subject: [keycloak-dev] API for Registering users / Flow for
 registration on iOS
In-Reply-To: <372556024.11804692.1439804741197.JavaMail.zimbra@redhat.com>
References: <CANWAcaXQ9TsUj-4UHRyyBgksq6AEsyDEgNy8AyD+Sxy2DVd9GQ@mail.gmail.com>
	<372556024.11804692.1439804741197.JavaMail.zimbra@redhat.com>
Message-ID: <CANWAcaU3u_13QF-6356OW29sG3UfNWv_0KhbBvMP5t2mWYWfMg@mail.gmail.com>

Yeap exactly.


Vinay

On Mon, Aug 17, 2015 at 5:45 AM, Stian Thorgersen <stian at redhat.com> wrote:

> Just configure the Facebook social provider for the realm and the users
> would now have a option to login with Facebook. First time the user logs in
> with Facebook a user is created internally.
>
> ----- Original Message -----
> > From: "Vinay Anantharaman" <vinayan3 at gmail.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, 14 August, 2015 10:22:41 PM
> > Subject: [keycloak-dev] API for Registering users / Flow for
> registration on  iOS
> >
> > Hi,
> > I would like to make an iOS app which uses social login using Facebook. I
> > don't want to have the user's register using Keycloak's HTML form to
> > register. I've made an app before where we had a native UI for social
> login
> > for Facebook. I passed the FB Access token to my backend and was able to
> > create a user from there.
> >
> > How can I get this workflow with Keycloak? I dug around the docs and
> couldn't
> > find anything. I assume that Keycloak's HTML registration forms must be
> > submitting and accept social login tokens to create users.
> >
> >
> > Thanks,
> >
> >
> >
> > Vinay Anantharamann
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Vinay Anantharaman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150817/3a68a282/attachment-0001.html 

From vinayan3 at gmail.com  Mon Aug 17 11:13:58 2015
From: vinayan3 at gmail.com (Vinay Anantharaman)
Date: Mon, 17 Aug 2015 11:13:58 -0400
Subject: [keycloak-dev] Implementing database-service example in Python
In-Reply-To: <852029863.11652841.1439798464060.JavaMail.zimbra@redhat.com>
References: <CANWAcaUP3jXVGY+cmAsnyEp0AiHYoBENucf4XO0cbPq3Ef89bg@mail.gmail.com>
	<826281598.9693806.1439445653118.JavaMail.zimbra@redhat.com>
	<55CC95FD.6050601@redhat.com>
	<CANWAcaVnBSaF22bHAXyyT8roMTD7pNLP6GVtOFyedixhzOP8zQ@mail.gmail.com>
	<852029863.11652841.1439798464060.JavaMail.zimbra@redhat.com>
Message-ID: <CANWAcaUpzb6M_t28_syRtqUvNxHKV39z=AEKHb6w9TX22U9S0w@mail.gmail.com>

Thanks! I really appreciate you guys helping me out with integrating
Keycloak.


Vinay

On Mon, Aug 17, 2015 at 4:01 AM, Stian Thorgersen <stian at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Vinay Anantharaman" <vinayan3 at gmail.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 14 August, 2015 9:42:39 PM
> > Subject: Re: [keycloak-dev] Implementing database-service example in
> Python
> >
> > I'll be looking into this and will report back if a library exists for
> Python
> > to read JWT tokens.
> >
> > I was wondering is there an API on the KeyCloak server for doing JWT
> token
> > verification? Or rather should we decode the token and use the REST admin
> > endpoints if we need to query more information?
>
> There is a rest endpoint that can be used to verify a token, but that
> requires a request to KC. As the token is signed it's better to just check
> it locally as it reduces the amount of request to Keycloak.
>
> >
> >
> > Vinay
> >
> > On Thu, Aug 13, 2015 at 9:05 AM, Bill Burke < bburke at redhat.com > wrote:
> >
> >
> > If you're interested in becoming a contributor Vinay, this would be a
> > very useful extension!
> >
> > BTW, we also have a "lightweight" Java Security HTTP Proxy based on
> > Undertow that you can use to secure python apps.
> >
> > On 8/13/2015 2:00 AM, Stian Thorgersen wrote:
> > > Afraid we don't have any libraries for Python yet.
> > >
> > > Simply verifying the token should be relatively straight forward
> though.
> > > It's a standard JWT token (base64 encoded json) with a JWS signature.
> You
> > > can look at RSATokenVerifier to see what details should be verified
> > > (expiration date, issuer, etc..). You also need to verify the
> signature.
> > > There may quite likely be JWT libraries for Python you can use.
> > >
> > > ----- Original Message -----
> > >> From: "Vinay Anantharaman" < vinayan3 at gmail.com >
> > >> To: keycloak-dev at lists.jboss.org
> > >> Sent: Thursday, 13 August, 2015 12:21:01 AM
> > >> Subject: [keycloak-dev] Implementing database-service example in
> Python
> > >>
> > >> Hi,
> > >> I'm trying to implement the example database service from Python. The
> > >> description is here:
> > >>
> > >>
> > >>
> > >>
> https://github.com/keycloak/keycloak/tree/master/examples/demo-template
> > >>
> > >> Our backend service is contacted directly by clients with an access
> token
> > >> from the Keycloak server. We would like to verify access tokens are
> and
> > >> then
> > >> return some data they need. I was looking at the code here:
> > >>
> > >>
> > >>
> > >>
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/database-
> > >> service/src/main/java/org/keycloak/example/oauth/CustomerService.java
> > >>
> > >> In Java this seems quite trivial with the support of Keycloak
> libraries.
> > >> In
> > >> Python I won't have them. What are the APIs on Keycloak I can use to
> > >> verify
> > >> an access token? Furthermore, are you aware of any classes like
> > >> RSATokenVerifier for python? I saw it being used here:
> > >>
> > >>
> > >>
> > >>
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/OAuthClient.java#L319
> > >>
> > >> Thanks,
> > >>
> > >>
> > >> Vinay Anantharaman
> > >>
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > --
> > Vinay Anantharaman
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Vinay Anantharaman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150817/df8bc9ef/attachment.html 

From mposolda at redhat.com  Tue Aug 18 02:58:00 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 18 Aug 2015 08:58:00 +0200
Subject: [keycloak-dev] Pluggable client authentication,
 Support for client authentication with signed JWT
Message-ID: <55D2D778.3030004@redhat.com>

I've sent PR https://github.com/keycloak/keycloak/pull/1545 for 
#subject. Few main points:
- Authentication of OIDC clients is now pluggable. I've added 
ClientAuthenticationSPI and some support classes like 
ClientAuthenticator . There is also new flow type 
ClientAuthenticationFlow as there are some differences between 
authenticating clients and users (ie. for clients you don't have 
ClientSession available etc).

- There is new builtin flow "clients" added automatically, which can be 
seen in "Authentication" tab in admin console . By default it has 2 
executions:
-- Traditional authentication with client_id and client_secret
-- Authentication with signed JWT . It works in a way that client 
generates JWT and signs it with his private key . Keycloak then verifies 
signature with public key attached to the certificate corresponding to 
client . Related specifications: [1] and [2] . I've implemented 6.1 and 
6.2 from the [1], which means that clients are able to authenticate 
themselves for retrieve service accounts (ie. "grant_type" is 
"client_credentials" ), but also authenticate themselves for all other 
backchannel requests (code-to-token, refresh token etc)

- In "Credentials" tab in admin console for Client is table with 
available authentication mechanism. Admin needs to choose "Client Id and 
Secret" or "Signed JWT" . For signed JWT he can either:
-- generate keypair + certificate and download his private key into JKS 
or PKCS12 keystore file
-- upload the certificate corresponding to his existing private key .
In both cases is Client's private key not saved in Keycloak DB as 
discussed in other thread last week. So just the client is exclusive 
owner of his private key and when he loose it, he needs to generate and 
download another one.


Possible remaining work:
1) Adapters support?  I am thinking about adding simple pluggable SPI 
for client authentication on adapter side. It will be ServiceLoader 
based and it will choose client authentication mechanism based on the 
credentials provided in keycloak.json in webapp. For example when there is:

"credentials": {
     "secret": "password"
}

it uses traditional clientId and clientSecret like now.

When there is:

"credentials": {
     "jwt": {
         "keystoreFile": "classpath:keystore/keystore.jks",
         "keystoreType": "JKS",
         "storePassword": "secret",
         "keyPassword": "secret",
         "tokenExpiration": 10
     }
}

it will authenticate client with signed JWT . WDYT?


2) Example, docs, polishing, maybe adapter tests . But most of automated 
testing is done already. I've added ClientAuthSignedJWTTest for testing 
signed JWT and CustomFlowTest for testing custom client authentication flow.


ETA for 1 and 2 are maybe 2-3 days of work. I will show more on the call 
on Thursday. WDYT?

Marek


[1] https://tools.ietf.org/html/draft-ietf-oauth-assertions-01
[2] https://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03

From bburke at redhat.com  Tue Aug 18 08:35:31 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Aug 2015 08:35:31 -0400
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <CAPyAMoaJzqs8fKNFDDU7ZjsbFRbdU1ObaHCimJN+f85t=B1TEA@mail.gmail.com>
References: <55CFB7AA.3080406@redhat.com>
	<CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
	<1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>
	<CAPyAMoaEJ4unWzLhugeNyQ=oFK2yV1u4iuLHVdT0+UxQxFUgOQ@mail.gmail.com>
	<462408759.11756368.1439804138850.JavaMail.zimbra@redhat.com>
	<CAPyAMoaJzqs8fKNFDDU7ZjsbFRbdU1ObaHCimJN+f85t=B1TEA@mail.gmail.com>
Message-ID: <55D32693.3030106@redhat.com>



On 8/17/2015 5:39 AM, Thomas Raehalme wrote:
>
>
> On Mon, Aug 17, 2015 at 12:35 PM, Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>> wrote:
>
>     I'm not convinced about this approach, I think it would end up being
>     complex and we'd continuously get request on tweaking it to support
>     other providers.
>
>     Having a simple Java interface with something like (just a quick
>     mock, not the suggested interface):
>
>     SMSProvider:
>
>     * Status sendMessage(String message, String phoneNumber)
>
>     Would be fairly easy for users to implement and would work for all
>     services.
>
>
> Sure, the interface would be simple to implement, but nevertheless it
> requires a customization to the install and Keycloak no longer works
> out-of-the-box.
>
> I'm not saying the interface should not be there, but that it would be
> great to also have a simple HTTP implementation available.
>

 From what I've researched, most of these simple services you have to 
pay for.  There's an OSS SMS proxy and library you can integrate and 
test. But that's it.


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

From bburke at redhat.com  Tue Aug 18 08:39:54 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Aug 2015 08:39:54 -0400
Subject: [keycloak-dev] Pluggable client authentication,
 Support for client authentication with signed JWT
In-Reply-To: <55D2D778.3030004@redhat.com>
References: <55D2D778.3030004@redhat.com>
Message-ID: <55D3279A.7070204@redhat.com>

SAML client console pages have a way to import/export keys/certs.  You 
may be able to reuse/merge with that.

Maybe we should figure out how to merge client and user 
authenticators/flows.

On 8/18/2015 2:58 AM, Marek Posolda wrote:
> I've sent PR https://github.com/keycloak/keycloak/pull/1545 for
> #subject. Few main points:
> - Authentication of OIDC clients is now pluggable. I've added
> ClientAuthenticationSPI and some support classes like
> ClientAuthenticator . There is also new flow type
> ClientAuthenticationFlow as there are some differences between
> authenticating clients and users (ie. for clients you don't have
> ClientSession available etc).
>
> - There is new builtin flow "clients" added automatically, which can be
> seen in "Authentication" tab in admin console . By default it has 2
> executions:
> -- Traditional authentication with client_id and client_secret
> -- Authentication with signed JWT . It works in a way that client
> generates JWT and signs it with his private key . Keycloak then verifies
> signature with public key attached to the certificate corresponding to
> client . Related specifications: [1] and [2] . I've implemented 6.1 and
> 6.2 from the [1], which means that clients are able to authenticate
> themselves for retrieve service accounts (ie. "grant_type" is
> "client_credentials" ), but also authenticate themselves for all other
> backchannel requests (code-to-token, refresh token etc)
>
> - In "Credentials" tab in admin console for Client is table with
> available authentication mechanism. Admin needs to choose "Client Id and
> Secret" or "Signed JWT" . For signed JWT he can either:
> -- generate keypair + certificate and download his private key into JKS
> or PKCS12 keystore file
> -- upload the certificate corresponding to his existing private key .
> In both cases is Client's private key not saved in Keycloak DB as
> discussed in other thread last week. So just the client is exclusive
> owner of his private key and when he loose it, he needs to generate and
> download another one.
>
>
> Possible remaining work:
> 1) Adapters support?  I am thinking about adding simple pluggable SPI
> for client authentication on adapter side. It will be ServiceLoader
> based and it will choose client authentication mechanism based on the
> credentials provided in keycloak.json in webapp. For example when there is:
>
> "credentials": {
>       "secret": "password"
> }
>
> it uses traditional clientId and clientSecret like now.
>
> When there is:
>
> "credentials": {
>       "jwt": {
>           "keystoreFile": "classpath:keystore/keystore.jks",
>           "keystoreType": "JKS",
>           "storePassword": "secret",
>           "keyPassword": "secret",
>           "tokenExpiration": 10
>       }
> }
>
> it will authenticate client with signed JWT . WDYT?
>
>
> 2) Example, docs, polishing, maybe adapter tests . But most of automated
> testing is done already. I've added ClientAuthSignedJWTTest for testing
> signed JWT and CustomFlowTest for testing custom client authentication flow.
>
>
> ETA for 1 and 2 are maybe 2-3 days of work. I will show more on the call
> on Thursday. WDYT?
>
> Marek
>
>
> [1] https://tools.ietf.org/html/draft-ietf-oauth-assertions-01
> [2] https://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Tue Aug 18 08:39:58 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Aug 2015 08:39:58 -0400 (EDT)
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <55D32693.3030106@redhat.com>
References: <55CFB7AA.3080406@redhat.com>
	<CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
	<1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>
	<CAPyAMoaEJ4unWzLhugeNyQ=oFK2yV1u4iuLHVdT0+UxQxFUgOQ@mail.gmail.com>
	<462408759.11756368.1439804138850.JavaMail.zimbra@redhat.com>
	<CAPyAMoaJzqs8fKNFDDU7ZjsbFRbdU1ObaHCimJN+f85t=B1TEA@mail.gmail.com>
	<55D32693.3030106@redhat.com>
Message-ID: <365356047.12917046.1439901598392.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Thomas Raehalme" <thomas.raehalme at aitiofinland.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 18 August, 2015 2:35:31 PM
> Subject: Re: [keycloak-dev] Abstract SMS support
> 
> 
> 
> On 8/17/2015 5:39 AM, Thomas Raehalme wrote:
> >
> >
> > On Mon, Aug 17, 2015 at 12:35 PM, Stian Thorgersen <stian at redhat.com
> > <mailto:stian at redhat.com>> wrote:
> >
> >     I'm not convinced about this approach, I think it would end up being
> >     complex and we'd continuously get request on tweaking it to support
> >     other providers.
> >
> >     Having a simple Java interface with something like (just a quick
> >     mock, not the suggested interface):
> >
> >     SMSProvider:
> >
> >     * Status sendMessage(String message, String phoneNumber)
> >
> >     Would be fairly easy for users to implement and would work for all
> >     services.
> >
> >
> > Sure, the interface would be simple to implement, but nevertheless it
> > requires a customization to the install and Keycloak no longer works
> > out-of-the-box.
> >
> > I'm not saying the interface should not be there, but that it would be
> > great to also have a simple HTTP implementation available.
> >
> 
>  From what I've researched, most of these simple services you have to
> pay for.  There's an OSS SMS proxy and library you can integrate and
> test. But that's it.

For a year or two ago most I looked at included a limited number of free texts. I guess that's changed :(

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

From bburke at redhat.com  Tue Aug 18 08:43:59 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Aug 2015 08:43:59 -0400
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <55D1001E.8010906@redhat.com>
References: <55D1001E.8010906@redhat.com>
Message-ID: <55D3288F.70008@redhat.com>

ping.  Didn't hear whether the Temporary Code addition to reset password 
was or about back to login links/"Cancel" button.

On 8/16/2015 5:26 PM, Bill Burke wrote:
> Here's what I did, I can change things based on questions I asked in
> other emails, but here's how it works.
>
> There's now the concept of "reset password" and a different one "change
> password".
>
> * Reset password is something the user initiates.  This will start an
> Authentication Flow and success will login the user and bring them to
> their application
> * Change password is something initiated by an admin.  This just sends
> an email to the user to reset their password and does not start an
> authentcation flow.
>
> Reset Password changes:
> * A Temporary Code is included in the Email in addition to a clickable
> link.
> * When a user requests to be sent an email, they are brought to a new
> screen.  This screen allows the user to alternatively enter in the code
> from the email rather than clicking on a link.
> * Temporary codes can only be entered once.  If it is entered wrong,
> user has to start login process all over again.
> * Links can only be clicked once.
> * The "Enter code" screen is shown with a success message even if a bad
> username or email is entered.  This is how it worked before.  I'm
> guessing this is here to avoid guessing email/usernames?
>
>
> Change Password changes:
> * It is a different email than Reset Password as there is no code
>
>
> Questions:
> * Should we get rid of the "back to login" links and instead have a
> "Cancel" button?  This applies to registration
> * Should "Enter code" screen show a success even if the username/email
> was invalid?  Do we need to protect hackers from guessing usernames?
>
>

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

From thomas.raehalme at aitiofinland.com  Tue Aug 18 08:56:36 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Tue, 18 Aug 2015 15:56:36 +0300
Subject: [keycloak-dev] Abstract SMS support
In-Reply-To: <55D32693.3030106@redhat.com>
References: <55CFB7AA.3080406@redhat.com>
	<CAPyAMobSmV-os3sNjTaNdptac5Qhy3Vc+hvusO0d_Odb2T1xuA@mail.gmail.com>
	<1991313842.11741716.1439803088874.JavaMail.zimbra@redhat.com>
	<CAPyAMoaEJ4unWzLhugeNyQ=oFK2yV1u4iuLHVdT0+UxQxFUgOQ@mail.gmail.com>
	<462408759.11756368.1439804138850.JavaMail.zimbra@redhat.com>
	<CAPyAMoaJzqs8fKNFDDU7ZjsbFRbdU1ObaHCimJN+f85t=B1TEA@mail.gmail.com>
	<55D32693.3030106@redhat.com>
Message-ID: <CAPyAMoZTrMCKtge4QdfO-hNW4vbJ4zKh3M90xLPyku5ewRecsA@mail.gmail.com>

On Tue, Aug 18, 2015 at 3:35 PM, Bill Burke <bburke at redhat.com> wrote:

>
> Sure, the interface would be simple to implement, but nevertheless it
>> requires a customization to the install and Keycloak no longer works
>> out-of-the-box.
>>
>> I'm not saying the interface should not be there, but that it would be
>> great to also have a simple HTTP implementation available.
>>
>>
> From what I've researched, most of these simple services you have to pay
> for.  There's an OSS SMS proxy and library you can integrate and test. But
> that's it.


In my opinion a perfect solution would be a template/keywords based HTTP
implementation where the user can configure endpoint URL and Keycloak will
find-and-replace keywords such as ${phone} and ${message}. That's easy to
test.

Then whoever wants to use SMS needs to purchase a service which provides
simple enough HTTP API, or write their own implementation of the Keycloak
interface Stian suggested.

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

From stian at redhat.com  Tue Aug 18 08:57:11 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Aug 2015 08:57:11 -0400 (EDT)
Subject: [keycloak-dev] refactoring reset password
In-Reply-To: <55CFC805.5000002@redhat.com>
References: <55CFC805.5000002@redhat.com>
Message-ID: <705609667.12962892.1439902631527.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, 16 August, 2015 1:15:17 AM
> Subject: [keycloak-dev] refactoring reset password
> 
> I'm refactoring reset password.  I'll be adding a pluggable
> "reset-credentials" flow so that users can add things like answering
> secret questions before they are sent the email.  They will also be able
> to remove/disable sending an email and implement their own mechanism,
> i.e. SMS.
> 
> Our old implementation would just reset the user's password, they would
> then have to click back to application and restart the login process.
> With flows, I can log the user in.  Isn't that a better approach?

That's incorrect, the old flow would login the user if the reset password link was opened in the same browser session as the flow was initiated from.

> 
> The only issue with automatic login is OTP.  What should be the default
> behavior be here?:
> 
> 1) If OTP is set up for the user or if required by realm, automatically
> set the OTP required action.
> 2) If OTP is set up for the user and not required by realm, disable
> their OTP, let them log in.
> 3) If OTP is set up for the user or if required by realm, don't
> automatically set the OTP required action, let the user login after
> successful email
> 4) If OTP is set up for the user or required by realm, don't set OTP
> required action, after successful email, require them to enter in the otp
> 
> I think the default behavior should be #1.  Without coding, users would
> still be able to configure any option above in the admin console by
> adding various authenticators to the flow.

I'm not following - in #1 are users required to re-configure OTP?

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

From stian at redhat.com  Tue Aug 18 09:04:24 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Aug 2015 09:04:24 -0400 (EDT)
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <55D1001E.8010906@redhat.com>
References: <55D1001E.8010906@redhat.com>
Message-ID: <306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>

Can you elaborate on what the benefits are of these changes? It seems to me that we had something that was working just fine..

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, 16 August, 2015 11:26:54 PM
> Subject: [keycloak-dev] Reset Password changes complete needs review
> 
> Here's what I did, I can change things based on questions I asked in
> other emails, but here's how it works.
> 
> There's now the concept of "reset password" and a different one "change
> password".
> 
> * Reset password is something the user initiates.  This will start an
> Authentication Flow and success will login the user and bring them to
> their application

I assume this is still through email - if so it's important that users are only logged-in if the reset password link is opened in the same user session as they initiated the reset password flow

> * Change password is something initiated by an admin.  This just sends
> an email to the user to reset their password and does not start an
> authentcation flow.

I don't understand why there's two different names/concepts here.

> 
> Reset Password changes:
> * A Temporary Code is included in the Email in addition to a clickable
> link.

What's the benefit of a temporary code? Is it not easier for a user to just click the link? Having both seems like it could confuse users.

> * When a user requests to be sent an email, they are brought to a new
> screen.  This screen allows the user to alternatively enter in the code
> from the email rather than clicking on a link.
> * Temporary codes can only be entered once.  If it is entered wrong,
> user has to start login process all over again.
> * Links can only be clicked once.
> * The "Enter code" screen is shown with a success message even if a bad
> username or email is entered.  This is how it worked before.  I'm
> guessing this is here to avoid guessing email/usernames?

Yes

> 
> 
> Change Password changes:
> * It is a different email than Reset Password as there is no code
> 
> 
> Questions:
> * Should we get rid of the "back to login" links and instead have a
> "Cancel" button?  This applies to registration

Cancel suggests to me that it would go back to the application. Back to login is more clear that it goes back to the login screen. A user could have clicked the recover password link by mistake.

> * Should "Enter code" screen show a success even if the username/email
> was invalid?  Do we need to protect hackers from guessing usernames?

Yes, we should never make it possible to guess/check usernames/emails.

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

From stian at redhat.com  Tue Aug 18 09:14:05 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Aug 2015 09:14:05 -0400 (EDT)
Subject: [keycloak-dev] Groups design
In-Reply-To: <55CCAB46.7060602@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>
	<55CC9933.6010405@redhat.com>
	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
	<55CCA3A6.8040002@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
Message-ID: <1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 4:35:50 PM
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> On 8/13/2015 10:17 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 13 August, 2015 4:03:18 PM
> >> Subject: Re: [keycloak-dev] Groups design
> >>
> >>
> >>
> >> On 8/13/2015 9:32 AM, Stian Thorgersen wrote:
> >>
> >>>>>> * Groups can be members of one or more groups
> >>>>>> * Users can be members of one or more groups
> >>>>>> * Users inherit attributes of the groups they belong to.
> >>>>>> * UserModel now has a getGroups(), hasGroup(), grantGroup(),
> >>>>>> deleteGroup()
> >>>>>> * Similar to default roles, we also have default groups.
> >>>>>
> >>>>> If we add default groups we don't need default roles and should remove
> >>>>> them.
> >>>>>
> >>>>
> >>>> Not sure I agree.  Users may not want roles.
> >>>
> >>> You mean may not want groups? I just don't like maintaining multiple ways
> >>> to achieve the same thing - extra work for us and complicates
> >>> documentation, etc..
> >>>
> >>
> >> Yeah, sorry, users just might not create any groups, plus its backward
> >> compatible to keep default roles.  The extra work to add default groups
> >> is simple.  Its just duplication of the equivalent role code.
> >
> > It's still extra stuff that needs documenting/explaining and for users to
> > understand. Having multiple things that does the "same thing" is a good
> > way of making software complicated IMO.
> >
> 
> Its not the same thing.  Its a convenience thing as with your proposal
> you have the extra step of creating the default group.

IMO it's the same thing. Having two options increases the amount of concepts a user has to understand, increases documentation, etc..

More importantly if we remove composite roles and replace fully with groups, then default roles are much less usable.

My vote is to remove default roles and just have default groups, then focus on making it easy to do the required setup around it.

> 
> >>
> >>> Why not just have a default group? Then users can add whatever roles and
> >>> other groups they want to it?
> >>>
> >>
> >> I don't like a "default group" for the same reason I don't like these
> >> pseudo "built in" clients.
> >
> > I agree
> >
> > But, if someone wants to add some default roles to a user, why would they
> > care if it's done through adding a default group and adding roles to that,
> > rather than adding default roles directly? If we remove composite roles,
> > it more or less makes the default roles feature a bit useless in either
> > case, so would be better to use groups for it.
> >
> 
> Why would they care?  Its an extra step.

Doesn't have to be, we can make it easy to do through the admin console

> 
> >>
> >>
> >>>> Not really our problem.  If somebody does an overcomplicated design,
> >>>> that's their problem.
> >>>
> >>> I think it is. It would be very hard for a user to interpret what would
> >>> end
> >>> up in the token even with relatively simple groups.
> >>>
> >>
> >> Still, I dont think its our problem.  They can choose not to use the
> >> feature.
> >
> > I disagree - KC is supposed to be easy to use, that should include the
> > advanced features as well. We shouldn't create something that by design
> > would potential be hard to use.
> >
> 
> I don't think a Group mapper would conflict with other Group mappers as
> they would generally be concerned with mapping attribute and roles that
> are defined within the Group.

Sure, but a user could be member of many groups, where each groups in turn could be members of other groups. IMO this will just end up messy even with a relatively simple group hierarchy.

> 
> >>
> >>>>
> >>>>> * Shouldn't token format be defined by a client, not by groups? A
> >>>>> client
> >>>>> will expect a token is a certain format, but if it's dependent on what
> >>>>> group a user belongs to all bets is off.
> >>>>>
> >>>>
> >>>> Probably depends on the app.  But that's a good point.  Just seem cool
> >>>> to be able to assign behavior to a group or even a role, rather than
> >>>> assigning behavior to the client.
> >>>
> >>> I'd rather think that groups are the source of the information. So the
> >>> available claims are:
> >>>
> >>> * Users roles and attributes
> >>> * Groups roles and attributes
> >>>
> >>> But, then you still have a set of protocol mappers (either specified on a
> >>> per-client as now, or ability to share these) that takes these claims and
> >>> adds it to the token.
> >>>
> >>
> >> Another way of looking at it is that the group defines of how attributes
> >> and roles look inside the claim/assertion, rather than the client
> >> defining how an attribute looks.
> >>
> >> I'm not entirely convinced is a great thing to have, but it does seem
> >> like it would be useful.
> >
> > I'm not at all convinced ;)
> >
> > It'll be more important to be able to share a set of protocol mappers
> > between clients. So a client should be able to define it's own protocol
> > mappers, and it should be possible to define protocol mappers groups (or
> > whatever it's called) at the realm level and re-use those. One issue with
> > a shared protocol mappers group is that would define the "token format",
> > but you then loose the ability to define what attributes/claims each
> > client should retrieve.
> >
> 
> I think defining a MapperGroup that could be shared between clients is a
> good thing.  Maybe a better name would be a ClientTemplate or something
> in which you could define not only mappers, but also protocol settings
> and scope.  I think this is orthogonal to Group mappers though...
> 
> Again, I don't think a Group mapper would conflict with other Group
> mappers as they would generally be concerned with mapping attribute and
> roles that are defined within the Group.
> 
> Group mappers are just a different type of association.  Again, allowing
> you to trigger behavior via a Group than by a Client.

I think I've misunderstood what you've suggested. Is it correct that:

* A realm has one or more "group mappers"
* A client belongs to one or more "group mappers"

If so, it sounds good. I think a flat structure is good enough though (no a group mapper can have one or more group mappers etc..).

Group mappers is probably a horrible name, so client template sounds much better.

> 
> 
> >>
> >>
> >>>>
> >>>>>>
> >>>>>> Questions:
> >>>>>> * Do we want to expand the concept of a Group so that clients and
> >>>>>> identity brokers can belong to a Group? Or just create a separate
> >>>>>> composite structure for this?
> >>>>>
> >>>>> Not sure we need that at all. Can't identity brokers and clients just
> >>>>> use
> >>>>> mappings to achieve the required effect? Or am I confusing what effect
> >>>>> this would have.
> >>>>>
> >>>>
> >>>> The concept of associating mappers to a Group isn't required, its just a
> >>>> different way of attacking the problem.
> >>>
> >>> I don't like alternatives ;)
> >>>
> >>
> >> I don't think it is an alternative.  It is just allowing the Group
> >> decide how to map things.
> >
> > Can you elaborate on it a bit more then? As I see it:
> >
> > * Identity brokers should be able to add a mapper that defines what groups
> > a user belongs to
> > * Clients should be able to use a "group" mapper to add a group to the
> > token. The group mapper would add the attributes and roles associated with
> > the group to the token.
> >
> 
> You would have to define a mapper like
> 
> Has Group:
> Attribute name:
> Maps to claim name:
> 
> Instead of just creating a mapper on the Group of
> 
> Attribute name:
> Mapps to Claim Name:

I'm not following

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

From stian at redhat.com  Tue Aug 18 09:46:18 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Aug 2015 09:46:18 -0400 (EDT)
Subject: [keycloak-dev] Pluggable client authentication,
 Support for client authentication with signed JWT
In-Reply-To: <55D2D778.3030004@redhat.com>
References: <55D2D778.3030004@redhat.com>
Message-ID: <788881850.12990892.1439905578332.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 August, 2015 8:58:00 AM
> Subject: [keycloak-dev] Pluggable client authentication, Support for client authentication with signed JWT
> 
> I've sent PR https://github.com/keycloak/keycloak/pull/1545 for
> #subject. Few main points:
> - Authentication of OIDC clients is now pluggable. I've added
> ClientAuthenticationSPI and some support classes like
> ClientAuthenticator . There is also new flow type
> ClientAuthenticationFlow as there are some differences between
> authenticating clients and users (ie. for clients you don't have
> ClientSession available etc).
> 
> - There is new builtin flow "clients" added automatically, which can be
> seen in "Authentication" tab in admin console . By default it has 2
> executions:
> -- Traditional authentication with client_id and client_secret
> -- Authentication with signed JWT . It works in a way that client
> generates JWT and signs it with his private key . Keycloak then verifies
> signature with public key attached to the certificate corresponding to
> client . Related specifications: [1] and [2] . I've implemented 6.1 and
> 6.2 from the [1], which means that clients are able to authenticate
> themselves for retrieve service accounts (ie. "grant_type" is
> "client_credentials" ), but also authenticate themselves for all other
> backchannel requests (code-to-token, refresh token etc)
> 
> - In "Credentials" tab in admin console for Client is table with
> available authentication mechanism. Admin needs to choose "Client Id and
> Secret" or "Signed JWT" . For signed JWT he can either:
> -- generate keypair + certificate and download his private key into JKS
> or PKCS12 keystore file
> -- upload the certificate corresponding to his existing private key .
> In both cases is Client's private key not saved in Keycloak DB as
> discussed in other thread last week. So just the client is exclusive
> owner of his private key and when he loose it, he needs to generate and
> download another one.
> 
> 
> Possible remaining work:
> 1) Adapters support?  I am thinking about adding simple pluggable SPI
> for client authentication on adapter side. It will be ServiceLoader
> based and it will choose client authentication mechanism based on the
> credentials provided in keycloak.json in webapp. For example when there is:
> 
> "credentials": {
>      "secret": "password"
> }
> 
> it uses traditional clientId and clientSecret like now.
> 
> When there is:
> 
> "credentials": {
>      "jwt": {
>          "keystoreFile": "classpath:keystore/keystore.jks",
>          "keystoreType": "JKS",
>          "storePassword": "secret",
>          "keyPassword": "secret",
>          "tokenExpiration": 10
>      }
> }
> 
> it will authenticate client with signed JWT . WDYT?

+1 Sounds good

> 
> 
> 2) Example, docs, polishing, maybe adapter tests . But most of automated
> testing is done already. I've added ClientAuthSignedJWTTest for testing
> signed JWT and CustomFlowTest for testing custom client authentication flow.

Did you add testing to integration-arquillian or the old testsuite?

For adapter tests Tomas is adding adapter testsuites that tests with full blown servers soon. Probably best to wait until this is added, not sure exactly when that'll be though.

> 
> 
> ETA for 1 and 2 are maybe 2-3 days of work. I will show more on the call
> on Thursday. WDYT?
> 
> Marek
> 
> 
> [1] https://tools.ietf.org/html/draft-ietf-oauth-assertions-01
> [2] https://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Aug 18 09:47:29 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Aug 2015 09:47:29 -0400 (EDT)
Subject: [keycloak-dev] Pluggable client authentication,
 Support for client authentication with signed JWT
In-Reply-To: <55D3279A.7070204@redhat.com>
References: <55D2D778.3030004@redhat.com> <55D3279A.7070204@redhat.com>
Message-ID: <1148159731.12993077.1439905649312.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 August, 2015 2:39:54 PM
> Subject: Re: [keycloak-dev] Pluggable client authentication, Support for client authentication with signed JWT
> 
> SAML client console pages have a way to import/export keys/certs.  You
> may be able to reuse/merge with that.
> 
> Maybe we should figure out how to merge client and user
> authenticators/flows.

Should we really merge them? Will they not always be different enough to warrant having them separate?

> 
> On 8/18/2015 2:58 AM, Marek Posolda wrote:
> > I've sent PR https://github.com/keycloak/keycloak/pull/1545 for
> > #subject. Few main points:
> > - Authentication of OIDC clients is now pluggable. I've added
> > ClientAuthenticationSPI and some support classes like
> > ClientAuthenticator . There is also new flow type
> > ClientAuthenticationFlow as there are some differences between
> > authenticating clients and users (ie. for clients you don't have
> > ClientSession available etc).
> >
> > - There is new builtin flow "clients" added automatically, which can be
> > seen in "Authentication" tab in admin console . By default it has 2
> > executions:
> > -- Traditional authentication with client_id and client_secret
> > -- Authentication with signed JWT . It works in a way that client
> > generates JWT and signs it with his private key . Keycloak then verifies
> > signature with public key attached to the certificate corresponding to
> > client . Related specifications: [1] and [2] . I've implemented 6.1 and
> > 6.2 from the [1], which means that clients are able to authenticate
> > themselves for retrieve service accounts (ie. "grant_type" is
> > "client_credentials" ), but also authenticate themselves for all other
> > backchannel requests (code-to-token, refresh token etc)
> >
> > - In "Credentials" tab in admin console for Client is table with
> > available authentication mechanism. Admin needs to choose "Client Id and
> > Secret" or "Signed JWT" . For signed JWT he can either:
> > -- generate keypair + certificate and download his private key into JKS
> > or PKCS12 keystore file
> > -- upload the certificate corresponding to his existing private key .
> > In both cases is Client's private key not saved in Keycloak DB as
> > discussed in other thread last week. So just the client is exclusive
> > owner of his private key and when he loose it, he needs to generate and
> > download another one.
> >
> >
> > Possible remaining work:
> > 1) Adapters support?  I am thinking about adding simple pluggable SPI
> > for client authentication on adapter side. It will be ServiceLoader
> > based and it will choose client authentication mechanism based on the
> > credentials provided in keycloak.json in webapp. For example when there is:
> >
> > "credentials": {
> >       "secret": "password"
> > }
> >
> > it uses traditional clientId and clientSecret like now.
> >
> > When there is:
> >
> > "credentials": {
> >       "jwt": {
> >           "keystoreFile": "classpath:keystore/keystore.jks",
> >           "keystoreType": "JKS",
> >           "storePassword": "secret",
> >           "keyPassword": "secret",
> >           "tokenExpiration": 10
> >       }
> > }
> >
> > it will authenticate client with signed JWT . WDYT?
> >
> >
> > 2) Example, docs, polishing, maybe adapter tests . But most of automated
> > testing is done already. I've added ClientAuthSignedJWTTest for testing
> > signed JWT and CustomFlowTest for testing custom client authentication
> > flow.
> >
> >
> > ETA for 1 and 2 are maybe 2-3 days of work. I will show more on the call
> > on Thursday. WDYT?
> >
> > Marek
> >
> >
> > [1] https://tools.ietf.org/html/draft-ietf-oauth-assertions-01
> > [2] https://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Tue Aug 18 10:03:08 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 18 Aug 2015 16:03:08 +0200
Subject: [keycloak-dev] Pluggable client authentication,
 Support for client authentication with signed JWT
In-Reply-To: <55D3279A.7070204@redhat.com>
References: <55D2D778.3030004@redhat.com> <55D3279A.7070204@redhat.com>
Message-ID: <55D33B1C.5040702@redhat.com>

Dne 18.8.2015 v 14:39 Bill Burke napsal(a):
> SAML client console pages have a way to import/export keys/certs.  You
> may be able to reuse/merge with that.
I already reused and merge with that whenever possible. Most of server 
logic ( ClientAttributeCertificateResource ) is reused and I also reused 
some of your angular code.

One thing, I didn't want, is storing the client private keys in keycloak 
DB, which we agreed with Stian last week (discussion with subject "Keep 
client private keys in Keycloak DB?" ).

For SAML, I think for both usecases where are keys/certs used (Signing 
SAMLRequest by client or encrypt SAML Assertion with client public key) 
is also private key not needed in Keycloak DB. Shoudn't we try to 
improve SAML as well and avoid storing private keys? IMO Client private 
keys should be exclusively owned by client and not by Keycloak server. 
If client loose the key, he can generate new keypair again.
>
> Maybe we should figure out how to merge client and user
> authenticators/flows.
yeah, I was trying to reuse whenever possible. Like 
ClientAuthenticatorFactory and AuthenticatorFactory has base superclass 
ConfigurableAuthenticatorFactory etc.


But maybe there is still space for improvement though.  Do we want to merge into one class and use generics? Like


public interface Authenticator<T> {

    void authenticate(AuthenticationContext<T> context);

}

when concrete implementation will use T as either UserModel or ClientModel ?

I was also thinking about doing abstract superclass for 
DefaultAuthenticationFlow and ClientAuthenticationFlow. But in the end, 
I added ClientAuthenticationFlow as separate class as there is lot of 
logic specific to user in DefaultAuthenticationFlow (like 
authenticator.requiresUser() etc). Another thing is that 
ClientAuthenticationFlow doesn't have access to ClientSession when 
DefaultAuthenticationFlow needs it as it maintains state between 
requests (client authentication is single request). There are few other 
similar things...

I will try to revisit and improve if possible, on the other hand having 
abstraction for everything might sometimes makes things more complex and 
harder to understand...

Marek
>
> On 8/18/2015 2:58 AM, Marek Posolda wrote:
>> I've sent PR https://github.com/keycloak/keycloak/pull/1545 for
>> #subject. Few main points:
>> - Authentication of OIDC clients is now pluggable. I've added
>> ClientAuthenticationSPI and some support classes like
>> ClientAuthenticator . There is also new flow type
>> ClientAuthenticationFlow as there are some differences between
>> authenticating clients and users (ie. for clients you don't have
>> ClientSession available etc).
>>
>> - There is new builtin flow "clients" added automatically, which can be
>> seen in "Authentication" tab in admin console . By default it has 2
>> executions:
>> -- Traditional authentication with client_id and client_secret
>> -- Authentication with signed JWT . It works in a way that client
>> generates JWT and signs it with his private key . Keycloak then verifies
>> signature with public key attached to the certificate corresponding to
>> client . Related specifications: [1] and [2] . I've implemented 6.1 and
>> 6.2 from the [1], which means that clients are able to authenticate
>> themselves for retrieve service accounts (ie. "grant_type" is
>> "client_credentials" ), but also authenticate themselves for all other
>> backchannel requests (code-to-token, refresh token etc)
>>
>> - In "Credentials" tab in admin console for Client is table with
>> available authentication mechanism. Admin needs to choose "Client Id and
>> Secret" or "Signed JWT" . For signed JWT he can either:
>> -- generate keypair + certificate and download his private key into JKS
>> or PKCS12 keystore file
>> -- upload the certificate corresponding to his existing private key .
>> In both cases is Client's private key not saved in Keycloak DB as
>> discussed in other thread last week. So just the client is exclusive
>> owner of his private key and when he loose it, he needs to generate and
>> download another one.
>>
>>
>> Possible remaining work:
>> 1) Adapters support?  I am thinking about adding simple pluggable SPI
>> for client authentication on adapter side. It will be ServiceLoader
>> based and it will choose client authentication mechanism based on the
>> credentials provided in keycloak.json in webapp. For example when there is:
>>
>> "credentials": {
>>        "secret": "password"
>> }
>>
>> it uses traditional clientId and clientSecret like now.
>>
>> When there is:
>>
>> "credentials": {
>>        "jwt": {
>>            "keystoreFile": "classpath:keystore/keystore.jks",
>>            "keystoreType": "JKS",
>>            "storePassword": "secret",
>>            "keyPassword": "secret",
>>            "tokenExpiration": 10
>>        }
>> }
>>
>> it will authenticate client with signed JWT . WDYT?
>>
>>
>> 2) Example, docs, polishing, maybe adapter tests . But most of automated
>> testing is done already. I've added ClientAuthSignedJWTTest for testing
>> signed JWT and CustomFlowTest for testing custom client authentication flow.
>>
>>
>> ETA for 1 and 2 are maybe 2-3 days of work. I will show more on the call
>> on Thursday. WDYT?
>>
>> Marek
>>
>>
>> [1] https://tools.ietf.org/html/draft-ietf-oauth-assertions-01
>> [2] https://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03
>> _______________________________________________
>> 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/20150818/551c0c26/attachment.html 

From bburke at redhat.com  Tue Aug 18 10:53:44 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Aug 2015 10:53:44 -0400
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>
Message-ID: <55D346F8.3030307@redhat.com>



On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
> Can you elaborate on what the benefits are of these changes? It seems to me that we had something that was working just fine..
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Sunday, 16 August, 2015 11:26:54 PM
>> Subject: [keycloak-dev] Reset Password changes complete needs review
>>
>> Here's what I did, I can change things based on questions I asked in
>> other emails, but here's how it works.
>>
>> There's now the concept of "reset password" and a different one "change
>> password".
>>
>> * Reset password is something the user initiates.  This will start an
>> Authentication Flow and success will login the user and bring them to
>> their application
>
> I assume this is still through email - if so it's important that users are only logged-in if the reset password link is opened in the same user session as they initiated the reset password flow
>

With the previous impl, if somebody as able to hack your email account, 
then they could bypass OTP entirely.  Also previous implementation 
wasn't really compatible with auth SPI.  There may be additional steps 
to reseting credentials beyond an email, i.e. entering in a code from an 
SMS message.  We may also be reseting both OTP and Password.  Finally, 
the update password required action had reset-password specific logic 
within it.

Honestly, I'd prefer to switch exclusively to a temporary code as it 
makes everything much simpler to support:  for us and for users wanting 
to write extensiosn.  I don't think this is a big usability issue as 
Google requires entering a temporary code from an SMS message.  Also, 
with the way it worked in 1.4, out-of-band email password reset would 
require relogging in which is actually more steps.  Finally, links can 
be messed up by email readers sometimes if they are long enough, making 
them error prone.




>> * Change password is something initiated by an admin.  This just sends
>> an email to the user to reset their password and does not start an
>> authentcation flow.
>
> I don't understand why there's two different names/concepts here.
>

The messages would be different:

Reset password: Somebody reset your password, click the link or enter in 
the code on the web page from the email

Change password:  Your adminstrator has requested you change your 
credentials.  Please click the link to reset them.


Reset password could potentially log the user in.  Change password would 
not log the user in and just display a "Credentials Reset" message.

> Yes, we should never make it possible to guess/check usernames/emails.
>

That's what I assumed and that's what I implemented.

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

From mposolda at redhat.com  Tue Aug 18 10:07:28 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 18 Aug 2015 16:07:28 +0200
Subject: [keycloak-dev] Pluggable client authentication,
 Support for client authentication with signed JWT
In-Reply-To: <788881850.12990892.1439905578332.JavaMail.zimbra@redhat.com>
References: <55D2D778.3030004@redhat.com>
	<788881850.12990892.1439905578332.JavaMail.zimbra@redhat.com>
Message-ID: <55D33C20.6040403@redhat.com>

Dne 18.8.2015 v 15:46 Stian Thorgersen napsal(a):
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 18 August, 2015 8:58:00 AM
>> Subject: [keycloak-dev] Pluggable client authentication, Support for client authentication with signed JWT
>>
>> I've sent PR https://github.com/keycloak/keycloak/pull/1545 for
>> #subject. Few main points:
>> - Authentication of OIDC clients is now pluggable. I've added
>> ClientAuthenticationSPI and some support classes like
>> ClientAuthenticator . There is also new flow type
>> ClientAuthenticationFlow as there are some differences between
>> authenticating clients and users (ie. for clients you don't have
>> ClientSession available etc).
>>
>> - There is new builtin flow "clients" added automatically, which can be
>> seen in "Authentication" tab in admin console . By default it has 2
>> executions:
>> -- Traditional authentication with client_id and client_secret
>> -- Authentication with signed JWT . It works in a way that client
>> generates JWT and signs it with his private key . Keycloak then verifies
>> signature with public key attached to the certificate corresponding to
>> client . Related specifications: [1] and [2] . I've implemented 6.1 and
>> 6.2 from the [1], which means that clients are able to authenticate
>> themselves for retrieve service accounts (ie. "grant_type" is
>> "client_credentials" ), but also authenticate themselves for all other
>> backchannel requests (code-to-token, refresh token etc)
>>
>> - In "Credentials" tab in admin console for Client is table with
>> available authentication mechanism. Admin needs to choose "Client Id and
>> Secret" or "Signed JWT" . For signed JWT he can either:
>> -- generate keypair + certificate and download his private key into JKS
>> or PKCS12 keystore file
>> -- upload the certificate corresponding to his existing private key .
>> In both cases is Client's private key not saved in Keycloak DB as
>> discussed in other thread last week. So just the client is exclusive
>> owner of his private key and when he loose it, he needs to generate and
>> download another one.
>>
>>
>> Possible remaining work:
>> 1) Adapters support?  I am thinking about adding simple pluggable SPI
>> for client authentication on adapter side. It will be ServiceLoader
>> based and it will choose client authentication mechanism based on the
>> credentials provided in keycloak.json in webapp. For example when there is:
>>
>> "credentials": {
>>       "secret": "password"
>> }
>>
>> it uses traditional clientId and clientSecret like now.
>>
>> When there is:
>>
>> "credentials": {
>>       "jwt": {
>>           "keystoreFile": "classpath:keystore/keystore.jks",
>>           "keystoreType": "JKS",
>>           "storePassword": "secret",
>>           "keyPassword": "secret",
>>           "tokenExpiration": 10
>>       }
>> }
>>
>> it will authenticate client with signed JWT . WDYT?
> +1 Sounds good
>
>>
>> 2) Example, docs, polishing, maybe adapter tests . But most of automated
>> testing is done already. I've added ClientAuthSignedJWTTest for testing
>> signed JWT and CustomFlowTest for testing custom client authentication flow.
> Did you add testing to integration-arquillian or the old testsuite?
Old testsuite. No changes in integration-arquillian but it passed on 
travis - on 2nd attempt :)
>
> For adapter tests Tomas is adding adapter testsuites that tests with full blown servers soon. Probably best to wait until this is added, not sure exactly when that'll be though.
Ok. For now, I can maybe do just 1-2 simple adapter tests to our 
existing adapter tests until Tomas's testsuite is finished. For the 
server part, the ClientAuthSignedJWTTest should already cover most of 
usecases and error/alternative flows.

Marek
>
>>
>> ETA for 1 and 2 are maybe 2-3 days of work. I will show more on the call
>> on Thursday. WDYT?
>>
>> Marek
>>
>>
>> [1] https://tools.ietf.org/html/draft-ietf-oauth-assertions-01
>> [2] https://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Tue Aug 18 11:14:21 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Aug 2015 11:14:21 -0400
Subject: [keycloak-dev] Groups design
In-Reply-To: <1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1566155132.9698442.1439447039422.JavaMail.zimbra@redhat.com>
	<55CC9933.6010405@redhat.com>
	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
	<55CCA3A6.8040002@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
Message-ID: <55D34BCD.50303@redhat.com>



On 8/18/2015 9:14 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 13 August, 2015 4:35:50 PM
>> Subject: Re: [keycloak-dev] Groups design
>>
>>
>>
>> On 8/13/2015 10:17 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 13 August, 2015 4:03:18 PM
>>>> Subject: Re: [keycloak-dev] Groups design
>>>>
>>>>
>>>>
>>>> On 8/13/2015 9:32 AM, Stian Thorgersen wrote:
>>>>
>>>>>>>> * Groups can be members of one or more groups
>>>>>>>> * Users can be members of one or more groups
>>>>>>>> * Users inherit attributes of the groups they belong to.
>>>>>>>> * UserModel now has a getGroups(), hasGroup(), grantGroup(),
>>>>>>>> deleteGroup()
>>>>>>>> * Similar to default roles, we also have default groups.
>>>>>>>
>>>>>>> If we add default groups we don't need default roles and should remove
>>>>>>> them.
>>>>>>>
>>>>>>
>>>>>> Not sure I agree.  Users may not want roles.
>>>>>
>>>>> You mean may not want groups? I just don't like maintaining multiple ways
>>>>> to achieve the same thing - extra work for us and complicates
>>>>> documentation, etc..
>>>>>
>>>>
>>>> Yeah, sorry, users just might not create any groups, plus its backward
>>>> compatible to keep default roles.  The extra work to add default groups
>>>> is simple.  Its just duplication of the equivalent role code.
>>>
>>> It's still extra stuff that needs documenting/explaining and for users to
>>> understand. Having multiple things that does the "same thing" is a good
>>> way of making software complicated IMO.
>>>
>>
>> Its not the same thing.  Its a convenience thing as with your proposal
>> you have the extra step of creating the default group.
>
> IMO it's the same thing. Having two options increases the amount of concepts a user has to understand, increases documentation, etc..
>
> More importantly if we remove composite roles and replace fully with groups, then default roles are much less usable.
>
> My vote is to remove default roles and just have default groups, then focus on making it easy to do the required setup around it.
>

I don't really care that much, but you still have to worry about 
migration and document how old default roles/role composites map onto 
the new Group model.

>>
>> I don't think a Group mapper would conflict with other Group mappers as
>> they would generally be concerned with mapping attribute and roles that
>> are defined within the Group.
>
> Sure, but a user could be member of many groups, where each groups in turn could be members of other groups. IMO this will just end up messy even with a relatively simple group hierarchy.
>

Only messy if there are conflicting mappers which IMO will be unlikely.

>
> I think I've misunderstood what you've suggested. Is it correct that:
>
> * A realm has one or more "group mappers"
> * A client belongs to one or more "group mappers"
>
> If so, it sounds good. I think a flat structure is good enough though (no a group mapper can have one or more group mappers etc..).
>
> Group mappers is probably a horrible name, so client template sounds much better.
>

I think we'll just have Client Templates where you can define common 
protocol settings and common mappers.

That's different than what I was proposing before.  User belong to 
Group.  A Group has a set of mappers.  A user's group;s mappers are 
applied to the token automatically.  I think its an interesting concept 
but am fine not having it.

So, decision making time?

Have the concept of Client Templates:
* protocol settings
* mappers


Have the concept of User Groups
* Users belong to User Groups
* User Groups have attributes and role mappings

Have the concept of Role Groups:
* Role Groups are just a namespace for roles.


Other actions:

* Deprecate Composite Roles.  Remove with the product cut
* Deprecate Default Roles.  Remove with the product cut.



K, signing off until Thursday.

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

From alexander.schwartz at gmx.net  Tue Aug 18 12:25:00 2015
From: alexander.schwartz at gmx.net (Alexander Schwartz)
Date: Tue, 18 Aug 2015 18:25:00 +0200
Subject: [keycloak-dev] Using Keycloak with Dropwizard
Message-ID: <trinity-15cb6125-ad03-4ac4-8e33-3246c3401609-1439915100369@3capp-gmx-bs31>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150818/a2ee70e2/attachment.html 

From ssilvert at redhat.com  Tue Aug 18 15:59:47 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 18 Aug 2015 15:59:47 -0400
Subject: [keycloak-dev] Upgrade Angular?
Message-ID: <55D38EB3.6060700@redhat.com>

We are using AngularJS 1.2.13.  The latest version is 1.4.4.

The reason I ask is because I am a little worried about performance as 
we begin to use angular-translate.  We are going to end up with a lot of 
$$watchers, which will eventually make the UI sluggish.

There is a solution starting with Angualr 1.3 that lets you specify a 
one-time-binding using double colons like this {{ ::value }}.

Any reason why we can't upgrade?

Stan

From stian at redhat.com  Wed Aug 19 02:01:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Aug 2015 02:01:49 -0400 (EDT)
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <55D346F8.3030307@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>
	<55D346F8.3030307@redhat.com>
Message-ID: <2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 August, 2015 4:53:44 PM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> 
> 
> 
> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
> > Can you elaborate on what the benefits are of these changes? It seems to me
> > that we had something that was working just fine..
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Sunday, 16 August, 2015 11:26:54 PM
> >> Subject: [keycloak-dev] Reset Password changes complete needs review
> >>
> >> Here's what I did, I can change things based on questions I asked in
> >> other emails, but here's how it works.
> >>
> >> There's now the concept of "reset password" and a different one "change
> >> password".
> >>
> >> * Reset password is something the user initiates.  This will start an
> >> Authentication Flow and success will login the user and bring them to
> >> their application
> >
> > I assume this is still through email - if so it's important that users are
> > only logged-in if the reset password link is opened in the same user
> > session as they initiated the reset password flow
> >
> 
> With the previous impl, if somebody as able to hack your email account,
> then they could bypass OTP entirely.  Also previous implementation
> wasn't really compatible with auth SPI.  There may be additional steps
> to reseting credentials beyond an email, i.e. entering in a code from an
> SMS message.  We may also be reseting both OTP and Password.  Finally,
> the update password required action had reset-password specific logic
> within it.
> 
> Honestly, I'd prefer to switch exclusively to a temporary code as it
> makes everything much simpler to support:  for us and for users wanting
> to write extensiosn.  I don't think this is a big usability issue as
> Google requires entering a temporary code from an SMS message.  Also,
> with the way it worked in 1.4, out-of-band email password reset would
> require relogging in which is actually more steps.  Finally, links can
> be messed up by email readers sometimes if they are long enough, making
> them error prone.

-100 We should stick with link in email (and only link, not confuse users by having multiple options), but why can't the link just include the same code?

> 
> 
> 
> 
> >> * Change password is something initiated by an admin.  This just sends
> >> an email to the user to reset their password and does not start an
> >> authentcation flow.
> >
> > I don't understand why there's two different names/concepts here.
> >
> 
> The messages would be different:
> 
> Reset password: Somebody reset your password, click the link or enter in
> the code on the web page from the email
> 
> Change password:  Your adminstrator has requested you change your
> credentials.  Please click the link to reset them.
> 
> 
> Reset password could potentially log the user in.  Change password would
> not log the user in and just display a "Credentials Reset" message.
> 
> > Yes, we should never make it possible to guess/check usernames/emails.
> >
> 
> That's what I assumed and that's what I implemented.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Wed Aug 19 02:05:20 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Aug 2015 02:05:20 -0400 (EDT)
Subject: [keycloak-dev] Groups design
In-Reply-To: <55D34BCD.50303@redhat.com>
References: <55CB4F1D.3000909@redhat.com> <55CC9933.6010405@redhat.com>
	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
	<55CCA3A6.8040002@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
	<55D34BCD.50303@redhat.com>
Message-ID: <951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 August, 2015 5:14:21 PM
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> On 8/18/2015 9:14 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 13 August, 2015 4:35:50 PM
> >> Subject: Re: [keycloak-dev] Groups design
> >>
> >>
> >>
> >> On 8/13/2015 10:17 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 13 August, 2015 4:03:18 PM
> >>>> Subject: Re: [keycloak-dev] Groups design
> >>>>
> >>>>
> >>>>
> >>>> On 8/13/2015 9:32 AM, Stian Thorgersen wrote:
> >>>>
> >>>>>>>> * Groups can be members of one or more groups
> >>>>>>>> * Users can be members of one or more groups
> >>>>>>>> * Users inherit attributes of the groups they belong to.
> >>>>>>>> * UserModel now has a getGroups(), hasGroup(), grantGroup(),
> >>>>>>>> deleteGroup()
> >>>>>>>> * Similar to default roles, we also have default groups.
> >>>>>>>
> >>>>>>> If we add default groups we don't need default roles and should
> >>>>>>> remove
> >>>>>>> them.
> >>>>>>>
> >>>>>>
> >>>>>> Not sure I agree.  Users may not want roles.
> >>>>>
> >>>>> You mean may not want groups? I just don't like maintaining multiple
> >>>>> ways
> >>>>> to achieve the same thing - extra work for us and complicates
> >>>>> documentation, etc..
> >>>>>
> >>>>
> >>>> Yeah, sorry, users just might not create any groups, plus its backward
> >>>> compatible to keep default roles.  The extra work to add default groups
> >>>> is simple.  Its just duplication of the equivalent role code.
> >>>
> >>> It's still extra stuff that needs documenting/explaining and for users to
> >>> understand. Having multiple things that does the "same thing" is a good
> >>> way of making software complicated IMO.
> >>>
> >>
> >> Its not the same thing.  Its a convenience thing as with your proposal
> >> you have the extra step of creating the default group.
> >
> > IMO it's the same thing. Having two options increases the amount of
> > concepts a user has to understand, increases documentation, etc..
> >
> > More importantly if we remove composite roles and replace fully with
> > groups, then default roles are much less usable.
> >
> > My vote is to remove default roles and just have default groups, then focus
> > on making it easy to do the required setup around it.
> >
> 
> I don't really care that much, but you still have to worry about
> migration and document how old default roles/role composites map onto
> the new Group model.
> 
> >>
> >> I don't think a Group mapper would conflict with other Group mappers as
> >> they would generally be concerned with mapping attribute and roles that
> >> are defined within the Group.
> >
> > Sure, but a user could be member of many groups, where each groups in turn
> > could be members of other groups. IMO this will just end up messy even
> > with a relatively simple group hierarchy.
> >
> 
> Only messy if there are conflicting mappers which IMO will be unlikely.
> 
> >
> > I think I've misunderstood what you've suggested. Is it correct that:
> >
> > * A realm has one or more "group mappers"
> > * A client belongs to one or more "group mappers"
> >
> > If so, it sounds good. I think a flat structure is good enough though (no a
> > group mapper can have one or more group mappers etc..).
> >
> > Group mappers is probably a horrible name, so client template sounds much
> > better.
> >
> 
> I think we'll just have Client Templates where you can define common
> protocol settings and common mappers.
> 
> That's different than what I was proposing before.  User belong to
> Group.  A Group has a set of mappers.  A user's group;s mappers are
> applied to the token automatically.  I think its an interesting concept
> but am fine not having it.
> 
> So, decision making time?
> 
> Have the concept of Client Templates:
> * protocol settings
> * mappers

Would be good if clients can import settings from client templates, but also override. Including adding mappers, maybe even removing mappers.

One thing about the name, templates could suggest it's only used at creation time. The effective mappers for a client should be updated when the client template is updated.

> 
> 
> Have the concept of User Groups
> * Users belong to User Groups
> * User Groups have attributes and role mappings
> 
> Have the concept of Role Groups:
> * Role Groups are just a namespace for roles.
> 
> 
> Other actions:
> 
> * Deprecate Composite Roles.  Remove with the product cut
> * Deprecate Default Roles.  Remove with the product cut.

Sounds good

> 
> 
> 
> K, signing off until Thursday.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Wed Aug 19 02:11:32 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Aug 2015 02:11:32 -0400 (EDT)
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <55D38EB3.6060700@redhat.com>
References: <55D38EB3.6060700@redhat.com>
Message-ID: <90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>

I'm not aware of any reasons we can't upgrade, but we would need to take care and do extra testing of the admin console afterwards.

I'd prefer to upgrade to 1.4.4 early in a Sprint, so if you can upgrade this week, that's fine. Otherwise I'd like to wait to 1.6 release cycle.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 August, 2015 9:59:47 PM
> Subject: [keycloak-dev] Upgrade Angular?
> 
> We are using AngularJS 1.2.13.  The latest version is 1.4.4.
> 
> The reason I ask is because I am a little worried about performance as
> we begin to use angular-translate.  We are going to end up with a lot of
> $$watchers, which will eventually make the UI sluggish.
> 
> There is a solution starting with Angualr 1.3 that lets you specify a
> one-time-binding using double colons like this {{ ::value }}.
> 
> Any reason why we can't upgrade?
> 
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Aug 19 02:24:35 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Aug 2015 02:24:35 -0400 (EDT)
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
Message-ID: <823394139.13467899.1439965475774.JavaMail.zimbra@redhat.com>

Useful resources when upgrading:

* https://github.com/angular/angular.js/blob/master/CHANGELOG.md
* http://blog.thoughtram.io/angularjs/2015/01/02/exploring-angular-1.3-bindToController.html

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Stan Silvert" <ssilvert at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 19 August, 2015 8:11:32 AM
> Subject: Re: [keycloak-dev] Upgrade Angular?
> 
> I'm not aware of any reasons we can't upgrade, but we would need to take care
> and do extra testing of the admin console afterwards.
> 
> I'd prefer to upgrade to 1.4.4 early in a Sprint, so if you can upgrade this
> week, that's fine. Otherwise I'd like to wait to 1.6 release cycle.
> 
> ----- Original Message -----
> > From: "Stan Silvert" <ssilvert at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 18 August, 2015 9:59:47 PM
> > Subject: [keycloak-dev] Upgrade Angular?
> > 
> > We are using AngularJS 1.2.13.  The latest version is 1.4.4.
> > 
> > The reason I ask is because I am a little worried about performance as
> > we begin to use angular-translate.  We are going to end up with a lot of
> > $$watchers, which will eventually make the UI sluggish.
> > 
> > There is a solution starting with Angualr 1.3 that lets you specify a
> > one-time-binding using double colons like this {{ ::value }}.
> > 
> > Any reason why we can't upgrade?
> > 
> > Stan
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Aug 19 03:17:37 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Aug 2015 03:17:37 -0400 (EDT)
Subject: [keycloak-dev] Groups design
In-Reply-To: <951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
	<55CCA3A6.8040002@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
	<55D34BCD.50303@redhat.com>
	<951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
Message-ID: <920254531.13544356.1439968657289.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 19 August, 2015 8:05:20 AM
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 18 August, 2015 5:14:21 PM
> > Subject: Re: [keycloak-dev] Groups design
> > 
> > 
> > 
> > On 8/18/2015 9:14 AM, Stian Thorgersen wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: "Stian Thorgersen" <stian at redhat.com>
> > >> Cc: keycloak-dev at lists.jboss.org
> > >> Sent: Thursday, 13 August, 2015 4:35:50 PM
> > >> Subject: Re: [keycloak-dev] Groups design
> > >>
> > >>
> > >>
> > >> On 8/13/2015 10:17 AM, Stian Thorgersen wrote:
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>> Cc: keycloak-dev at lists.jboss.org
> > >>>> Sent: Thursday, 13 August, 2015 4:03:18 PM
> > >>>> Subject: Re: [keycloak-dev] Groups design
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 8/13/2015 9:32 AM, Stian Thorgersen wrote:
> > >>>>
> > >>>>>>>> * Groups can be members of one or more groups
> > >>>>>>>> * Users can be members of one or more groups
> > >>>>>>>> * Users inherit attributes of the groups they belong to.
> > >>>>>>>> * UserModel now has a getGroups(), hasGroup(), grantGroup(),
> > >>>>>>>> deleteGroup()
> > >>>>>>>> * Similar to default roles, we also have default groups.
> > >>>>>>>
> > >>>>>>> If we add default groups we don't need default roles and should
> > >>>>>>> remove
> > >>>>>>> them.
> > >>>>>>>
> > >>>>>>
> > >>>>>> Not sure I agree.  Users may not want roles.
> > >>>>>
> > >>>>> You mean may not want groups? I just don't like maintaining multiple
> > >>>>> ways
> > >>>>> to achieve the same thing - extra work for us and complicates
> > >>>>> documentation, etc..
> > >>>>>
> > >>>>
> > >>>> Yeah, sorry, users just might not create any groups, plus its backward
> > >>>> compatible to keep default roles.  The extra work to add default
> > >>>> groups
> > >>>> is simple.  Its just duplication of the equivalent role code.
> > >>>
> > >>> It's still extra stuff that needs documenting/explaining and for users
> > >>> to
> > >>> understand. Having multiple things that does the "same thing" is a good
> > >>> way of making software complicated IMO.
> > >>>
> > >>
> > >> Its not the same thing.  Its a convenience thing as with your proposal
> > >> you have the extra step of creating the default group.
> > >
> > > IMO it's the same thing. Having two options increases the amount of
> > > concepts a user has to understand, increases documentation, etc..
> > >
> > > More importantly if we remove composite roles and replace fully with
> > > groups, then default roles are much less usable.
> > >
> > > My vote is to remove default roles and just have default groups, then
> > > focus
> > > on making it easy to do the required setup around it.
> > >
> > 
> > I don't really care that much, but you still have to worry about
> > migration and document how old default roles/role composites map onto
> > the new Group model.
> > 
> > >>
> > >> I don't think a Group mapper would conflict with other Group mappers as
> > >> they would generally be concerned with mapping attribute and roles that
> > >> are defined within the Group.
> > >
> > > Sure, but a user could be member of many groups, where each groups in
> > > turn
> > > could be members of other groups. IMO this will just end up messy even
> > > with a relatively simple group hierarchy.
> > >
> > 
> > Only messy if there are conflicting mappers which IMO will be unlikely.
> > 
> > >
> > > I think I've misunderstood what you've suggested. Is it correct that:
> > >
> > > * A realm has one or more "group mappers"
> > > * A client belongs to one or more "group mappers"
> > >
> > > If so, it sounds good. I think a flat structure is good enough though (no
> > > a
> > > group mapper can have one or more group mappers etc..).
> > >
> > > Group mappers is probably a horrible name, so client template sounds much
> > > better.
> > >
> > 
> > I think we'll just have Client Templates where you can define common
> > protocol settings and common mappers.
> > 
> > That's different than what I was proposing before.  User belong to
> > Group.  A Group has a set of mappers.  A user's group;s mappers are
> > applied to the token automatically.  I think its an interesting concept
> > but am fine not having it.
> > 
> > So, decision making time?
> > 
> > Have the concept of Client Templates:
> > * protocol settings
> > * mappers
> 
> Would be good if clients can import settings from client templates, but also
> override. Including adding mappers, maybe even removing mappers.
> 
> One thing about the name, templates could suggest it's only used at creation
> time. The effective mappers for a client should be updated when the client
> template is updated.
> 
> > 
> > 
> > Have the concept of User Groups
> > * Users belong to User Groups
> > * User Groups have attributes and role mappings
> > 
> > Have the concept of Role Groups:
> > * Role Groups are just a namespace for roles.

Just to double check as part of this we're removing the concept of realm and client roles, and we're also adding some ability of defining what roles are listed in adapters (so we can have plain role names, like 'user', in jee apps for example)

> > 
> > 
> > Other actions:
> > 
> > * Deprecate Composite Roles.  Remove with the product cut
> > * Deprecate Default Roles.  Remove with the product cut.
> 
> Sounds good
> 
> > 
> > 
> > 
> > K, signing off until Thursday.
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From sebastian.olscher at traveltainment.de  Wed Aug 19 03:21:30 2015
From: sebastian.olscher at traveltainment.de (Sebastian Olscher)
Date: Wed, 19 Aug 2015 07:21:30 +0000
Subject: [keycloak-dev] How to start with development?
Message-ID: <5C3DDBFAC4DBF04084678703EC0AC294251709DE@EX-TT-AC-02.traveltainment.int>

Hello,

I?ve downloaded the keycloak-src-1.4.0.Final.zip<http://www.redhat.com/j/elqNow/elqRedir.htm?ref=http://downloads.jboss.org/keycloak/1.4.0.Final/keycloak-src-1.4.0.Final.zip> archive from the keycloak homepage and have imported all maven projects into my IDE. Doing that I was faced with many many projects. My question is now: how to start to get a knowing about what is the responsibility of what project? Is there any overview, any documentation, any architectural diagram which shows how the whole system works? Is there any developer documentation?

Thanks,
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150819/7d09233b/attachment.html 

From giriraj.sharma27 at gmail.com  Wed Aug 19 03:29:01 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Wed, 19 Aug 2015 12:59:01 +0530
Subject: [keycloak-dev] How to start with development?
In-Reply-To: <5C3DDBFAC4DBF04084678703EC0AC294251709DE@EX-TT-AC-02.traveltainment.int>
References: <5C3DDBFAC4DBF04084678703EC0AC294251709DE@EX-TT-AC-02.traveltainment.int>
Message-ID: <CAB5vuUxmFvaObhNJ=-T0TEUqep7Jz4s40ej3Eh6T3pK9feN2Zw@mail.gmail.com>

Hi Sebastian,

I would recommend you to begin with by having a thorough reading of the
documentation and screen cast videos[1].
Also, keycloak source itself includes a misc directory listing all the
hacks you will need to set up and start contributing to keycloak [2].

[1] http://keycloak.jboss.org/docs
[2] https://github.com/keycloak/keycloak/tree/master/misc


Cheers,


On Wed, Aug 19, 2015 at 12:51 PM, Sebastian Olscher <
sebastian.olscher at traveltainment.de> wrote:

> Hello,
>
>
>
> I?ve downloaded the keycloak-src-1.4.0.Final.zip
> <http://www.redhat.com/j/elqNow/elqRedir.htm?ref=http://downloads.jboss.org/keycloak/1.4.0.Final/keycloak-src-1.4.0.Final.zip>
> archive from the keycloak homepage and have imported all maven projects
> into my IDE. Doing that I was faced with many many projects. My question is
> now: how to start to get a knowing about what is the responsibility of what
> project? Is there any overview, any documentation, any architectural
> diagram which shows how the whole system works? Is there any developer
> documentation?
>
>
>
> Thanks,
>
> Sebastian
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

Giriraj Sharma
about.me/girirajsharma
<http://about.me/girirajsharma?promo=email_sig>
 Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150819/b45e5ba4/attachment.html 

From stian at redhat.com  Wed Aug 19 03:29:58 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Aug 2015 03:29:58 -0400 (EDT)
Subject: [keycloak-dev] How to start with development?
In-Reply-To: <5C3DDBFAC4DBF04084678703EC0AC294251709DE@EX-TT-AC-02.traveltainment.int>
References: <5C3DDBFAC4DBF04084678703EC0AC294251709DE@EX-TT-AC-02.traveltainment.int>
Message-ID: <1809562085.13551408.1439969398302.JavaMail.zimbra@redhat.com>

https://github.com/keycloak/keycloak/blob/master/misc/HackingOnKeycloak.md

There are no architectural diagrams or developer documentation as these would get outdated and not maintained. The code is the documentation ;)

----- Original Message -----
> From: "Sebastian Olscher" <sebastian.olscher at traveltainment.de>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 19 August, 2015 9:21:30 AM
> Subject: [keycloak-dev] How to start with development?
> 
> 
> 
> Hello,
> 
> 
> 
> I?ve downloaded the keycloak-src-1.4.0.Final.zip archive from the keycloak
> homepage and have imported all maven projects into my IDE. Doing that I was
> faced with many many projects. My question is now: how to start to get a
> knowing about what is the responsibility of what project? Is there any
> overview, any documentation, any architectural diagram which shows how the
> whole system works? Is there any developer documentation?
> 
> 
> 
> Thanks,
> 
> Sebastian
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ssilvert at redhat.com  Wed Aug 19 08:28:04 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 19 Aug 2015 08:28:04 -0400
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
Message-ID: <55D47654.70503@redhat.com>

On 8/19/2015 2:11 AM, Stian Thorgersen wrote:
> I'm not aware of any reasons we can't upgrade, but we would need to take care and do extra testing of the admin console afterwards.
>
> I'd prefer to upgrade to 1.4.4 early in a Sprint, so if you can upgrade this week, that's fine. Otherwise I'd like to wait to 1.6 release cycle.
I think we should wait until a fresh sprint.

We may need a Sprint that is partially or fully dedicated to the UI.  
It's going to be a big job to go through the UI and replace every bit of 
static text and static message with an angular-translate lookup.   As 
you suggested, it probably makes sense to divide that work up among the 
team members.

When we do that, we should also upgrade Angular.  That way, everyone is 
covering the full UI to make sure that everything is localized and every 
part works properly with Angular 1.4.x.

Sound like a good plan?
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 18 August, 2015 9:59:47 PM
>> Subject: [keycloak-dev] Upgrade Angular?
>>
>> We are using AngularJS 1.2.13.  The latest version is 1.4.4.
>>
>> The reason I ask is because I am a little worried about performance as
>> we begin to use angular-translate.  We are going to end up with a lot of
>> $$watchers, which will eventually make the UI sluggish.
>>
>> There is a solution starting with Angualr 1.3 that lets you specify a
>> one-time-binding using double colons like this {{ ::value }}.
>>
>> Any reason why we can't upgrade?
>>
>> Stan
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Wed Aug 19 09:07:15 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Aug 2015 09:07:15 -0400 (EDT)
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <55D47654.70503@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
	<55D47654.70503@redhat.com>
Message-ID: <1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 19 August, 2015 2:28:04 PM
> Subject: Re: [keycloak-dev] Upgrade Angular?
> 
> On 8/19/2015 2:11 AM, Stian Thorgersen wrote:
> > I'm not aware of any reasons we can't upgrade, but we would need to take
> > care and do extra testing of the admin console afterwards.
> >
> > I'd prefer to upgrade to 1.4.4 early in a Sprint, so if you can upgrade
> > this week, that's fine. Otherwise I'd like to wait to 1.6 release cycle.
> I think we should wait until a fresh sprint.
> 
> We may need a Sprint that is partially or fully dedicated to the UI.
> It's going to be a big job to go through the UI and replace every bit of
> static text and static message with an angular-translate lookup.   As
> you suggested, it probably makes sense to divide that work up among the
> team members.
> 
> When we do that, we should also upgrade Angular.  That way, everyone is
> covering the full UI to make sure that everything is localized and every
> part works properly with Angular 1.4.x.
> 
> Sound like a good plan?

I'd say upgrading to Angular 1.4.x should be done first. If there's any issues with it it will be much easier to resolve them without also having the localization to deal with. Ideally we should do that this week and include for 1.5. Upgrading to 1.4.x could break everything/nothing, but it's hard to know what parts could be affected, that's why it requires a full test of the admin console.

Internationalization would only affect the page that you edit, so whoever updates a page to also verify that it works. It can also be incremental, we don't have to internationalize the whole console in one sprint.

We should:

a) Upgrade to 1.4.x - test all functionality in the console
b) Add internationalization of a few pages
c) Make sure internationalization works as expected
d) Internationalize all pages

Ideally I'd like a-c included in 1.5.

> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 18 August, 2015 9:59:47 PM
> >> Subject: [keycloak-dev] Upgrade Angular?
> >>
> >> We are using AngularJS 1.2.13.  The latest version is 1.4.4.
> >>
> >> The reason I ask is because I am a little worried about performance as
> >> we begin to use angular-translate.  We are going to end up with a lot of
> >> $$watchers, which will eventually make the UI sluggish.
> >>
> >> There is a solution starting with Angualr 1.3 that lets you specify a
> >> one-time-binding using double colons like this {{ ::value }}.
> >>
> >> Any reason why we can't upgrade?
> >>
> >> Stan
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From ssilvert at redhat.com  Wed Aug 19 09:13:56 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 19 Aug 2015 09:13:56 -0400
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
	<55D47654.70503@redhat.com>
	<1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
Message-ID: <55D48114.6000100@redhat.com>

On 8/19/2015 9:07 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 19 August, 2015 2:28:04 PM
>> Subject: Re: [keycloak-dev] Upgrade Angular?
>>
>> On 8/19/2015 2:11 AM, Stian Thorgersen wrote:
>>> I'm not aware of any reasons we can't upgrade, but we would need to take
>>> care and do extra testing of the admin console afterwards.
>>>
>>> I'd prefer to upgrade to 1.4.4 early in a Sprint, so if you can upgrade
>>> this week, that's fine. Otherwise I'd like to wait to 1.6 release cycle.
>> I think we should wait until a fresh sprint.
>>
>> We may need a Sprint that is partially or fully dedicated to the UI.
>> It's going to be a big job to go through the UI and replace every bit of
>> static text and static message with an angular-translate lookup.   As
>> you suggested, it probably makes sense to divide that work up among the
>> team members.
>>
>> When we do that, we should also upgrade Angular.  That way, everyone is
>> covering the full UI to make sure that everything is localized and every
>> part works properly with Angular 1.4.x.
>>
>> Sound like a good plan?
> I'd say upgrading to Angular 1.4.x should be done first. If there's any issues with it it will be much easier to resolve them without also having the localization to deal with. Ideally we should do that this week and include for 1.5. Upgrading to 1.4.x could break everything/nothing, but it's hard to know what parts could be affected, that's why it requires a full test of the admin console.
>
> Internationalization would only affect the page that you edit, so whoever updates a page to also verify that it works. It can also be incremental, we don't have to internationalize the whole console in one sprint.
>
> We should:
>
> a) Upgrade to 1.4.x - test all functionality in the console
The "test all functionality in the console" is what I'm worried about.  
How do we do that?   Do we have the ability to do a full regression on 
the UI in a short time frame?

I'd hate to upgrade Angular, do a release, and then find out that some 
things are broken.
> b) Add internationalization of a few pages
> c) Make sure internationalization works as expected
> d) Internationalize all pages
>
> Ideally I'd like a-c included in 1.5.
>
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 18 August, 2015 9:59:47 PM
>>>> Subject: [keycloak-dev] Upgrade Angular?
>>>>
>>>> We are using AngularJS 1.2.13.  The latest version is 1.4.4.
>>>>
>>>> The reason I ask is because I am a little worried about performance as
>>>> we begin to use angular-translate.  We are going to end up with a lot of
>>>> $$watchers, which will eventually make the UI sluggish.
>>>>
>>>> There is a solution starting with Angualr 1.3 that lets you specify a
>>>> one-time-binding using double colons like this {{ ::value }}.
>>>>
>>>> Any reason why we can't upgrade?
>>>>
>>>> Stan
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>


From ssilvert at redhat.com  Wed Aug 19 09:19:24 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 19 Aug 2015 09:19:24 -0400
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
	<55D47654.70503@redhat.com>
	<1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
Message-ID: <55D4825C.9030000@redhat.com>

On 8/19/2015 9:07 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 19 August, 2015 2:28:04 PM
>> Subject: Re: [keycloak-dev] Upgrade Angular?
>>
>> On 8/19/2015 2:11 AM, Stian Thorgersen wrote:
>>> I'm not aware of any reasons we can't upgrade, but we would need to take
>>> care and do extra testing of the admin console afterwards.
>>>
>>> I'd prefer to upgrade to 1.4.4 early in a Sprint, so if you can upgrade
>>> this week, that's fine. Otherwise I'd like to wait to 1.6 release cycle.
>> I think we should wait until a fresh sprint.
>>
>> We may need a Sprint that is partially or fully dedicated to the UI.
>> It's going to be a big job to go through the UI and replace every bit of
>> static text and static message with an angular-translate lookup.   As
>> you suggested, it probably makes sense to divide that work up among the
>> team members.
>>
>> When we do that, we should also upgrade Angular.  That way, everyone is
>> covering the full UI to make sure that everything is localized and every
>> part works properly with Angular 1.4.x.
>>
>> Sound like a good plan?
> I'd say upgrading to Angular 1.4.x should be done first. If there's any issues with it it will be much easier to resolve them without also having the localization to deal with. Ideally we should do that this week and include for 1.5. Upgrading to 1.4.x could break everything/nothing, but it's hard to know what parts could be affected, that's why it requires a full test of the admin console.
>
> Internationalization would only affect the page that you edit, so whoever updates a page to also verify that it works. It can also be incremental, we don't have to internationalize the whole console in one sprint.
>
> We should:
>
> a) Upgrade to 1.4.x - test all functionality in the console
> b) Add internationalization of a few pages
> c) Make sure internationalization works as expected
> d) Internationalize all pages
>
> Ideally I'd like a-c included in 1.5.
BTW, I agree that we should do b and c in 1.5.  I'm just worried about a.

d doesn't necessarily have to be done in one sprint, but it seems to be 
a good way to make sure we have full coverage in testing the Angular 
upgrade.
>
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 18 August, 2015 9:59:47 PM
>>>> Subject: [keycloak-dev] Upgrade Angular?
>>>>
>>>> We are using AngularJS 1.2.13.  The latest version is 1.4.4.
>>>>
>>>> The reason I ask is because I am a little worried about performance as
>>>> we begin to use angular-translate.  We are going to end up with a lot of
>>>> $$watchers, which will eventually make the UI sluggish.
>>>>
>>>> There is a solution starting with Angualr 1.3 that lets you specify a
>>>> one-time-binding using double colons like this {{ ::value }}.
>>>>
>>>> Any reason why we can't upgrade?
>>>>
>>>> Stan
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>


From stian at redhat.com  Wed Aug 19 09:31:25 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Aug 2015 09:31:25 -0400 (EDT)
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <55D4825C.9030000@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
	<55D47654.70503@redhat.com>
	<1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
	<55D4825C.9030000@redhat.com>
Message-ID: <1651015162.13983560.1439991085619.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 19 August, 2015 3:19:24 PM
> Subject: Re: [keycloak-dev] Upgrade Angular?
> 
> On 8/19/2015 9:07 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 19 August, 2015 2:28:04 PM
> >> Subject: Re: [keycloak-dev] Upgrade Angular?
> >>
> >> On 8/19/2015 2:11 AM, Stian Thorgersen wrote:
> >>> I'm not aware of any reasons we can't upgrade, but we would need to take
> >>> care and do extra testing of the admin console afterwards.
> >>>
> >>> I'd prefer to upgrade to 1.4.4 early in a Sprint, so if you can upgrade
> >>> this week, that's fine. Otherwise I'd like to wait to 1.6 release cycle.
> >> I think we should wait until a fresh sprint.
> >>
> >> We may need a Sprint that is partially or fully dedicated to the UI.
> >> It's going to be a big job to go through the UI and replace every bit of
> >> static text and static message with an angular-translate lookup.   As
> >> you suggested, it probably makes sense to divide that work up among the
> >> team members.
> >>
> >> When we do that, we should also upgrade Angular.  That way, everyone is
> >> covering the full UI to make sure that everything is localized and every
> >> part works properly with Angular 1.4.x.
> >>
> >> Sound like a good plan?
> > I'd say upgrading to Angular 1.4.x should be done first. If there's any
> > issues with it it will be much easier to resolve them without also having
> > the localization to deal with. Ideally we should do that this week and
> > include for 1.5. Upgrading to 1.4.x could break everything/nothing, but
> > it's hard to know what parts could be affected, that's why it requires a
> > full test of the admin console.
> >
> > Internationalization would only affect the page that you edit, so whoever
> > updates a page to also verify that it works. It can also be incremental,
> > we don't have to internationalize the whole console in one sprint.
> >
> > We should:
> >
> > a) Upgrade to 1.4.x - test all functionality in the console
> > b) Add internationalization of a few pages
> > c) Make sure internationalization works as expected
> > d) Internationalize all pages
> >
> > Ideally I'd like a-c included in 1.5.
> BTW, I agree that we should do b and c in 1.5.  I'm just worried about a.
> 
> d doesn't necessarily have to be done in one sprint, but it seems to be
> a good way to make sure we have full coverage in testing the Angular
> upgrade.

a) has to be done first - if you upgrade it, test it to as much as you can, then either me or someone else does a full round of testing as well. Once a is done you can start adding b.

We always do a more or less full test of the admin console before releasing as we don't have any automated tests for it yet, but as upgrading AngularJS could introduce a lot of changes I want the testing done early and any issues resolved prior to internationalization added. I don't want to end up in a situation where we identity issues during last tests for the release and then we don't know if it's broken due to AngularJS or internationalization.


> >
> >>> ----- Original Message -----
> >>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 18 August, 2015 9:59:47 PM
> >>>> Subject: [keycloak-dev] Upgrade Angular?
> >>>>
> >>>> We are using AngularJS 1.2.13.  The latest version is 1.4.4.
> >>>>
> >>>> The reason I ask is because I am a little worried about performance as
> >>>> we begin to use angular-translate.  We are going to end up with a lot of
> >>>> $$watchers, which will eventually make the UI sluggish.
> >>>>
> >>>> There is a solution starting with Angualr 1.3 that lets you specify a
> >>>> one-time-binding using double colons like this {{ ::value }}.
> >>>>
> >>>> Any reason why we can't upgrade?
> >>>>
> >>>> Stan
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>
> 
> 

From ssilvert at redhat.com  Wed Aug 19 09:42:58 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 19 Aug 2015 09:42:58 -0400
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <1651015162.13983560.1439991085619.JavaMail.zimbra@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
	<55D47654.70503@redhat.com>
	<1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
	<55D4825C.9030000@redhat.com>
	<1651015162.13983560.1439991085619.JavaMail.zimbra@redhat.com>
Message-ID: <55D487E2.4070601@redhat.com>

On 8/19/2015 9:31 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 19 August, 2015 3:19:24 PM
>> Subject: Re: [keycloak-dev] Upgrade Angular?
>>
>> On 8/19/2015 9:07 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 19 August, 2015 2:28:04 PM
>>>> Subject: Re: [keycloak-dev] Upgrade Angular?
>>>>
>>>> On 8/19/2015 2:11 AM, Stian Thorgersen wrote:
>>>>> I'm not aware of any reasons we can't upgrade, but we would need to take
>>>>> care and do extra testing of the admin console afterwards.
>>>>>
>>>>> I'd prefer to upgrade to 1.4.4 early in a Sprint, so if you can upgrade
>>>>> this week, that's fine. Otherwise I'd like to wait to 1.6 release cycle.
>>>> I think we should wait until a fresh sprint.
>>>>
>>>> We may need a Sprint that is partially or fully dedicated to the UI.
>>>> It's going to be a big job to go through the UI and replace every bit of
>>>> static text and static message with an angular-translate lookup.   As
>>>> you suggested, it probably makes sense to divide that work up among the
>>>> team members.
>>>>
>>>> When we do that, we should also upgrade Angular.  That way, everyone is
>>>> covering the full UI to make sure that everything is localized and every
>>>> part works properly with Angular 1.4.x.
>>>>
>>>> Sound like a good plan?
>>> I'd say upgrading to Angular 1.4.x should be done first. If there's any
>>> issues with it it will be much easier to resolve them without also having
>>> the localization to deal with. Ideally we should do that this week and
>>> include for 1.5. Upgrading to 1.4.x could break everything/nothing, but
>>> it's hard to know what parts could be affected, that's why it requires a
>>> full test of the admin console.
>>>
>>> Internationalization would only affect the page that you edit, so whoever
>>> updates a page to also verify that it works. It can also be incremental,
>>> we don't have to internationalize the whole console in one sprint.
>>>
>>> We should:
>>>
>>> a) Upgrade to 1.4.x - test all functionality in the console
>>> b) Add internationalization of a few pages
>>> c) Make sure internationalization works as expected
>>> d) Internationalize all pages
>>>
>>> Ideally I'd like a-c included in 1.5.
>> BTW, I agree that we should do b and c in 1.5.  I'm just worried about a.
>>
>> d doesn't necessarily have to be done in one sprint, but it seems to be
>> a good way to make sure we have full coverage in testing the Angular
>> upgrade.
> a) has to be done first - if you upgrade it, test it to as much as you can, then either me or someone else does a full round of testing as well. Once a is done you can start adding b.
>
> We always do a more or less full test of the admin console before releasing as we don't have any automated tests for it yet, but as upgrading AngularJS could introduce a lot of changes I want the testing done early and any issues resolved prior to internationalization added. I don't want to end up in a situation where we identity issues during last tests for the release and then we don't know if it's broken due to AngularJS or internationalization.
If you think we can adequately test the Angular upgrade in this sprint 
then I'm fine with it.

I'll start on it and see if anything obvious breaks.
>
>
>>>>> ----- Original Message -----
>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Tuesday, 18 August, 2015 9:59:47 PM
>>>>>> Subject: [keycloak-dev] Upgrade Angular?
>>>>>>
>>>>>> We are using AngularJS 1.2.13.  The latest version is 1.4.4.
>>>>>>
>>>>>> The reason I ask is because I am a little worried about performance as
>>>>>> we begin to use angular-translate.  We are going to end up with a lot of
>>>>>> $$watchers, which will eventually make the UI sluggish.
>>>>>>
>>>>>> There is a solution starting with Angualr 1.3 that lets you specify a
>>>>>> one-time-binding using double colons like this {{ ::value }}.
>>>>>>
>>>>>> Any reason why we can't upgrade?
>>>>>>
>>>>>> Stan
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>


From bburke at redhat.com  Wed Aug 19 21:10:26 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Aug 2015 21:10:26 -0400
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>
	<55D346F8.3030307@redhat.com>
	<2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>
Message-ID: <55D52902.5010806@redhat.com>



On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>
>>
>>
>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
>>> Can you elaborate on what the benefits are of these changes? It seems to me
>>> that we had something that was working just fine..
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
>>>> Subject: [keycloak-dev] Reset Password changes complete needs review
>>>>
>>>> Here's what I did, I can change things based on questions I asked in
>>>> other emails, but here's how it works.
>>>>
>>>> There's now the concept of "reset password" and a different one "change
>>>> password".
>>>>
>>>> * Reset password is something the user initiates.  This will start an
>>>> Authentication Flow and success will login the user and bring them to
>>>> their application
>>>
>>> I assume this is still through email - if so it's important that users are
>>> only logged-in if the reset password link is opened in the same user
>>> session as they initiated the reset password flow
>>>
>>
>> With the previous impl, if somebody as able to hack your email account,
>> then they could bypass OTP entirely.  Also previous implementation
>> wasn't really compatible with auth SPI.  There may be additional steps
>> to reseting credentials beyond an email, i.e. entering in a code from an
>> SMS message.  We may also be reseting both OTP and Password.  Finally,
>> the update password required action had reset-password specific logic
>> within it.
>>
>> Honestly, I'd prefer to switch exclusively to a temporary code as it
>> makes everything much simpler to support:  for us and for users wanting
>> to write extensiosn.  I don't think this is a big usability issue as
>> Google requires entering a temporary code from an SMS message.  Also,
>> with the way it worked in 1.4, out-of-band email password reset would
>> require relogging in which is actually more steps.  Finally, links can
>> be messed up by email readers sometimes if they are long enough, making
>> them error prone.
>
> -100 We should stick with link in email (and only link, not confuse users by having multiple options), but why can't the link just include the same code?
>

I also don't want multiple options.  I want to get rid of the link entirely.

I'm repeating myself, but, This is about your requirement of out-of-band 
link-clicks not logging in the user.  That kind of flow is not 
compatible with the current Auth SPI and it requires hacks to required 
actions like Update Password to even work (which already exist).  We're 
also going to have to make users aware of it and explain how to code for 
it if they are writing their own extension.  It just makes things a lot 
more complicated if you are extending things.

Finally, I don't like the link because at least for me, it opens a brand 
new tab and leaves the original still active.  I also don't think the 
link is more user-friendly when the link is clicked in another browser. 
  It is also possible the user is obtaining the link on a phone and that 
our update password screen will be a bit cramped there.  Also, typing in 
a password from a phone is quite awkward and time consuming.

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

From bburke at redhat.com  Wed Aug 19 21:15:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Aug 2015 21:15:41 -0400
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <55D487E2.4070601@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
	<55D47654.70503@redhat.com>
	<1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
	<55D4825C.9030000@redhat.com>
	<1651015162.13983560.1439991085619.JavaMail.zimbra@redhat.com>
	<55D487E2.4070601@redhat.com>
Message-ID: <55D52A3D.9060409@redhat.com>

Do no upgrade angular until you go over with the team any changes that 
must be made.  I don't want to be banging my head wondering why I can't 
get my UI changes to work.

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

From bburke at redhat.com  Wed Aug 19 21:46:13 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Aug 2015 21:46:13 -0400
Subject: [keycloak-dev] Groups design
In-Reply-To: <951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
References: <55CB4F1D.3000909@redhat.com> <55CC9933.6010405@redhat.com>
	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
	<55CCA3A6.8040002@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
	<55D34BCD.50303@redhat.com>
	<951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
Message-ID: <55D53165.8010908@redhat.com>



On 8/19/2015 2:05 AM, Stian Thorgersen wrote:

>> Have the concept of Client Templates:
>> * protocol settings
>> * mappers
>
> Would be good if clients can import settings from client templates, but also override. Including adding mappers, maybe even removing mappers.
>

Inheriting from a template and adding addtional mappers would be ok. 
Removing mappers but retaining the inheritance relationship would be a 
mess in the UI and in code.


> One thing about the name, templates could suggest it's only used at creation time. The effective mappers for a client should be updated when the client template is updated.
>

Client Group ain't a good name either.

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

From bburke at redhat.com  Wed Aug 19 21:53:28 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Aug 2015 21:53:28 -0400
Subject: [keycloak-dev] Groups design
In-Reply-To: <920254531.13544356.1439968657289.JavaMail.zimbra@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1403901091.9985883.1439472727755.JavaMail.zimbra@redhat.com>
	<55CCA3A6.8040002@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
	<55D34BCD.50303@redhat.com>
	<951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
	<920254531.13544356.1439968657289.JavaMail.zimbra@redhat.com>
Message-ID: <55D53318.8000901@redhat.com>



On 8/19/2015 3:17 AM, Stian Thorgersen wrote:
>>> Have the concept of Role Groups:
>>> * Role Groups are just a namespace for roles.
>
> Just to double check as part of this we're removing the concept of realm and client roles, and we're also adding some ability of defining what roles are listed in adapters (so we can have plain role names, like 'user', in jee apps for example)
>

Yes.  We'll have a flat user role mapping in the token

roles: [ "role1", "role2" ]

You'll either manipulate how roles look in the token via a mapper, or 
you'll define a role mapping within the adapter config.  Default role 
mapper on server will specify a URI for the role.  BTW, this URI 
probably shouldn't have a DNS name within it.  Something like 
role:{realm-name}.{group}.{role-name}.  This is so that adapter config 
doesn't have to be changed as it moves from dev->QE->production.  BTW, 
this is why I hate the OIDC requirement that the realm is some http:// 
based URI.


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

From bburke at redhat.com  Wed Aug 19 22:04:31 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Aug 2015 22:04:31 -0400
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <55D52902.5010806@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>
	<55D346F8.3030307@redhat.com>
	<2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>
	<55D52902.5010806@redhat.com>
Message-ID: <55D535AF.9080906@redhat.com>



On 8/19/2015 9:10 PM, Bill Burke wrote:
>
>
> On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>>
>>>
>>>
>>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
>>>> Can you elaborate on what the benefits are of these changes? It seems to me
>>>> that we had something that was working just fine..
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
>>>>> Subject: [keycloak-dev] Reset Password changes complete needs review
>>>>>
>>>>> Here's what I did, I can change things based on questions I asked in
>>>>> other emails, but here's how it works.
>>>>>
>>>>> There's now the concept of "reset password" and a different one "change
>>>>> password".
>>>>>
>>>>> * Reset password is something the user initiates.  This will start an
>>>>> Authentication Flow and success will login the user and bring them to
>>>>> their application
>>>>
>>>> I assume this is still through email - if so it's important that users are
>>>> only logged-in if the reset password link is opened in the same user
>>>> session as they initiated the reset password flow
>>>>
>>>
>>> With the previous impl, if somebody as able to hack your email account,
>>> then they could bypass OTP entirely.  Also previous implementation
>>> wasn't really compatible with auth SPI.  There may be additional steps
>>> to reseting credentials beyond an email, i.e. entering in a code from an
>>> SMS message.  We may also be reseting both OTP and Password.  Finally,
>>> the update password required action had reset-password specific logic
>>> within it.
>>>
>>> Honestly, I'd prefer to switch exclusively to a temporary code as it
>>> makes everything much simpler to support:  for us and for users wanting
>>> to write extensiosn.  I don't think this is a big usability issue as
>>> Google requires entering a temporary code from an SMS message.  Also,
>>> with the way it worked in 1.4, out-of-band email password reset would
>>> require relogging in which is actually more steps.  Finally, links can
>>> be messed up by email readers sometimes if they are long enough, making
>>> them error prone.
>>
>> -100 We should stick with link in email (and only link, not confuse users by having multiple options), but why can't the link just include the same code?
>>
>
> I also don't want multiple options.  I want to get rid of the link entirely.
>
> I'm repeating myself, but, This is about your requirement of out-of-band
> link-clicks not logging in the user.  That kind of flow is not
> compatible with the current Auth SPI and it requires hacks to required
> actions like Update Password to even work (which already exist).  We're
> also going to have to make users aware of it and explain how to code for
> it if they are writing their own extension.  It just makes things a lot
> more complicated if you are extending things.
>
> Finally, I don't like the link because at least for me, it opens a brand
> new tab and leaves the original still active.  I also don't think the
> link is more user-friendly when the link is clicked in another browser.
>    It is also possible the user is obtaining the link on a phone and that
> our update password screen will be a bit cramped there.  Also, typing in
> a password from a phone is quite awkward and time consuming.
>

Furthermore, I don't like Verify Email either.  It also should be 
changed from link clicking to code entry.  Like Reset Email, a new tab 
is opened if you click the link.  Like Reset Email, Verify email 
requires you to completely relogin if the link is clicked in a different 
browser.


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

From stian at redhat.com  Thu Aug 20 02:41:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 02:41:49 -0400 (EDT)
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <55D52A3D.9060409@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
	<55D47654.70503@redhat.com>
	<1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
	<55D4825C.9030000@redhat.com>
	<1651015162.13983560.1439991085619.JavaMail.zimbra@redhat.com>
	<55D487E2.4070601@redhat.com> <55D52A3D.9060409@redhat.com>
Message-ID: <83756299.14938617.1440052909041.JavaMail.zimbra@redhat.com>

There are no changes that must be made - it just has to be checked that things still work

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 3:15:41 AM
> Subject: Re: [keycloak-dev] Upgrade Angular?
> 
> Do no upgrade angular until you go over with the team any changes that
> must be made.  I don't want to be banging my head wondering why I can't
> get my UI changes to work.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Aug 20 02:44:12 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 02:44:12 -0400 (EDT)
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <55D535AF.9080906@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>
	<55D346F8.3030307@redhat.com>
	<2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>
	<55D52902.5010806@redhat.com> <55D535AF.9080906@redhat.com>
Message-ID: <1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>

-1000 Clicking a link is a lot simpler for most users - especially mobile/tablet users. Have you ever tried to copy/paste on a mobile! 

Do not change this to requiring copy/pasting a code!

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 4:04:31 AM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> 
> 
> 
> On 8/19/2015 9:10 PM, Bill Burke wrote:
> >
> >
> > On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: "Stian Thorgersen" <stian at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
> >>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> >>>
> >>>
> >>>
> >>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
> >>>> Can you elaborate on what the benefits are of these changes? It seems to
> >>>> me
> >>>> that we had something that was working just fine..
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: keycloak-dev at lists.jboss.org
> >>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
> >>>>> Subject: [keycloak-dev] Reset Password changes complete needs review
> >>>>>
> >>>>> Here's what I did, I can change things based on questions I asked in
> >>>>> other emails, but here's how it works.
> >>>>>
> >>>>> There's now the concept of "reset password" and a different one "change
> >>>>> password".
> >>>>>
> >>>>> * Reset password is something the user initiates.  This will start an
> >>>>> Authentication Flow and success will login the user and bring them to
> >>>>> their application
> >>>>
> >>>> I assume this is still through email - if so it's important that users
> >>>> are
> >>>> only logged-in if the reset password link is opened in the same user
> >>>> session as they initiated the reset password flow
> >>>>
> >>>
> >>> With the previous impl, if somebody as able to hack your email account,
> >>> then they could bypass OTP entirely.  Also previous implementation
> >>> wasn't really compatible with auth SPI.  There may be additional steps
> >>> to reseting credentials beyond an email, i.e. entering in a code from an
> >>> SMS message.  We may also be reseting both OTP and Password.  Finally,
> >>> the update password required action had reset-password specific logic
> >>> within it.
> >>>
> >>> Honestly, I'd prefer to switch exclusively to a temporary code as it
> >>> makes everything much simpler to support:  for us and for users wanting
> >>> to write extensiosn.  I don't think this is a big usability issue as
> >>> Google requires entering a temporary code from an SMS message.  Also,
> >>> with the way it worked in 1.4, out-of-band email password reset would
> >>> require relogging in which is actually more steps.  Finally, links can
> >>> be messed up by email readers sometimes if they are long enough, making
> >>> them error prone.
> >>
> >> -100 We should stick with link in email (and only link, not confuse users
> >> by having multiple options), but why can't the link just include the same
> >> code?
> >>
> >
> > I also don't want multiple options.  I want to get rid of the link
> > entirely.
> >
> > I'm repeating myself, but, This is about your requirement of out-of-band
> > link-clicks not logging in the user.  That kind of flow is not
> > compatible with the current Auth SPI and it requires hacks to required
> > actions like Update Password to even work (which already exist).  We're
> > also going to have to make users aware of it and explain how to code for
> > it if they are writing their own extension.  It just makes things a lot
> > more complicated if you are extending things.
> >
> > Finally, I don't like the link because at least for me, it opens a brand
> > new tab and leaves the original still active.  I also don't think the
> > link is more user-friendly when the link is clicked in another browser.
> >    It is also possible the user is obtaining the link on a phone and that
> > our update password screen will be a bit cramped there.  Also, typing in
> > a password from a phone is quite awkward and time consuming.
> >
> 
> Furthermore, I don't like Verify Email either.  It also should be
> changed from link clicking to code entry.  Like Reset Email, a new tab
> is opened if you click the link.  Like Reset Email, Verify email
> requires you to completely relogin if the link is clicked in a different
> browser.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Aug 20 02:46:15 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 02:46:15 -0400 (EDT)
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>
	<55D346F8.3030307@redhat.com>
	<2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>
	<55D52902.5010806@redhat.com> <55D535AF.9080906@redhat.com>
	<1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
Message-ID: <28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>

By the way try reset your password on any website, they will all send you a link you need to click

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 8:44:12 AM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> 
> -1000 Clicking a link is a lot simpler for most users - especially
> mobile/tablet users. Have you ever tried to copy/paste on a mobile!
> 
> Do not change this to requiring copy/pasting a code!
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 20 August, 2015 4:04:31 AM
> > Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> > 
> > 
> > 
> > On 8/19/2015 9:10 PM, Bill Burke wrote:
> > >
> > >
> > > On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Bill Burke" <bburke at redhat.com>
> > >>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>> Cc: keycloak-dev at lists.jboss.org
> > >>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
> > >>> Subject: Re: [keycloak-dev] Reset Password changes complete needs
> > >>> review
> > >>>
> > >>>
> > >>>
> > >>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
> > >>>> Can you elaborate on what the benefits are of these changes? It seems
> > >>>> to
> > >>>> me
> > >>>> that we had something that was working just fine..
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>> To: keycloak-dev at lists.jboss.org
> > >>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
> > >>>>> Subject: [keycloak-dev] Reset Password changes complete needs review
> > >>>>>
> > >>>>> Here's what I did, I can change things based on questions I asked in
> > >>>>> other emails, but here's how it works.
> > >>>>>
> > >>>>> There's now the concept of "reset password" and a different one
> > >>>>> "change
> > >>>>> password".
> > >>>>>
> > >>>>> * Reset password is something the user initiates.  This will start an
> > >>>>> Authentication Flow and success will login the user and bring them to
> > >>>>> their application
> > >>>>
> > >>>> I assume this is still through email - if so it's important that users
> > >>>> are
> > >>>> only logged-in if the reset password link is opened in the same user
> > >>>> session as they initiated the reset password flow
> > >>>>
> > >>>
> > >>> With the previous impl, if somebody as able to hack your email account,
> > >>> then they could bypass OTP entirely.  Also previous implementation
> > >>> wasn't really compatible with auth SPI.  There may be additional steps
> > >>> to reseting credentials beyond an email, i.e. entering in a code from
> > >>> an
> > >>> SMS message.  We may also be reseting both OTP and Password.  Finally,
> > >>> the update password required action had reset-password specific logic
> > >>> within it.
> > >>>
> > >>> Honestly, I'd prefer to switch exclusively to a temporary code as it
> > >>> makes everything much simpler to support:  for us and for users wanting
> > >>> to write extensiosn.  I don't think this is a big usability issue as
> > >>> Google requires entering a temporary code from an SMS message.  Also,
> > >>> with the way it worked in 1.4, out-of-band email password reset would
> > >>> require relogging in which is actually more steps.  Finally, links can
> > >>> be messed up by email readers sometimes if they are long enough, making
> > >>> them error prone.
> > >>
> > >> -100 We should stick with link in email (and only link, not confuse
> > >> users
> > >> by having multiple options), but why can't the link just include the
> > >> same
> > >> code?
> > >>
> > >
> > > I also don't want multiple options.  I want to get rid of the link
> > > entirely.
> > >
> > > I'm repeating myself, but, This is about your requirement of out-of-band
> > > link-clicks not logging in the user.  That kind of flow is not
> > > compatible with the current Auth SPI and it requires hacks to required
> > > actions like Update Password to even work (which already exist).  We're
> > > also going to have to make users aware of it and explain how to code for
> > > it if they are writing their own extension.  It just makes things a lot
> > > more complicated if you are extending things.
> > >
> > > Finally, I don't like the link because at least for me, it opens a brand
> > > new tab and leaves the original still active.  I also don't think the
> > > link is more user-friendly when the link is clicked in another browser.
> > >    It is also possible the user is obtaining the link on a phone and that
> > > our update password screen will be a bit cramped there.  Also, typing in
> > > a password from a phone is quite awkward and time consuming.
> > >
> > 
> > Furthermore, I don't like Verify Email either.  It also should be
> > changed from link clicking to code entry.  Like Reset Email, a new tab
> > is opened if you click the link.  Like Reset Email, Verify email
> > requires you to completely relogin if the link is clicked in a different
> > browser.
> > 
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From stian at redhat.com  Thu Aug 20 02:48:03 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 02:48:03 -0400 (EDT)
Subject: [keycloak-dev] Groups design
In-Reply-To: <55D53165.8010908@redhat.com>
References: <55CB4F1D.3000909@redhat.com> <55CCA3A6.8040002@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
	<55D34BCD.50303@redhat.com>
	<951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
	<55D53165.8010908@redhat.com>
Message-ID: <522736374.14942853.1440053283564.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 3:46:13 AM
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> On 8/19/2015 2:05 AM, Stian Thorgersen wrote:
> 
> >> Have the concept of Client Templates:
> >> * protocol settings
> >> * mappers
> >
> > Would be good if clients can import settings from client templates, but
> > also override. Including adding mappers, maybe even removing mappers.
> >
> 
> Inheriting from a template and adding addtional mappers would be ok.
> Removing mappers but retaining the inheritance relationship would be a
> mess in the UI and in code.

Agree - let's not add option to removing mappers

> 
> 
> > One thing about the name, templates could suggest it's only used at
> > creation time. The effective mappers for a client should be updated when
> > the client template is updated.
> >
> 
> Client Group ain't a good name either.

Ok, let's stick with client template

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

From stian at redhat.com  Thu Aug 20 02:49:50 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 02:49:50 -0400 (EDT)
Subject: [keycloak-dev] Groups design
In-Reply-To: <55D53318.8000901@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
	<55D34BCD.50303@redhat.com>
	<951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
	<920254531.13544356.1439968657289.JavaMail.zimbra@redhat.com>
	<55D53318.8000901@redhat.com>
Message-ID: <1866268216.14943768.1440053390976.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 3:53:28 AM
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> On 8/19/2015 3:17 AM, Stian Thorgersen wrote:
> >>> Have the concept of Role Groups:
> >>> * Role Groups are just a namespace for roles.
> >
> > Just to double check as part of this we're removing the concept of realm
> > and client roles, and we're also adding some ability of defining what
> > roles are listed in adapters (so we can have plain role names, like
> > 'user', in jee apps for example)
> >
> 
> Yes.  We'll have a flat user role mapping in the token
> 
> roles: [ "role1", "role2" ]
> 
> You'll either manipulate how roles look in the token via a mapper, or
> you'll define a role mapping within the adapter config.  Default role
> mapper on server will specify a URI for the role.  BTW, this URI
> probably shouldn't have a DNS name within it.  Something like
> role:{realm-name}.{group}.{role-name}.  This is so that adapter config
> doesn't have to be changed as it moves from dev->QE->production.  BTW,
> this is why I hate the OIDC requirement that the realm is some http://
> based URI.

Do we need real-name? Seems like that'll only make it hard to use.

I like OIDC requirement that it's URL based - a realm is not a unique name, but a URL is and I think it should be unique

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

From stian at redhat.com  Thu Aug 20 03:09:41 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 03:09:41 -0400 (EDT)
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>
	<55D346F8.3030307@redhat.com>
	<2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>
	<55D52902.5010806@redhat.com> <55D535AF.9080906@redhat.com>
	<1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
	<28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>
Message-ID: <401917060.14958009.1440054581854.JavaMail.zimbra@redhat.com>

Attached screenshots of reset password from Facebook, Redhat, Twitter and Microsoft. All, but Microsoft, send a reset password link. Other websites where I've recently changed my password also all send links.

It's clearly easier for users to click a link than copy/pasting, which would include finding the original window/tab. If the email is delayed with a few minutes the user may quite likely have moved on to something else and might have closed the original window.

This all boils down to a single argument and that is that it's not compatible with the current authentication SPI. That's a problem with the SPI that needs resolving.

What would work fine is that we store the required context in an encrypted cookie. Only if the cookie is available would we proceed with loging-in the user. Otherwise the user would only be allowed to reset the password and would then have to go back to the application to re-login with the new password. In that case resetting the password is not an authentication flow, but an action that a user is permitted to do with a special temporary key.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 8:46:15 AM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> 
> By the way try reset your password on any website, they will all send you a
> link you need to click
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 20 August, 2015 8:44:12 AM
> > Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> > 
> > -1000 Clicking a link is a lot simpler for most users - especially
> > mobile/tablet users. Have you ever tried to copy/paste on a mobile!
> > 
> > Do not change this to requiring copy/pasting a code!
> > 
> > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Thursday, 20 August, 2015 4:04:31 AM
> > > Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> > > 
> > > 
> > > 
> > > On 8/19/2015 9:10 PM, Bill Burke wrote:
> > > >
> > > >
> > > > On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Bill Burke" <bburke at redhat.com>
> > > >>> To: "Stian Thorgersen" <stian at redhat.com>
> > > >>> Cc: keycloak-dev at lists.jboss.org
> > > >>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
> > > >>> Subject: Re: [keycloak-dev] Reset Password changes complete needs
> > > >>> review
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
> > > >>>> Can you elaborate on what the benefits are of these changes? It
> > > >>>> seems
> > > >>>> to
> > > >>>> me
> > > >>>> that we had something that was working just fine..
> > > >>>>
> > > >>>> ----- Original Message -----
> > > >>>>> From: "Bill Burke" <bburke at redhat.com>
> > > >>>>> To: keycloak-dev at lists.jboss.org
> > > >>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
> > > >>>>> Subject: [keycloak-dev] Reset Password changes complete needs
> > > >>>>> review
> > > >>>>>
> > > >>>>> Here's what I did, I can change things based on questions I asked
> > > >>>>> in
> > > >>>>> other emails, but here's how it works.
> > > >>>>>
> > > >>>>> There's now the concept of "reset password" and a different one
> > > >>>>> "change
> > > >>>>> password".
> > > >>>>>
> > > >>>>> * Reset password is something the user initiates.  This will start
> > > >>>>> an
> > > >>>>> Authentication Flow and success will login the user and bring them
> > > >>>>> to
> > > >>>>> their application
> > > >>>>
> > > >>>> I assume this is still through email - if so it's important that
> > > >>>> users
> > > >>>> are
> > > >>>> only logged-in if the reset password link is opened in the same user
> > > >>>> session as they initiated the reset password flow
> > > >>>>
> > > >>>
> > > >>> With the previous impl, if somebody as able to hack your email
> > > >>> account,
> > > >>> then they could bypass OTP entirely.  Also previous implementation
> > > >>> wasn't really compatible with auth SPI.  There may be additional
> > > >>> steps
> > > >>> to reseting credentials beyond an email, i.e. entering in a code from
> > > >>> an
> > > >>> SMS message.  We may also be reseting both OTP and Password.
> > > >>> Finally,
> > > >>> the update password required action had reset-password specific logic
> > > >>> within it.
> > > >>>
> > > >>> Honestly, I'd prefer to switch exclusively to a temporary code as it
> > > >>> makes everything much simpler to support:  for us and for users
> > > >>> wanting
> > > >>> to write extensiosn.  I don't think this is a big usability issue as
> > > >>> Google requires entering a temporary code from an SMS message.  Also,
> > > >>> with the way it worked in 1.4, out-of-band email password reset would
> > > >>> require relogging in which is actually more steps.  Finally, links
> > > >>> can
> > > >>> be messed up by email readers sometimes if they are long enough,
> > > >>> making
> > > >>> them error prone.
> > > >>
> > > >> -100 We should stick with link in email (and only link, not confuse
> > > >> users
> > > >> by having multiple options), but why can't the link just include the
> > > >> same
> > > >> code?
> > > >>
> > > >
> > > > I also don't want multiple options.  I want to get rid of the link
> > > > entirely.
> > > >
> > > > I'm repeating myself, but, This is about your requirement of
> > > > out-of-band
> > > > link-clicks not logging in the user.  That kind of flow is not
> > > > compatible with the current Auth SPI and it requires hacks to required
> > > > actions like Update Password to even work (which already exist).  We're
> > > > also going to have to make users aware of it and explain how to code
> > > > for
> > > > it if they are writing their own extension.  It just makes things a lot
> > > > more complicated if you are extending things.
> > > >
> > > > Finally, I don't like the link because at least for me, it opens a
> > > > brand
> > > > new tab and leaves the original still active.  I also don't think the
> > > > link is more user-friendly when the link is clicked in another browser.
> > > >    It is also possible the user is obtaining the link on a phone and
> > > >    that
> > > > our update password screen will be a bit cramped there.  Also, typing
> > > > in
> > > > a password from a phone is quite awkward and time consuming.
> > > >
> > > 
> > > Furthermore, I don't like Verify Email either.  It also should be
> > > changed from link clicking to code entry.  Like Reset Email, a new tab
> > > is opened if you click the link.  Like Reset Email, Verify email
> > > requires you to completely relogin if the link is clicked in a different
> > > browser.
> > > 
> > > 
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: microsoft.png
Type: image/png
Size: 27337 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150820/b0c06ed0/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facebook.png
Type: image/png
Size: 18938 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150820/b0c06ed0/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: redhat.png
Type: image/png
Size: 46452 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150820/b0c06ed0/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twitter.png
Type: image/png
Size: 20757 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150820/b0c06ed0/attachment-0007.png 

From stian at redhat.com  Thu Aug 20 07:28:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 07:28:00 -0400 (EDT)
Subject: [keycloak-dev] Time skew in client adapters
In-Reply-To: <1957839355.15087317.1440069738931.JavaMail.zimbra@redhat.com>
Message-ID: <1558505695.15090086.1440070080017.JavaMail.zimbra@redhat.com>

We recently had someone that had issues with the javascript adapter not refreshing tokens. The reason for this was that the browser and Keycloak server was in different time zones, so exp was not checked properly.

I've now updated the javascript adapter to include a timeSkew property. This is calculated by:

   timeSkew = (timeRequestStarted + timeRequestCompleted) / 2 - token.iat

The assumption is that if the request and response takes roughly as long the tokens iat value will be set in the middle of request start and request stop.

This will work both for cases where the browser time is not correct as well as when the browser is in a different time-zone.

Big question is, should we do the same for all adapters? For server-side adapters we can be more assured that the time is in sync (not sure if we mention in the documentation that it's important to keep times in sync), but we still have the issue if the servers are in different time zones.

From bburke at redhat.com  Thu Aug 20 09:54:40 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Aug 2015 09:54:40 -0400
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <401917060.14958009.1440054581854.JavaMail.zimbra@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<306687037.12967809.1439903064742.JavaMail.zimbra@redhat.com>
	<55D346F8.3030307@redhat.com>
	<2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>
	<55D52902.5010806@redhat.com> <55D535AF.9080906@redhat.com>
	<1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
	<28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>
	<401917060.14958009.1440054581854.JavaMail.zimbra@redhat.com>
Message-ID: <55D5DC20.8050606@redhat.com>

And yet with Google, you enter in a temporary code to reset credentials.

You talk about this "single argument", but it is more than that...With 
us, a brand new tab is opened when you click the link leaving the old 
one open. Leaving that old window in a stale state where a user may or 
may not get an error message if they try to use that window.  (This 
problem existed prior to the Auth SPI).

And, if you read my email, its more than just being incompatible, its 
something we'll have to explain in detail in the documentation as well 
as provide "hack" APIs just to support when users want to write 
extensions.  It also forces required actions to be aware of the context 
they are called in.  Its a mess...It as all fine and dandy to hard code 
this stuff before, but now that we have a public API we can't have all 
these special cases as writing extensions becomes a real pain in the ass 
for users and for us as we'll be answering the same questions over and 
over..."Why doesn't this work?"  "Well, did you read section 9.2.1.1 of 
the manual, paragraph 2 where it says you have to call this special API 
call and manage a cookie?"


On 8/20/2015 3:09 AM, Stian Thorgersen wrote:
> Attached screenshots of reset password from Facebook, Redhat, Twitter and Microsoft. All, but Microsoft, send a reset password link. Other websites where I've recently changed my password also all send links.
>
> It's clearly easier for users to click a link than copy/pasting, which would include finding the original window/tab. If the email is delayed with a few minutes the user may quite likely have moved on to something else and might have closed the original window.
>
> This all boils down to a single argument and that is that it's not compatible with the current authentication SPI. That's a problem with the SPI that needs resolving.
>
> What would work fine is that we store the required context in an encrypted cookie. Only if the cookie is available would we proceed with loging-in the user. Otherwise the user would only be allowed to reset the password and would then have to go back to the application to re-login with the new password. In that case resetting the password is not an authentication flow, but an action that a user is permitted to do with a special temporary key.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 20 August, 2015 8:46:15 AM
>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>
>> By the way try reset your password on any website, they will all send you a
>> link you need to click
>>
>> ----- Original Message -----
>>> From: "Stian Thorgersen" <stian at redhat.com>
>>> To: "Bill Burke" <bburke at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 20 August, 2015 8:44:12 AM
>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>>
>>> -1000 Clicking a link is a lot simpler for most users - especially
>>> mobile/tablet users. Have you ever tried to copy/paste on a mobile!
>>>
>>> Do not change this to requiring copy/pasting a code!
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 20 August, 2015 4:04:31 AM
>>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>>>
>>>>
>>>>
>>>> On 8/19/2015 9:10 PM, Bill Burke wrote:
>>>>>
>>>>>
>>>>> On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
>>>>>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs
>>>>>>> review
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
>>>>>>>> Can you elaborate on what the benefits are of these changes? It
>>>>>>>> seems
>>>>>>>> to
>>>>>>>> me
>>>>>>>> that we had something that was working just fine..
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
>>>>>>>>> Subject: [keycloak-dev] Reset Password changes complete needs
>>>>>>>>> review
>>>>>>>>>
>>>>>>>>> Here's what I did, I can change things based on questions I asked
>>>>>>>>> in
>>>>>>>>> other emails, but here's how it works.
>>>>>>>>>
>>>>>>>>> There's now the concept of "reset password" and a different one
>>>>>>>>> "change
>>>>>>>>> password".
>>>>>>>>>
>>>>>>>>> * Reset password is something the user initiates.  This will start
>>>>>>>>> an
>>>>>>>>> Authentication Flow and success will login the user and bring them
>>>>>>>>> to
>>>>>>>>> their application
>>>>>>>>
>>>>>>>> I assume this is still through email - if so it's important that
>>>>>>>> users
>>>>>>>> are
>>>>>>>> only logged-in if the reset password link is opened in the same user
>>>>>>>> session as they initiated the reset password flow
>>>>>>>>
>>>>>>>
>>>>>>> With the previous impl, if somebody as able to hack your email
>>>>>>> account,
>>>>>>> then they could bypass OTP entirely.  Also previous implementation
>>>>>>> wasn't really compatible with auth SPI.  There may be additional
>>>>>>> steps
>>>>>>> to reseting credentials beyond an email, i.e. entering in a code from
>>>>>>> an
>>>>>>> SMS message.  We may also be reseting both OTP and Password.
>>>>>>> Finally,
>>>>>>> the update password required action had reset-password specific logic
>>>>>>> within it.
>>>>>>>
>>>>>>> Honestly, I'd prefer to switch exclusively to a temporary code as it
>>>>>>> makes everything much simpler to support:  for us and for users
>>>>>>> wanting
>>>>>>> to write extensiosn.  I don't think this is a big usability issue as
>>>>>>> Google requires entering a temporary code from an SMS message.  Also,
>>>>>>> with the way it worked in 1.4, out-of-band email password reset would
>>>>>>> require relogging in which is actually more steps.  Finally, links
>>>>>>> can
>>>>>>> be messed up by email readers sometimes if they are long enough,
>>>>>>> making
>>>>>>> them error prone.
>>>>>>
>>>>>> -100 We should stick with link in email (and only link, not confuse
>>>>>> users
>>>>>> by having multiple options), but why can't the link just include the
>>>>>> same
>>>>>> code?
>>>>>>
>>>>>
>>>>> I also don't want multiple options.  I want to get rid of the link
>>>>> entirely.
>>>>>
>>>>> I'm repeating myself, but, This is about your requirement of
>>>>> out-of-band
>>>>> link-clicks not logging in the user.  That kind of flow is not
>>>>> compatible with the current Auth SPI and it requires hacks to required
>>>>> actions like Update Password to even work (which already exist).  We're
>>>>> also going to have to make users aware of it and explain how to code
>>>>> for
>>>>> it if they are writing their own extension.  It just makes things a lot
>>>>> more complicated if you are extending things.
>>>>>
>>>>> Finally, I don't like the link because at least for me, it opens a
>>>>> brand
>>>>> new tab and leaves the original still active.  I also don't think the
>>>>> link is more user-friendly when the link is clicked in another browser.
>>>>>     It is also possible the user is obtaining the link on a phone and
>>>>>     that
>>>>> our update password screen will be a bit cramped there.  Also, typing
>>>>> in
>>>>> a password from a phone is quite awkward and time consuming.
>>>>>
>>>>
>>>> Furthermore, I don't like Verify Email either.  It also should be
>>>> changed from link clicking to code entry.  Like Reset Email, a new tab
>>>> is opened if you click the link.  Like Reset Email, Verify email
>>>> requires you to completely relogin if the link is clicked in a different
>>>> browser.
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From stian at redhat.com  Thu Aug 20 10:00:13 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 10:00:13 -0400 (EDT)
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <55D5DC20.8050606@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>
	<55D52902.5010806@redhat.com> <55D535AF.9080906@redhat.com>
	<1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
	<28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>
	<401917060.14958009.1440054581854.JavaMail.zimbra@redhat.com>
	<55D5DC20.8050606@redhat.com>
Message-ID: <2010747614.15188695.1440079213447.JavaMail.zimbra@redhat.com>

Google sends link as well, see attached screenshot

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 3:54:40 PM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> 
> And yet with Google, you enter in a temporary code to reset credentials.
> 
> You talk about this "single argument", but it is more than that...With
> us, a brand new tab is opened when you click the link leaving the old
> one open. Leaving that old window in a stale state where a user may or
> may not get an error message if they try to use that window.  (This
> problem existed prior to the Auth SPI).
> 
> And, if you read my email, its more than just being incompatible, its
> something we'll have to explain in detail in the documentation as well
> as provide "hack" APIs just to support when users want to write
> extensions.  It also forces required actions to be aware of the context
> they are called in.  Its a mess...It as all fine and dandy to hard code
> this stuff before, but now that we have a public API we can't have all
> these special cases as writing extensions becomes a real pain in the ass
> for users and for us as we'll be answering the same questions over and
> over..."Why doesn't this work?"  "Well, did you read section 9.2.1.1 of
> the manual, paragraph 2 where it says you have to call this special API
> call and manage a cookie?"
> 
> 
> On 8/20/2015 3:09 AM, Stian Thorgersen wrote:
> > Attached screenshots of reset password from Facebook, Redhat, Twitter and
> > Microsoft. All, but Microsoft, send a reset password link. Other websites
> > where I've recently changed my password also all send links.
> >
> > It's clearly easier for users to click a link than copy/pasting, which
> > would include finding the original window/tab. If the email is delayed
> > with a few minutes the user may quite likely have moved on to something
> > else and might have closed the original window.
> >
> > This all boils down to a single argument and that is that it's not
> > compatible with the current authentication SPI. That's a problem with the
> > SPI that needs resolving.
> >
> > What would work fine is that we store the required context in an encrypted
> > cookie. Only if the cookie is available would we proceed with loging-in
> > the user. Otherwise the user would only be allowed to reset the password
> > and would then have to go back to the application to re-login with the new
> > password. In that case resetting the password is not an authentication
> > flow, but an action that a user is permitted to do with a special
> > temporary key.
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 20 August, 2015 8:46:15 AM
> >> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> >>
> >> By the way try reset your password on any website, they will all send you
> >> a
> >> link you need to click
> >>
> >> ----- Original Message -----
> >>> From: "Stian Thorgersen" <stian at redhat.com>
> >>> To: "Bill Burke" <bburke at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, 20 August, 2015 8:44:12 AM
> >>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> >>>
> >>> -1000 Clicking a link is a lot simpler for most users - especially
> >>> mobile/tablet users. Have you ever tried to copy/paste on a mobile!
> >>>
> >>> Do not change this to requiring copy/pasting a code!
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 20 August, 2015 4:04:31 AM
> >>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> >>>>
> >>>>
> >>>>
> >>>> On 8/19/2015 9:10 PM, Bill Burke wrote:
> >>>>>
> >>>>>
> >>>>> On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
> >>>>>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs
> >>>>>>> review
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
> >>>>>>>> Can you elaborate on what the benefits are of these changes? It
> >>>>>>>> seems
> >>>>>>>> to
> >>>>>>>> me
> >>>>>>>> that we had something that was working just fine..
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
> >>>>>>>>> Subject: [keycloak-dev] Reset Password changes complete needs
> >>>>>>>>> review
> >>>>>>>>>
> >>>>>>>>> Here's what I did, I can change things based on questions I asked
> >>>>>>>>> in
> >>>>>>>>> other emails, but here's how it works.
> >>>>>>>>>
> >>>>>>>>> There's now the concept of "reset password" and a different one
> >>>>>>>>> "change
> >>>>>>>>> password".
> >>>>>>>>>
> >>>>>>>>> * Reset password is something the user initiates.  This will start
> >>>>>>>>> an
> >>>>>>>>> Authentication Flow and success will login the user and bring them
> >>>>>>>>> to
> >>>>>>>>> their application
> >>>>>>>>
> >>>>>>>> I assume this is still through email - if so it's important that
> >>>>>>>> users
> >>>>>>>> are
> >>>>>>>> only logged-in if the reset password link is opened in the same user
> >>>>>>>> session as they initiated the reset password flow
> >>>>>>>>
> >>>>>>>
> >>>>>>> With the previous impl, if somebody as able to hack your email
> >>>>>>> account,
> >>>>>>> then they could bypass OTP entirely.  Also previous implementation
> >>>>>>> wasn't really compatible with auth SPI.  There may be additional
> >>>>>>> steps
> >>>>>>> to reseting credentials beyond an email, i.e. entering in a code from
> >>>>>>> an
> >>>>>>> SMS message.  We may also be reseting both OTP and Password.
> >>>>>>> Finally,
> >>>>>>> the update password required action had reset-password specific logic
> >>>>>>> within it.
> >>>>>>>
> >>>>>>> Honestly, I'd prefer to switch exclusively to a temporary code as it
> >>>>>>> makes everything much simpler to support:  for us and for users
> >>>>>>> wanting
> >>>>>>> to write extensiosn.  I don't think this is a big usability issue as
> >>>>>>> Google requires entering a temporary code from an SMS message.  Also,
> >>>>>>> with the way it worked in 1.4, out-of-band email password reset would
> >>>>>>> require relogging in which is actually more steps.  Finally, links
> >>>>>>> can
> >>>>>>> be messed up by email readers sometimes if they are long enough,
> >>>>>>> making
> >>>>>>> them error prone.
> >>>>>>
> >>>>>> -100 We should stick with link in email (and only link, not confuse
> >>>>>> users
> >>>>>> by having multiple options), but why can't the link just include the
> >>>>>> same
> >>>>>> code?
> >>>>>>
> >>>>>
> >>>>> I also don't want multiple options.  I want to get rid of the link
> >>>>> entirely.
> >>>>>
> >>>>> I'm repeating myself, but, This is about your requirement of
> >>>>> out-of-band
> >>>>> link-clicks not logging in the user.  That kind of flow is not
> >>>>> compatible with the current Auth SPI and it requires hacks to required
> >>>>> actions like Update Password to even work (which already exist).  We're
> >>>>> also going to have to make users aware of it and explain how to code
> >>>>> for
> >>>>> it if they are writing their own extension.  It just makes things a lot
> >>>>> more complicated if you are extending things.
> >>>>>
> >>>>> Finally, I don't like the link because at least for me, it opens a
> >>>>> brand
> >>>>> new tab and leaves the original still active.  I also don't think the
> >>>>> link is more user-friendly when the link is clicked in another browser.
> >>>>>     It is also possible the user is obtaining the link on a phone and
> >>>>>     that
> >>>>> our update password screen will be a bit cramped there.  Also, typing
> >>>>> in
> >>>>> a password from a phone is quite awkward and time consuming.
> >>>>>
> >>>>
> >>>> Furthermore, I don't like Verify Email either.  It also should be
> >>>> changed from link clicking to code entry.  Like Reset Email, a new tab
> >>>> is opened if you click the link.  Like Reset Email, Verify email
> >>>> requires you to completely relogin if the link is clicked in a different
> >>>> browser.
> >>>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: google.png
Type: image/png
Size: 72323 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150820/dcd0ce57/attachment-0001.png 

From stian at redhat.com  Thu Aug 20 10:05:19 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 10:05:19 -0400 (EDT)
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <2010747614.15188695.1440079213447.JavaMail.zimbra@redhat.com>
References: <55D1001E.8010906@redhat.com> <55D52902.5010806@redhat.com>
	<55D535AF.9080906@redhat.com>
	<1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
	<28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>
	<401917060.14958009.1440054581854.JavaMail.zimbra@redhat.com>
	<55D5DC20.8050606@redhat.com>
	<2010747614.15188695.1440079213447.JavaMail.zimbra@redhat.com>
Message-ID: <473141848.15192034.1440079519079.JavaMail.zimbra@redhat.com>

If it makes it easier I think sending a recover password link, but not loging-in the user afterwards is fine.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 4:00:13 PM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> 
> Google sends link as well, see attached screenshot
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 20 August, 2015 3:54:40 PM
> > Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> > 
> > And yet with Google, you enter in a temporary code to reset credentials.
> > 
> > You talk about this "single argument", but it is more than that...With
> > us, a brand new tab is opened when you click the link leaving the old
> > one open. Leaving that old window in a stale state where a user may or
> > may not get an error message if they try to use that window.  (This
> > problem existed prior to the Auth SPI).
> > 
> > And, if you read my email, its more than just being incompatible, its
> > something we'll have to explain in detail in the documentation as well
> > as provide "hack" APIs just to support when users want to write
> > extensions.  It also forces required actions to be aware of the context
> > they are called in.  Its a mess...It as all fine and dandy to hard code
> > this stuff before, but now that we have a public API we can't have all
> > these special cases as writing extensions becomes a real pain in the ass
> > for users and for us as we'll be answering the same questions over and
> > over..."Why doesn't this work?"  "Well, did you read section 9.2.1.1 of
> > the manual, paragraph 2 where it says you have to call this special API
> > call and manage a cookie?"
> > 
> > 
> > On 8/20/2015 3:09 AM, Stian Thorgersen wrote:
> > > Attached screenshots of reset password from Facebook, Redhat, Twitter and
> > > Microsoft. All, but Microsoft, send a reset password link. Other websites
> > > where I've recently changed my password also all send links.
> > >
> > > It's clearly easier for users to click a link than copy/pasting, which
> > > would include finding the original window/tab. If the email is delayed
> > > with a few minutes the user may quite likely have moved on to something
> > > else and might have closed the original window.
> > >
> > > This all boils down to a single argument and that is that it's not
> > > compatible with the current authentication SPI. That's a problem with the
> > > SPI that needs resolving.
> > >
> > > What would work fine is that we store the required context in an
> > > encrypted
> > > cookie. Only if the cookie is available would we proceed with loging-in
> > > the user. Otherwise the user would only be allowed to reset the password
> > > and would then have to go back to the application to re-login with the
> > > new
> > > password. In that case resetting the password is not an authentication
> > > flow, but an action that a user is permitted to do with a special
> > > temporary key.
> > >
> > > ----- Original Message -----
> > >> From: "Stian Thorgersen" <stian at redhat.com>
> > >> To: "Bill Burke" <bburke at redhat.com>
> > >> Cc: keycloak-dev at lists.jboss.org
> > >> Sent: Thursday, 20 August, 2015 8:46:15 AM
> > >> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> > >>
> > >> By the way try reset your password on any website, they will all send
> > >> you
> > >> a
> > >> link you need to click
> > >>
> > >> ----- Original Message -----
> > >>> From: "Stian Thorgersen" <stian at redhat.com>
> > >>> To: "Bill Burke" <bburke at redhat.com>
> > >>> Cc: keycloak-dev at lists.jboss.org
> > >>> Sent: Thursday, 20 August, 2015 8:44:12 AM
> > >>> Subject: Re: [keycloak-dev] Reset Password changes complete needs
> > >>> review
> > >>>
> > >>> -1000 Clicking a link is a lot simpler for most users - especially
> > >>> mobile/tablet users. Have you ever tried to copy/paste on a mobile!
> > >>>
> > >>> Do not change this to requiring copy/pasting a code!
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: keycloak-dev at lists.jboss.org
> > >>>> Sent: Thursday, 20 August, 2015 4:04:31 AM
> > >>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs
> > >>>> review
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 8/19/2015 9:10 PM, Bill Burke wrote:
> > >>>>>
> > >>>>>
> > >>>>> On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>> ----- Original Message -----
> > >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>>>>> Cc: keycloak-dev at lists.jboss.org
> > >>>>>>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
> > >>>>>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs
> > >>>>>>> review
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
> > >>>>>>>> Can you elaborate on what the benefits are of these changes? It
> > >>>>>>>> seems
> > >>>>>>>> to
> > >>>>>>>> me
> > >>>>>>>> that we had something that was working just fine..
> > >>>>>>>>
> > >>>>>>>> ----- Original Message -----
> > >>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>>>>>> To: keycloak-dev at lists.jboss.org
> > >>>>>>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
> > >>>>>>>>> Subject: [keycloak-dev] Reset Password changes complete needs
> > >>>>>>>>> review
> > >>>>>>>>>
> > >>>>>>>>> Here's what I did, I can change things based on questions I asked
> > >>>>>>>>> in
> > >>>>>>>>> other emails, but here's how it works.
> > >>>>>>>>>
> > >>>>>>>>> There's now the concept of "reset password" and a different one
> > >>>>>>>>> "change
> > >>>>>>>>> password".
> > >>>>>>>>>
> > >>>>>>>>> * Reset password is something the user initiates.  This will
> > >>>>>>>>> start
> > >>>>>>>>> an
> > >>>>>>>>> Authentication Flow and success will login the user and bring
> > >>>>>>>>> them
> > >>>>>>>>> to
> > >>>>>>>>> their application
> > >>>>>>>>
> > >>>>>>>> I assume this is still through email - if so it's important that
> > >>>>>>>> users
> > >>>>>>>> are
> > >>>>>>>> only logged-in if the reset password link is opened in the same
> > >>>>>>>> user
> > >>>>>>>> session as they initiated the reset password flow
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> With the previous impl, if somebody as able to hack your email
> > >>>>>>> account,
> > >>>>>>> then they could bypass OTP entirely.  Also previous implementation
> > >>>>>>> wasn't really compatible with auth SPI.  There may be additional
> > >>>>>>> steps
> > >>>>>>> to reseting credentials beyond an email, i.e. entering in a code
> > >>>>>>> from
> > >>>>>>> an
> > >>>>>>> SMS message.  We may also be reseting both OTP and Password.
> > >>>>>>> Finally,
> > >>>>>>> the update password required action had reset-password specific
> > >>>>>>> logic
> > >>>>>>> within it.
> > >>>>>>>
> > >>>>>>> Honestly, I'd prefer to switch exclusively to a temporary code as
> > >>>>>>> it
> > >>>>>>> makes everything much simpler to support:  for us and for users
> > >>>>>>> wanting
> > >>>>>>> to write extensiosn.  I don't think this is a big usability issue
> > >>>>>>> as
> > >>>>>>> Google requires entering a temporary code from an SMS message.
> > >>>>>>> Also,
> > >>>>>>> with the way it worked in 1.4, out-of-band email password reset
> > >>>>>>> would
> > >>>>>>> require relogging in which is actually more steps.  Finally, links
> > >>>>>>> can
> > >>>>>>> be messed up by email readers sometimes if they are long enough,
> > >>>>>>> making
> > >>>>>>> them error prone.
> > >>>>>>
> > >>>>>> -100 We should stick with link in email (and only link, not confuse
> > >>>>>> users
> > >>>>>> by having multiple options), but why can't the link just include the
> > >>>>>> same
> > >>>>>> code?
> > >>>>>>
> > >>>>>
> > >>>>> I also don't want multiple options.  I want to get rid of the link
> > >>>>> entirely.
> > >>>>>
> > >>>>> I'm repeating myself, but, This is about your requirement of
> > >>>>> out-of-band
> > >>>>> link-clicks not logging in the user.  That kind of flow is not
> > >>>>> compatible with the current Auth SPI and it requires hacks to
> > >>>>> required
> > >>>>> actions like Update Password to even work (which already exist).
> > >>>>> We're
> > >>>>> also going to have to make users aware of it and explain how to code
> > >>>>> for
> > >>>>> it if they are writing their own extension.  It just makes things a
> > >>>>> lot
> > >>>>> more complicated if you are extending things.
> > >>>>>
> > >>>>> Finally, I don't like the link because at least for me, it opens a
> > >>>>> brand
> > >>>>> new tab and leaves the original still active.  I also don't think the
> > >>>>> link is more user-friendly when the link is clicked in another
> > >>>>> browser.
> > >>>>>     It is also possible the user is obtaining the link on a phone and
> > >>>>>     that
> > >>>>> our update password screen will be a bit cramped there.  Also, typing
> > >>>>> in
> > >>>>> a password from a phone is quite awkward and time consuming.
> > >>>>>
> > >>>>
> > >>>> Furthermore, I don't like Verify Email either.  It also should be
> > >>>> changed from link clicking to code entry.  Like Reset Email, a new tab
> > >>>> is opened if you click the link.  Like Reset Email, Verify email
> > >>>> requires you to completely relogin if the link is clicked in a
> > >>>> different
> > >>>> browser.
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Bill Burke
> > >>>> JBoss, a division of Red Hat
> > >>>> http://bill.burkecentral.com
> > >>>> _______________________________________________
> > >>>> keycloak-dev mailing list
> > >>>> keycloak-dev at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>>
> > >>>
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mposolda at redhat.com  Thu Aug 20 10:23:05 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 20 Aug 2015 16:23:05 +0200
Subject: [keycloak-dev] Time skew in client adapters
In-Reply-To: <1558505695.15090086.1440070080017.JavaMail.zimbra@redhat.com>
References: <1558505695.15090086.1440070080017.JavaMail.zimbra@redhat.com>
Message-ID: <55D5E2C9.8010806@redhat.com>

It's actually strange that different timezone is an issue? As from what 
I searched both Java implementation "System.currentTimeMillis()" and 
javascript implementation "new Date().getTime()" should be independent 
on timezone (it should be time since 1.1.1970 UTC). So looks like it's 
the bad time set either on the browser or server machine?

+1 to add the timeSkew to the javascript adapter as these are end user 
machines. But not sure if we need to add the support for server adapters 
. Maybe rather document that correct time should be set on the server 
machines. This is also required for TOTP working correctly.

Marek

On 20/08/15 13:28, Stian Thorgersen wrote:
> We recently had someone that had issues with the javascript adapter not refreshing tokens. The reason for this was that the browser and Keycloak server was in different time zones, so exp was not checked properly.
>
> I've now updated the javascript adapter to include a timeSkew property. This is calculated by:
>
>     timeSkew = (timeRequestStarted + timeRequestCompleted) / 2 - token.iat
>
> The assumption is that if the request and response takes roughly as long the tokens iat value will be set in the middle of request start and request stop.
>
> This will work both for cases where the browser time is not correct as well as when the browser is in a different time-zone.
>
> Big question is, should we do the same for all adapters? For server-side adapters we can be more assured that the time is in sync (not sure if we mention in the documentation that it's important to keep times in sync), but we still have the issue if the servers are in different time zones.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Thu Aug 20 10:24:32 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 10:24:32 -0400 (EDT)
Subject: [keycloak-dev] Time skew in client adapters
In-Reply-To: <55D5E2C9.8010806@redhat.com>
References: <1558505695.15090086.1440070080017.JavaMail.zimbra@redhat.com>
	<55D5E2C9.8010806@redhat.com>
Message-ID: <1808013386.15251563.1440080672866.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 20 August, 2015 4:23:05 PM
> Subject: Re: [keycloak-dev] Time skew in client adapters
> 
> It's actually strange that different timezone is an issue? As from what
> I searched both Java implementation "System.currentTimeMillis()" and
> javascript implementation "new Date().getTime()" should be independent
> on timezone (it should be time since 1.1.1970 UTC). So looks like it's
> the bad time set either on the browser or server machine?

Great, so problem is solved :)

> 
> +1 to add the timeSkew to the javascript adapter as these are end user
> machines. But not sure if we need to add the support for server adapters
> . Maybe rather document that correct time should be set on the server
> machines. This is also required for TOTP working correctly.
> 
> Marek
> 
> On 20/08/15 13:28, Stian Thorgersen wrote:
> > We recently had someone that had issues with the javascript adapter not
> > refreshing tokens. The reason for this was that the browser and Keycloak
> > server was in different time zones, so exp was not checked properly.
> >
> > I've now updated the javascript adapter to include a timeSkew property.
> > This is calculated by:
> >
> >     timeSkew = (timeRequestStarted + timeRequestCompleted) / 2 - token.iat
> >
> > The assumption is that if the request and response takes roughly as long
> > the tokens iat value will be set in the middle of request start and
> > request stop.
> >
> > This will work both for cases where the browser time is not correct as well
> > as when the browser is in a different time-zone.
> >
> > Big question is, should we do the same for all adapters? For server-side
> > adapters we can be more assured that the time is in sync (not sure if we
> > mention in the documentation that it's important to keep times in sync),
> > but we still have the issue if the servers are in different time zones.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From bburke at redhat.com  Thu Aug 20 10:30:40 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Aug 2015 10:30:40 -0400
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <2010747614.15188695.1440079213447.JavaMail.zimbra@redhat.com>
References: <55D1001E.8010906@redhat.com>
	<2080349423.13459268.1439964109068.JavaMail.zimbra@redhat.com>
	<55D52902.5010806@redhat.com> <55D535AF.9080906@redhat.com>
	<1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
	<28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>
	<401917060.14958009.1440054581854.JavaMail.zimbra@redhat.com>
	<55D5DC20.8050606@redhat.com>
	<2010747614.15188695.1440079213447.JavaMail.zimbra@redhat.com>
Message-ID: <55D5E490.5000206@redhat.com>



On 8/20/2015 10:00 AM, Stian Thorgersen wrote:
> Google sends link as well, see attached screenshot
>

Not in the USA.  For me I get a text:  "Your Google verification code is 
XXXXXX".



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

From stian at redhat.com  Thu Aug 20 10:34:11 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Aug 2015 10:34:11 -0400 (EDT)
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <55D5E490.5000206@redhat.com>
References: <55D1001E.8010906@redhat.com> <55D535AF.9080906@redhat.com>
	<1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
	<28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>
	<401917060.14958009.1440054581854.JavaMail.zimbra@redhat.com>
	<55D5DC20.8050606@redhat.com>
	<2010747614.15188695.1440079213447.JavaMail.zimbra@redhat.com>
	<55D5E490.5000206@redhat.com>
Message-ID: <1005224636.15294510.1440081251265.JavaMail.zimbra@redhat.com>

Did it send "Your Google verification code" to email? That's what I get on SMS if I recover through SMS. If you have another recovery email address associated with your account you should get the email I pasted.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 August, 2015 4:30:40 PM
> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
> 
> 
> 
> On 8/20/2015 10:00 AM, Stian Thorgersen wrote:
> > Google sends link as well, see attached screenshot
> >
> 
> Not in the USA.  For me I get a text:  "Your Google verification code is
> XXXXXX".
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Aug 20 10:53:00 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Aug 2015 10:53:00 -0400
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <473141848.15192034.1440079519079.JavaMail.zimbra@redhat.com>
References: <55D1001E.8010906@redhat.com> <55D52902.5010806@redhat.com>
	<55D535AF.9080906@redhat.com>
	<1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
	<28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>
	<401917060.14958009.1440054581854.JavaMail.zimbra@redhat.com>
	<55D5DC20.8050606@redhat.com>
	<2010747614.15188695.1440079213447.JavaMail.zimbra@redhat.com>
	<473141848.15192034.1440079519079.JavaMail.zimbra@redhat.com>
Message-ID: <55D5E9CC.3080200@redhat.com>



On 8/20/2015 10:05 AM, Stian Thorgersen wrote:
> If it makes it easier I think sending a recover password link, but not loging-in the user afterwards is fine.
>

That might work.   I think that might allow us to not have special 
user-facing APIs and also avoid a stale login window.

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

From bburke at redhat.com  Thu Aug 20 17:08:14 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Aug 2015 17:08:14 -0400
Subject: [keycloak-dev] Reset Password changes complete needs review
In-Reply-To: <473141848.15192034.1440079519079.JavaMail.zimbra@redhat.com>
References: <55D1001E.8010906@redhat.com> <55D52902.5010806@redhat.com>
	<55D535AF.9080906@redhat.com>
	<1239024844.14941384.1440053052930.JavaMail.zimbra@redhat.com>
	<28320362.14942196.1440053175969.JavaMail.zimbra@redhat.com>
	<401917060.14958009.1440054581854.JavaMail.zimbra@redhat.com>
	<55D5DC20.8050606@redhat.com>
	<2010747614.15188695.1440079213447.JavaMail.zimbra@redhat.com>
	<473141848.15192034.1440079519079.JavaMail.zimbra@redhat.com>
Message-ID: <55D641BE.4050506@redhat.com>



On 8/20/2015 10:05 AM, Stian Thorgersen wrote:
> If it makes it easier I think sending a recover password link, but not loging-in the user afterwards is fine.
>

I implemented it so that after you type in the username for Forgot 
Password, it brings you to the login screen with a message "You should 
receive an email with instructions to reset your credentials".  Clicking 
on the link in the email allows you to log in.

I added a fork() method that clones the current ClientSession and resets 
it to follow the browser login flow.  This is called in the email 
authenticator.  I couldn't get around introducing another SPI method.

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

From Scott.Rehorn at software.dell.com  Thu Aug 20 19:18:32 2015
From: Scott.Rehorn at software.dell.com (Scott Rehorn)
Date: Thu, 20 Aug 2015 23:18:32 +0000
Subject: [keycloak-dev] Groups design
In-Reply-To: <1866268216.14943768.1440053390976.JavaMail.zimbra@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
	<55D34BCD.50303@redhat.com>
	<951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
	<920254531.13544356.1439968657289.JavaMail.zimbra@redhat.com>
	<55D53318.8000901@redhat.com>
	<1866268216.14943768.1440053390976.JavaMail.zimbra@redhat.com>
Message-ID: <F893802C2FB19B459F1A54D865A9C95C35DE4B65@ALVMBXW01.prod.quest.corp>

We've been watching the groups discussion with interest over the last week or so, and we have a some comments and input re your proposed 'groups' implementation:
 
* our simple, purpose-built 'organizations' requirements can be readily subsumed by a group. It's possible that an 'organization' construct might still be useful as an organization structure similar in function to the 'client template' at the client level, but we'll see. 

* We generally feel that the group construct should have attributes associated with it - i.e., a user who is a member of a group gets attributes added to his token. The example we like best is 'subscriptionId' (with some value associated with it) as an attribute associated with a group so that a user identified as a member of that group always has that name-value pair in his token. We consider this an important means to support cooperating clients. 

* In our discussions, we tend to believe that 'permissions' are separate from 'roles', but it's not a deal-killer. That is, a role is a collection of permissions, but you can arrive at the same thing by naming convention in roles, e.g., admin-can-perform-backup, admin-can-reboot, etc. The usual treatments of role-based access control separate permissions from roles but that might be a function of academic purity. 

* +1 for client templates: this seems like a very helpful construct for organizing configuration patterns (for protocol, IdPs, etc.). Generally the 'client template' seems like a good location to specify a consistent group assignment based on incoming IdP. E.g., a CT could specify that for client x, any user who logs in with one of the available IdPs for that client, automatically gets put into x-users-group. The term 'membership' seems good here: membership defines the group(s) that a given user should belong to as part of client-x. 

* We think the distinction could be emphasized that groups can be only users and/or other groups and are thus for organizational applications and distinct from roles/permissions. If people make nested groups with conflicting role assignments, that could be trouble, but IMO indicates a larger authZ definition issue that KC shouldn't be involved in. 

* The "RoleGroup" concept seems strained, and/or we don't understand the use case. Firstly, using the word 'group' in there is dangerous :). If it's just 'namespace' for roles, then maybe just simple tagging for Roles would be sufficient as a means to collect related roles? Or attach that association in the client template? 

* You mention that having the URI for a role name is awkward, and, true, it can be a pain, but it's worth noting that it can be a 'urn:' which doesn't need to include a deployment-host-based DNS-based name. A URN is a clean way to express a canonical easily-read identifier (as opposed to a guid or something). 

* When you say 'deprecate {default,composite} roles' you just mean that a user's collection of roles is no longer named that way? It's still important for a user to wind up with a collection of roles which are certainly composites (due to possible role assertions contributed by an IdP, or as a result of group membership). 

* Just to see if we understand the boundaries and responsibilities for mappers:
  - Claims arriving from an IdP can be mapped to the token, relabeling them
  - Group and role assignments are mapped into the token for an authenticated user
  - These mapper configs are governed by client implementers (for better or worse) and implemented as client template directives 

* Task for The Intern Riding a Unicorn: have a debug UX which creates and displays a token in the admin interface so one could fiddle with the mappers and group assignments without having to write an external client to see the resulting token :)

* We think it's implicit, but just to be sure: the group membership collection will also be in the token, correct? So a token has group membership, role association, any claims mapped from the IdP, group-defined attributes, and user-level attributes. 
 

- scott r
(On behalf of the identity broker team at Dell Software)

> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
> Sent: Wednesday, August 19, 2015 11:50 PM
> To: Bill Burke <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 20 August, 2015 3:53:28 AM
> > Subject: Re: [keycloak-dev] Groups design
> >
> >
> >
> > On 8/19/2015 3:17 AM, Stian Thorgersen wrote:
> > >>> Have the concept of Role Groups:
> > >>> * Role Groups are just a namespace for roles.
> > >
> > > Just to double check as part of this we're removing the concept of
> > > realm and client roles, and we're also adding some ability of
> > > defining what roles are listed in adapters (so we can have plain
> > > role names, like 'user', in jee apps for example)
> > >
> >
> > Yes.  We'll have a flat user role mapping in the token
> >
> > roles: [ "role1", "role2" ]
> >
> > You'll either manipulate how roles look in the token via a mapper, or
> > you'll define a role mapping within the adapter config.  Default role
> > mapper on server will specify a URI for the role.  BTW, this URI
> > probably shouldn't have a DNS name within it.  Something like
> > role:{realm-name}.{group}.{role-name}.  This is so that adapter config
> > doesn't have to be changed as it moves from dev->QE->production.  BTW,
> > this is why I hate the OIDC requirement that the realm is some http://
> > based URI.
> 
> Do we need real-name? Seems like that'll only make it hard to use.
> 
> I like OIDC requirement that it's URL based - a realm is not a unique name,
> but a URL is and I think it should be unique
> 
> >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Thu Aug 20 22:34:27 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Aug 2015 22:34:27 -0400
Subject: [keycloak-dev] Groups design
In-Reply-To: <F893802C2FB19B459F1A54D865A9C95C35DE4B65@ALVMBXW01.prod.quest.corp>
References: <55CB4F1D.3000909@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
	<55D34BCD.50303@redhat.com>
	<951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
	<920254531.13544356.1439968657289.JavaMail.zimbra@redhat.com>
	<55D53318.8000901@redhat.com>
	<1866268216.14943768.1440053390976.JavaMail.zimbra@redhat.com>
	<F893802C2FB19B459F1A54D865A9C95C35DE4B65@ALVMBXW01.prod.quest.corp>
Message-ID: <55D68E33.2040702@redhat.com>



On 8/20/2015 7:18 PM, Scott Rehorn wrote:
> We've been watching the groups discussion with interest over the last week or so, and we have a some comments and input re your proposed 'groups' implementation:
>
> * our simple, purpose-built 'organizations' requirements can be readily subsumed by a group. It's possible that an 'organization' construct might still be useful as an organization structure similar in function to the 'client template' at the client level, but we'll see.
>
> * We generally feel that the group construct should have attributes associated with it - i.e., a user who is a member of a group gets attributes added to his token. The example we like best is 'subscriptionId' (with some value associated with it) as an attribute associated with a group so that a user identified as a member of that group always has that name-value pair in his token. We consider this an important means to support cooperating clients.
>

Stian didn't like the idea of associating mappers with Groups.   Because 
of this, e're gonna end up having to add conditionals to mappers, i.e. 
if user has role or group, add this attribute.  If user has this 
attribute with value x, add this role or attribute, etc...



> * In our discussions, we tend to believe that 'permissions' are separate from 'roles', but it's not a deal-killer. That is, a role is a collection of permissions, but you can arrive at the same thing by naming convention in roles, e.g., admin-can-perform-backup, admin-can-reboot, etc. The usual treatments of role-based access control separate permissions from roles but that might be a function of academic purity.
>

I always thought a role was just a tag and permissions were something 
that can have value.  i.e. a file permission might be 775.


> * +1 for client templates: this seems like a very helpful construct for organizing configuration patterns (for protocol, IdPs, etc.). Generally the 'client template' seems like a good location to specify a consistent group assignment based on incoming IdP. E.g., a CT could specify that for client x, any user who logs in with one of the available IdPs for that client, automatically gets put into x-users-group. The term 'membership' seems good here: membership defines the group(s) that a given user should belong to as part of client-x.
>

Nah, wouldn't work that way.  You'd define a mapper at the IDP 
Federation entry.  For external IDP X, add mapper Y which assigns user 
to group Z.

> * We think the distinction could be emphasized that groups can be only users and/or other groups and are thus for organizational applications and distinct from roles/permissions. If people make nested groups with conflicting role assignments, that could be trouble, but IMO indicates a larger authZ definition issue that KC shouldn't be involved in.
>
> * The "RoleGroup" concept seems strained, and/or we don't understand the use case. Firstly, using the word 'group' in there is dangerous :). If it's just 'namespace' for roles, then maybe just simple tagging for Roles would be sufficient as a means to collect related roles? Or attach that association in the client template?
>

Role Groups are just a namespace.  You have a good point.  Now that we 
have mappers we kinda don't need role groups.  The counter point is how 
do we migrate older apps?

The counter point is that it becomes harder to pick and choose roles to 
assign/map/whatever if they are not categorized at all.  I'm open to a 
better name than Role Group.

> * You mention that having the URI for a role name is awkward, and, true, it can be a pain, but it's worth noting that it can be a 'urn:' which doesn't need to include a deployment-host-based DNS-based name. A URN is a clean way to express a canonical easily-read identifier (as opposed to a guid or something).
>
> * When you say 'deprecate {default,composite} roles' you just mean that a user's collection of roles is no longer named that way? It's still important for a user to wind up with a collection of roles which are certainly composites (due to possible role assertions contributed by an IdP, or as a result of group membership).
>

Default roles are roles assigned automatically when a user registers or 
when a user is imported from an external IDP.

Right now any role can be a composite of other roles.   Meaning it can 
be associated with other roles.  It is kind of like a group.

We're deprecating both these features in

> * Just to see if we understand the boundaries and responsibilities for mappers:
>    - Claims arriving from an IdP can be mapped to the token, relabeling them
>    - Group and role assignments are mapped into the token for an authenticated user
>    - These mapper configs are governed by client implementers (for better or worse) and implemented as client template directives
>

yeah, I think that would be the initial route.  I'm not sure yet if I 
want to allow clients to override the template they are associated with. 
  Might get messy.


> * Task for The Intern Riding a Unicorn: have a debug UX which creates and displays a token in the admin interface so one could fiddle with the mappers and group assignments without having to write an external client to see the resulting token :)
>

That's a good idea.  Probably not very hard to do either.

> * We think it's implicit, but just to be sure: the group membership collection will also be in the token, correct? So a token has group membership, role association, any claims mapped from the IdP, group-defined attributes, and user-level attributes.
>

Yeah, I think that should be the default.  The default Client Template 
will have some default mappers that adds all user attributes, group 
attributes and group membership.  Then you can remove these defaults as 
needed and bring stuff in a la carte if you want.


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

From ssilvert at redhat.com  Fri Aug 21 07:21:58 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 21 Aug 2015 07:21:58 -0400
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <83756299.14938617.1440052909041.JavaMail.zimbra@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
	<55D47654.70503@redhat.com>
	<1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
	<55D4825C.9030000@redhat.com>
	<1651015162.13983560.1439991085619.JavaMail.zimbra@redhat.com>
	<55D487E2.4070601@redhat.com> <55D52A3D.9060409@redhat.com>
	<83756299.14938617.1440052909041.JavaMail.zimbra@redhat.com>
Message-ID: <55D709D6.4070101@redhat.com>

On 8/20/2015 2:41 AM, Stian Thorgersen wrote:
> There are no changes that must be made - it just has to be checked that things still work
I did find a couple of things that broke.   I had to change the way 
response interceptors are registered and also fix our <kc-tooltip> 
directive.  But those should be one-time fixes to app.js.

It would be good for everyone to at least browse the migration guide to 
see if you notice any mandatory changes that need to be made. Remember, 
we are moving from 1.2 to 1.4.  See 
https://docs.angularjs.org/guide/migration.

I'm going to do some more manual testing and if all goes well I'll 
submit a PR by the end of the day.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 20 August, 2015 3:15:41 AM
>> Subject: Re: [keycloak-dev] Upgrade Angular?
>>
>> Do no upgrade angular until you go over with the team any changes that
>> must be made.  I don't want to be banging my head wondering why I can't
>> get my UI changes to work.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Fri Aug 21 07:30:16 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Aug 2015 13:30:16 +0200
Subject: [keycloak-dev] Offline tokens
Message-ID: <55D70BC8.10108@redhat.com>

Some thoughts around offline tokens impl:

- Client has switch "Allow offline tokens" . Offline token can be 
requested just if the switch is enabled

- Offline token can be requested if parameter "scope=offline" is sent. 
Offline token is sent alone, no IDToken or refreshToken is sent together 
with it.
Question: Should be offline tokens available just for 
ResourceOwnerPasswordCredentials and ServiceAccounts or also for classic 
web based authorization code flow?

- There are methods on UserModel to track which offline tokens were 
issued for particular user. Like:

List<String> getOfflineTokens();
void addOfflineToken(String offlineToken);
void removeOfflineToken(String offlineToken);

- Offline token will never expire. Or should we eventually add another 
timeout for offline token (With some big default value like 1 month or so)?

- Offline token is not refreshable.

- Offline token can be validated by current OIDC endpoint for token 
validation. Offline token is not valid if UserModel doesn't have token 
anymore on it. But offline token is still valid even if corresponding 
UserSession doesn't exist. So we can still have offline tokens valid for 
1 year even if SsoSessionMaxLifespan is just 10 hours.

- Offline token can be logged out. Logout will remove offline token from 
corresponding UserModel.

- In Account management applications page can user see list of offline 
tokens issued for individual clients and he can revoke them. Not sure if 
put another "Revoke offline token" or use current "Revoke grant" action, 
which will revoke both consents and offline tokens?

- Admin can see the offline tokens for user in admin console and can 
revoke them too . Current button "Logout All" in sessions tab will 
revoke offline tokens from all users . For performance reasons, we may 
need method on UserProvider, so it's possible to clean whole DB table 
"OFFLINE_TOKEN" (similarly for mongo) instead of iterating through all 
users.

- For adapters, we should likely have an option, so the REST endpoint 
adapter has possibility to validate offline token by always sending 
validation request to KC server. We didn't need it for access tokens, 
which are valid just for 1 minute or so, but offline tokens are long 
lived so adapter should have this possibility IMO.

WDYT?

Marek

From mposolda at redhat.com  Fri Aug 21 08:09:31 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Aug 2015 14:09:31 +0200
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D70BC8.10108@redhat.com>
References: <55D70BC8.10108@redhat.com>
Message-ID: <55D714FB.5000506@redhat.com>

On 21/08/15 13:30, Marek Posolda wrote:
> Some thoughts around offline tokens impl:
>
> - Client has switch "Allow offline tokens" . Offline token can be
> requested just if the switch is enabled
>
> - Offline token can be requested if parameter "scope=offline" is sent.
> Offline token is sent alone, no IDToken or refreshToken is sent together
> with it.
> Question: Should be offline tokens available just for
> ResourceOwnerPasswordCredentials and ServiceAccounts or also for classic
> web based authorization code flow?
>
> - There are methods on UserModel to track which offline tokens were
> issued for particular user. Like:
>
> List<String> getOfflineTokens();
> void addOfflineToken(String offlineToken);
> void removeOfflineToken(String offlineToken);
>
> - Offline token will never expire. Or should we eventually add another
> timeout for offline token (With some big default value like 1 month or so)?
>
> - Offline token is not refreshable.
>
> - Offline token can be validated by current OIDC endpoint for token
> validation. Offline token is not valid if UserModel doesn't have token
> anymore on it. But offline token is still valid even if corresponding
> UserSession doesn't exist. So we can still have offline tokens valid for
> 1 year even if SsoSessionMaxLifespan is just 10 hours.
>
> - Offline token can be logged out. Logout will remove offline token from
> corresponding UserModel.
>
> - In Account management applications page can user see list of offline
> tokens issued for individual clients and he can revoke them. Not sure if
> put another "Revoke offline token" or use current "Revoke grant" action,
> which will revoke both consents and offline tokens?
>
> - Admin can see the offline tokens for user in admin console and can
> revoke them too . Current button "Logout All" in sessions tab will
> revoke offline tokens from all users . For performance reasons, we may
> need method on UserProvider, so it's possible to clean whole DB table
> "OFFLINE_TOKEN" (similarly for mongo) instead of iterating through all
> users.
>
> - For adapters, we should likely have an option, so the REST endpoint
> adapter has possibility to validate offline token by always sending
> validation request to KC server. We didn't need it for access tokens,
> which are valid just for 1 minute or so, but offline tokens are long
> lived so adapter should have this possibility IMO.
- Actually, for the frontend adapters (both server and keycloak.js ) I 
am thinking about adding the persistent cookie, which will be put on the 
application after successful login and is valid for the same time like 
the offline token (so couple of months). When browser is opened next 
time, the adapter will find the cookie and send the validation request 
to KC to check if offline token is still valid. This will allow the 
browser application to be logged with the same offline token for couple 
of months.

I also wonder if we should put the IP address checking when validating 
offline token (Offline token is valid just if validation request come 
from same address like the original request) ?

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


From prabhalar at yahoo.com  Fri Aug 21 08:15:46 2015
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Fri, 21 Aug 2015 12:15:46 +0000 (UTC)
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D70BC8.10108@redhat.com>
References: <55D70BC8.10108@redhat.com>
Message-ID: <238746206.8519766.1440159346963.JavaMail.yahoo@mail.yahoo.com>

Hi Marek - My two cents on this:
1) Offline tokens can be long lived but must have a way of revoking them. If they are requested by users (see the openid connect spec below), the life should be of shorter duration (a week?) but if they are requested by clients then they can be of much longer duration (upto a year) but there should be a mechanism to refresh/revoke.
http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess

Thanks,Raghu
      From: Marek Posolda <mposolda at redhat.com>
 To: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org> 
 Sent: Friday, August 21, 2015 7:30 AM
 Subject: [keycloak-dev] Offline tokens
   
Some thoughts around offline tokens impl:

- Client has switch "Allow offline tokens" . Offline token can be 
requested just if the switch is enabled

- Offline token can be requested if parameter "scope=offline" is sent. 
Offline token is sent alone, no IDToken or refreshToken is sent together 
with it.
Question: Should be offline tokens available just for 
ResourceOwnerPasswordCredentials and ServiceAccounts or also for classic 
web based authorization code flow?

- There are methods on UserModel to track which offline tokens were 
issued for particular user. Like:

List<String> getOfflineTokens();
void addOfflineToken(String offlineToken);
void removeOfflineToken(String offlineToken);

- Offline token will never expire. Or should we eventually add another 
timeout for offline token (With some big default value like 1 month or so)?

- Offline token is not refreshable.

- Offline token can be validated by current OIDC endpoint for token 
validation. Offline token is not valid if UserModel doesn't have token 
anymore on it. But offline token is still valid even if corresponding 
UserSession doesn't exist. So we can still have offline tokens valid for 
1 year even if SsoSessionMaxLifespan is just 10 hours.

- Offline token can be logged out. Logout will remove offline token from 
corresponding UserModel.

- In Account management applications page can user see list of offline 
tokens issued for individual clients and he can revoke them. Not sure if 
put another "Revoke offline token" or use current "Revoke grant" action, 
which will revoke both consents and offline tokens?

- Admin can see the offline tokens for user in admin console and can 
revoke them too . Current button "Logout All" in sessions tab will 
revoke offline tokens from all users . For performance reasons, we may 
need method on UserProvider, so it's possible to clean whole DB table 
"OFFLINE_TOKEN" (similarly for mongo) instead of iterating through all 
users.

- For adapters, we should likely have an option, so the REST endpoint 
adapter has possibility to validate offline token by always sending 
validation request to KC server. We didn't need it for access tokens, 
which are valid just for 1 minute or so, but offline tokens are long 
lived so adapter should have this possibility IMO.

WDYT?

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/20150821/0fe61feb/attachment-0001.html 

From juraci at kroehling.de  Fri Aug 21 08:27:58 2015
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Fri, 21 Aug 2015 14:27:58 +0200
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D70BC8.10108@redhat.com>
References: <55D70BC8.10108@redhat.com>
Message-ID: <55D7194E.5070605@kroehling.de>

Marek,

On 08/21/2015 01:30 PM, Marek Posolda wrote:
> - Offline token can be requested if parameter "scope=offline" is sent.
> Offline token is sent alone, no IDToken or refreshToken is sent together
> with it.
> Question: Should be offline tokens available just for
> ResourceOwnerPasswordCredentials and ServiceAccounts or also for classic
> web based authorization code flow?

Not quite sure what ResourceOwnerPasswordCredentials is (is it something 
new?), but I think that having the possibility of requesting an offline 
token based on a bearer token is desirable. In my case, I intend to have 
a "token exchange proxy", where the end user would create API keys for 
the agent. This API key is an UUID, that relates to a token that I'd 
store in Hawkular's backend. Whenever I get this token, I retrieve the 
offline token and use it for backend operations, as if the user were online.

This means: I don't intend to have access to the user's password at any 
point when creating or sending offline tokens.

> - Offline token will never expire. Or should we eventually add another
> timeout for offline token (With some big default value like 1 month or so)?

It should never expire. Or at most, there should be a setting for the 
realm/client that would allow the offline token to never expire. It can, 
however, be revoked.

> - Offline token can be validated by current OIDC endpoint for token
> validation. Offline token is not valid if UserModel doesn't have token
> anymore on it. But offline token is still valid even if corresponding
> UserSession doesn't exist. So we can still have offline tokens valid for
> 1 year even if SsoSessionMaxLifespan is just 10 hours.

+1

> - Offline token can be logged out. Logout will remove offline token from
> corresponding UserModel.

I guess this is the revoked part I mentioned above, right?

> - In Account management applications page can user see list of offline
> tokens issued for individual clients and he can revoke them. Not sure if
> put another "Revoke offline token" or use current "Revoke grant" action,
> which will revoke both consents and offline tokens?

Not sure what would be the difference there. The consent is linked to 
the client, while the offline token would be a session, right? If so, 
I'd revoke only the token itself.

> - Admin can see the offline tokens for user in admin console and can
> revoke them too . Current button "Logout All" in sessions tab will
> revoke offline tokens from all users . For performance reasons, we may
> need method on UserProvider, so it's possible to clean whole DB table
> "OFFLINE_TOKEN" (similarly for mongo) instead of iterating through all
> users.

+1

> - For adapters, we should likely have an option, so the REST endpoint
> adapter has possibility to validate offline token by always sending
> validation request to KC server. We didn't need it for access tokens,
> which are valid just for 1 minute or so, but offline tokens are long
> lived so adapter should have this possibility IMO.

+1

- Juca.

From thomas.raehalme at aitiofinland.com  Fri Aug 21 08:32:40 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Fri, 21 Aug 2015 15:32:40 +0300
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D7194E.5070605@kroehling.de>
References: <55D70BC8.10108@redhat.com>
	<55D7194E.5070605@kroehling.de>
Message-ID: <CAPyAMoZr0O7deVndx5Le9tvv_CasH_Suzb=4_yUnCZSD=zTJ8g@mail.gmail.com>

On Fri, Aug 21, 2015 at 3:27 PM, Juraci Paix?o Kr?hling <juraci at kroehling.de
> wrote:

> > - Offline token will never expire. Or should we eventually add another
> > timeout for offline token (With some big default value like 1 month or
> so)?
>
> It should never expire. Or at most, there should be a setting for the
> realm/client that would allow the offline token to never expire. It can,
> however, be revoked.
>

+1 from me too, or at least it should be possible to use NEVER in the
timeout configuration.

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

From bburke at redhat.com  Fri Aug 21 08:50:38 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Aug 2015 08:50:38 -0400
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D714FB.5000506@redhat.com>
References: <55D70BC8.10108@redhat.com> <55D714FB.5000506@redhat.com>
Message-ID: <55D71E9E.5020803@redhat.com>



On 8/21/2015 8:09 AM, Marek Posolda wrote:
> - Actually, for the frontend adapters (both server and keycloak.js ) I
> am thinking about adding the persistent cookie, which will be put on the
> application after successful login and is valid for the same time like
> the offline token (so couple of months). When browser is opened next
> time, the adapter will find the cookie and send the validation request
> to KC to check if offline token is still valid. This will allow the
> browser application to be logged with the same offline token for couple
> of months.
>

I don't understand why you need an offline token for browser 
applications.  We already support persistent cookies.

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

From bburke at redhat.com  Fri Aug 21 08:58:17 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Aug 2015 08:58:17 -0400
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D71E9E.5020803@redhat.com>
References: <55D70BC8.10108@redhat.com> <55D714FB.5000506@redhat.com>
	<55D71E9E.5020803@redhat.com>
Message-ID: <55D72069.9000308@redhat.com>



On 8/21/2015 8:50 AM, Bill Burke wrote:
>
>
> On 8/21/2015 8:09 AM, Marek Posolda wrote:
>> - Actually, for the frontend adapters (both server and keycloak.js ) I
>> am thinking about adding the persistent cookie, which will be put on the
>> application after successful login and is valid for the same time like
>> the offline token (so couple of months). When browser is opened next
>> time, the adapter will find the cookie and send the validation request
>> to KC to check if offline token is still valid. This will allow the
>> browser application to be logged with the same offline token for couple
>> of months.
>>
>
> I don't understand why you need an offline token for browser
> applications.  We already support persistent cookies.
>

IMO, but Stian disgreed IIRC, is that what would be needed would be a 
persistent UserSessionModel/ClientSessionModel store.  If an offline 
token is requested, then the current UserSessionModel is cloned and 
stored persistently and the client's accesstoken/refresh token 
references this cloned persistent UserSession/ClientSession.  Then you 
don't have to have any special UI in the admin console to manage offline 
sessions.  These sessions would just have a flag showing if they are 
offline or not.

I just don't like the idea at all of creating a completely parallel and 
redundant model that is a near duplicate of UserSession/ClientSession.


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

From eric.wittmann at redhat.com  Fri Aug 21 09:47:54 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 21 Aug 2015 09:47:54 -0400
Subject: [keycloak-dev] <kc:bearer-only> and BASIC auth
Message-ID: <55D72C0A.8020607@redhat.com>

[Resending this because apparently I wasn't subscribed to this mailing 
list before!]

----

Hey guys.  This is in reference to the discussion here:

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

At Bill's request, I'm moving it here.

I think KEYCLOAK-1472 (for us) might have a couple different aspects to 
it.  So I'm going to focus on just one in this email.  And I'll start a 
different thread for the other aspect.

We have a REST endpoint located at /apiman which is protected by 
keycloak.  We need to support both bearer token authentication *and* 
BASIC authentication on that endpoint.  Our apiman UI uses bearer-token 
auth to access the API.  However, for scripts and CLIs and other 
integrations, we need to allow users to provide BASIC auth credentials 
if they so choose.

In any case, here is the relevant config in standalone.xml for this:

       <kc:secure-deployment xmlns:kc="urn:jboss:domain:keycloak:1.0" 
name="apiman.war">
         <kc:realm>apiman</kc:realm>
         <kc:resource>apiman</kc:resource>
         <kc:credential name="secret">
           password
         </kc:credential>
         <kc:enable-basic-auth>true</kc:enable-basic-auth>
         <kc:disable-trust-manager>true</kc:disable-trust-manager>
       </kc:secure-deployment>

This works great unless authentication fails, at which point we get a 
redirect to the login page.  That makes sense if this were a UI, but 
it's not.  The solution to the redirect problem is to add:

<kc:bearer-only>true</kc:bearer-only>

This fixes the redirect to login page problem but it disables BASIC auth 
support.

Can we get an option that disables the login redirect but still allows 
BASIC auth to work?

-Eric

From bburke at redhat.com  Fri Aug 21 09:56:26 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Aug 2015 09:56:26 -0400
Subject: [keycloak-dev] <kc:bearer-only> and BASIC auth
In-Reply-To: <55D72C0A.8020607@redhat.com>
References: <55D72C0A.8020607@redhat.com>
Message-ID: <55D72E0A.1020801@redhat.com>

I'm more interested in the CORS problems.  What you want is an easy fix.

On 8/21/2015 9:47 AM, Eric Wittmann wrote:
> Can we get an option that disables the login redirect but still allows
> BASIC auth to work?
>
> -Eric
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Fri Aug 21 10:03:48 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Aug 2015 10:03:48 -0400
Subject: [keycloak-dev] <kc:bearer-only> and BASIC auth
In-Reply-To: <55D72E0A.1020801@redhat.com>
References: <55D72C0A.8020607@redhat.com> <55D72E0A.1020801@redhat.com>
Message-ID: <55D72FC4.3040703@redhat.com>

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

committing a fix for this in next hour or so.  Please elaborate on your 
CORS problem though.

On 8/21/2015 9:56 AM, Bill Burke wrote:
> I'm more interested in the CORS problems.  What you want is an easy fix.
>
> On 8/21/2015 9:47 AM, Eric Wittmann wrote:
>> Can we get an option that disables the login redirect but still allows
>> BASIC auth to work?
>>
>> -Eric
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

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

From eric.wittmann at redhat.com  Fri Aug 21 10:17:16 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 21 Aug 2015 10:17:16 -0400
Subject: [keycloak-dev] KC + apiman + CORS
Message-ID: <55D732EC.5040705@redhat.com>

Well, I was going to wait on this until I've done some more testing and 
really come up to speed.  But can have a go at it now with what I know.

After looking into it, we are in fact *not* using the KC CORS support. 
Why are we not using it?  That's a great question with a real answer... 
but it's what I need more time to figure out.  Perhaps @msavy has some 
insight into that.

In any case, we've implemented our own CORS support for our API (as a 
simple filter).  However, as you can imagine it doesn't work for 
preflighting because KC denies the OPTIONS request since it doesn't 
include the auth creds (the browser doesn't send auth creds for 
preflight requests).

So I guess we either need to use the KC CORS support, in which case I 
need to figure out why we *stopped* using it.  Or else we'd need to 
request a way to bypass KC auth for OPTIONS requests.

From bburke at redhat.com  Fri Aug 21 11:09:35 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Aug 2015 11:09:35 -0400
Subject: [keycloak-dev] <kc:bearer-only> and BASIC auth
In-Reply-To: <55D72FC4.3040703@redhat.com>
References: <55D72C0A.8020607@redhat.com> <55D72E0A.1020801@redhat.com>
	<55D72FC4.3040703@redhat.com>
Message-ID: <55D73F2F.2090505@redhat.com>

BTW, I despise our Basic Auth option.  One of the points of SAML/OIDC is 
that the application never has access to user credentials.  Using Basic 
Auth violates that principle....But to each his own...

On 8/21/2015 10:03 AM, Bill Burke wrote:
> https://issues.jboss.org/browse/KEYCLOAK-1778
>
> committing a fix for this in next hour or so.  Please elaborate on your
> CORS problem though.
>
> On 8/21/2015 9:56 AM, Bill Burke wrote:
>> I'm more interested in the CORS problems.  What you want is an easy fix.
>>
>> On 8/21/2015 9:47 AM, Eric Wittmann wrote:
>>> Can we get an option that disables the login redirect but still allows
>>> BASIC auth to work?
>>>
>>> -Eric
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>

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

From thomas.raehalme at aitiofinland.com  Fri Aug 21 11:17:33 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Fri, 21 Aug 2015 18:17:33 +0300
Subject: [keycloak-dev] <kc:bearer-only> and BASIC auth
In-Reply-To: <55D73F2F.2090505@redhat.com>
References: <55D72C0A.8020607@redhat.com> <55D72E0A.1020801@redhat.com>
	<55D72FC4.3040703@redhat.com> <55D73F2F.2090505@redhat.com>
Message-ID: <CAPyAMob8aOVm4vaCJHiu5WiGVOxsytqcdwOsSAVYCgV25kTFNQ@mail.gmail.com>

On Aug 21, 2015 6:09 PM, "Bill Burke" <bburke at redhat.com> wrote:
>
> BTW, I despise our Basic Auth option.  One of the points of SAML/OIDC is
> that the application never has access to user credentials.  Using Basic
> Auth violates that principle....But to each his own...

I understand your point of view. But from a user perspective having the
Basic auth option makes migration so much easier as you can migrate clients
one by one.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150821/285c7102/attachment-0001.html 

From bburke at redhat.com  Fri Aug 21 11:29:21 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Aug 2015 11:29:21 -0400
Subject: [keycloak-dev] KC + apiman + CORS
In-Reply-To: <55D732EC.5040705@redhat.com>
References: <55D732EC.5040705@redhat.com>
Message-ID: <55D743D1.6070506@redhat.com>



On 8/21/2015 10:17 AM, Eric Wittmann wrote:
> Well, I was going to wait on this until I've done some more testing and
> really come up to speed.  But can have a go at it now with what I know.
>
> After looking into it, we are in fact *not* using the KC CORS support.
> Why are we not using it?  That's a great question with a real answer...
> but it's what I need more time to figure out.  Perhaps @msavy has some
> insight into that.
>
> In any case, we've implemented our own CORS support for our API (as a
> simple filter).  However, as you can imagine it doesn't work for
> preflighting because KC denies the OPTIONS request since it doesn't
> include the auth creds (the browser doesn't send auth creds for
> preflight requests).
>
> So I guess we either need to use the KC CORS support, in which case I
> need to figure out why we *stopped* using it.  Or else we'd need to
> request a way to bypass KC auth for OPTIONS requests.

Ok, this makes a lot more sense now.  You disabled our CORS support and 
are trying to handle CORS yourself.

What I think you can do is modify your security constraints in web.xml 
to allow OPTIONS requests through.

<security-constraint>
     <web-resource-collection>
         <web-resource-name>wholesale</web-resource-name>
         <url-pattern>/*</url-pattern>
         <http-method>GET</http-method>
         <http-method>POST</http-method>
     </web-resource-collection>
...
</security-constraint>

The above should trigger Keycloak authentication for only GET and POST 
methods and let OPTIONS through.


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

From eric.wittmann at redhat.com  Fri Aug 21 13:02:23 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 21 Aug 2015 13:02:23 -0400
Subject: [keycloak-dev] <kc:bearer-only> and BASIC auth
In-Reply-To: <55D73F2F.2090505@redhat.com>
References: <55D72C0A.8020607@redhat.com> <55D72E0A.1020801@redhat.com>
	<55D72FC4.3040703@redhat.com> <55D73F2F.2090505@redhat.com>
Message-ID: <55D7599F.8040003@redhat.com>

I'm not a fan of basic auth either, but ... give the people what they 
want?

We had to implement a BASIC Authentication Policy in apiman for the same 
reason - lots of people use it and want it still.

On 8/21/2015 11:09 AM, Bill Burke wrote:
> BTW, I despise our Basic Auth option.  One of the points of SAML/OIDC is
> that the application never has access to user credentials.  Using Basic
> Auth violates that principle....But to each his own...
>
> On 8/21/2015 10:03 AM, Bill Burke wrote:
>> https://issues.jboss.org/browse/KEYCLOAK-1778
>>
>> committing a fix for this in next hour or so.  Please elaborate on your
>> CORS problem though.
>>
>> On 8/21/2015 9:56 AM, Bill Burke wrote:
>>> I'm more interested in the CORS problems.  What you want is an easy fix.
>>>
>>> On 8/21/2015 9:47 AM, Eric Wittmann wrote:
>>>> Can we get an option that disables the login redirect but still allows
>>>> BASIC auth to work?
>>>>
>>>> -Eric
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>
>

From eric.wittmann at redhat.com  Fri Aug 21 13:04:40 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 21 Aug 2015 13:04:40 -0400
Subject: [keycloak-dev] KC + apiman + CORS
In-Reply-To: <55D743D1.6070506@redhat.com>
References: <55D732EC.5040705@redhat.com> <55D743D1.6070506@redhat.com>
Message-ID: <55D75A28.9090607@redhat.com>

Oh man.  I was so tunnel-focused on keycloak and standalone.xml that I 
completely forgot that the security constraints were configured in web.xml.

My bad.

Thanks - will try that out asap.

-Eric

On 8/21/2015 11:29 AM, Bill Burke wrote:
>
>
> On 8/21/2015 10:17 AM, Eric Wittmann wrote:
>> Well, I was going to wait on this until I've done some more testing and
>> really come up to speed.  But can have a go at it now with what I know.
>>
>> After looking into it, we are in fact *not* using the KC CORS support.
>> Why are we not using it?  That's a great question with a real answer...
>> but it's what I need more time to figure out.  Perhaps @msavy has some
>> insight into that.
>>
>> In any case, we've implemented our own CORS support for our API (as a
>> simple filter).  However, as you can imagine it doesn't work for
>> preflighting because KC denies the OPTIONS request since it doesn't
>> include the auth creds (the browser doesn't send auth creds for
>> preflight requests).
>>
>> So I guess we either need to use the KC CORS support, in which case I
>> need to figure out why we *stopped* using it.  Or else we'd need to
>> request a way to bypass KC auth for OPTIONS requests.
>
> Ok, this makes a lot more sense now.  You disabled our CORS support and
> are trying to handle CORS yourself.
>
> What I think you can do is modify your security constraints in web.xml
> to allow OPTIONS requests through.
>
> <security-constraint>
>      <web-resource-collection>
>          <web-resource-name>wholesale</web-resource-name>
>          <url-pattern>/*</url-pattern>
>          <http-method>GET</http-method>
>          <http-method>POST</http-method>
>      </web-resource-collection>
> ...
> </security-constraint>
>
> The above should trigger Keycloak authentication for only GET and POST
> methods and let OPTIONS through.
>
>

From bburke at redhat.com  Fri Aug 21 13:23:31 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Aug 2015 13:23:31 -0400
Subject: [keycloak-dev] <kc:bearer-only> and BASIC auth
In-Reply-To: <55D7599F.8040003@redhat.com>
References: <55D72C0A.8020607@redhat.com> <55D72E0A.1020801@redhat.com>
	<55D72FC4.3040703@redhat.com> <55D73F2F.2090505@redhat.com>
	<55D7599F.8040003@redhat.com>
Message-ID: <55D75E93.5010903@redhat.com>

I won't give somebody what they want if it is the wrong decision.  Its 
better to enforce best practices.  BASIC Auth is a fine protocol, the 
issue is that the remote app gets access to credentials.

On 8/21/2015 1:02 PM, Eric Wittmann wrote:
> I'm not a fan of basic auth either, but ... give the people what they want?
>
> We had to implement a BASIC Authentication Policy in apiman for the same
> reason - lots of people use it and want it still.
>
> On 8/21/2015 11:09 AM, Bill Burke wrote:
>> BTW, I despise our Basic Auth option.  One of the points of SAML/OIDC is
>> that the application never has access to user credentials.  Using Basic
>> Auth violates that principle....But to each his own...
>>
>> On 8/21/2015 10:03 AM, Bill Burke wrote:
>>> https://issues.jboss.org/browse/KEYCLOAK-1778
>>>
>>> committing a fix for this in next hour or so.  Please elaborate on your
>>> CORS problem though.
>>>
>>> On 8/21/2015 9:56 AM, Bill Burke wrote:
>>>> I'm more interested in the CORS problems.  What you want is an easy
>>>> fix.
>>>>
>>>> On 8/21/2015 9:47 AM, Eric Wittmann wrote:
>>>>> Can we get an option that disables the login redirect but still allows
>>>>> BASIC auth to work?
>>>>>
>>>>> -Eric
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>
>>

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

From bburke at redhat.com  Fri Aug 21 13:26:27 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Aug 2015 13:26:27 -0400
Subject: [keycloak-dev] <kc:bearer-only> and BASIC auth
In-Reply-To: <55D75E93.5010903@redhat.com>
References: <55D72C0A.8020607@redhat.com> <55D72E0A.1020801@redhat.com>
	<55D72FC4.3040703@redhat.com> <55D73F2F.2090505@redhat.com>
	<55D7599F.8040003@redhat.com> <55D75E93.5010903@redhat.com>
Message-ID: <55D75F43.5020505@redhat.com>

Oh, FYI, BASIC auth problem should be fixed next release (early September).

On 8/21/2015 1:23 PM, Bill Burke wrote:
> I won't give somebody what they want if it is the wrong decision.  Its
> better to enforce best practices.  BASIC Auth is a fine protocol, the
> issue is that the remote app gets access to credentials.
>
> On 8/21/2015 1:02 PM, Eric Wittmann wrote:
>> I'm not a fan of basic auth either, but ... give the people what they want?
>>
>> We had to implement a BASIC Authentication Policy in apiman for the same
>> reason - lots of people use it and want it still.
>>
>> On 8/21/2015 11:09 AM, Bill Burke wrote:
>>> BTW, I despise our Basic Auth option.  One of the points of SAML/OIDC is
>>> that the application never has access to user credentials.  Using Basic
>>> Auth violates that principle....But to each his own...
>>>
>>> On 8/21/2015 10:03 AM, Bill Burke wrote:
>>>> https://issues.jboss.org/browse/KEYCLOAK-1778
>>>>
>>>> committing a fix for this in next hour or so.  Please elaborate on your
>>>> CORS problem though.
>>>>
>>>> On 8/21/2015 9:56 AM, Bill Burke wrote:
>>>>> I'm more interested in the CORS problems.  What you want is an easy
>>>>> fix.
>>>>>
>>>>> On 8/21/2015 9:47 AM, Eric Wittmann wrote:
>>>>>> Can we get an option that disables the login redirect but still allows
>>>>>> BASIC auth to work?
>>>>>>
>>>>>> -Eric
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>
>>>
>

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

From ssilvert at redhat.com  Fri Aug 21 15:09:19 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 21 Aug 2015 15:09:19 -0400
Subject: [keycloak-dev] Upgrade Angular?
In-Reply-To: <55D709D6.4070101@redhat.com>
References: <55D38EB3.6060700@redhat.com>
	<90174216.13463072.1439964692611.JavaMail.zimbra@redhat.com>
	<55D47654.70503@redhat.com>
	<1096452455.13923635.1439989635205.JavaMail.zimbra@redhat.com>
	<55D4825C.9030000@redhat.com>
	<1651015162.13983560.1439991085619.JavaMail.zimbra@redhat.com>
	<55D487E2.4070601@redhat.com> <55D52A3D.9060409@redhat.com>
	<83756299.14938617.1440052909041.JavaMail.zimbra@redhat.com>
	<55D709D6.4070101@redhat.com>
Message-ID: <55D7775F.10602@redhat.com>

PR is done.  There is one more caveat you need to know about.  If you 
are using the tooltip attributes outside of the <kc-tooltip> directive, 
you will need to manually specify tooltip-trigger and tooltip-placement. 
Apparently, if you leave them out it now means "no triggers" and "no 
placement".

For example:
<buton tooltip-trigger="mouseover mouseout" tooltip="my message" 
tooltip-placement="right">Foo</button>"

On 8/21/2015 7:21 AM, Stan Silvert wrote:
> On 8/20/2015 2:41 AM, Stian Thorgersen wrote:
>> There are no changes that must be made - it just has to be checked that things still work
> I did find a couple of things that broke.   I had to change the way
> response interceptors are registered and also fix our <kc-tooltip>
> directive.  But those should be one-time fixes to app.js.
>
> It would be good for everyone to at least browse the migration guide to
> see if you notice any mandatory changes that need to be made. Remember,
> we are moving from 1.2 to 1.4.  See
> https://docs.angularjs.org/guide/migration.
>
> I'm going to do some more manual testing and if all goes well I'll
> submit a PR by the end of the day.
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 20 August, 2015 3:15:41 AM
>>> Subject: Re: [keycloak-dev] Upgrade Angular?
>>>
>>> Do no upgrade angular until you go over with the team any changes that
>>> must be made.  I don't want to be banging my head wondering why I can't
>>> get my UI changes to work.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri Aug 21 21:31:56 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 21 Aug 2015 21:31:56 -0400
Subject: [keycloak-dev] refactored admin reset email and required actions
Message-ID: <55D7D10C.6030401@redhat.com>

Admin console can send a reset password email to the user.  Originally 
it just executed update password.  I changed this so that it sets an 
Update Password required action on the User.  The email link click runs 
all required actions set for the user, then displays a message that the 
Account has been updated.

When I get back, I'm also going to change the admin console behavior and 
look too.  Instead of a "Reset Password Email" button on Credentials 
tab, there will be a button next to the Required Actions selection box 
on user detail, something like "Email Required Actions"  (I need a 
better name).  Clicking on this button will send an email to user

"Your adminstrator has requested that you update and/or reset some of 
your account settings.  Please click the link below to perform these 
actions."

We do it this way because there may be multiple credentials the admin 
wants the user to reset.  These credentials may be custom authenticators.

Also I refactored the CONFIG_TOTP, UPDATE_PROFILE, and UPDATE_PASSWORD 
required actions.  They are now fully encapsulated under the required 
actions SPI and are not hardcoded with any special cases.  I still need 
to refactor verify email.  Ran out of time.

Finally, I need to add a check to user-initiated Reset Credentials.  I 
haven't put back in the cookie check to make sure not to log in the user 
if its not the same browser.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Scott.Rehorn at software.dell.com  Sun Aug 23 13:09:12 2015
From: Scott.Rehorn at software.dell.com (Scott Rehorn)
Date: Sun, 23 Aug 2015 17:09:12 +0000
Subject: [keycloak-dev] Groups design
In-Reply-To: <55D68E33.2040702@redhat.com>
References: <55CB4F1D.3000909@redhat.com>
	<1657900384.10019388.1439475471775.JavaMail.zimbra@redhat.com>
	<55CCAB46.7060602@redhat.com>
	<1875532423.12972575.1439903645789.JavaMail.zimbra@redhat.com>
	<55D34BCD.50303@redhat.com>
	<951436012.13460187.1439964320722.JavaMail.zimbra@redhat.com>
	<920254531.13544356.1439968657289.JavaMail.zimbra@redhat.com>
	<55D53318.8000901@redhat.com>
	<1866268216.14943768.1440053390976.JavaMail.zimbra@redhat.com>
	<F893802C2FB19B459F1A54D865A9C95C35DE4B65@ALVMBXW01.prod.quest.corp>
	<55D68E33.2040702@redhat.com>
Message-ID: <D1FF4956.8F56%scott.rehorn@software.dell.com>

Comments inline?


On 8/20/15, 7:34 PM, "Bill Burke" <bburke at redhat.com> wrote:

>
>
>On 8/20/2015 7:18 PM, Scott Rehorn wrote:
>> We've been watching the groups discussion with interest over the last
>>week or so, and we have a some comments and input re your proposed
>>'groups' implementation:
>>
>> * our simple, purpose-built 'organizations' requirements can be readily
>>subsumed by a group. It's possible that an 'organization' construct
>>might still be useful as an organization structure similar in function
>>to the 'client template' at the client level, but we'll see.
>>
>> * We generally feel that the group construct should have attributes
>>associated with it - i.e., a user who is a member of a group gets
>>attributes added to his token. The example we like best is
>>'subscriptionId' (with some value associated with it) as an attribute
>>associated with a group so that a user identified as a member of that
>>group always has that name-value pair in his token. We consider this an
>>important means to support cooperating clients.
>>
>
>Stian didn't like the idea of associating mappers with Groups.   Because
>of this, e're gonna end up having to add conditionals to mappers, i.e.
>if user has role or group, add this attribute.  If user has this
>attribute with value x, add this role or attribute, etc...
>

I can see that, but I think what we're talking about is actually dumber.
We want to define the group entity with attributes which come along as
part of the group itself during normal mapping so there is no logic there.
A mapper would inject a group assertion into a token for "AcmeBostonUsers"
and this group definition would carry with it an attribute expressing
"officeLocation=Boston". One *could* do this just with more groups, but it
overloads the purpose of group labels. Mappers can and should be fairly
simple at first, as they are just a mechanism to map claims (with optional
transformation) from some source into the token. Currently there are two
sources for claims, the IdP, and KC itself. BTW we've been doing a bunch
with mappers using drools and it's working well - it gives us a nice
pluggable way to do interesting transformations without having to change
intrinsic KC code.
 

>
>
>> * In our discussions, we tend to believe that 'permissions' are
>>separate from 'roles', but it's not a deal-killer. That is, a role is a
>>collection of permissions, but you can arrive at the same thing by
>>naming convention in roles, e.g., admin-can-perform-backup,
>>admin-can-reboot, etc. The usual treatments of role-based access control
>>separate permissions from roles but that might be a function of academic
>>purity.
>>
>
>I always thought a role was just a tag and permissions were something
>that can have value.  i.e. a file permission might be 775.


That?s a compact way to view it. In this rbac-stuff, you cannot assign a
permission to a user, you can only assign one or more permissions to a
role, and the role is assigned to the user or group. So to make 'scott' an
admin, then you would create 'AppAdmin' group is assigned the 'Admin'
role. The Admin role carries permissions like 'root-access=false',
'restart=ohhailno' so when scott logs in as part of group AppAdmin, then
he has that role's permissions. Tagged permissions works better for me
mentally because the typical hierarchical model of RBAC can yield weird
and messy combinations of permissions and roles, but a taggy graph would
be simpler.

 

>
>
>> * +1 for client templates: this seems like a very helpful construct for
>>organizing configuration patterns (for protocol, IdPs, etc.). Generally
>>the 'client template' seems like a good location to specify a consistent
>>group assignment based on incoming IdP. E.g., a CT could specify that
>>for client x, any user who logs in with one of the available IdPs for
>>that client, automatically gets put into x-users-group. The term
>>'membership' seems good here: membership defines the group(s) that a
>>given user should belong to as part of client-x.
>>
>
>Nah, wouldn't work that way.  You'd define a mapper at the IDP
>Federation entry.  For external IDP X, add mapper Y which assigns user
>to group Z.

Ah ok yes - I was getting overly excited about what could be put in a
client template :) 

>
>> * We think the distinction could be emphasized that groups can be only
>>users and/or other groups and are thus for organizational applications
>>and distinct from roles/permissions. If people make nested groups with
>>conflicting role assignments, that could be trouble, but IMO indicates a
>>larger authZ definition issue that KC shouldn't be involved in.
>>
>> * The "RoleGroup" concept seems strained, and/or we don't understand
>>the use case. Firstly, using the word 'group' in there is dangerous :).
>>If it's just 'namespace' for roles, then maybe just simple tagging for
>>Roles would be sufficient as a means to collect related roles? Or attach
>>that association in the client template?
>>
>
>Role Groups are just a namespace.  You have a good point.  Now that we
>have mappers we kinda don't need role groups.  The counter point is how
>do we migrate older apps?
>
>The counter point is that it becomes harder to pick and choose roles to
>assign/map/whatever if they are not categorized at all.  I'm open to a
>better name than Role Group.


Candidates: "RoleCollection" or "RoleNamespace" (the latter makes sense to
me, anyway). Maybe a loose, opt-in tagging mecha would work? I can
definitely see how a proliferation of these things would be a pain. That
is, from the admin console, a user just sees a flat listing of roles to
which he can assign tags and then filter the view by tag?
 

>
>> * You mention that having the URI for a role name is awkward, and,
>>true, it can be a pain, but it's worth noting that it can be a 'urn:'
>>which doesn't need to include a deployment-host-based DNS-based name. A
>>URN is a clean way to express a canonical easily-read identifier (as
>>opposed to a guid or something).
>>
>> * When you say 'deprecate {default,composite} roles' you just mean that
>>a user's collection of roles is no longer named that way? It's still
>>important for a user to wind up with a collection of roles which are
>>certainly composites (due to possible role assertions contributed by an
>>IdP, or as a result of group membership).
>>
>
>Default roles are roles assigned automatically when a user registers or
>when a user is imported from an external IDP.
>
>Right now any role can be a composite of other roles.   Meaning it can
>be associated with other roles.  It is kind of like a group.
>
>We're deprecating both these features in
>
>> * Just to see if we understand the boundaries and responsibilities for
>>mappers:
>>    - Claims arriving from an IdP can be mapped to the token, relabeling
>>them
>>    - Group and role assignments are mapped into the token for an
>>authenticated user
>>    - These mapper configs are governed by client implementers (for
>>better or worse) and implemented as client template directives
>>
>
>yeah, I think that would be the initial route.  I'm not sure yet if I
>want to allow clients to override the template they are associated with.
>  Might get messy.

Agreed - override is a maybe-later thing. In our use case, it's important
for a client to be able to read/write values for attributes for users and
groups subject to authZ constraints, and we eventually want to support
what amounts to a schema - validation for values written to an attribute
for a particular client, and the ability for a client to add and manage
new attributes persisted in KC for a given client.



>
>
>> * Task for The Intern Riding a Unicorn: have a debug UX which creates
>>and displays a token in the admin interface so one could fiddle with the
>>mappers and group assignments without having to write an external client
>>to see the resulting token :)
>>
>
>That's a good idea.  Probably not very hard to do either.

Ha, yes, indeed almost fun :)



>
>> * We think it's implicit, but just to be sure: the group membership
>>collection will also be in the token, correct? So a token has group
>>membership, role association, any claims mapped from the IdP,
>>group-defined attributes, and user-level attributes.
>>
>
>Yeah, I think that should be the default.  The default Client Template
>will have some default mappers that adds all user attributes, group
>attributes and group membership.  Then you can remove these defaults as
>needed and bring stuff in a la carte if you want.
>
>
>-- 
>Bill Burke
>JBoss, a division of Red Hat
>http://bill.burkecentral.com

- scott r
(on behalf of the Dell Identity Broker team) at Dell Software Group




From satyajit.das at spire2grow.com  Tue Aug 25 04:48:51 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Tue, 25 Aug 2015 14:18:51 +0530
Subject: [keycloak-dev] Query on multi Tenancy
Message-ID: <CA+oCsRqjxMWT0ynUd4ofz6mNJC-PJT2c8ACPc7NF9BCRxwQAFg@mail.gmail.com>

Hi Team,

I have some query on multi tenancy.

Scenario:

a)
I have a webservice (named: SampleService) that is to be shared across
multi tenants , i.e in other words, the service will be present in multiple
realms.

The number of realms are dynamic, they can be increased based on new client
onboard.

Configuration:
I have multiple keycloak.json files present in resource folder of
SampleService such as:
realm1-keycloak.json
realm2-keycloak.json.

TO resolve this multiple jsons, I have a path resolver in web.xml of
SampleService:
 <context-param>
        <param-name>keycloak.config.resolver</param-name>

<param-value>com.crunchify.restjersey.PathBasedKeycloakConfigResolver</param-value>
    </context-param>


b)
I have a UI application, that gets authenticated by calling the the service
to get the token:
example
new HttpPost(KeycloakUriBuilder.fromUri("http://localhost:8080/auth")
.path(ServiceUrlConstants.TOKEN_PATH).build(realmName));

Now My question is. I have the token for a particular realm(say realm1) and
I want to call the SampleService using that token. How will SampleService
come to know which keycloakJson to use to resolve the token validation:

Note my service call URI doesn't change as per realm: example:
URI are
localhost:8080/sampleService/getRequsitionDetails
or
localhost:8080/sampleService/postRequsitionDetails

and not

localhost:8080/sampleService/realm1/getRequsitionDetails
or
localhost:8080/sampleService/realm2/postRequsitionDetails.


Kindly respond to the above case.

Please let me know in case of any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150825/bab9910f/attachment.html 

From satyajit.das at spire2grow.com  Tue Aug 25 04:55:11 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Tue, 25 Aug 2015 14:25:11 +0530
Subject: [keycloak-dev] Query on multi Tenancy
In-Reply-To: <CA+oCsRqjxMWT0ynUd4ofz6mNJC-PJT2c8ACPc7NF9BCRxwQAFg@mail.gmail.com>
References: <CA+oCsRqjxMWT0ynUd4ofz6mNJC-PJT2c8ACPc7NF9BCRxwQAFg@mail.gmail.com>
Message-ID: <CA+oCsRoib8-piwPrwM10SGFCw-sPjwkHynj-UR3ofj1KEDQ__Q@mail.gmail.com>

A point to note I have the realm id or realm name after the user
authenticates and gets the token.

On Tue, Aug 25, 2015 at 2:18 PM, Satyajit Das <satyajit.das at spire2grow.com>
wrote:

> Hi Team,
>
> I have some query on multi tenancy.
>
> Scenario:
>
> a)
> I have a webservice (named: SampleService) that is to be shared across
> multi tenants , i.e in other words, the service will be present in multiple
> realms.
>
> The number of realms are dynamic, they can be increased based on new
> client onboard.
>
> Configuration:
> I have multiple keycloak.json files present in resource folder of
> SampleService such as:
> realm1-keycloak.json
> realm2-keycloak.json.
>
> TO resolve this multiple jsons, I have a path resolver in web.xml of
> SampleService:
>  <context-param>
>         <param-name>keycloak.config.resolver</param-name>
>
> <param-value>com.crunchify.restjersey.PathBasedKeycloakConfigResolver</param-value>
>     </context-param>
>
>
> b)
> I have a UI application, that gets authenticated by calling the the
> service to get the token:
> example
> new HttpPost(KeycloakUriBuilder.fromUri("http://localhost:8080/auth")
> .path(ServiceUrlConstants.TOKEN_PATH).build(realmName));
>
> Now My question is. I have the token for a particular realm(say realm1)
> and I want to call the SampleService using that token. How will
> SampleService come to know which keycloakJson to use to resolve the token
> validation:
>
> Note my service call URI doesn't change as per realm: example:
> URI are
> localhost:8080/sampleService/getRequsitionDetails
> or
> localhost:8080/sampleService/postRequsitionDetails
>
> and not
>
> localhost:8080/sampleService/realm1/getRequsitionDetails
> or
> localhost:8080/sampleService/realm2/postRequsitionDetails.
>
>
> Kindly respond to the above case.
>
> Please let me know in case of any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150825/04d66764/attachment.html 

From satyajit.das at spire2grow.com  Thu Aug 27 05:29:01 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Thu, 27 Aug 2015 14:59:01 +0530
Subject: [keycloak-dev] Issue with PathBasedKeycloakConfigResolver
Message-ID: <CA+oCsRoMU+gSAgAXtUvP1dwgbcnibWrLGwLv_-8gobkza-fXcQ@mail.gmail.com>

Hi Team,

I have configured PathBasedKeycloakConfigResolver in my package:
com.demo.util.

The context param has been set on web.xml
<context-param>
        <param-name>keycloak.config.resolver</param-name>

<param-value>org.keycloak.example.PathBasedKeycloakConfigResolver</param-value>
    </context-param>

I deployed the application on Tomcat. I have registered the context.xml in
meta-inf with the required adapter.

Tomcat lib directory has all the required keycloak jar files.

But PathBasedKeycloakConfigResolver never gets called on any request to the
url.

Kindly comment.


Regards,
Satya.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150827/c1e2d7cc/attachment.html 

From satyajit.das at spire2grow.com  Fri Aug 28 03:44:06 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Fri, 28 Aug 2015 13:14:06 +0530
Subject: [keycloak-dev] Issue with PathBasedKeycloakConfigResolver
In-Reply-To: <CA+oCsRoMU+gSAgAXtUvP1dwgbcnibWrLGwLv_-8gobkza-fXcQ@mail.gmail.com>
References: <CA+oCsRoMU+gSAgAXtUvP1dwgbcnibWrLGwLv_-8gobkza-fXcQ@mail.gmail.com>
Message-ID: <CA+oCsRoGf=bGY4B5w5=UJhc8KHfhsQwAoj_QNednbA=z6tyiDQ@mail.gmail.com>

Hi Team,
Any update in this.

One strange thing i find that in eclipse if I remove the maven dependency
from deployment assembly(right click on project-> properties->deployment
assembly) it works But if i put it back it fails. Maven dependency is a
must.

Please comment on this . it is a bit urgent.

On Thu, Aug 27, 2015 at 2:59 PM, Satyajit Das <satyajit.das at spire2grow.com>
wrote:

> Hi Team,
>
> I have configured PathBasedKeycloakConfigResolver in my package:
> com.demo.util.
>
> The context param has been set on web.xml
> <context-param>
>         <param-name>keycloak.config.resolver</param-name>
>
> <param-value>org.keycloak.example.PathBasedKeycloakConfigResolver</param-value>
>     </context-param>
>
> I deployed the application on Tomcat. I have registered the context.xml in
> meta-inf with the required adapter.
>
> Tomcat lib directory has all the required keycloak jar files.
>
> But PathBasedKeycloakConfigResolver never gets called on any request to
> the url.
>
> Kindly comment.
>
>
> Regards,
> Satya.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150828/b6d9cead/attachment.html 

From satyajit.das at spire2grow.com  Fri Aug 28 09:08:05 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Fri, 28 Aug 2015 18:38:05 +0530
Subject: [keycloak-dev] Issue with MultiTenancy on Tomcat
Message-ID: <CA+oCsRq0fEL1oP9GX_LFGzLr3Zd6c4amQO-3+Ufiyp4gqedXJQ@mail.gmail.com>

Hi Team,

I have configured PathBasedKeycloakConfigResolver in my package:
com.demo.util.

The context param has been set on web.xml
<context-param>
        <param-name>keycloak.config.resolver</param-name>

<param-value>org.keycloak.example.PathBasedKeycloakConfigResolver</param-value>
    </context-param>

I deployed the application on Tomcat. I have registered the context.xml in
meta-inf with the required adapter.

Tomcat lib directory has all the required keycloak jar files.

But PathBasedKeycloakConfigResolver never gets called on any request to the
url.
One strange thing i find that in eclipse if I remove the maven dependency
from deployment assembly(right click on project-> properties->deployment
assembly) it works But if i put it back it fails. Maven dependency is a
must.



Kindly comment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150828/1da3d736/attachment.html 

From juraci at kroehling.de  Fri Aug 28 09:59:22 2015
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Fri, 28 Aug 2015 15:59:22 +0200
Subject: [keycloak-dev] Issue with MultiTenancy on Tomcat
In-Reply-To: <CA+oCsRq0fEL1oP9GX_LFGzLr3Zd6c4amQO-3+Ufiyp4gqedXJQ@mail.gmail.com>
References: <CA+oCsRq0fEL1oP9GX_LFGzLr3Zd6c4amQO-3+Ufiyp4gqedXJQ@mail.gmail.com>
Message-ID: <55E0693A.6020107@kroehling.de>

Satyajit,

I believe this question is better suited for the hawkular-user list. In 
any case, what I can recommend "quickly" is to put a debugger on the 
following line and check what's the going on there:

http://git.io/vGmGg

- Juca.

On 08/28/2015 03:08 PM, Satyajit Das wrote:
> Hi Team,
>
> I have configured PathBasedKeycloakConfigResolver in my package:
> com.demo.util.
>
> The context param has been set on web.xml
> <context-param>
>          <param-name>keycloak.config.resolver</param-name>
>
> <param-value>org.keycloak.example.PathBasedKeycloakConfigResolver</param-value>
>      </context-param>
>
> I deployed the application on Tomcat. I have registered the context.xml
> in meta-inf with the required adapter.
>
> Tomcat lib directory has all the required keycloak jar files.
>
> But PathBasedKeycloakConfigResolver never gets called on any request to
> the url.
> One strange thing i find that in eclipse if I remove the maven
> dependency from deployment assembly(right click on project->
> properties->deployment assembly) it works But if i put it back it fails.
> Maven dependency is a must.
>
>
>
> Kindly comment.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From satyajit.das at spire2grow.com  Fri Aug 28 10:08:33 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Fri, 28 Aug 2015 19:38:33 +0530
Subject: [keycloak-dev] Issue with MultiTenancy on Tomcat
In-Reply-To: <55E0693A.6020107@kroehling.de>
References: <CA+oCsRq0fEL1oP9GX_LFGzLr3Zd6c4amQO-3+Ufiyp4gqedXJQ@mail.gmail.com>
	<55E0693A.6020107@kroehling.de>
Message-ID: <CA+oCsRok-vu4X5jgxFz9_hhm6ZkAM5nN5stmvaxbTfZd4AfJxQ@mail.gmail.com>

Hi Juraci,

Can you please provide me the email for hawkular-user list

Regards,
Satya

On Fri, Aug 28, 2015 at 7:29 PM, Juraci Paix?o Kr?hling <juraci at kroehling.de
> wrote:

> Satyajit,
>
> I believe this question is better suited for the hawkular-user list. In
> any case, what I can recommend "quickly" is to put a debugger on the
> following line and check what's the going on there:
>
> http://git.io/vGmGg
>
> - Juca.
>
> On 08/28/2015 03:08 PM, Satyajit Das wrote:
> > Hi Team,
> >
> > I have configured PathBasedKeycloakConfigResolver in my package:
> > com.demo.util.
> >
> > The context param has been set on web.xml
> > <context-param>
> >          <param-name>keycloak.config.resolver</param-name>
> >
> >
> <param-value>org.keycloak.example.PathBasedKeycloakConfigResolver</param-value>
> >      </context-param>
> >
> > I deployed the application on Tomcat. I have registered the context.xml
> > in meta-inf with the required adapter.
> >
> > Tomcat lib directory has all the required keycloak jar files.
> >
> > But PathBasedKeycloakConfigResolver never gets called on any request to
> > the url.
> > One strange thing i find that in eclipse if I remove the maven
> > dependency from deployment assembly(right click on project->
> > properties->deployment assembly) it works But if i put it back it fails.
> > Maven dependency is a must.
> >
> >
> >
> > Kindly comment.
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.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/20150828/bbc748e7/attachment.html 

From satyajit.das at spire2grow.com  Fri Aug 28 11:01:10 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Fri, 28 Aug 2015 20:31:10 +0530
Subject: [keycloak-dev] Issue with multi tenancy
Message-ID: <CA+oCsRq-3GWJtC=23q18jYDVuv0KX9_e8mxKCZB44BzwNMWbOw@mail.gmail.com>

>
> Hi Team,
>
> I have configured PathBasedKeycloakConfigResolver in my package:
> com.demo.util.
>
> The context param has been set on web.xml
> <context-param>
>         <param-name>keycloak.config.resolver</param-name>
>
> <param-value>org.keycloak.example.PathBasedKeycloakConfigResolver</param-value>
>     </context-param>
>
> I deployed the application on Tomcat. I have registered the context.xml in
> meta-inf with the required adapter.
>
> Tomcat lib directory has all the required keycloak jar files.
>
> But PathBasedKeycloakConfigResolver never gets called on any request to
> the url.
> One strange thing i find that in eclipse if I remove the maven dependency
> from deployment assembly(right click on project-> properties->deployment
> assembly) it works But if i put it back it fails. Maven dependency is a
> must.
>

After debugging   String configResolverClass =
context.getServletContext().getInitParameter("keycloak.config.resolver");
of AbstractKeycloakAuthenticatorValve class

Got the following error: when PathBasedKeycloakConfigResolver  is being
instantiated.

java.lang.ClassCastException:
org.keycloak.example.PathBasedKeycloakConfigResolver cannot be cast to
org.keycloak.adapters.KeycloakConfigResolver

But PathBasedKeycloakConfigResolver implements
org.keycloak.adapters.KeycloakConfigResolver.


Regards,
Satya.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150828/9ea0ad8a/attachment.html 

From hermann.hill at optile.net  Fri Aug 28 11:59:59 2015
From: hermann.hill at optile.net (Hermann Hill)
Date: Fri, 28 Aug 2015 15:59:59 +0000
Subject: [keycloak-dev] Where to store data for the SSO session?
Message-ID: <DB3PR05MB378C055E2A87A2806F00656FC6E0@DB3PR05MB378.eurprd05.prod.outlook.com>

Hi,

I'm currently working on attaching an internal authentication API to Keycloak by implementing an UserFederationProvider.

Basically it is working, but I'm wondering where I'm supposed to store additional data that should be tied to the lifetime of the SSO session of an user. The KeycloakSession object seems to be recreated on every access to the server and I got lost in its subobjects without finding something usable.

Is there any documentation on the recommended way to do that? If not, could somebody please be so kind and point me in the right direction?

Best regards,

Hermann Josef Hill
Software Architect

optile GmbH
Ganghoferstra?e 39 | 80339 M?nchen
Mobil +49 (151) 5385 0784

hermann.hill at optile.net | www.optile.net

USt.Id.-Nr. DE268847980
Gesch?ftsf?hrer: Daniel Smeds
Handelsregister M?nchen HRB 183178

+++ Besuchen Sie uns auf der dmexco 2015 am 16. & 17. September, K?ln, Halle 7.1 Stand F013 +++

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

From satyajit.das at spire2grow.com  Mon Aug 31 00:16:37 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Mon, 31 Aug 2015 09:46:37 +0530
Subject: [keycloak-dev] Issue with multi tenancy
In-Reply-To: <CA+oCsRq-3GWJtC=23q18jYDVuv0KX9_e8mxKCZB44BzwNMWbOw@mail.gmail.com>
References: <CA+oCsRq-3GWJtC=23q18jYDVuv0KX9_e8mxKCZB44BzwNMWbOw@mail.gmail.com>
Message-ID: <CA+oCsRr2v6zcLVosN=RypZF3gYy4HMzSJs_sGH53NpaADoLGUQ@mail.gmail.com>

HI Team,

Did any one get a chance to look at the issue.

Kindly look into it.

Looking forward to your positive response.

Regards,
Satya

On Fri, Aug 28, 2015 at 8:31 PM, Satyajit Das <satyajit.das at spire2grow.com>
wrote:

> Hi Team,
>>
>> I have configured PathBasedKeycloakConfigResolver in my package:
>> com.demo.util.
>>
>> The context param has been set on web.xml
>> <context-param>
>>         <param-name>keycloak.config.resolver</param-name>
>>
>> <param-value>org.keycloak.example.PathBasedKeycloakConfigResolver</param-value>
>>     </context-param>
>>
>> I deployed the application on Tomcat. I have registered the context.xml
>> in meta-inf with the required adapter.
>>
>> Tomcat lib directory has all the required keycloak jar files.
>>
>> But PathBasedKeycloakConfigResolver never gets called on any request to
>> the url.
>> One strange thing i find that in eclipse if I remove the maven dependency
>> from deployment assembly(right click on project-> properties->deployment
>> assembly) it works But if i put it back it fails. Maven dependency is a
>> must.
>>
>
> After debugging   String configResolverClass =
> context.getServletContext().getInitParameter("keycloak.config.resolver");
> of AbstractKeycloakAuthenticatorValve class
>
> Got the following error: when PathBasedKeycloakConfigResolver  is being
> instantiated.
>
> java.lang.ClassCastException:
> org.keycloak.example.PathBasedKeycloakConfigResolver cannot be cast to
> org.keycloak.adapters.KeycloakConfigResolver
>
> But PathBasedKeycloakConfigResolver implements
> org.keycloak.adapters.KeycloakConfigResolver.
>
>
> Regards,
> Satya.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150831/5e698120/attachment-0001.html 

From stian at redhat.com  Mon Aug 31 04:30:34 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 31 Aug 2015 04:30:34 -0400 (EDT)
Subject: [keycloak-dev] Where to store data for the SSO session?
In-Reply-To: <DB3PR05MB378C055E2A87A2806F00656FC6E0@DB3PR05MB378.eurprd05.prod.outlook.com>
References: <DB3PR05MB378C055E2A87A2806F00656FC6E0@DB3PR05MB378.eurprd05.prod.outlook.com>
Message-ID: <1889876385.21906051.1441009834527.JavaMail.zimbra@redhat.com>

KeycloakSession is not a users session it's created/closed per-request to the server.

We recently added an Authentication SPI in 1.4 and in 1.5 we're including a way to define custom flows. This may be better suited to your needs than the User Federation SPI.

With regards to the user session there's a user session provider that's responsible for that, and you can add attributes to the user session. You can get the user session provider from KeycloakSession.sessions(). How you get the user-session or the user session id depends on where exactly you want to obtain it.

----- Original Message -----
> From: "Hermann Hill" <hermann.hill at optile.net>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 28 August, 2015 5:59:59 PM
> Subject: [keycloak-dev] Where to store data for the SSO session?
> 
> 
> 
> Hi,
> 
> 
> 
> I?m currently working on attaching an internal authentication API to Keycloak
> by implementing an UserFederationProvider.
> 
> 
> 
> Basically it is working, but I?m wondering where I?m supposed to store
> additional data that should be tied to the lifetime of the SSO session of an
> user. The KeycloakSession object seems to be recreated on every access to
> the server and I got lost in its subobjects without finding something
> usable.
> 
> 
> 
> Is there any documentation on the recommended way to do that? If not, could
> somebody please be so kind and point me in the right direction?
> 
> 
> 
> Best regards,
> 
> 
> 
> Hermann Josef Hill
> Software Architect
> 
> optile GmbH
> Ganghoferstra?e 39 | 80339 M?nchen
> Mobil +49 (151) 5385 0784
> 
> hermann.hill at optile.net | www.optile.net
> 
> USt.Id.-Nr. DE268847980
> Gesch?ftsf?hrer: Daniel Smeds
> Handelsregister M?nchen HRB 183178
> 
> +++ Besuchen Sie uns auf der dmexco 2015 am 16. & 17. September, K?ln, Halle
> 7.1 Stand F013 +++
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Mon Aug 31 05:37:13 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 31 Aug 2015 05:37:13 -0400 (EDT)
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D70BC8.10108@redhat.com>
References: <55D70BC8.10108@redhat.com>
Message-ID: <1424056350.21951921.1441013833229.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 21 August, 2015 1:30:16 PM
> Subject: [keycloak-dev] Offline tokens
> 
> Some thoughts around offline tokens impl:
> 
> - Client has switch "Allow offline tokens" . Offline token can be
> requested just if the switch is enabled
> 
> - Offline token can be requested if parameter "scope=offline" is sent.
> Offline token is sent alone, no IDToken or refreshToken is sent together
> with it.
> Question: Should be offline tokens available just for
> ResourceOwnerPasswordCredentials and ServiceAccounts or also for classic
> web based authorization code flow?

An offline token is just a refresh token, but without any expiration. For an offline token the response should be exactly the same as a non-offline token, except the refresh token has no expiration time.

> 
> - There are methods on UserModel to track which offline tokens were
> issued for particular user. Like:
> 
> List<String> getOfflineTokens();
> void addOfflineToken(String offlineToken);
> void removeOfflineToken(String offlineToken);
> 
> - Offline token will never expire. Or should we eventually add another
> timeout for offline token (With some big default value like 1 month or so)?

Shouldn't expire, it's a permanent access until manually revoked

> 
> - Offline token is not refreshable.

Not sure what you mean, but a offline token is a refresh token without expiration. An offline token should never be sent to a service, instead it should be used to obtain an access token.

> 
> - Offline token can be validated by current OIDC endpoint for token
> validation. Offline token is not valid if UserModel doesn't have token
> anymore on it. But offline token is still valid even if corresponding
> UserSession doesn't exist. So we can still have offline tokens valid for
> 1 year even if SsoSessionMaxLifespan is just 10 hours.

OIDC endpoint for token validation validates an access token, not the refresh token. So I don't think it should be possible to validate it.

> 
> - Offline token can be logged out. Logout will remove offline token from
> corresponding UserModel.

Not sure what this means - an offline token can be revoked by a user. There's no log out as such.

> 
> - In Account management applications page can user see list of offline
> tokens issued for individual clients and he can revoke them. Not sure if
> put another "Revoke offline token" or use current "Revoke grant" action,
> which will revoke both consents and offline tokens?

Each application should have a list of what access it has. Where offline access is one of the "permissions" the app has. Each application should have a single button "Revoke application access", which removes grants as well as invalidates all offline tokens.

> 
> - Admin can see the offline tokens for user in admin console and can
> revoke them too . Current button "Logout All" in sessions tab will
> revoke offline tokens from all users . For performance reasons, we may
> need method on UserProvider, so it's possible to clean whole DB table
> "OFFLINE_TOKEN" (similarly for mongo) instead of iterating through all
> users.

"Logout All" in sessions tabs should not revoke offline tokens.

> 
> - For adapters, we should likely have an option, so the REST endpoint
> adapter has possibility to validate offline token by always sending
> validation request to KC server. We didn't need it for access tokens,
> which are valid just for 1 minute or so, but offline tokens are long
> lived so adapter should have this possibility IMO.

Again, offline tokens should not be sent to services. Instead they should send access tokens that are obtained from an offline token.

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

From stian at redhat.com  Mon Aug 31 05:38:15 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 31 Aug 2015 05:38:15 -0400 (EDT)
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D714FB.5000506@redhat.com>
References: <55D70BC8.10108@redhat.com> <55D714FB.5000506@redhat.com>
Message-ID: <2063281707.21952247.1441013895062.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 21 August, 2015 2:09:31 PM
> Subject: Re: [keycloak-dev] Offline tokens
> 
> On 21/08/15 13:30, Marek Posolda wrote:
> > Some thoughts around offline tokens impl:
> >
> > - Client has switch "Allow offline tokens" . Offline token can be
> > requested just if the switch is enabled
> >
> > - Offline token can be requested if parameter "scope=offline" is sent.
> > Offline token is sent alone, no IDToken or refreshToken is sent together
> > with it.
> > Question: Should be offline tokens available just for
> > ResourceOwnerPasswordCredentials and ServiceAccounts or also for classic
> > web based authorization code flow?
> >
> > - There are methods on UserModel to track which offline tokens were
> > issued for particular user. Like:
> >
> > List<String> getOfflineTokens();
> > void addOfflineToken(String offlineToken);
> > void removeOfflineToken(String offlineToken);
> >
> > - Offline token will never expire. Or should we eventually add another
> > timeout for offline token (With some big default value like 1 month or so)?
> >
> > - Offline token is not refreshable.
> >
> > - Offline token can be validated by current OIDC endpoint for token
> > validation. Offline token is not valid if UserModel doesn't have token
> > anymore on it. But offline token is still valid even if corresponding
> > UserSession doesn't exist. So we can still have offline tokens valid for
> > 1 year even if SsoSessionMaxLifespan is just 10 hours.
> >
> > - Offline token can be logged out. Logout will remove offline token from
> > corresponding UserModel.
> >
> > - In Account management applications page can user see list of offline
> > tokens issued for individual clients and he can revoke them. Not sure if
> > put another "Revoke offline token" or use current "Revoke grant" action,
> > which will revoke both consents and offline tokens?
> >
> > - Admin can see the offline tokens for user in admin console and can
> > revoke them too . Current button "Logout All" in sessions tab will
> > revoke offline tokens from all users . For performance reasons, we may
> > need method on UserProvider, so it's possible to clean whole DB table
> > "OFFLINE_TOKEN" (similarly for mongo) instead of iterating through all
> > users.
> >
> > - For adapters, we should likely have an option, so the REST endpoint
> > adapter has possibility to validate offline token by always sending
> > validation request to KC server. We didn't need it for access tokens,
> > which are valid just for 1 minute or so, but offline tokens are long
> > lived so adapter should have this possibility IMO.
> - Actually, for the frontend adapters (both server and keycloak.js ) I
> am thinking about adding the persistent cookie, which will be put on the
> application after successful login and is valid for the same time like
> the offline token (so couple of months). When browser is opened next
> time, the adapter will find the cookie and send the validation request
> to KC to check if offline token is still valid. This will allow the
> browser application to be logged with the same offline token for couple
> of months.
> 
> I also wonder if we should put the IP address checking when validating
> offline token (Offline token is valid just if validation request come
> from same address like the original request) ?


JS adapters shouldn't use offline tokens. Offline tokens are to give servers permanent offline access to a users account. Only confidential clients should be able to use this.

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

From stian at redhat.com  Mon Aug 31 07:06:15 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 31 Aug 2015 07:06:15 -0400 (EDT)
Subject: [keycloak-dev] refactored admin reset email and required actions
In-Reply-To: <55D7D10C.6030401@redhat.com>
References: <55D7D10C.6030401@redhat.com>
Message-ID: <1838995732.21980975.1441019175370.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, 22 August, 2015 3:31:56 AM
> Subject: [keycloak-dev] refactored admin reset email and required actions
> 
> Admin console can send a reset password email to the user.  Originally
> it just executed update password.  I changed this so that it sets an
> Update Password required action on the User.  The email link click runs
> all required actions set for the user, then displays a message that the
> Account has been updated.

The admin console could do either - set a password (and choose if it was temporary or not) as well as send a reset password link

> 
> When I get back, I'm also going to change the admin console behavior and
> look too.  Instead of a "Reset Password Email" button on Credentials
> tab, there will be a button next to the Required Actions selection box
> on user detail, something like "Email Required Actions"  (I need a
> better name).  Clicking on this button will send an email to user

This isn't the correct approach IMO. What we used to have was the ability for an admin to send an email to a user to allow the user to recover the password. It wasn't a required action, just something the user could do if they needed to. I think how it worked before was much clearer to end users, also credentials tab is the correct place for "recovering password".

> 
> "Your adminstrator has requested that you update and/or reset some of
> your account settings.  Please click the link below to perform these
> actions."
> 
> We do it this way because there may be multiple credentials the admin
> wants the user to reset.  These credentials may be custom authenticators.
> 
> Also I refactored the CONFIG_TOTP, UPDATE_PROFILE, and UPDATE_PASSWORD
> required actions.  They are now fully encapsulated under the required
> actions SPI and are not hardcoded with any special cases.  I still need
> to refactor verify email.  Ran out of time.
> 
> Finally, I need to add a check to user-initiated Reset Credentials.  I
> haven't put back in the cookie check to make sure not to log in the user
> if its not the same browser.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Mon Aug 31 09:06:48 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 31 Aug 2015 15:06:48 +0200
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D71E9E.5020803@redhat.com>
References: <55D70BC8.10108@redhat.com> <55D714FB.5000506@redhat.com>
	<55D71E9E.5020803@redhat.com>
Message-ID: <55E45168.806@redhat.com>

Actually KEYCLOAK_IDENTITY cookie is persistent just for the configured 
idle timeout (like 30 minutes). But for the offline token, I imagine we 
want to support the scenario when user authenticates to his application 
after a week of inactivity or so.

Here I meant the cookie will be on the application side, not on the KC 
side. When user opens his browser and goes to 
http://localhost:8080/customer-portal , the application (adapter) side 
will read the offline token from the persistent cookie and then login 
user based on that.

Marek


On 21/08/15 14:50, Bill Burke wrote:
>
> On 8/21/2015 8:09 AM, Marek Posolda wrote:
>> - Actually, for the frontend adapters (both server and keycloak.js ) I
>> am thinking about adding the persistent cookie, which will be put on the
>> application after successful login and is valid for the same time like
>> the offline token (so couple of months). When browser is opened next
>> time, the adapter will find the cookie and send the validation request
>> to KC to check if offline token is still valid. This will allow the
>> browser application to be logged with the same offline token for couple
>> of months.
>>
> I don't understand why you need an offline token for browser
> applications.  We already support persistent cookies.
>


From stian at redhat.com  Mon Aug 31 09:17:26 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 31 Aug 2015 09:17:26 -0400 (EDT)
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55E45168.806@redhat.com>
References: <55D70BC8.10108@redhat.com> <55D714FB.5000506@redhat.com>
	<55D71E9E.5020803@redhat.com> <55E45168.806@redhat.com>
Message-ID: <1176695833.22055128.1441027046720.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, 31 August, 2015 3:06:48 PM
> Subject: Re: [keycloak-dev] Offline tokens
> 
> Actually KEYCLOAK_IDENTITY cookie is persistent just for the configured
> idle timeout (like 30 minutes). But for the offline token, I imagine we
> want to support the scenario when user authenticates to his application
> after a week of inactivity or so.

You sure - is it not the SSO max lifespan?

> 
> Here I meant the cookie will be on the application side, not on the KC
> side. When user opens his browser and goes to
> http://localhost:8080/customer-portal , the application (adapter) side
> will read the offline token from the persistent cookie and then login
> user based on that.

The offline token is for a background process or server, so there shouldn't be a persistent cookie. A example flow for a backup application could be:

1. User logs in to backup application
2. App redirects to KC login with scope=offline
3. Backup application stores the offline token in a database
4. Users logs out of KC SSO
5. Backup application now wants to execute a backup, it will then retrieve the offline token from the database, send it to Keycloak to obtain an access token, then invoke the data service
6. Users opens backup application again and clicks login
7. User is again presented with login screen (as the user isn't logged-in, even though the backup application has offline access)
8. User is now logged-in to backup application and can change settings

> 
> Marek
> 
> 
> On 21/08/15 14:50, Bill Burke wrote:
> >
> > On 8/21/2015 8:09 AM, Marek Posolda wrote:
> >> - Actually, for the frontend adapters (both server and keycloak.js ) I
> >> am thinking about adding the persistent cookie, which will be put on the
> >> application after successful login and is valid for the same time like
> >> the offline token (so couple of months). When browser is opened next
> >> time, the adapter will find the cookie and send the validation request
> >> to KC to check if offline token is still valid. This will allow the
> >> browser application to be logged with the same offline token for couple
> >> of months.
> >>
> > I don't understand why you need an offline token for browser
> > applications.  We already support persistent cookies.
> >
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From hermann.hill at optile.net  Mon Aug 31 09:22:22 2015
From: hermann.hill at optile.net (Hermann Hill)
Date: Mon, 31 Aug 2015 13:22:22 +0000
Subject: [keycloak-dev] Where to store data for the SSO session?
In-Reply-To: <1889876385.21906051.1441009834527.JavaMail.zimbra@redhat.com>
References: <DB3PR05MB378C055E2A87A2806F00656FC6E0@DB3PR05MB378.eurprd05.prod.outlook.com>
	<1889876385.21906051.1441009834527.JavaMail.zimbra@redhat.com>
Message-ID: <DB3PR05MB378C32ADC53F816EAE0E92BFC6B0@DB3PR05MB378.eurprd05.prod.outlook.com>

Hi Stian,

> KeycloakSession is not a users session it's created/closed per-request to the
> server.

exactly what I was thinking about KeycloakSession, good thing to have it confirmed.

> We recently added an Authentication SPI in 1.4 and in 1.5 we're including a
> way to define custom flows. This may be better suited to your needs than
> the User Federation SPI.

I don't think I need anything special here - just the normal username/password authentication with our authentication API as the source of users and passwords.

What I do at the moment:
- in getUserByUsername I check the username with our API - if it exists, I will either get the related Keycloak user or create it (if it doesn't exist yet).
- in validCredentials I authenticate the username/password with our API
  From the authentication call I get back some additional data that is valid for the SSO session of the user.
- in validateAndProxy I wrap the UserModel object 
  The wrapper will show the additional data as transient attributes to the outside (they should not be stored to DB!).

For my test implementation I use some static cache to handle the additional data, but I don't think this is good for production. :)

So I would probably need to access the session from validCredentials and validateAndProxy...

Best regards,

Hermann Josef Hill 
Software Architect

optile GmbH
Ganghoferstra?e 39 | 80339 M?nchen
Mobil +49 (151) 5385 0784

hermann.hill at optile.net | www.optile.net

USt.Id.-Nr. DE268847980
Gesch?ftsf?hrer: Daniel Smeds
Handelsregister M?nchen HRB 183178

+++ Besuchen Sie uns auf der dmexco 2015 am 16. & 17. September, K?ln, Halle 7.1 Stand F013 +++

> -----Urspr?ngliche Nachricht-----
> Von: Stian Thorgersen [mailto:stian at redhat.com]
> Gesendet: Montag, 31. August 2015 10:31
> An: Hermann Hill <hermann.hill at optile.net>
> Cc: keycloak-dev at lists.jboss.org
> Betreff: Re: [keycloak-dev] Where to store data for the SSO session?
> 
> KeycloakSession is not a users session it's created/closed per-request to the
> server.
> 
> We recently added an Authentication SPI in 1.4 and in 1.5 we're including a
> way to define custom flows. This may be better suited to your needs than
> the User Federation SPI.
> 
> With regards to the user session there's a user session provider that's
> responsible for that, and you can add attributes to the user session. You can
> get the user session provider from KeycloakSession.sessions(). How you get
> the user-session or the user session id depends on where exactly you want
> to obtain it.
> 
> ----- Original Message -----
> > From: "Hermann Hill" <hermann.hill at optile.net>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, 28 August, 2015 5:59:59 PM
> > Subject: [keycloak-dev] Where to store data for the SSO session?
> >
> >
> >
> > Hi,
> >
> >
> >
> > I?m currently working on attaching an internal authentication API to
> > Keycloak by implementing an UserFederationProvider.
> >
> >
> >
> > Basically it is working, but I?m wondering where I?m supposed to store
> > additional data that should be tied to the lifetime of the SSO session
> > of an user. The KeycloakSession object seems to be recreated on every
> > access to the server and I got lost in its subobjects without finding
> > something usable.
> >
> >
> >
> > Is there any documentation on the recommended way to do that? If not,
> > could somebody please be so kind and point me in the right direction?
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Hermann Josef Hill
> > Software Architect
> >
> > optile GmbH
> > Ganghoferstra?e 39 | 80339 M?nchen
> > Mobil +49 (151) 5385 0784
> >
> > hermann.hill at optile.net | www.optile.net
> >
> > USt.Id.-Nr. DE268847980
> > Gesch?ftsf?hrer: Daniel Smeds
> > Handelsregister M?nchen HRB 183178
> >
> > +++ Besuchen Sie uns auf der dmexco 2015 am 16. & 17. September, K?ln,
> > +++ Halle
> > 7.1 Stand F013 +++
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Mon Aug 31 09:34:28 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 31 Aug 2015 15:34:28 +0200
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <1176695833.22055128.1441027046720.JavaMail.zimbra@redhat.com>
References: <55D70BC8.10108@redhat.com> <55D714FB.5000506@redhat.com>
	<55D71E9E.5020803@redhat.com> <55E45168.806@redhat.com>
	<1176695833.22055128.1441027046720.JavaMail.zimbra@redhat.com>
Message-ID: <55E457E4.7040405@redhat.com>

On 31/08/15 15:17, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Monday, 31 August, 2015 3:06:48 PM
>> Subject: Re: [keycloak-dev] Offline tokens
>>
>> Actually KEYCLOAK_IDENTITY cookie is persistent just for the configured
>> idle timeout (like 30 minutes). But for the offline token, I imagine we
>> want to support the scenario when user authenticates to his application
>> after a week of inactivity or so.
> You sure - is it not the SSO max lifespan?
You're right. I failed to read the code, 1st day after pto ;-)
>
>> Here I meant the cookie will be on the application side, not on the KC
>> side. When user opens his browser and goes to
>> http://localhost:8080/customer-portal , the application (adapter) side
>> will read the offline token from the persistent cookie and then login
>> user based on that.
> The offline token is for a background process or server, so there shouldn't be a persistent cookie. A example flow for a backup application could be:
>
> 1. User logs in to backup application
> 2. App redirects to KC login with scope=offline
> 3. Backup application stores the offline token in a database
> 4. Users logs out of KC SSO
> 5. Backup application now wants to execute a backup, it will then retrieve the offline token from the database, send it to Keycloak to obtain an access token, then invoke the data service
> 6. Users opens backup application again and clicks login
> 7. User is again presented with login screen (as the user isn't logged-in, even though the backup application has offline access)
> 8. User is now logged-in to backup application and can change settings
Ah, ok. So SSO logout won't automatically invalidate offline token. User 
would need to do it in account management.

Marek
>
>> Marek
>>
>>
>> On 21/08/15 14:50, Bill Burke wrote:
>>> On 8/21/2015 8:09 AM, Marek Posolda wrote:
>>>> - Actually, for the frontend adapters (both server and keycloak.js ) I
>>>> am thinking about adding the persistent cookie, which will be put on the
>>>> application after successful login and is valid for the same time like
>>>> the offline token (so couple of months). When browser is opened next
>>>> time, the adapter will find the cookie and send the validation request
>>>> to KC to check if offline token is still valid. This will allow the
>>>> browser application to be logged with the same offline token for couple
>>>> of months.
>>>>
>>> I don't understand why you need an offline token for browser
>>> applications.  We already support persistent cookies.
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From hermann.hill at optile.net  Mon Aug 31 09:42:11 2015
From: hermann.hill at optile.net (Hermann Hill)
Date: Mon, 31 Aug 2015 13:42:11 +0000
Subject: [keycloak-dev] Issue with multi tenancy
In-Reply-To: <CA+oCsRr2v6zcLVosN=RypZF3gYy4HMzSJs_sGH53NpaADoLGUQ@mail.gmail.com>
References: <CA+oCsRq-3GWJtC=23q18jYDVuv0KX9_e8mxKCZB44BzwNMWbOw@mail.gmail.com>
	<CA+oCsRr2v6zcLVosN=RypZF3gYy4HMzSJs_sGH53NpaADoLGUQ@mail.gmail.com>
Message-ID: <DB3PR05MB37815E9A9BBB88788817044FC6B0@DB3PR05MB378.eurprd05.prod.outlook.com>

Hi Satya,

without being able to look more deeply into your set-up: it sounds like a typical class-loading problem. The class and the interface seem to be present twice: one time inside your deployment, one time outside. Those classes are different for the JVM, so any PathBasedKeycloakConfigResolver in your deployment does not implement the ?outside? interface KeycloakConfigResolver ? and that?s why it fails.

Can you use <scope>provided</scope> with your Maven dependency? This way the library would probably not be in the deployment assembly and not be a problem.

Best regards,

Hermann Josef Hill
Software Architect

optile GmbH
Ganghoferstra?e 39 | 80339 M?nchen
Mobil +49 (151) 5385 0784

hermann.hill at optile.net | www.optile.net

USt.Id.-Nr. DE268847980
Gesch?ftsf?hrer: Daniel Smeds
Handelsregister M?nchen HRB 183178

+++ Besuchen Sie uns auf der dmexco 2015 am 16. & 17. September, K?ln, Halle 7.1 Stand F013 +++

Von: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] Im Auftrag von Satyajit Das
Gesendet: Montag, 31. August 2015 06:17
An: keycloak-user at lists.jboss.org
Cc: keycloak-dev at lists.jboss.org
Betreff: Re: [keycloak-dev] Issue with multi tenancy

HI Team,

Did any one get a chance to look at the issue.

Kindly look into it.

Looking forward to your positive response.

Regards,
Satya

On Fri, Aug 28, 2015 at 8:31 PM, Satyajit Das <satyajit.das at spire2grow.com<mailto:satyajit.das at spire2grow.com>> wrote:
Hi Team,

I have configured PathBasedKeycloakConfigResolver in my package: com.demo.util.

The context param has been set on web.xml
<context-param>
        <param-name>keycloak.config.resolver</param-name>
        <param-value>org.keycloak.example.PathBasedKeycloakConfigResolver</param-value>
    </context-param>

I deployed the application on Tomcat. I have registered the context.xml in meta-inf with the required adapter.

Tomcat lib directory has all the required keycloak jar files.

But PathBasedKeycloakConfigResolver never gets called on any request to the url.
One strange thing i find that in eclipse if I remove the maven dependency from deployment assembly(right click on project-> properties->deployment assembly) it works But if i put it back it fails. Maven dependency is a must.

After debugging   String configResolverClass = context.getServletContext().getInitParameter("keycloak.config.resolver"); of AbstractKeycloakAuthenticatorValve class

Got the following error: when PathBasedKeycloakConfigResolver  is being instantiated.

java.lang.ClassCastException: org.keycloak.example.PathBasedKeycloakConfigResolver cannot be cast to org.keycloak.adapters.KeycloakConfigResolver

But PathBasedKeycloakConfigResolver implements org.keycloak.adapters.KeycloakConfigResolver.


Regards,
Satya.

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

From bburke at redhat.com  Mon Aug 31 10:09:54 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 31 Aug 2015 10:09:54 -0400
Subject: [keycloak-dev] refactored admin reset email and required actions
In-Reply-To: <1838995732.21980975.1441019175370.JavaMail.zimbra@redhat.com>
References: <55D7D10C.6030401@redhat.com>
	<1838995732.21980975.1441019175370.JavaMail.zimbra@redhat.com>
Message-ID: <55E46032.3040101@redhat.com>



On 8/31/2015 7:06 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Saturday, 22 August, 2015 3:31:56 AM
>> Subject: [keycloak-dev] refactored admin reset email and required actions
>>
>> Admin console can send a reset password email to the user.  Originally
>> it just executed update password.  I changed this so that it sets an
>> Update Password required action on the User.  The email link click runs
>> all required actions set for the user, then displays a message that the
>> Account has been updated.
>
> The admin console could do either - set a password (and choose if it was temporary or not) as well as send a reset password link
>

Admin console can still manually set the password (temporary or not).


>>
>> When I get back, I'm also going to change the admin console behavior and
>> look too.  Instead of a "Reset Password Email" button on Credentials
>> tab, there will be a button next to the Required Actions selection box
>> on user detail, something like "Email Required Actions"  (I need a
>> better name).  Clicking on this button will send an email to user
>
> This isn't the correct approach IMO. What we used to have was the ability for an admin to send an email to a user to allow the user to recover the password. It wasn't a required action, just something the user could do if they needed to. I think how it worked before was much clearer to end users, also credentials tab is the correct place for "recovering password".
>


I'll repeat myself.  There may be more than one credential the 
admin/user needs/wants to reset.  These credentials may also be custom 
ones written by an system integrator.  I don't want to introduce yet 
another SPI for credential recovery when it would work exactly the same 
way as required actions.  Now, there is one place the admin can email 
the user to perform any specific action.

If you want to create a separate SPI and way of doing this to support 
reset of more than just password, feel free to create that SPI, extend 
the Model API, write the tests, update the docs and create new examples 
and make sure the flow is configurable. I think this approach is fine.


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

From mposolda at redhat.com  Mon Aug 31 11:23:03 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 31 Aug 2015 17:23:03 +0200
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D716C3.6050707@redhat.com>
References: <55D70BC8.10108@redhat.com> <55D714FB.5000506@redhat.com>
	<55D716C3.6050707@redhat.com>
Message-ID: <55E47157.6050502@redhat.com>

Hi Mike,

actually we likely won't support the cookie on the adapter side in the 
end. However you can achieve the same/similar effect by enable "remember 
me" for your realm in Keycloak admin console and increase the realm 
timeouts accordingly ("max session timeout" and "idle timeout" ). In 
this case, the keycloak server cookies are persistent and you will be 
logged automatically when you open your application next time from your 
browser/phone.

Marek

On 21/08/15 14:17, Mike Cirioli wrote:
> I think this sounds like an excellent idea - my team has been getting 
> requests to saml enable mobile applications, and particularly in the 
> case of internal applications that we require OTP auth for, this 
> sounds like it would enable us to secure those apps with relatively 
> little pain for the user (OTP auth on your mobile device is a bit of a 
> PITA).  Requiring the user to only go through that process once and 
> then having the app save the offline token to be used for subsequent 
> access would be perfect.
>
> Is this use case something that makes sense in this context?
>
> thanks
> -mike cirioli
>
>
> On 8/21/15 8:09 AM, Marek Posolda wrote:
>> On 21/08/15 13:30, Marek Posolda wrote:
>>> Some thoughts around offline tokens impl:
>>>
>>> - Client has switch "Allow offline tokens" . Offline token can be
>>> requested just if the switch is enabled
>>>
>>> - Offline token can be requested if parameter "scope=offline" is sent.
>>> Offline token is sent alone, no IDToken or refreshToken is sent 
>>> together
>>> with it.
>>> Question: Should be offline tokens available just for
>>> ResourceOwnerPasswordCredentials and ServiceAccounts or also for 
>>> classic
>>> web based authorization code flow?
>>>
>>> - There are methods on UserModel to track which offline tokens were
>>> issued for particular user. Like:
>>>
>>> List<String> getOfflineTokens();
>>> void addOfflineToken(String offlineToken);
>>> void removeOfflineToken(String offlineToken);
>>>
>>> - Offline token will never expire. Or should we eventually add another
>>> timeout for offline token (With some big default value like 1 month 
>>> or so)?
>>>
>>> - Offline token is not refreshable.
>>>
>>> - Offline token can be validated by current OIDC endpoint for token
>>> validation. Offline token is not valid if UserModel doesn't have token
>>> anymore on it. But offline token is still valid even if corresponding
>>> UserSession doesn't exist. So we can still have offline tokens valid 
>>> for
>>> 1 year even if SsoSessionMaxLifespan is just 10 hours.
>>>
>>> - Offline token can be logged out. Logout will remove offline token 
>>> from
>>> corresponding UserModel.
>>>
>>> - In Account management applications page can user see list of offline
>>> tokens issued for individual clients and he can revoke them. Not 
>>> sure if
>>> put another "Revoke offline token" or use current "Revoke grant" 
>>> action,
>>> which will revoke both consents and offline tokens?
>>>
>>> - Admin can see the offline tokens for user in admin console and can
>>> revoke them too . Current button "Logout All" in sessions tab will
>>> revoke offline tokens from all users . For performance reasons, we may
>>> need method on UserProvider, so it's possible to clean whole DB table
>>> "OFFLINE_TOKEN" (similarly for mongo) instead of iterating through all
>>> users.
>>>
>>> - For adapters, we should likely have an option, so the REST endpoint
>>> adapter has possibility to validate offline token by always sending
>>> validation request to KC server. We didn't need it for access tokens,
>>> which are valid just for 1 minute or so, but offline tokens are long
>>> lived so adapter should have this possibility IMO.
>> - Actually, for the frontend adapters (both server and keycloak.js ) I
>> am thinking about adding the persistent cookie, which will be put on the
>> application after successful login and is valid for the same time like
>> the offline token (so couple of months). When browser is opened next
>> time, the adapter will find the cookie and send the validation request
>> to KC to check if offline token is still valid. This will allow the
>> browser application to be logged with the same offline token for couple
>> of months.
>>
>> I also wonder if we should put the IP address checking when validating
>> offline token (Offline token is valid just if validation request come
>> from same address like the original request) ?
>>
>> Mare
>>>
>>> WDYT?
>>>
>>> Marek
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From mposolda at redhat.com  Mon Aug 31 11:37:53 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 31 Aug 2015 17:37:53 +0200
Subject: [keycloak-dev] Offline tokens
In-Reply-To: <55D7194E.5070605@kroehling.de>
References: <55D70BC8.10108@redhat.com> <55D7194E.5070605@kroehling.de>
Message-ID: <55E474D1.5050409@redhat.com>

Hi Juca,

On 21/08/15 14:27, Juraci Paix?o Kr?hling wrote:
> Marek,
>
> On 08/21/2015 01:30 PM, Marek Posolda wrote:
>> - Offline token can be requested if parameter "scope=offline" is sent.
>> Offline token is sent alone, no IDToken or refreshToken is sent together
>> with it.
>> Question: Should be offline tokens available just for
>> ResourceOwnerPasswordCredentials and ServiceAccounts or also for classic
>> web based authorization code flow?
> Not quite sure what ResourceOwnerPasswordCredentials is (is it something
> new?),
It's just different name for "Direct access grant" which you are already 
aware I guess :-)

See docs 
http://keycloak.github.io/docs/userguide/html/direct-access-grants.html 
. Actually "Resource owner password credentials" is the term used by 
OAuth2 specs, but we used the term "Direct access grant" for some reason...

> but I think that having the possibility of requesting an offline
> token based on a bearer token is desirable. In my case, I intend to have
> a "token exchange proxy", where the end user would create API keys for
> the agent. This API key is an UUID, that relates to a token that I'd
> store in Hawkular's backend. Whenever I get this token, I retrieve the
> offline token and use it for backend operations, as if the user were online.
>
> This means: I don't intend to have access to the user's password at any
> point when creating or sending offline tokens.
Actually it will likely work in a way, that offline token is "special" 
refresh token, which will never expire. So when you login with the user, 
you will receive offline token instead of classic refresh token. You can 
then store this offline token itself in your DB and use it later (next 
day or so) to obtain access token, which would then be possible to use 
against REST services.

So the condition "I don't intend to have access to the user's password 
at any point when creating or sending offline tokens." will be met.

Marek
>
>> - Offline token will never expire. Or should we eventually add another
>> timeout for offline token (With some big default value like 1 month or so)?
> It should never expire. Or at most, there should be a setting for the
> realm/client that would allow the offline token to never expire. It can,
> however, be revoked.
>
>> - Offline token can be validated by current OIDC endpoint for token
>> validation. Offline token is not valid if UserModel doesn't have token
>> anymore on it. But offline token is still valid even if corresponding
>> UserSession doesn't exist. So we can still have offline tokens valid for
>> 1 year even if SsoSessionMaxLifespan is just 10 hours.
> +1
>
>> - Offline token can be logged out. Logout will remove offline token from
>> corresponding UserModel.
> I guess this is the revoked part I mentioned above, right?
>
>> - In Account management applications page can user see list of offline
>> tokens issued for individual clients and he can revoke them. Not sure if
>> put another "Revoke offline token" or use current "Revoke grant" action,
>> which will revoke both consents and offline tokens?
> Not sure what would be the difference there. The consent is linked to
> the client, while the offline token would be a session, right? If so,
> I'd revoke only the token itself.
>
>> - Admin can see the offline tokens for user in admin console and can
>> revoke them too . Current button "Logout All" in sessions tab will
>> revoke offline tokens from all users . For performance reasons, we may
>> need method on UserProvider, so it's possible to clean whole DB table
>> "OFFLINE_TOKEN" (similarly for mongo) instead of iterating through all
>> users.
> +1
>
>> - For adapters, we should likely have an option, so the REST endpoint
>> adapter has possibility to validate offline token by always sending
>> validation request to KC server. We didn't need it for access tokens,
>> which are valid just for 1 minute or so, but offline tokens are long
>> lived so adapter should have this possibility IMO.
> +1
>
> - Juca.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev